注意

本文档适用于 Ceph 的开发版本。

健康检查

概述

Ceph 集群可以引发一系列健康状态。这些状态被称为健康检查。每个健康检查都有一个唯一的标识符。

该标识符是一个简洁的、人类可读的字符串——也就是说，该标识符的易读性与典型的变量名相似。它旨在帮助工具（例如监控和 UI）理解健康检查，并以反映其含义的方式呈现它们。

本页列出了由 monitor 和 manager 守护进程引发的健康检查。除此之外，您可能还会看到源自 CephFS MDS 守护进程的健康检查（请参阅CephFS 健康消息），以及由 ceph-mgr 模块定义的健康检查。

定义

Monitor

DAEMON_OLD_VERSION

一个或多个 Ceph 守护进程正在运行旧的 Ceph 版本。如果检测到多个版本，则会引发健康检查。这种情况必须持续一段时间，大于 mon_warn_older_version_delay（默认为一周），才会引发健康检查。这允许大多数升级在不引发预期且短暂的警告的情况下进行。如果升级暂停时间过长，可以使用 health mute 命令来运行 ceph health mute DAEMON_OLD_VERSION --sticky。但是，请务必在升级完成后运行 ceph health unmute DAEMON_OLD_VERSION，以便未来的意外实例不会被掩盖。

MON_DOWN

一个或多个 Ceph Monitor 守护进程已停止。集群要求已配置的多数（超过一半）的 monitor 可用。当一个或多个 monitor 停止时，客户端可能更难与集群建立初始连接，因为它们可能需要尝试额外的 IP 地址才能找到一个正在运行的 monitor。

应尽快恢复或重启停止的 monitor 守护进程，以减少因额外的 monitor 故障而导致服务中断的风险。

MON_CLOCK_SKEW

运行 Ceph Monitor 守护进程的主机上的时钟未良好同步。如果集群检测到时钟偏差大于 mon_clock_drift_allowed，则会引发此健康检查。

解决此问题的最佳方法是使用诸如传统的 ntpd 或较新的 chrony 等工具同步时钟。理想情况下，应配置 NTP 守护进程以针对多个内部和外部源进行同步以实现弹性；该协议将自适应地确定最佳可用源。让 Ceph Monitor 主机上的 NTP 守护进程相互同步也很有益，因为 monitor 之间的同步比它们相对于参考时间的“正确性”更为重要。

如果无法保持时钟紧密同步，可以增加 mon_clock_drift_allowed 阈值。但是，此值必须显著低于 mon_lease 间隔，monitor 集群才能正常运行。通过高质量的 NTP 或 PTP 配置实现亚毫秒级同步并不困难，因此极少有需要更改此值的情况。

MON_MSGR2_NOT_ENABLED

ms_bind_msgr2 选项已启用，但集群的 monmap 中有一个或多个 monitor 未配置为绑定到 v2 端口。这意味着特定于 msgr2 协议的功能（例如加密）在某些或所有连接上不可用。

在大多数情况下，可以通过运行以下命令进行修正

ceph mon enable-msgr2

运行此命令后，配置为侦听旧默认端口（6789）的任何 monitor 将继续侦听 6789 上的 v1 连接，并开始侦听新默认端口 3300 上的 v2 连接。

如果 monitor 配置为侦听非标准端口（即除 6789 以外的端口）上的 v1 连接，则需要手动修改 monmap。

MON_DISK_LOW

一个或多个 monitor 存储空间不足。当 monitor 数据库使用的文件系统（通常是 /var/lib/ceph/<fsid>/mon.<monid>）上的可用空间低于阈值 mon_data_avail_warn（默认值：30%）时，会引发此健康检查。

此警报可能表明系统上其他进程或用户正在填满 monitor 使用的文件系统。它也可能表明 monitor 数据库过大（请参阅下面的 MON_DISK_BIG）。另一种常见情况是，为了故障排除目的而提高了 Ceph 日志子系统级别，但随后未恢复到默认级别。持续的冗长日志记录很容易填满包含 /var/log 的文件系统。如果您修剪当前打开的日志，请记住重启或指示您的 syslog 或其他守护进程重新打开日志文件。另一个常见的动态是用户或进程向 /tmp 或 /var/tmp 写入了大量数据，这些目录可能位于同一文件系统上。

如果无法释放空间，可能需要将 monitor 的数据目录移动到另一个存储设备或文件系统。此重新定位过程必须在 monitor 守护进程未运行时执行。

MON_DISK_CRIT

一个或多个 monitor 存储空间严重不足。如果 monitor 数据库使用的文件系统（通常是 /var/lib/ceph/mon）上的可用空间百分比低于百分比值 mon_data_avail_crit（默认值：5%），则会引发此健康检查。请参阅上文的 MON_DISK_LOW。

MON_DISK_BIG

一个或多个 monitor 的数据库大小非常大。如果 monitor 数据库的大小大于 mon_data_size_warn（默认值：15 GiB），则会引发此健康检查。

数据库过大并不常见，但也不一定表明存在问题。当有放置组长时间未达到 active+clean 状态时，或者最近发生了大量的集群恢复、扩展或拓扑更改时，monitor 数据库可能会增长。建议在进行大规模集群更改时，每周至少让集群“休息”几个小时。

