參考：https://docs.ceph.com/en/pacific/rados/operations/health-checks/
概述
Ceph 集群可以發出一組有限的可能的健康消息——這些消息被定義為具有唯一標識符的健康檢查。
標識符是一個簡潔的偽人類可讀（即像變量名）字符串。它旨在使工具（例如 UI）能夠理解健康檢查，並以反映其含義的方式呈現它們。
此頁面列出了監視器和管理器守護程序引發的健康檢查。除了這些之外，您還可能會看到源自 MDS 守護進程的健康檢查（請參閱CephFS 健康消息），以及由 ceph-mgr python 模塊定義的健康檢查。
定義
MON
- DAEMON_OLD_VERSION
如果舊版本的 Ceph 正在任何守護進程上運行，則發出警告。如果檢測到多個版本，它將生成健康錯誤。此條件必須存在超過 mon_warn_older_version_delay（默認設置為 1 周）才能觸發健康狀況。這允許大多數升級繼續進行而不會錯誤地看到警告。如果升級暫停很長一段時間，可以使用健康靜音，如“ceph health mute DAEMON_OLD_VERSION –sticky”。在這種情況下，升級完成后使用“ceph health unmute DAEMON_OLD_VERSION”。
- MON_DOWN
一個或多個監視器守護程序當前已關閉。集群需要大多數（超過 1/2）的監視器才能運行。當一個或多個監視器關閉時，客戶端可能很難建立與集群的初始連接，因為他們可能需要嘗試更多地址才能到達正在運行的監視器。
通常應盡快重新啟動停機監視器守護程序，以降低后續監視器故障導致服務中斷的風險。
- MON_CLOCK_SKEW
運行 ceph-mon 監視器守護進程的主機上的時鍾沒有充分同步。如果集群檢測到時鍾偏差大於mon_clock_drift_allowed.
這最好通過使用類似 ntpd 或 chrony 的工具同步時鍾來解決。
如果保持時鍾緊密同步不切實際， mon_clock_drift_allowed也可以增加閾值，但該值必須保持在顯着低於 mon_lease 間隔才能使監視器集群正常運行。
- MON_MSGR2_NOT_ENABLED
該ms_bind_msgr2選項已啟用，但一個或多個監視器未配置為綁定到集群的 monmap 中的 v2 端口。這意味着特定於 msgr2 協議的功能（例如，加密）在某些或所有連接上不可用。
在大多數情況下，這可以通過發出以下命令來糾正：
ceph mon enable-msgr2
該命令將更改為舊默認端口 6789 配置的任何監視器，以繼續偵聽 6789 上的 v1 連接，並在新的默認 3300 端口上偵聽 v2 連接。
如果監視器配置為在非標准端口（不是 6789）上偵聽 v1 連接，則需要手動修改 monmap。
- MON_DISK_LOW
一台或多台監視器的磁盤空間不足。如果存儲監控數據庫的文件系統上的可用空間（通常為 /var/lib/ceph/mon）低於百分比 mon_data_avail_warn（默認值：30%） ，則會觸發此警報。
這可能表明系統上的某些其他進程或用戶正在填充監視器使用的同一文件系統。它也可能表明監視器數據庫很大（見MON_DISK_BIG 下文）。
如果無法釋放空間，則可能需要將監視器的數據目錄移動到另一個存儲設備或文件系統（必須當監視器守護程序沒有運行時操作）。
- MON_DISK_CRIT
一個或多個監視器的磁盤空間嚴重不足。如果存儲監控數據庫的文件系統上的可用空間（通常為 /var/lib/ceph/mon）低於百分比mon_data_avail_crit（默認值：5%） ，則會觸發此警報。見MON_DISK_LOW，以上。
- MON_DISK_BIG
一個或多個監視器的數據庫大小非常大。如果監視器的數據庫大小大於 mon_data_size_warn（默認值：15 GiB），則會觸發此警報。
大型數據庫不常見，但不一定表示存在問題。當有active+clean長時間未達到狀態的歸置組時，監控數據庫的大小可能會增長。
這也可能表明監視器的數據庫沒有正確壓縮，在一些舊版本的 leveldb 和 Rocksdb 中已經觀察到了這種情況。ceph daemon mon.
此警告還可能表明監視器存在阻止其修剪其存儲的集群元數據的錯誤。如果問題仍然存在，請報告錯誤。
可以通過以下方式調整警告閾值：
ceph config set global mon_data_size_warn <size>
- AUTH_INSECURE_GLOBAL_ID_RECLAIM
一個或多個連接到集群的客戶端或守護程序在重新連接到監視器時未安全地回收其 global_id（標識集群中每個實體的唯一編號）。客戶端仍然被允許連接，因為該 auth_allow_insecure_global_id_reclaim選項設置為 true（在所有 ceph 客戶端升級之前可能是必需的），並且 auth_expose_insecure_global_id_reclaim選項設置為true（在他們第一次進行身份驗證之后，允許監視器通過強制重新連接來盡早檢測具有不安全回收的客戶端）。
您可以通過以下方式識別哪些客戶端正在使用未打補丁的 ceph 客戶端代碼：
ceph health detail
客戶端 global_id reclaim rehavior 也可以在 連接到單個監視器的客戶端轉儲中的global_id_status字段中看到（reclaim_insecure意味着客戶端未打補丁並且正在促成此健康警報）：
ceph tell mon.\* sessions
我們強烈建議將系統中的所有客戶端升級到正確回收 global_id 值的較新版本的 Ceph。更新所有客戶端后，您可以通過以下方式停止允許不安全的重新連接：
ceph config set mon auth_allow_insecure_global_id_reclaim false
如果立即升級所有客戶端不切實際，您可以使用以下命令暫時消除此警告：
ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM 1w # 1 week
雖然我們不建議這樣做，但您也可以通過以下方式無限期禁用此警告：
ceph config set mon mon_warn_on_insecure_global_id_reclaim false
- AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED
Ceph 當前配置為允許客戶端使用不安全的進程重新連接到監視器，以回收其先前的 global_id，因為該設置 auth_allow_insecure_global_id_reclaim設置為true. 當現有 Ceph 客戶端升級到正確且安全地回收其 global_id 的較新版本的 Ceph 時，可能需要啟用此設置。
如果AUTH_INSECURE_GLOBAL_ID_RECLAIM還沒有引發健康警報並且該auth_expose_insecure_global_id_reclaim設置沒有被禁用（默認情況下處於啟用狀態），那么當前沒有連接需要升級的客戶端，並且可以安全地禁止不安全的 global_id 回收：
ceph config set mon auth_allow_insecure_global_id_reclaim false
如果仍有客戶端需要升級，則可以通過以下方式暫時消除此警報：
ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w # 1 week
雖然我們不建議這樣做，但您也可以通過以下方式無限期禁用此警告：
ceph config set mon mon_warn_on_insecure_global_id_reclaim_allowed false
MGR
- MGR_DOWN
所有管理器守護程序當前都已關閉。集群通常應該至少有一個正在運行的管理器 ( ceph-mgr) 守護程序。如果沒有管理器守護程序在運行，則集群監控自身的能力將受到影響，並且部分管理 API 將變得不可用（例如，儀表板將無法工作，並且大多數報告指標或運行時狀態的 CLI 命令將被阻止）。但是，集群仍然能夠執行所有 IO 操作並從故障中恢復。
通常應該盡快重新啟動停機管理器守護程序，以確保可以監視集群（例如，以便ceph -s信息是最新的，和/或 Prometheus 可以抓取指標）。
- MGR_MODULE_DEPENDENCY
啟用的管理器模塊未通過其依賴性檢查。此運行狀況檢查應附帶來自模塊的有關問題的解釋性消息。
例如，一個模塊可能會報告未安裝所需的包：安裝所需的包並重新啟動管理器守護程序。
此運行狀況檢查僅適用於啟用的模塊。如果一個模塊沒有啟用，你可以在ceph module ls的輸出中看到它是否報告了依賴問題。
- MGR_MODULE_ERROR
管理器模塊遇到意外錯誤。通常，這意味着模塊的服務 函數引發了未處理的異常。如果異常沒有提供對自身的有用描述，那么人類可讀的錯誤描述可能會措辭模糊。
此運行狀況檢查可能表明存在錯誤：如果您認為遇到錯誤，請打開 Ceph 錯誤報告。
如果您認為錯誤是暫時的，您可以重新啟動管理器守護程序，或者在活動守護程序上使用ceph mgr fail來提示故障轉移到另一個守護程序。
OSD
- OSD_DOWN
一個或多個 OSD 被標記為 down。ceph-osd 守護進程可能已經停止，或者對等 OSD 可能無法通過網絡訪問 OSD。常見原因包括守護程序停止或崩潰、主機停機或網絡中斷。
驗證主機是否健康、守護程序已啟動以及網絡是否正常運行。如果守護程序已崩潰，則守護程序日志文件 ( /var/log/ceph/ceph-osd.*) 可能包含調試信息。
- OSD_
_DOWN
（例如 OSD_HOST_DOWN、OSD_ROOT_DOWN）
特定 CRUSH 子樹中的所有 OSD 都被標記為 down，例如主機上的所有 OSD。
- OSD_ORPHAN
在 CRUSH 地圖層次結構中引用了 OSD，但不存在。
可以通過以下方式從 CRUSH 層次結構中刪除 OSD：
ceph osd crush rm osd.<id>
- OSD_OUT_OF_ORDER_FULL
Nearfull、backfillfull、full和/或failsafe_full的利用率閾值沒有上升。特別是，我們期望 nearfull < backfillfull、backfillfull < full 和 full < failsafe_full。
可以通過以下方式調整閾值：
ceph osd set-nearfull-ratio <ratio>
ceph osd set-backfillfull-ratio <ratio>
ceph osd set-full-ratio <ratio>
- OSD_FULL
一個或多個 OSD 已超過完整閾值並阻止集群為寫入提供服務。
可以通過以下方式檢查池的利用率：
ceph df
當前定義的完整比率可以通過以下方式查看：
ceph osd dump | grep full_ratio
恢復寫入可用性的短期解決方法是將完整閾值提高少量：
ceph osd set-full-ratio <ratio>
應通過部署更多 OSD 將新存儲添加到集群中，或者應刪除現有數據以釋放空間。
- OSD_BACKFILLFULL
一個或多個 OSD 已超過backfillfull閾值，這將阻止允許數據重新平衡到此設備。這是一個早期警告，表明重新平衡可能無法完成並且集群即將滿員。
可以通過以下方式檢查池的利用率：
ceph df
- OSD_NEARFULL
一個或多個 OSD 已超過接近滿閾值。這是集群即將滿員的早期警告。
可以通過以下方式檢查池的利用率：
ceph df
- OSDMAP_FLAGS
已設置一個或多個感興趣的集群標志。這些標志包括：
full- 集群被標記為已滿，無法提供寫入服務
pauserd , pausewr - 暫停讀取或寫入
noup - 不允許啟動 OSD
nodown - 忽略 OSD 故障報告，因此監視器不會將 OSD 標記為關閉
noin - 之前標記為out的 OSD在啟動時不會被標記回in
noout - 在配置的時間間隔后，關閉的 OSD 不會自動被標記出來
nobackfill , norecover , norebalance - 恢復或數據重新平衡被暫停
noscrub , nodeep_scrub - 清理被禁用
notieragent - 緩存分層活動暫停
除了full，這些標志可以通過以下方式設置或清除：
ceph osd set <flag>
ceph osd unset <flag>
- OSD_FLAGS
一個或多個 OSD 或 CRUSH {nodes,device classes} 設置了一個感興趣的標志。這些標志包括：
noup : 這些 OSD 不允許啟動
nodown : 這些 OSD 的故障報告將被忽略
noin：如果這些 OSD 之前在失敗后被自動標記為out，則它們在啟動時不會被標記為in
noout：如果這些 OSD 關閉，它們不會 在配置的時間間隔后自動被標記out
這些標志可以通過以下方式批量設置和清除：
ceph osd set-group <flags> <who>
ceph osd unset-group <flags> <who>
例如，
ceph osd set-group noup,noout osd.0 osd.1
ceph osd unset-group noup,noout osd.0 osd.1
ceph osd set-group noup,noout host-foo
ceph osd unset-group noup,noout host-foo
ceph osd set-group noup,noout class-hdd
ceph osd unset-group noup,noout class-hdd
- OLD_CRUSH_TUNABLES
CRUSH 圖使用非常舊的設置，應該更新。在不觸發此健康警告的情況下可以使用的最舊的可調參數（即可以連接到集群的最舊的客戶端版本）由mon_crush_min_required_version配置選項確定。有關詳細信息，請參閱可調參數。
- OLD_CRUSH_STRAW_CALC_VERSION
CRUSH 圖使用一種較舊的非最佳方法來計算straw存儲桶的中間權重值。
應該更新 CRUSH 圖以使用更新的方法 ( straw_calc_version=1)。有關詳細信息，請參閱 可調參數。
- CACHE_POOL_NO_HIT_SET
一個或多個緩存池未配置命中集以跟蹤利用率，這將阻止分層代理識別冷對象以從緩存中刷新和驅逐。
命中集可以在緩存池上配置：
ceph osd pool set <poolname> hit_set_type <type>
ceph osd pool set <poolname> hit_set_period <period-in-seconds>
ceph osd pool set <poolname> hit_set_count <number-of-hitsets>
ceph osd pool set <poolname> hit_set_fpp <target-false-positive-rate>
- OSD_NO_SORTBITWISE
沒有 pre-luminous v12.y.z OSD 正在運行，但sortbitwise尚未設置標志。
該sortbitwise標志必須在 luminous v12.y.z 或更新的 OSD 可以啟動之前設置。您可以通過以下方式安全地設置標志：
ceph osd set sortbitwise
- POOL_FULL
一個或多個池已達到其配額並且不再允許寫入。
可以通過以下方式查看池配額和利用率：
ceph df detail
您可以通過以下方式提高池配額：
ceph osd pool set-quota <poolname> max_objects <num-objects>
ceph osd pool set-quota <poolname> max_bytes <num-bytes>
或刪除一些現有數據以降低利用率。
- BLUEFS_SPILLOVER
一個或多個使用 BlueStore 后端的 OSD 已被分配 db分區（元數據的存儲空間，通常在較快的設備上），但該空間已被填滿，因此元數據“溢出”到正常的慢速設備上。這不一定是錯誤情況甚至是意外情況，但如果管理員期望所有元數據都適合更快的設備，則表明沒有提供足夠的空間。
可以通過以下方式在所有 OSD 上禁用此警告：
ceph config set osd bluestore_warn_on_bluefs_spillover false
或者，可以通過以下方式在特定 OSD 上禁用它：
ceph config set osd.123 bluestore_warn_on_bluefs_spillover false
為了提供更多的元數據空間，可以銷毀和重新配置相關 OSD。這將涉及數據遷移和恢復。
也可以擴展支持 數據庫存儲的 LVM 邏輯卷。如果底層 LV 已經擴展，需要停止 OSD 守護進程，並且 BlueFS 通過以下方式通知設備大小的變化：
ceph-bluestore-tool bluefs-bdev-expand --path /var/lib/ceph/osd/ceph-$ID
- BLUEFS_AVAILABLE_SPACE
要檢查 BlueFS 有多少可用空間，請執行以下操作：
ceph daemon osd.123 bluestore bluefs available
這將輸出最多 3 個值：BDEV_DB free、BDEV_SLOW free和 available_from_bluestore。BDEV_DB和BDEV_SLOW報告 BlueFS 已獲取並被視為空閑的空間量。值available_from_bluestore 表示BlueStore 將更多空間讓給BlueFS 的能力。此值與 BlueStore 可用空間量不同是正常的，因為 BlueFS 分配單元通常大於 BlueStore 分配單元。這意味着 BlueFS 只能接受部分 BlueStore 可用空間。
- BLUEFS_LOW_SPACE
如果 BlueFS 可用空間不足，並且 available_from_bluestore 很少，則可以考慮減少 BlueFS 分配單元的大小。要在分配單元不同時模擬可用空間，請執行以下操作：
ceph daemon osd.123 bluestore bluefs available <alloc-unit-size>
- BLUESTORE_FRAGMENTATION
隨着 BlueStore 工作，底層存儲上的可用空間將變得碎片化。這是正常且不可避免的，但過多的碎片會導致速度變慢。要檢查 BlueStore 碎片，可以執行以下操作：
ceph daemon osd.123 bluestore allocator score block
分數在 [0-1] 范圍內給出。[0.0 .. 0.4] 微小碎片 [0.4 .. 0.7] 小，可接受的碎片 [0.7 .. 0.9] 相當大，但安全碎片 [0.9 .. 1.0] 嚴重碎片，可能會影響 BlueFS 從 BlueStore 獲取空間的能力。
如果需要碎片的詳細報告，請執行以下操作：
ceph daemon osd.123 bluestore allocator dump block
如果在處理沒有運行碎片的 OSD 進程時，可以使用ceph-bluestore-tool檢查。獲取碎片分數：
ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-123 --allocator block free-score
並轉儲詳細的空閑塊：
ceph-bluestore-tool --path /var/lib/ceph/osd/ceph-123 --allocator block free-dump
- BLUESTORE_LEGACY_STATFS
在 Nautilus 版本中，BlueStore 在每個池的粒度基礎上跟蹤其內部使用統計數據，並且一個或多個 OSD 具有在 Nautilus 之前創建的 BlueStore 卷。如果所有OSD 都比 Nautilus 舊，這僅意味着每個池的指標不可用。但是，如果混合使用了 pre-Nautilus 和 post-Nautilus OSD，則ceph df報告的集群使用情況統計信息將不准確。
可以通過停止每個 OSD、運行修復操作並重新啟動它來更新舊的 OSD 以使用新的使用跟蹤方案。例如，如果osd.123需要更新：
systemctl stop ceph-osd@123
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-123
systemctl start ceph-osd@123
可以通過以下方式禁用此警告：
ceph config set global bluestore_warn_on_legacy_statfs false
- BLUESTORE_NO_PER_POOL_OMAP
從 Octopus 版本開始，BlueStore 按池跟蹤 omap 空間利用率，並且一個或多個 OSD 具有在 Octopus 之前創建的卷。如果所有 OSD 都沒有在啟用新跟蹤的情況下運行 BlueStore，則集群將根據最近的 deep-scrub 報告每個池的 omap 使用情況和近似值。
可以通過停止每個 OSD、運行修復操作並重新啟動它來更新舊 OSD 以按池跟蹤。例如，如果 osd.123需要更新：
systemctl stop ceph-osd@123
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-123
systemctl start ceph-osd@123
可以通過以下方式禁用此警告：
ceph config set global bluestore_warn_on_no_per_pool_omap false
- BLUESTORE_NO_PER_PG_OMAP
從 Pacific 版本開始，BlueStore 會按 PG 跟蹤 omap 空間利用率，並且一個或多個 OSD 具有在 Pacific 之前創建的卷。Per-PG omap 可以在 PG 遷移時更快地刪除 PG。
PG 可以通過停止每個 OSD、運行修復操作並重新啟動它來更新舊 OSD 以進行跟蹤。例如，如果 osd.123需要更新：
systemctl stop ceph-osd@123
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-123
systemctl start ceph-osd@123
可以通過以下方式禁用此警告：
ceph config set global bluestore_warn_on_no_per_pg_omap false
- BLUESTORE_DISK_SIZE_MISMATCH
一個或多個使用 BlueStore 的 OSD 在物理設備的大小和跟蹤其大小的元數據之間存在內部不一致。這可能會導致 OSD 將來崩潰。
有問題的 OSD 應該被銷毀並重新配置。應注意一次只執行一個 OSD，並且不會使任何數據面臨風險。例如，如果 osd$N有錯誤，則：
ceph osd out osd.$N
while ! ceph osd safe-to-destroy osd.$N ; do sleep 1m ; done
ceph osd destroy osd.$N
ceph-volume lvm zap /path/to/device
ceph-volume lvm create --osd-id $N --data /path/to/device
- BLUESTORE_NO_COMPRESSION
一個或多個 OSD 無法加載 BlueStore 壓縮插件。這可能是由於安裝損壞，其中ceph-osd 二進制文件與壓縮插件不匹配，或者最近的升級不包括重新啟動ceph-osd守護程序。
驗證運行相關 OSD 的主機上的軟件包是否已正確安裝，並且 OSD 守護程序已重新啟動。如果問題仍然存在，請檢查 OSD 日志以獲取有關問題根源的任何線索。
- BLUESTORE_SURIOUS_READ_ERRORS
一個或多個使用 BlueStore 的 OSD 檢測主設備上的虛假讀取錯誤。BlueStore 通過重試磁盤讀取已從這些錯誤中恢復。雖然這可能會顯示底層硬件、I/O 子系統等存在一些問題。理論上這可能會導致永久性數據損壞。關於根本原因的一些觀察可以在 https://tracker.ceph.com/issues/22464 找到。
此警報不需要立即響應，但相應的主機可能需要額外注意，例如升級到最新的操作系統/內核版本和硬件資源利用率監控。
可以通過以下方式在所有 OSD 上禁用此警告：
ceph config set osd bluestore_warn_on_spurious_read_errors false
或者，可以通過以下方式在特定 OSD 上禁用它：
ceph config set osd.123 bluestore_warn_on_spurious_read_errors false
設備健康
- DEVICE_HEALTH
預計一台或多台設備將很快發生故障，其中警告閾值由mgr/devicehealth/warn_threshold 配置選項控制。
此警告僅適用於當前標記為“in”的 OSD，因此對該故障的預期響應是將設備標記為“out”，以便將數據遷移出設備，然后從系統中刪除硬件。請注意，如果mgr/devicehealth/self_heal基於mgr/devicehealth/mark_out_threshold.
可以通過以下方式檢查設備運行狀況：
ceph device info <device-id>
設備預期壽命由MGR運行的預測模型或外部工具通過以下命令設置：
ceph device set-life-expectancy <device-id> <from> <to>
您可以手動更改存儲的預期壽命，但這通常不會完成任何事情，因為最初設置的任何工具都可能會再次設置它，並且更改存儲的值不會影響硬件設備的實際運行狀況。
- DEVICE_HEALTH_IN_USE
一台或多台設備預計很快會發生故障，並已被標記為“out”基於 mgr/devicehealth/mark_out_threshold的集群，但它仍在參與另外一個 PG。這可能是因為它最近才被標記為“out”並且數據仍在遷移，或者因為某些原因無法遷移數據（例如，集群快滿了，或者 CRUSH 層次結構中沒有另一個合適的OSD 也可以遷移數據）。
可以通過禁用自我修復行為（設置mgr/devicehealth/self_heal為 false）、調整 mgr/devicehealth/mark_out_threshold或解決阻止數據從故障設備遷移的原因來消除此消息。
- DEVICE_HEALTH_TOOMANY
太多的設備預計很快就會出現故障，並且 mgr/devicehealth/self_heal啟用了該行為，這樣標記所有出現故障的設備將超過集群 mon_osd_min_in_ratio比例，從而防止太多的 OSD 被自動標記為“out”。
這通常表明您的集群中的太多設備預計很快就會發生故障，您應該采取措施在太多設備發生故障和數據丟失之前添加更新（更健康）的設備。
也可以通過調整參數（如 mon_osd_min_in_ratio或mgr/devicehealth/mark_out_threshold）來使運行狀況消息靜音，但請注意，這將增加集群中不可恢復的數據丟失的可能性。
數據健康（池和歸置組）
- PG_AVAILABILITY
數據可用性降低，這意味着集群無法為集群中某些數據的潛在讀取或寫入請求提供服務。具體來說，一個或多個 PG 處於不允許服務 IO 請求的狀態。有問題的 PG 狀態包括對等、 陳舊、不完整和缺乏活動（如果這些條件沒有迅速清除）。
有關哪些 PG 受到影響的詳細信息，請參閱：
ceph health detail
在大多數情況下，根本原因是一個或多個 OSD 當前已關閉；參見OSD_DOWN上面的討論。
可以通過以下方式查詢特定問題 PG 的狀態：
ceph tell <pgid> query
- PG_DEGRADED
某些數據的數據冗余減少了，這意味着集群沒有所需數量的所有數據（對於復制池）或糾刪碼片段（對於糾刪碼池）的副本。具體來說，一個或多個 PG：
設置了degraded或undersized標志，這意味着集群中沒有足夠的該歸置組實例；
已經有一段時間沒有設置clean的標志了。
有關哪些 PG 受到影響的詳細信息，請參閱：
ceph health detail
在大多數情況下，根本原因是一個或多個 OSD 當前已關閉；見OSD_DOWN上面的討論。
可以通過以下方式查詢特定問題 PG 的狀態：
ceph tell <pgid> query
- PG_RECOVERY_FULL
由於集群中的可用空間不足，某些數據的數據冗余可能會減少或面臨風險。具體來說，一個或多個 PG 設置了 recovery_toofull標志，這意味着集群無法遷移或恢復數據，因為一個或多個 OSD 超過了full閾值。
有關解決此情況的步驟，請參閱上面對 OSD_FULL的討論。
- PG_BACKFILL_FULL
由於集群中的可用空間不足，某些數據的數據冗余可能會減少或面臨風險。具體來說，一個或多個 PG 設置了 backfill_toofull標志，這意味着集群無法遷移或恢復數據，因為一個或多個 OSD 高於backfillfull閾值。
有關解決此問題的步驟，請參閱上面對 OSD_BACKFILLFULL的討論。
- PG_DAMAGED
數據清洗發現了集群中數據一致性的一些問題。具體來說，一個或多個 PG 具有不一致或 設置了snaptrim_error標志，表示較早的清理操作發現了問題，或者設置了修復標志，這意味着當前正在進行針對此類不一致的修復。
有關詳細信息，請參閱修復 PG 不一致。
- OSD_SCRUB_ERRORS
最近的 OSD 清理發現了不一致之處。此錯誤通常與PG_DAMAGED配對（見上文）。
有關詳細信息，請參閱修復 PG 不一致。
- OSD_TOO_MANY_REPAIRS
當發生讀取錯誤並且另一個副本可用時，它用於立即修復錯誤，以便客戶端可以獲取對象數據。Scrub 處理靜態數據的錯誤。為了識別沒有出現擦洗錯誤的可能故障磁盤，維護了讀取修復計數。如果它超過配置值閾值mon_osd_warn_num_repaired默認 10，則會生成此運行狀況警告。
- LARGE_OMAP_OBJECTS
一個或多個池包含由 osd_deep_scrub_large_omap_object_key_threshold（用於確定大型 omap 對象的鍵數的 osd_deep_scrub_large_omap_object_value_sum_threshold閾值）或（用於確定大型 omap 對象的所有鍵值的總大小（字節）的閾值）或兩者確定的大型 omap 對象。可以通過在集群日志中搜索“找到的大型 omap 對象”來找到有關對象名稱、鍵計數和大小（以字節為單位）的更多信息。大型 omap 對象可能是由未啟用自動重新分片的 RGW 存儲桶索引對象引起的。有關重新分片的更多信息，請參閱RGW 動態存儲桶索引重新分片。
可以通過以下方式調整閾值：
ceph config set osd osd_deep_scrub_large_omap_object_key_threshold <keys>
ceph config set osd osd_deep_scrub_large_omap_object_value_sum_threshold <bytes>
- CACHE_POOL_NEAR_FULL
緩存層池幾乎已滿。此上下文中的完整由緩存池上的target_max_bytes和target_max_objects屬性確定。一旦池達到目標閾值，對池的寫入請求可能會在數據被刷新並從緩存中逐出時阻塞，這種狀態通常會導致非常高的延遲和較差的性能。
緩存池目標大小可以通過以下方式調整：
ceph osd pool set <cache-pool-name> target_max_bytes <bytes>
ceph osd pool set <cache-pool-name> target_max_objects <objects>
由於基礎層的可用性或性能降低，或整體集群負載降低，正常的緩存刷新和驅逐活動也可能受到限制。
- TOO_FEW_PGS
集群中使用的 PG 數量低於mon_pg_warn_min_per_osd每個 OSD 的可配置 PG 閾值。這可能導致集群中 OSD 之間的數據分布和平衡欠佳，同樣會降低整體性能。
如果尚未創建數據池，這可能是預期的情況。
可以增加現有池的 PG 計數，也可以創建新池。有關詳細信息，請參閱選擇歸置組的數量。
- POOL_PG_NUM_NOT_POWER_OF_TWO
一個或多個池的pg_num值不是 2 的冪。盡管這並非完全不正確，但它確實會導致數據分布不平衡，因為某些 PG 的數據量大約是其他 PG 的兩倍。
pg_num這很容易通過將受影響池的值設置為附近的 2 次方來糾正：
ceph osd pool set <pool-name> pg_num <value>
可以通過以下方式禁用此健康警告：
ceph config set global mon_warn_on_pool_pg_num_not_power_of_two false
- POOL_TOO_FEW_PGS
根據當前存儲在池中的數據量，一個或多個池可能應該有更多的 PG。這可能導致集群中 OSD 之間的數據分布和平衡欠佳，同樣會降低整體性能。如果池上 pg_autoscale_mode的屬性設置為 warn，則會生成此警告。
要禁用警告，您可以完全禁用池的 PG 自動縮放：
ceph osd pool set <pool-name> pg_autoscale_mode off
要讓集群自動調整 PG 的數量，請：
ceph osd pool set <pool-name> pg_autoscale_mode on
您還可以手動將池的 PG 數量設置為推薦數量：
ceph osd pool set <pool-name> pg_num <new-pg-num>
有關詳細信息，請參閱選擇歸置組的數量和 自動縮放歸置組。
- TOO_MANY_PGS
集群中使用的 PG 數量高於mon_max_pg_per_osd每個 OSD 的可配置 PG 閾值。如果超過此閾值，集群將不允許創建新池、增加池pg_num或增加池副本（其中任何一個都會導致集群中出現更多 PG）。大量的 PG 會導致 OSD 守護進程的內存利用率更高，集群狀態更改（如 OSD 重新啟動、添加或刪除）后的對等連接速度變慢，以及 Manager 和 Monitor 守護進程的負載更高。
緩解該問題的最簡單方法是通過添加更多硬件來增加集群中 OSD 的數量。請注意，用於此運行狀況檢查的 OSD 計數是“in” OSD 的數量，因此將“out” OSD 標記為“in”（如果有）也可以提供幫助：
ceph osd in <osd id(s)>
有關詳細信息，請參閱選擇歸置組的數量。
- POOL_TOO_MANY_PGS
根據當前存儲在池中的數據量，一個或多個池可能應該有更多的 PG。這會導致 OSD 守護進程的內存利用率更高，集群狀態更改（如 OSD 重新啟動、添加或刪除）后的對等連接速度變慢，以及 Manager 和 Monitor 守護進程的負載更高。如果池上pg_autoscale_mode的屬性設置為 warn，則會生成此警告 。
要禁用警告，您可以完全禁用池的 PG 自動縮放：
ceph osd pool set <pool-name> pg_autoscale_mode off
要讓集群自動調整 PG 的數量，請：
ceph osd pool set <pool-name> pg_autoscale_mode on
您還可以手動將池的 PG 數量設置為推薦數量：
ceph osd pool set <pool-name> pg_num <new-pg-num>
有關詳細信息，請參閱選擇歸置組的數量和 自動縮放歸置組。
- POOL_TARGET_SIZE_BYTES_OVERCOMMITTED
一個或多個池具有一個target_size_bytes屬性集來估計池的預期大小，但該值超過了可用存儲總量（單獨或與其他池的實際使用情況相結合）。
這通常表明target_size_bytes池的值太大，應通過以下方式減小或設置為零：
ceph osd pool set <pool-name> target_size_bytes 0
有關更多信息，請參閱指定預期池大小。
- POOL_HAS_TARGET_SIZE_BYTES_AND_RATIO
一個或多個池具有兩者target_size_bytes並 target_size_ratio設置為估計池的預期大小。這些屬性中只有一個應該是非零的。如果兩者都設置， 則target_size_ratio優先並且target_size_bytes被忽略。
要重置target_size_bytes為零：
ceph osd pool set <pool-name> target_size_bytes 0
有關更多信息，請參閱指定預期池大小。
- TOO_FEW_OSDS
集群中的 OSD 數量低於可配置閾值osd_pool_default_size.
- SMALLER_PGP_NUM
一個或多個池的pgp_num值小於pg_num。這通常表明 PG 計數增加而沒有增加放置行為。
有時會故意這樣做，以便在調整 PG 計數時將拆分步驟與更改時所需的數據遷移分開pgp_num。
這通常通過設置pgp_num為 match來解決pg_num，觸發數據遷移，使用：
ceph osd pool set <pool> pgp_num <pg-num-value>
- MANY_OBJECTS_PER_PG
一個或多個池的每個 PG 的平均對象數明顯高於整個集群的平均值。具體閾值由mon_pg_warn_max_object_skew 配置值控制。
這通常表明包含集群中大部分數據的池的 PG 太少，和/或其他不包含那么多數據的池的 PG 太多。請參閱上面對TOO_MANY_PGS的討論 。
通過調整管理器上的mon_pg_warn_max_object_skew配置選項，可以提高閾值以使健康警告靜音。
- POOL_APP_NOT_ENABLED
存在一個包含一個或多個對象但尚未標記為供特定應用程序使用的池。
通過標記池以供應用程序使用來解決此警告。例如，如果池被 RBD 使用，則：
rbd pool init <poolname>
如果自定義應用程序“foo”正在使用該池，您還可以通過低級命令進行標記：
ceph osd pool application enable foo
有關更多信息，請參閱將池關聯到應用程序。
- POOL_FULL
一個或多個池已達到（或非常接近）其配額。觸發此錯誤條件的閾值由 mon_pool_quota_crit_threshold 配置選項控制。
池配額可以通過以下方式向上或向下調整（或刪除）：
ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>
將配額值設置為 0 將禁用配額。
ceph osd pool set-quota <pool> max_bytes 0
ceph osd pool set-quota <pool> max_objects 0
- POOL_NEAR_FULL
一個或多個池正在接近配置的充滿度閾值。
可以觸發此警告條件的一個閾值是 mon_pool_quota_warn_threshold 配置選項。
池配額可以通過以下方式向上或向下調整（或刪除）：
ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>
將配額值設置為 0 將禁用配額。
可以觸發上述兩個警告條件的其他閾值是 mon_osd_nearfull_ratio和mon_osd_full_ratio。有關詳細信息和解決方案，請訪問 存儲容量和無可用驅動器空間文檔。
- OBJECT_MISPLACED
集群中的一個或多個對象未存儲在集群希望存儲的節點上。這表明由於最近的一些集群更改而導致的數據遷移尚未完成。
錯位數據本身並不是危險情況；數據一致性永遠不會受到威脅，並且在出現所需數量的新副本（在所需位置）之前，永遠不會刪除對象的舊副本。
- OBJECT_UNFOUND
找不到集群中的一個或多個對象。具體來說，OSD 知道應該存在一個新的或更新的對象副本，但在當前在線的 OSD 上還沒有找到該對象版本的副本。
對未找到對象的讀取或寫入請求將被阻塞。
理想情況下，可以使具有未找到對象的最新副本的停機 OSD 重新聯機。候選 OSD 可以從負責未找到對象的 PG 的對等狀態中識別：
ceph tell <pgid> query
如果對象的最新副本不可用，則可以通知集群回滾到對象的先前版本。有關詳細信息，請參閱 未找到的對象。
- SLOW_OPS
一個或多個 OSD 或監視器請求需要很長時間來處理。這可能表示負載過大、存儲設備緩慢或軟件錯誤。
可以使用以下命令查詢相關守護程序的請求隊列，從守護程序的主機執行：
ceph daemon osd.<id> ops
可以通過以下方式查看最近最慢請求的摘要：
ceph daemon osd.<id> dump_historic_ops
可以通過以下方式找到 OSD 的位置：
ceph osd find osd.<id>
- PG_NOT_SCRUBBED
一個或多個 PG 最近沒有被擦洗。PG 通常會在 osd_scrub_max_interval全局指定的每個配置間隔內進行清理。這個時間間隔可以在每個池的基礎上用 scrub_max_interval 覆蓋。當 mon_warn_pg_not_scrubbed_ratio間隔百分比自到期后未進行清理時，將觸發警告。
如果 PG 沒有被標記為clean ，它們將不會擦洗，如果它們放錯位置或降級可能會發生這種情況（參見上面的PG_AVAILABILITY和 PG_DEGRADED）。
您可以手動啟動清理 PG 的清理：
ceph pg scrub <pgid>
- PG_NOT_DEEP_SCRUBBED
一個或多個 PG 最近沒有被深度擦洗。PG 通常每秒鍾清理一次，並且當間隔的osd_deep_scrub_interval百分比自到期后沒有清理時觸發此mon_warn_pg_not_deep_scrubbed_ratio警告。
如果 PG 沒有標記為clean ，它們將不會（深度）擦洗，如果它們放錯位置或降級，則可能會發生這種情況（請參閱上面的PG_AVAILABILITY和 PG_DEGRADED）。
您可以手動啟動清理 PG 的清理：
ceph pg deep-scrub <pgid>
- PG_SLOW_SNAP_TRIMMING
一個或多個 PG 的快照修剪隊列已超過配置的警告閾值。這表明最近刪除了大量快照，或者 OSD 無法足夠快地修剪快照以跟上新快照刪除的速度。
警告閾值由 mon_osd_snap_trim_queue_warn_on選項控制（默認值：32768）。
如果 OSD 負載過大且無法跟上其后台工作，或者如果 OSD 的內部元數據數據庫嚴重碎片化且無法執行，則可能會觸發此警告。它還可能表明 OSD 存在其他一些性能問題。
快照修剪隊列的確切大小由 ceph pg ls -f json-detail的 snaptrimq_len字段報告。
雜項
- RECENT_CRASH
一個或多個 Ceph 守護進程最近發生了崩潰，並且該崩潰尚未被管理員存檔（確認）。這可能表示軟件錯誤、硬件問題（例如，故障磁盤）或一些其他問題。
可以列出新的崩潰：
ceph crash ls-new
可以通過以下方式檢查有關特定崩潰的信息：
ceph crash info <crash-id>
可以通過“歸檔”崩潰（可能在管理員檢查后）來消除此警告，這樣它就不會生成此警告：
ceph crash archive <crash-id>
同樣，所有新的崩潰都可以存檔：
ceph crash archive-all
存檔的崩潰仍然可以通過ceph crash ls可見，但ceph crash ls-new不可見。
“recent”表示的時間段由選項mgr/crash/warn_recent_interval控制 （默認值：兩周）。
可以通過以下方式完全禁用這些警告：
ceph config set mgr/crash/warn_recent_interval 0
- TELEMETRY_CHANGED
遙測已啟用，但遙測報告的內容自那時起已更改，因此不會發送遙測報告。
Ceph 開發人員會定期修改遙測功能以包含新的有用信息，或刪除發現無用或敏感的信息。如果報告中包含任何新信息，Ceph 將要求管理員重新啟用遙測，以確保他們有機會（重新）查看將共享的信息。
要查看遙測報告的內容，請：
ceph telemetry show
請注意，遙測報告由幾個可以獨立啟用或禁用的可選通道組成。有關詳細信息，請參閱 遙測模塊。
要重新啟用遙測（並使此警告消失），請：
ceph telemetry on
要禁用遙測（並使此警告消失），請：
ceph telemetry off
- AUTH_BAD_CAPS
一個或多個身份驗證用戶具有監視器無法解析的功能。這通常表明用戶將無權使用一種或多種守護程序類型執行任何操作。
如果功能是使用未正確驗證其語法的舊版 Ceph 設置的，或者功能的語法已更改，則此錯誤很可能在升級后發生。
可以通過以下方式刪除相關用戶：
ceph auth rm <entity-name>
（這將解決健康警報，但顯然客戶端將無法以該用戶身份進行身份驗證。）
或者，可以使用以下方式更新用戶的功能：
ceph auth <entity-name> <daemon-type> <caps> [<daemon-type> <caps> ...]
有關身份驗證功能的更多信息，請參閱用戶管理。
- OSD_NO_DOWN_OUT_INTERVAL
mon_osd_down_out_interval選項設置為0，這意味着系統不會在 OSD 發生故障后自動執行任何修復或修復操作。相反，管理員（或其他一些外部實體）需要手動將 OSD 標記為“out”（即 ceph osd out
此選項通常設置為 5 或 10 分鍾——足夠主機重啟或重啟的時間。
可以通過將 mon_warn_on_osd_down_out_interval_zero設置為 false 來消除此警告：
ceph config global mon mon_warn_on_osd_down_out_interval_zero false
- DASHBOARD_DEBUG
儀表板調試模式已啟用。這意味着，如果在處理 REST API 請求時出現錯誤，HTTP 錯誤響應將包含 Python 回溯。在生產環境中應禁用此行為，因為此類回溯可能包含並公開敏感信息。
可以通過以下方式禁用調試模式：
ceph dashboard debug disable