此警报也可能表明 monitor 的数据库未正确压缩，这是 RocksDB 旧版本中观察到的问题。使用 ceph daemon mon.<id> compact 强制压缩可能足以缩小数据库的存储使用量。

此警报也可能表明 monitor 存在阻止其修剪所存储的集群元数据的错误。如果问题仍然存在，请报告错误。

要调整警告阈值，请运行以下命令

ceph config set global mon_data_size_warn <size>

MON_NETSPLIT

Ceph Monitor 之间发生了网络分区。当一个或多个 monitor 检测到至少两个 Ceph Monitor 失去连接或可达性时，会引发此健康检查，这是基于它们单独的连接分数（经常更新）确定的。此警告仅在集群配置了至少三个 Ceph Monitor 并使用 connectivity 选举策略时出现。

为了减少瞬态网络问题引起的误报，检测到的网络分区不会立即报告为健康警告。相反，它们必须持续至少 mon_netsplit_grace_period 秒（默认值：9 秒）才会报告。如果网络分区在此宽限期内解决，则不会发出健康警告。

网络分区以两种方式报告

  • 作为位置级别网络分区（例如，“Netsplit detected between dc1 and dc2”），当一个位置中的所有 monitor 无法与另一个位置中的所有 monitor 通信时。

  • 作为单个 monitor 网络分区（例如，“Netsplit detected between mon.a and mon.d”），当只有特定 monitor 在位置之间断开连接时。

系统优先在可能的最高拓扑级别（datacenter、rack 等）报告，以更好地帮助操作员识别基础设施级别的网络问题。

要调整宽限期阈值，请运行以下命令

ceph config set mon mon_netsplit_grace_period <seconds>

要完全禁用宽限期（立即报告），请将值设置为 0

ceph config set mon mon_netsplit_grace_period 0

AUTH_INSECURE_GLOBAL_ID_RECLAIM

连接到集群的一个或多个客户端或守护进程在重新连接到 monitor 时没有安全地回收其 global_id（标识集群中每个实体的唯一编号）。由于 auth_allow_insecure_global_id_reclaim 选项设置为 true（在所有 Ceph 客户端升级之前可能是必需的），并且由于 auth_expose_insecure_global_id_reclaim 选项设置为 true（这允许 monitor 通过强制这些客户端在初始身份验证后立即重新连接来更快地检测具有“不安全回收”的客户端），因此允许客户端连接。

要识别正在使用未修补的 Ceph 客户端代码的客户端，请运行以下命令

ceph health detail

如果您收集连接到单个 monitor 的客户端转储，并检查转储输出中的 global_id_status 字段，您可以看到这些客户端的 global_id 回收行为。这里的 reclaim_insecure 意味着客户端未打补丁，并且导致此健康检查。要执行客户端转储，请运行以下命令

ceph tell mon.\* sessions

我们强烈建议将系统中的所有客户端升级到较新版本的 Ceph，该版本可以正确回收 global_id 值。所有客户端更新后，运行以下命令以停止允许不安全的重新连接

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 当前配置为允许客户端使用不安全过程重新连接到 monitor 来回收其先前的 global_id。允许这种回收是因为默认情况下 auth_allow_insecure_global_id_reclaim 设置为 true。在将现有 Ceph 客户端升级到正确且安全地回收其 global_id 的较新版本 Ceph 时，可能需要保持启用此设置。

如果 AUTH_INSECURE_GLOBAL_ID_RECLAIM 健康检查尚未引发，并且 auth_expose_insecure_global_id_reclaim 设置未禁用（默认启用），则当前没有连接的客户端需要升级。在这种情况下，可以安全地通过运行以下命令禁用 insecure global_id reclaim

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

Manager

MGR_DOWN

所有 Ceph Manager 守护进程当前已停止。集群通常应该至少有一个正在运行的 manager (ceph-mgr) 守护进程。如果没有 manager 守护进程运行，集群自我监控的能力将受损，部分管理 API 将不可用（例如，仪表板将无法工作，并且大多数报告指标或运行时状态的 CLI 命令将阻塞）。然而，集群仍将能够执行客户端 I/O 操作并从故障中恢复。

应尽快重启停止的 manager 守护进程，以确保可以监控集群（例如，ceph -s 信息可用且最新，并且 Prometheus 可以抓取指标）。

MGR_MODULE_DEPENDENCY

已启用的 manager 模块未能通过其依赖性检查。此健康检查通常伴随模块对问题的解释性消息。

例如，模块可能报告缺少所需的软件包：在这种情况下，您应该安装所需的软件包并重启 manager 守护进程。

此健康检查仅适用于启用的模块。如果模块未启用，您可以通过 ceph module ls 的输出来查看它是否报告了依赖性问题。

MGR_MODULE_ERROR

manager 模块遇到了意外错误。通常，这意味着从模块的 serve 函数中引发了未处理的异常。如果异常本身没有提供有用的描述，则错误的人类可读描述可能会含糊不清。

此健康检查可能表明存在错误：如果您认为遇到了错误，请提交 Ceph 错误报告。

但是，如果您认为错误是暂时的，可以重启 manager 守护进程或在活动守护进程上使用 ceph mgr fail 以强制故障转移到另一个守护进程。

OSD

OSD_DOWN

一个或多个 OSD 被标记为 down。ceph-osd 守护进程或其主机可能已崩溃或停止，或者对等 OSD 可能无法通过公共或私有网络访问 OSD。常见原因包括守护进程停止或崩溃、“down”主机或网络故障。

验证主机是否健康、守护进程是否已启动以及网络是否正常运行。如果守护进程已崩溃，守护进程日志文件（/var/log/ceph/ceph-osd.*）可能包含故障排除信息。

OSD_<crush type>_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 已超过 full 阈值，并阻止集群提供写入服务。

要按池查看利用率，请运行以下命令

ceph df

要查看当前定义的 full 比率，请运行以下命令

ceph osd dump | grep full_ratio

恢复写入可用性的短期解决方案是将 full 阈值提高少量。为此，请运行以下命令

ceph osd set-full-ratio <ratio>

应在适当的 CRUSH 故障域内部署额外的 OSD 以增加容量，和/或删除现有数据以释放集群中的空间。一个微妙的情况是，可能使用了 rados bench 工具来测试一个或多个池的性能，但随后未清理由此产生的 RADOS 对象。您可以通过针对每个池调用 rados ls 并查找名称以 bench 或其他作业名称开头的对象来检查此情况。然后可以手动但非常小心地删除这些对象以回收容量。

OSD_BACKFILLFULL

一个或多个 OSD 已超过 backfillfull 阈值，或者如果当前映射的回填完成，将超过该阈值，这将阻止数据重新平衡到此 OSD。此警报是一个早期警告，表明重新平衡可能无法完成，并且集群即将满。

要按池查看利用率，请运行以下命令

ceph df

OSD_NEARFULL

一个或多个 OSD 已超过 nearfull 阈值。此警报是一个早期警告，表明集群即将满。

要按池查看利用率，请运行以下命令

ceph df

OSDMAP_FLAGS

已设置一个或多个受关注的集群标志。这些标志包括

  • full - 集群被标记为满，无法提供写入服务

  • pauserd, pausewr - 存在暂停的读取或写入

  • noup - 不允许 OSD 启动

  • nodown - OSD 故障报告被忽略，这意味着 monitor 不会将 OSD 标记为“down”

  • noin - 以前被标记为 out 的 OSD 在启动时不会被标记回 in

  • noout - “down”的 OSD 在配置的时间间隔后不会自动被标记为 out

  • nobackfill, norecover, norebalance - 恢复或数据重新平衡被暂停

  • noscrub, nodeep_scrub - 清理被禁用

  • notieragent - 缓存分层活动被暂停

除了 full 之外，可以通过运行以下命令设置或清除这些标志

ceph osd set <flag>
ceph osd unset <flag>

OSD_FLAGS

一个或多个 OSD 或 CRUSH {节点,设备类} 设置了受关注的标志。这些标志包括

  • noup: 不允许这些 OSD 启动

  • nodown: 这些 OSD 的故障报告将被忽略

  • noin: 如果这些 OSD 在故障后自动被标记为 out，则在它们启动时不会被标记为 in

  • noout: 如果这些 OSD 处于“down”状态，它们在配置的时间间隔后不会自动被标记为 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 bucket 的中间权重值。

应更新 CRUSH 映射以使用较新的方法（即：straw_calc_version=1）。有关更多信息，请参阅可调参数。

CACHE_POOL_NO_HIT_SET

一个或多个缓存池未配置 hit set 来跟踪利用率。此问题阻止了分层代理识别要从缓存中刷新和逐出的冷对象。

要在缓存池上配置 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

OSD_FILESTORE

如果 OSD 正在运行旧的 Filestore 后端，则发出警告。Filestore OSD 后端已弃用；BlueStore 后端自 Ceph Luminous 版本以来一直是默认的对象存储。

Filestore OSD 不支持 'mclock_scheduler'。因此，Filestore OSD 的默认 'osd_op_queue' 设置为 'wpq'，即使尝试更改它也会强制执行。

ceph report | jq -c '."osd_metadata" | .[] | select(.osd_objectstore | contains("filestore")) | {id, osd_objectstore}'

要升级到 Reef 或更高版本，必须首先将所有 Filestore OSD 迁移到 BlueStore。

如果您正在将 pre-Reef 版本升级到 Reef 或更高版本，但无法立即将 Filestore OSD 迁移到 BlueStore，可以通过运行以下命令暂时静默此警报

ceph health mute OSD_FILESTORE

由于 Filestore OSD 迁移到 BlueStore 可能需要相当长的时间才能完成，我们建议您在更新到 Reef 或更高版本之前尽早开始此过程。

OSD_UNREACHABLE

一个或多个 OSD 的注册 v1/v2 公共地址不在定义的 public_network 子网内，这会阻止这些无法访问的 OSD 与 ceph 客户端正确通信。

尽管这些无法访问的 OSD 处于 up 状态，但由于这种不一致性，rados 客户端将在 TCP 超时之前挂起，然后报错。

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。此过程涉及数据迁移和恢复。

也可以扩展支持 db 存储的 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

这将输出最多三个值：BDEV_DB free、BDEV_SLOW free 和 available_from_bluestore。BDEV_DB 和 BDEV_SLOW 报告 BlueFS 已获取且现在被认为是空闲的空间量。available_from_bluestore 值表示 BlueStore 释放更多空间给 BlueFS 的能力。此值与 BlueStore 空闲空间量不同是正常的，因为 BlueFS 分配单元通常大于 BlueStore 分配单元。这意味着只有部分 BlueStore 空闲空间可用于 BlueFS。

BLUEFS_LOW_SPACE

如果 BlueFS 可用空闲空间不足，并且 BlueStore 提供的空闲空间也不多（换句话说，available_from_bluestore 的值很低），请考虑减小 BlueFS 分配单元大小。要模拟分配单元不同时的可用空间，请运行以下命令

ceph daemon osd.123 bluestore bluefs available <alloc-unit-size>

BLUESTORE_FRAGMENTATION

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

一个或多个 OSD 具有在 Nautilus 版本之前创建的 BlueStore 卷。（在 Nautilus 中，BlueStore 以细粒度的、按池的方式跟踪其内部使用统计信息。）

如果 所有 OSD 都早于 Nautilus，则意味着按池指标根本不可用。但是，如果存在 pre-Nautilus 和 post-Nautilus OSD 的混合，则 ceph df 报告的集群使用统计信息将不准确。

可以通过停止每个 OSD、运行修复操作，然后重启 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

一个或多个 OSD 具有在 Octopus 版本之前创建的卷。（在 Octopus 及更高版本中，BlueStore 按池跟踪 omap 空间利用率。）

如果任何 BlueStore OSD 未启用新跟踪，集群将根据最近的深度清理报告按池 omap 使用情况的近似值。

可以通过停止每个 OSD、运行修复操作，然后重启 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

一个或多个 OSD 具有在 Pacific 版本之前创建的卷。（在 Pacific 及更高版本中，Bluestore 按放置组 (PG) 跟踪 omap 空间利用率。）

按 PG omap 允许在 PG 迁移时更快地删除 PG。

可以通过停止每个 OSD、运行修复操作，然后重启 OSD 来更新旧 OSD 以按 PG 跟踪。例如，要更新 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 执行此过程，以尽量减少数据丢失的风险。要执行此过程（其中 $N 是具有不一致性的 OSD），请运行以下命令

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

注意

等待一个 OSD 上的此恢复过程完全完成后，再对下一个 OSD 运行。

BLUESTORE_NO_COMPRESSION

一个或多个 OSD 无法加载 BlueStore 压缩插件。此问题可能是由安装损坏引起的，其中 ceph-osd 二进制文件与压缩插件不匹配。或者可能是最近升级中 ceph-osd 守护进程未重启引起的。

要解决此问题，请验证运行受影响 OSD 的主机上的所有软件包是否正确安装，并且 OSD 守护进程已重启。如果问题仍然存在，请检查 OSD 日志以获取有关问题根源的信息。

BLUESTORE_SPURIOUS_READ_ERRORS

一个（或多个）BlueStore OSD 检测到主设备上的读取错误。BlueStore 通过重试磁盘读取已从这些错误中恢复。此警报可能表明底层硬件存在问题、I/O 子系统存在问题或类似问题。此类问题可能导致永久性数据损坏。有关虚假读取错误根本原因的一些观察结果可以在这里找到：https://tracker.ceph.com/issues/22464

此警报不需要立即响应，但受影响的主机可能需要额外的关注：例如，将主机升级到最新的 OS/内核版本并实施硬件资源利用率监控。

要禁用所有 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

BLOCK_DEVICE_STALLED_READ_ALERT

BlueStore 日志消息揭示了可能导致性能下降并可能导致数据不可用或丢失的存储驱动器问题。这些可能表明存储驱动器正在发生故障，应进行评估并可能移除和更换。

read stalled read 0x29f40370000~100000 (buffered) since 63410177.290546s, timeout is 5.000000s

然而，这很难发现，因为没有明显的警告（例如，在 ceph health detail 中没有健康警告或信息）。更多观察结果可以在这里找到：https://tracker.ceph.com/issues/62500

此外，由于可能存在误报 stalled read 实例，已添加一种机制来提高准确性。如果在最近 bdev_stalled_read_warn_lifetime 秒内，给定 BlueStore 块设备的 stalled read 事件数大于或等于 bdev_stalled_read_warn_threshold，则会在 ceph health detail 中报告此警告。当条件清除时，警告状态将被移除。

bdev_stalled_read_warn_lifetime 和 bdev_stalled_read_warn_threshold 的默认值可以全局覆盖或针对特定 OSD 覆盖。

要更改此设置，请运行以下命令

ceph config set global bdev_stalled_read_warn_lifetime 10
ceph config set global bdev_stalled_read_warn_threshold 5

这可以针对特定 OSD 或给定掩码完成。例如，仅应用于 SSD OSD

ceph config set osd.123 bdev_stalled_read_warn_lifetime 10
ceph config set osd.123 bdev_stalled_read_warn_threshold 5
ceph config set class:ssd bdev_stalled_read_warn_lifetime 10
ceph config set class:ssd bdev_stalled_read_warn_threshold 5

WAL_DEVICE_STALLED_READ_ALERT

引发警告状态 WAL_DEVICE_STALLED_READ_ALERT 以指示给定 BlueStore OSD 的 WAL_DEVICE 上的 stalled read 实例。此警告可以通过 bdev_stalled_read_warn_lifetime 和 bdev_stalled_read_warn_threshold 选项配置，使用与 BLOCK_DEVICE_STALLED_READ_ALERT 警告部分所述类似的命令。

DB_DEVICE_STALLED_READ_ALERT

引发警告状态 DB_DEVICE_STALLED_READ_ALERT 以指示给定 BlueStore OSD 的 DB_DEVICE 上的 stalled read 实例。此警告可以通过 bdev_stalled_read_warn_lifetime 和 bdev_stalled_read_warn_threshold 选项配置，使用与 BLOCK_DEVICE_STALLED_READ_ALERT 警告部分所述类似的命令。

BLUESTORE_SLOW_OP_ALERT

BlueStore 日志消息揭示了可能导致性能下降并可能导致数据不可用或丢失的存储驱动器问题。这些表明存储驱动器可能正在发生故障，应进行调查并可能更换。

log_latency_fn slow operation observed for _txc_committed_kv, latency = 12.028621219s, txc = 0x55a107c30f00 log_latency_fn slow operation observed for upper_bound, latency = 6.25955s log_latency slow operation observed for submit_transaction..

这也可能反映在 BLUESTORE_SLOW_OP_ALERT 集群健康标志中。

由于可能存在误报 slow ops 实例，已添加一种机制来提高可靠性。如果在最近 bluestore_slow_ops_warn_lifetime 秒内，给定 BlueStore OSD 的 slow ops 指示数大于或等于 bluestore_slow_ops_warn_threshold，则会在 ceph health detail 中报告此警告。当条件清除时，警告状态被清除。

bluestore_slow_ops_warn_lifetime 和 bluestore_slow_ops_warn_threshold 的默认值可以全局覆盖或针对特定 OSD 覆盖。

要更改此设置，请运行以下形式的命令

ceph config set global bluestore_slow_ops_warn_lifetime 300
ceph config set global bluestore_slow_ops_warn_threshold 5

这可以针对特定 OSD 或给定掩码完成，例如

ceph config set osd.123 bluestore_slow_ops_warn_lifetime 300
ceph config set osd.123 bluestore_slow_ops_warn_threshold 5
ceph config set class:ssd bluestore_slow_ops_warn_lifetime 300
ceph config set class:ssd bluestore_slow_ops_warn_threshold 5

设备健康

DEVICE_HEALTH

一个或多个 OSD 设备预计很快会发生故障，其中警告阈值由 mgr/devicehealth/warn_threshold 配置选项确定。

由于此警报仅适用于当前标记为 in 的 OSD，因此对此预期故障的适当响应是 (1) 将 OSD 标记为 out，以便数据从 OSD 迁移出来，然后 (2) 从系统中移除硬件。请注意，如果启用了 mgr/devicehealth/self_heal（由 mgr/devicehealth/mark_out_threshold 确定），则通常会自动执行此 out 标记。如果 OSD 设备受损但该设备上的 OSD 仍处于 up 状态，恢复可能会降级。在这种情况下，强制停止有问题的 OSD 守护进程可能是有利的，以便恢复可以从幸存的健康 OSD 继续进行。必须极其小心地执行此操作并注意故障域，以免危及数据可用性。

要检查设备健康状况，请运行以下形式的命令

ceph device info <device-id>

设备预期寿命由 Ceph Manager 运行的预测模型或运行以下形式命令的外部工具设置

ceph device set-life-expectancy <device-id> <from> <to>

您可以手动更改存储的预期寿命，但此类更改通常没有任何作用。原因在于最初设置存储预期寿命的工具可能会通过再次设置它来撤销您的更改，并且对存储值的更改不会影响硬件设备的实际健康状况。

DEVICE_HEALTH_IN_USE

一个或多个设备（即 OSD）预计很快会发生故障，并且已被标记为集群 out（由 mgr/devicehealth/mark_out_threshold 控制），但它们仍参与一个或多个放置组。这可能是因为 OSD 最近才被标记为 out 并且数据仍在迁移中，或者因为由于某种原因数据无法从 OSD 迁移出来（例如，集群接近满，或者 CRUSH 层次结构配置为没有另一个合适的 OSD 来迁移数据）。

可以通过禁用自我修复行为（即，将 mgr/devicehealth/self_heal 设置为 false），调整 mgr/devicehealth/mark_out_threshold，或者解决阻止数据从故障 OSD 迁移出来的任何条件来静默此消息。

DEVICE_HEALTH_TOOMANY

太多设备（即 OSD）预计很快会发生故障，并且由于启用了 mgr/devicehealth/self_heal 行为，将所有故障 OSD 标记为 out 将超过集群的 mon_osd_min_in_ratio 比率。此比率可防止太多 OSD 自动被标记为 out。

您应该立即向集群添加新的 OSD 以防止数据丢失，或者逐步更换发生故障的 OSD。

或者，您可以通过调整包括 mon_osd_min_in_ratio 或 mgr/devicehealth/mark_out_threshold 在内的选项来静默此健康检查。但是请注意，这会增加不可恢复数据丢失的可能性。

数据健康（池和放置组）

PG_AVAILABILITY

数据可用性降低。换句话说，集群无法为集群中至少某些数据提供潜在的读取或写入请求服务。更准确地说，一个或多个放置组 (PG) 处于不允许提供 I/O 请求的状态。以下任何 PG 状态如果不能迅速清除，都会有问题：peering、stale、incomplete 以及缺少 active。

有关受影响 PG 的详细信息，请运行以下命令

ceph health detail

在大多数情况下，此问题的根本原因是当前一个或多个 OSD down：请参阅上文的 OSD_DOWN。

要查看特定有问题 PG 的状态，请运行以下形式的命令

ceph tell <pgid> query

PG_DEGRADED

某些数据的冗余降低：换句话说，集群没有所有数据所需的副本数（对于复制池）或纠删码片段（对于纠删码池）。更准确地说，一个或多个放置组 (PG)

  • 设置了 degraded 或 undersized 标志，这意味着集群中没有足够的该 PG 实例；或者

  • 长时间未设置 clean 状态。

有关受影响 PG 的详细信息，请运行以下命令

ceph health detail

在大多数情况下，此问题的根本原因是当前一个或多个 OSD 处于“down”状态：请参阅上文的 OSD_DOWN。

要查看特定有问题 PG 的状态，请运行以下形式的命令

ceph tell <pgid> query

PG_RECOVERY_FULL

由于集群中缺少空闲空间，某些数据的冗余可能会降低甚至面临风险。更准确地说，一个或多个放置组设置了 recovery_toofull 标志，这意味着集群无法迁移或恢复数据，因为一个或多个 OSD 超过了 full 阈值。

有关解决此条件的步骤，请参阅上文的 OSD_FULL。

PG_BACKFILL_FULL

由于集群中缺少空闲空间，某些数据的冗余可能会降低甚至面临风险。更准确地说，一个或多个放置组设置了 backfill_toofull 标志，这意味着集群无法迁移或恢复数据，因为一个或多个 OSD 超过了 backfillfull 阈值。

有关解决此条件的步骤，请参阅上文的 OSD_BACKFILLFULL。

PG_DAMAGED

数据清理发现了集群中的数据一致性问题。更准确地说，一个或多个放置组 (1) 设置了 inconsistent 或 snaptrim_error 标志，这表明早期的数据清理操作发现了问题，或者 (2) 设置了 repair 标志，这意味着当前正在进行此类不一致的修复。

有关更多信息，请参阅故障排除 PGs。

OSD_SCRUB_ERRORS

最近的 OSD 清理发现了不一致性。此警报通常与 PG_DAMAGED 配对（见上文）。

有关更多信息，请参阅故障排除 PGs。

OSD_TOO_MANY_REPAIRS

读取修复计数已超过配置值阈值 mon_osd_warn_num_repaired（默认值：10）。由于清理仅处理静止数据错误，并且在另一个副本可用时发生的任何读取错误都会立即修复，以便客户端可以获取对象数据，因此可能存在未记录任何清理错误的故障磁盘。此修复计数是识别任何此类故障磁盘的一种方式。

为了允许清除警告，已添加新命令 ceph tell osd.# clear_shards_repaired [count]。默认情况下，它将修复计数设置为 0。可以将 count 值传递给命令。因此，管理员可以选择通过将 mon_osd_warn_num_repaired（或更高）的值传递给命令来重新启用警告。使用 clear_shards_repaired 的替代方法是使用 ceph health mute 静默 OSD_TOO_MANY_REPAIRS 警报。

LARGE_OMAP_OBJECTS

一个或多个池包含大型 omap 对象，由 osd_deep_scrub_large_omap_object_key_threshold（用于确定什么是大型 omap 对象的键数阈值）或 osd_deep_scrub_large_omap_object_value_sum_threshold（用于确定什么是大型 omap 对象的键值总和大小（以字节为单位）阈值）或两者共同决定。要查找有关对象名称、键计数和大小（以字节为单位）的更多信息，请在集群日志中搜索“Large omap object found”。此问题可能是由未启用自动重新分片的 RGW-bucket 索引对象引起的。有关重新分片的更多信息，请参阅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) 数量低于每 OSD mon_pg_warn_min_per_osd PG 的可配置阈值。这可能导致数据在集群中的 OSD 之间分布不理想且平衡性不佳，并降低整体性能。

如果尚未创建数据池，则此情况是预期的。

要解决此问题，您可以增加现有池的 PG 计数或创建新池。有关更多信息，请参阅选择 PG 数量。

POOL_PG_NUM_NOT_POWER_OF_TWO

一个或多个池的 pg_num 值不是 2 的幂。虽然这不是致命的，但确实会导致数据分布不太平衡，因为某些放置组将包含比其他组更多的数据。

通过将受影响池的 pg_num 值设置为附近的 2 的幂，可以轻松纠正此问题。启用 PG Autoscaler 或运行以下形式的命令

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>

有关更多信息，请参阅选择 PG 数量和自动缩放放置组。

TOO_MANY_PGS

集群中使用的放置组 (PG) 数量超过了每 OSD mon_max_pg_per_osd PG 的可配置阈值。如果超过此阈值，集群将不允许创建新池、增加池 pg_num 或增加池复制（任何这些操作如果允许，都会导致集群中出现更多 PG）。大量的 PG 可能导致 OSD 守护进程的内存利用率更高，集群状态更改后（例如 OSD 重启、添加或移除）对等速度变慢，以及 Manager 和 Monitor 守护进程上的负载更高。

缓解此问题的最简单方法是通过添加更多硬件来增加集群中的 OSD 数量。请注意，因为用于此健康检查目的的 OSD 计数是 in OSD 的数量，所以将 out OSD 标记为 in（如果有可用的 out OSD）也有助于解决问题。为此，请运行以下形式的命令

ceph osd in <osd id(s)>

有关更多信息，请参阅选择 PG 数量。

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>

有关更多信息，请参阅选择 PG 数量和自动缩放放置组。

POOL_TARGET_SIZE_BYTES_OVERCOMMITTED

一个或多个池设置了 target_size_bytes 属性以估计池的预期大小，但该属性的值大于总可用存储空间（无论是单独还是与其他池组合）。

此警报通常表明池的 target_size_bytes 值过大，应减小或设置为零。要减小 target_size_bytes 值或将其设置为零，请运行以下命令

ceph osd pool set <pool-name> target_size_bytes 0

上面的命令将 target_size_bytes 的值设置为零。要将 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。这意味着部分或全部数据可能无法满足 CRUSH 规则和池设置中指定的数据保护策略。

SMALLER_PGP_NUM

一个或多个池的 pgp_num 值小于 pg_num。此警报通常表示增加了放置组 (PG) 计数，但未增加放置行为。

这种差异有时是故意造成的，目的是在调整 PG 计数时，将“拆分”步骤与更改 pgp_num 时需要的数据迁移分离开来。

通常通过运行以下形式的命令，将 pgp_num 设置为与 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 配置选项来提高阈值。

仅当 pg_autoscale_mode 设置为 on 时，才会针对特定池关闭健康检查。

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。

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

集群中的一个或多个对象没有存储在 CRUSH 倾向存储的节点上。此警报表示由于最近的集群更改而导致的数据迁移尚未完成。

数据错位本身并不是危险情况；数据一致性永远不会受到威胁，并且在创建所需数量的新副本（在所需位置）之前，旧的对象副本不会被删除。

OBJECT_UNFOUND

集群中的一个或多个对象无法找到。更准确地说，OSD 知道应该存在一个新或更新的对象副本，但在当前在线的 OSD 上找不到此副本。

对未找到对象的读取或写入请求将阻塞。

理想情况下，可以使具有未找到对象的更新副本的“down” OSD 重新上线。要确定候选 OSD，请检查负责未找到对象的 PG 的 peering 状态。要查看 peering 状态，请运行以下形式的命令：

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 不会被标记为 clean（请参阅上文的 PG_AVAILABILITY 和 PG_DEGRADED）。

要手动启动对 clean PG 的擦洗，请运行以下形式的命令：

PG_NOT_DEEP_SCRUBBED

一个或多个放置组 (PG) 最近未进行深度擦洗。PG 通常最多每 osd_deep_scrub_interval 秒进行一次深度擦洗。如果在安排擦洗的时间过后，间隔的某个百分比（由 mon_warn_pg_not_deep_scrubbed_ratio 确定）已过去，并且尚未执行深度擦洗，则会触发此健康检查。

仅当 PG 被标记为 clean（这意味着它们将被清理，而不是已经检查过并发现干净）时，才会进行深度擦洗。错位或降级的 PG 可能不会被标记为 clean（请参阅上文的 PG_AVAILABILITY 和 PG_DEGRADED）。

本文档提供了两种设置 osd_deep_scrub_interval 值的方法。此处列出的第一种方法全局更改 osd_deep_scrub_interval 的值。此处列出的第二种方法更改 OSD 和 Manager 守护程序的 osd_deep scrub interval 值。

第一种方法

要手动启动对 clean PG 的深度擦洗，请运行以下形式的命令：

ceph pg deep-scrub <pgid>

在某些情况下，会出现警告 PGs not deep-scrubbed in time。这可能是因为集群包含许多大型 PG，这使得深度擦洗需要更长的时间。为了解决这种情况，您必须全局更改 osd_deep_scrub_interval 的值。

  1. 确认 ceph health detail 返回 pgs not deep-scrubbed in time 警告：

    # ceph health detail
HEALTH_WARN 1161 pgs not deep-scrubbed in time
[WRN] PG_NOT_DEEP_SCRUBBED: 1161 pgs not deep-scrubbed in time
pg 86.fff not deep-scrubbed since 2024-08-21T02:35:25.733187+0000

  2. 全局更改 osd_deep_scrub_interval：

    ceph config set global osd_deep_scrub_interval 1209600

上述程序由 Eugen Block 于 2024 年 9 月开发。

有关更多详细信息，请参阅 Eugen Block 的博客文章。

请参阅 Redmine tracker issue #44959。

第二种方法

要手动启动对 clean PG 的深度擦洗，请运行以下形式的命令：

ceph pg deep-scrub <pgid>

在某些情况下，会出现警告 PGs not deep-scrubbed in time。这可能是因为集群包含许多大型 PG，这使得深度擦洗需要更长的时间。为了解决这种情况，您必须更改 OSD 和 Manager 守护程序的 osd_deep_scrub_interval 值。

  1. 确认 ceph health detail 返回 pgs not deep-scrubbed in time 警告：

    # ceph health detail
HEALTH_WARN 1161 pgs not deep-scrubbed in time
[WRN] PG_NOT_DEEP_SCRUBBED: 1161 pgs not deep-scrubbed in time
pg 86.fff not deep-scrubbed since 2024-08-21T02:35:25.733187+0000

  2. 更改 OSD 的 osd_deep_scrub_interval：

    ceph config set osd osd_deep_scrub_interval 1209600

  3. 更改 Manager 的 osd_deep_scrub_interval：

    ceph config set mgr osd_deep_scrub_interval 1209600

上述程序由 Eugen Block 于 2024 年 9 月开发。

有关更多详细信息，请参阅 Eugen Block 的博客文章。

请参阅 Redmine tracker issue #44959。

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 字段报告。

拉伸模式

INCORRECT_NUM_BUCKETS_STRETCH_MODE

拉伸模式目前仅支持 2 个带有 OSD 的划分存储桶，此警告表明启用拉伸模式后划分存储桶的数量不等于 2。在条件修复之前，您可能会遇到不可预测的故障和 MON 断言。

我们建议您通过删除额外的划分存储桶或将划分存储桶的数量增加到 2 来修复此问题。

UNEVEN_WEIGHTS_STRETCH_MODE

启用拉伸模式时，2 个划分存储桶必须具有相等的权重。此警告表明启用拉伸模式后 2 个划分存储桶的权重不均匀。这不会立即致命，但是，当 Ceph 尝试处理划分存储桶之间的转换时，您可能会遇到混乱。

我们建议您通过使两个划分存储桶上的权重均匀来修复此问题。这可以通过确保每个划分存储桶上的 OSD 总权重相同来实现。

NONEXISTENT_MON_CRUSH_LOC_STRETCH_MODE

启用拉伸模式时，为监视器指定的 CRUSH 位置必须属于其中一个划分存储桶。作为唯一例外的 tiebreaker 监视器除外。

此警告表明一个或多个监视器具有不属于拉伸模式中任何划分存储桶的 CRUSH 位置。

我们建议您通过确保监视器的 CRUSH 位置属于其中一个划分存储桶来修复此问题。

NVMeoF 网关

NVMEOF_SINGLE_GATEWAY

其中一个网关组只有一个网关。这不理想，因为它使得单个网关在组中无法实现高可用性 (HA)。这可能导致 NVMeoF 网关的故障转移和故障恢复操作出现问题。

建议在组中设置多个 NVMeoF 网关。

NVMEOF_GATEWAY_DOWN

某些网关处于 GW_UNAVAILABLE 状态。如果 NVMeoF 守护程序崩溃，守护程序日志文件（位于 /var/log/ceph/）可能包含故障排除信息。

NVMEOF_GATEWAY_DELETING

某些网关处于 GW_DELETING 状态。它们将保持此状态，直到网关负载平衡组下的所有命名空间都移动到另一个负载平衡组 ID。这由负载平衡过程自动完成。如果此警报持续很长时间，则该过程可能存在问题。

杂项

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 查看。

被视为最近的时间段由选项 mgr/crash/warn_recent_interval 决定（默认值：两周）。

要完全禁用此警报，请运行以下命令：

ceph config set mgr/crash/warn_recent_interval 0

RECENT_MGR_MODULE_CRASH

一个或多个 ceph-mgr 模块最近崩溃，且崩溃尚未得到管理员确认和归档。此警报通常表示在 ceph-mgr 守护程序内部运行的某个软件模块中存在软件错误。遇到问题的模块可能会因此被禁用，但其他模块不受影响，并继续按预期运行。

与 RECENT_CRASH 健康检查一样，可以通过运行以下命令来检查特定崩溃：

ceph crash info <crash-id>

要关闭此警报，您可以归档崩溃（可能在管理员检查崩溃之后），方法是运行以下形式的命令：

ceph crash archive <crash-id>

同样，要归档所有最近的崩溃，请运行以下命令：

ceph crash archive-all

归档的崩溃仍可通过运行命令 ceph crash ls 查看，但不能通过运行命令 ceph crash ls-new 查看。

被视为最近的时间段由选项 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

一个或多个身份验证用户的权限无法被监视器解析。通常，此警报表示用户未被授权使用一个或多个守护程序类型来执行任何操作。

此警报最有可能在升级后触发，如果 (1) 权限是使用较旧版本的 Ceph 设置的，该版本没有正确验证这些权限的语法，或者 (2) 权限的语法发生了变化。

要删除相关用户，请运行以下形式的命令：

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 选项设置为零，这意味着当 OSD 失败时，系统不会自动执行任何修复或自愈操作。相反，管理员或外部协调器必须手动将“down” OSD 标记为 out（通过运行 ceph osd out <osd-id>）以触发恢复。

此选项通常设置为五或十分钟，这应该足以让主机断电或重启。

要关闭此警报，请通过运行以下命令将 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

由 Ceph 基金会为您呈现

Ceph 文档是由非营利性 Ceph 基金会 资助和托管的社区资源。如果您希望支持这项工作和我们的其他努力，请考虑 立即加入。