注意

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

监视器故障排除

即使集群遇到与监视器相关的问题，集群也未必有宕机的危险。如果集群丢失了多个监视器，只要有足够的存活监视器来形成法定人数，它仍然可以保持运行。

如果您的集群遇到与监视器相关的问题，我们建议您参考以下故障排除信息。

初步故障排除

监视器故障排除过程中的第一步是确保监视器正在运行，并且能够与网络通信并在网络上通信。按照本节中的步骤排除监视器故障的最简单原因。

  1. 确保监视器正在运行。

    确保监视器（mon）守护进程（ceph-mon）正在运行。可能的情况是，在升级后监视器尚未重新启动。检查这个简单的疏忽可以节省数小时的辛苦故障排除时间。

    确保管理器守护进程（ceph-mgr）正在运行也很重要。请记住，典型的集群配置为每个监视器（ceph-mon）提供一个管理器（ceph-mgr）。

    注意

    在 v1.12.5 之前的版本中，Rook 不会运行两个以上的管理器。

  2. 确保您可以访问监视器节点。

    在某些罕见情况下，iptables 规则可能会阻止对监视器节点或 TCP 端口的访问。这些规则可能是早期压力测试或规则开发留下的。要检查是否存在此类规则，请通过 SSH 连接到每个监视器节点，并使用 telnet 或 nc 或类似工具尝试连接到其他每个监视器节点的 tcp/3300 和 tcp/6789 端口。

  3. 确保“ceph status”命令运行并从集群接收到回复。

    如果 ceph status 命令从集群接收到回复，则集群正在运行。监视器只有在形成法定人数时才会回复 status 请求。确认报告有一个或多个 mgr 守护进程正在运行。在没有缺陷的集群中，ceph status 将报告所有 mgr 守护进程都在运行。

    如果 ceph status 命令没有从集群接收到回复，则可能没有足够的监视器 up 来形成法定人数。如果运行 ceph -s 命令时没有指定其他选项，它会连接到一个任意选择的监视器。然而，在某些情况下，通过向命令添加 -m 标志来连接到特定的监视器（或按顺序连接到多个特定监视器）可能很有帮助：例如，ceph status -m mymon1。

  4. 以上方法都不起作用。现在怎么办？

    如果上述解决方案没有解决您的问题，您可能会发现依次检查每个监视器很有帮助。即使没有形成法定人数，也可以单独联系每个监视器并使用 ceph tell mon.ID mon_status 命令请求其状态（这里的 ID 是监视器的标识符）。

    对集群中的每个监视器运行 ceph tell mon.ID mon_status 命令。有关此命令输出的更多信息，请参阅了解 mon_status。

    还有另一种联系每个监视器的方法：通过 SSH 连接到每个监视器节点并查询守护进程的管理套接字。请参阅使用监视器的管理套接字。

使用监视器的管理套接字

监视器的管理套接字允许您通过 Unix 套接字文件直接与特定守护进程交互。此套接字文件位于监视器的 run 目录中。

管理套接字的默认目录是 /var/run/ceph/ceph-mon.ID.asok。可以覆盖管理套接字的默认位置。如果默认位置已被覆盖，则管理套接字将在其他地方。当集群的守护进程部署在容器中时，这种情况经常发生。

要查找管理套接字的目录，请检查您的 ceph.conf 以获取替代路径，或运行以下命令

ceph-conf --name mon.ID --show-config-value admin_socket

管理套接字只有在监视器守护进程正在运行时才可用。每次监视器正常关闭时，管理套接字都会被移除。如果监视器没有运行但管理套接字仍然存在，则可能是监视器未正常关闭。如果监视器没有运行，将无法使用管理套接字，并且 ceph 命令可能会返回 Error 111: Connection Refused。

要访问管理套接字，请运行以下形式的 ceph tell 命令（指定您感兴趣的守护进程）

ceph tell mon.<id> mon_status

此命令通过其管理套接字将 help 命令传递给指定的正在运行的监视器守护进程 <id>。如果您知道管理套接字文件的完整路径，可以通过运行以下命令更直接地完成此操作

ceph --admin-daemon <full_path_to_asok_file> <command>

运行 ceph help 会显示通过管理套接字可用的所有支持的命令。特别请参阅 config get、config show、mon stat 和 quorum_status。

了解 mon_status

监视器的状态（如 ceph tell mon.X mon_status 命令所报告）可以通过管理套接字获取。 ceph tell mon.X mon_status 命令输出大量关于监视器的信息（包括 quorum_status 命令输出中的信息）。

注意

命令 ceph tell mon.X mon_status 并非按字面意思输入。当您运行命令时，mon.X 中的 X 部分应替换为特定于您的 Ceph 集群的值。

为了理解此命令的输出，让我们考虑以下示例，其中我们看到 ceph tell mon.c mon_status 的输出

{ "name": "c",
  "rank": 2,
  "state": "peon",
  "election_epoch": 38,
  "quorum": [
        1,
        2],
  "outside_quorum": [],
  "extra_probe_peers": [],
  "sync_provider": [],
  "monmap": { "epoch": 3,
      "fsid": "5c4e9d53-e2e1-478a-8061-f543f8be4cf8",
      "modified": "2013-10-30 04:12:01.945629",
      "created": "2013-10-29 14:14:41.914786",
      "mons": [
            { "rank": 0,
              "name": "a",
              "addr": "127.0.0.1:6789\/0"},
            { "rank": 1,
              "name": "b",
              "addr": "127.0.0.1:6790\/0"},
            { "rank": 2,
              "name": "c",
              "addr": "127.0.0.1:6795\/0"}]}}

此输出报告 monmap 中有三个监视器（a、b 和 c），法定人数仅由两个监视器组成，并且 c 是一个 peon。

哪个监视器不在法定人数内？

答案是 a（即 mon.a）。mon.a 不在法定人数内。

在这个例子中，我们如何知道 mon.a 不在法定人数内？

我们知道 mon.a 不在法定人数内，因为它具有排名 0，而排名为 0 的监视器根据定义不在法定人数内。

如果我们检查 quorum 集合，我们可以清楚地看到集合中有两个监视器：1 和 2。但这些不是监视器名称。它们是在当前 monmap 中建立的监视器排名。quorum 集合不包括具有排名 0 的监视器，并且根据 monmap，该监视器是 mon.a。

监视器排名是如何确定的？

每当监视器添加到集群或从集群中移除时，都会计算（或重新计算）监视器排名。排名的计算遵循一个简单的规则：IP:PORT 组合越大，排名越低。在这种情况下，因为 127.0.0.1:6789（mon.a）在数值上小于其他两个 IP:PORT 组合（“监视器 b”为 127.0.0.1:6790，“监视器 c”为 127.0.0.1:6795），所以 mon.a 具有最高排名：即排名 0。

最常见的监视器问题

集群有法定人数但至少有一个监视器宕机

当集群有法定人数但至少有一个监视器宕机时，ceph health detail 返回类似以下的输出

$ ceph health detail
[snip]
mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)

如何对有法定人数但至少有一个监视器宕机的 Ceph 集群进行故障排除？

  1. 确保 mon.a 正在运行。

  2. 确保您可以从其他监视器节点连接到 mon.a 的节点。也检查 TCP 端口。在所有节点上检查 iptables 和 nf_conntrack，确保没有丢弃/拒绝连接。

如果这些初步故障排除未能解决您的问题，则需要进一步调查。

首先，通过管理套接字检查有问题的监视器的 mon_status，如使用监视器的管理套接字和了解 mon_status中所述。

如果监视器不在法定人数内，则其状态将是以下之一：probing、electing 或 synchronizing。如果监视器的状态是 leader 或 peon，则监视器认为自己处于法定人数内，但集群的其余部分认为它不在法定人数内。处于 probing、electing 或 synchronizing 状态之一的监视器可能在故障排除过程中进入了法定人数。再次检查 ceph status 以确定监视器是否在故障排除期间进入了法定人数。如果监视器仍不在法定人数内，则继续执行本文档本节所述的调查。

当监视器状态为 ``probing`` 时是什么意思？

如果 ceph health detail 显示监视器的状态为 probing，则监视器仍在寻找其他监视器。每个监视器在启动时都会保持此状态一段时间。当监视器连接到 monmap 中指定的其他监视器时，它将停止处于 probing 状态。监视器处于 probing 状态的时间量取决于它所属集群的参数。例如，当监视器是单监视器集群的一部分时（切勿在生产环境中这样做），监视器几乎会瞬间通过探测状态。在多监视器集群中，监视器保持 probing 状态，直到它们找到足够的监视器来形成法定人数——这意味着如果集群中的三个监视器中有两个 down，则剩下的一个监视器会无限期地保持 probing 状态，直到您启动其他监视器之一。

如果已建立法定人数，那么只要可以联系到其他监视器，监视器守护进程应该能够快速找到它们。如果监视器卡在 probing 状态并且您已用尽上述描述监视器之间通信故障排除的程序，则有问题的监视器可能正在尝试以错误的地址联系其他监视器。 mon_status 输出监视器已知的 monmap：确定 monmap 中指定的其他监视器的位置是否与网络中监视器的位置匹配。如果不匹配，请参阅恢复损坏的监视器 monmap。如果 monmap 中指定的监视器位置与网络中监视器的位置匹配，则持续的 probing 状态可能与监视器节点之间的严重时钟偏移有关。请参阅时钟偏移。如果时钟偏移中的信息没有使监视器脱离 probing 状态，则准备好您的系统日志并向 Ceph 社区寻求帮助。有关正确准备日志的信息，请参阅准备您的日志。

当监视器状态为 ``electing`` 时是什么意思？

如果 ceph health detail 显示监视器的状态为 electing，则监视器正在进行选举。选举通常很快完成，但有时监视器可能会陷入所谓的选举风暴。有关监视器选举的更多信息，请参阅监视器选举。

选举风暴的存在可能表明监视器节点之间存在时钟偏移。有关详细信息，请参阅时钟偏移。

如果您的时钟已正确同步，请在邮件列表和错误跟踪器中搜索与您的问题类似的问题。 electing 状态不太可能持续存在。在 Cuttlefish 版本之后的 Ceph 版本中，除了时钟偏移之外，没有明显的原因可以解释为什么 electing 状态会持续存在。

如果您在调查时将有问题的监视器置于 down 状态，则可以调查持续存在的 electing 状态的原因。只有当有足够的存活监视器来形成法定人数时，这才是可能的。

当监视器状态为 ``synchronizing`` 时是什么意思？

如果 ceph health detail 显示监视器正在 synchronizing，则监视器正在赶上集群的其余部分，以便它可以加入法定人数。监视器与法定人数的其余部分同步所需的时间取决于集群监视器存储的大小、集群的大小和集群的状态。更大且降级的集群通常使监视器处于 synchronizing 状态的时间比更小、更新的集群要长。

如果监视器将其状态从 synchronizing 更改为 electing，然后再回到 synchronizing，则表明存在问题：集群状态可能推进得太快（即生成新地图），以至于同步过程无法跟上创建新地图的速度。这个问题在 Cuttlefish 版本发布之前比在最近的版本中更频繁地出现，因为同步过程已被重构和增强以避免这种动态。如果您在更高版本中遇到此问题，请在Ceph 错误跟踪器中报告此问题。准备并提供日志以证实您提出的任何错误。有关正确准备日志的信息，请参阅准备您的日志。

当监视器状态为 ``leader`` 或 ``peon`` 时是什么意思？

在 Ceph 正常操作期间，当集群处于 HEALTH_OK 状态时，Ceph 集群中的一个监视器处于 leader 状态，其余监视器处于 peon 状态。给定监视器的状态可以通过检查命令 ceph tell <mon_name> mon_status 返回的状态键的值来确定。

如果 ceph health detail 显示监视器处于 leader 状态或 peon 状态，则可能存在时钟偏移。按照时钟偏移中的说明进行操作。如果您已遵循这些说明，并且 ceph health detail 仍显示监视器处于 leader 状态或 peon 状态，请在Ceph 错误跟踪器中报告此问题。如果您提出问题，请提供日志以证实它。有关正确准备日志的信息，请参阅准备您的日志。

恢复损坏的监视器“monmap”

如了解 mon_status中所述，可以使用 ceph tell mon.c mon_status 形式的命令检索 monmap。

这是一个 monmap 的示例

epoch 3
fsid 5c4e9d53-e2e1-478a-8061-f543f8be4cf8
last_changed 2013-10-30 04:12:01.945629
created 2013-10-29 14:14:41.914786
0: 127.0.0.1:6789/0 mon.a
1: 127.0.0.1:6790/0 mon.b
2: 127.0.0.1:6795/0 mon.c

这个 monmap 正在正常工作，但您的 monmap 可能无法正常工作。给定节点中的 monmap 可能已过时，因为该节点长时间宕机，在此期间集群的监视器发生了变化。

有两种方法可以更新过时的监视器 monmap

  1. 废弃监视器并重新部署。

    仅当您确定不会丢失被废弃监视器保留的信息时才这样做。确保您有其他状况良好的监视器，以便新监视器能够与存活的监视器同步。请记住，如果没有监视器内容的任何其他副本，销毁监视器可能会导致数据丢失。

  2. 将 monmap 注入监视器。

    可以通过从集群中存活的监视器检索最新的 monmap 并将其注入具有损坏或丢失 monmap 的监视器来修复具有过时 monmap 的监视器。

    通过执行以下步骤来实现此解决方案

    1. 通过以下两种方式之一检索 monmap

      1. 如果存在法定人数的监视器

        从法定人数中检索 monmap

        ceph mon getmap -o /tmp/monmap

      2. 如果没有法定人数的监视器

        直接从已停止的监视器检索 monmap

        ceph-mon -i ID-FOO --extract-monmap /tmp/monmap

        在此示例中，已停止监视器的 ID 是 ID-FOO。

    2. 停止要注入 monmap 的监视器

      service ceph -a stop mon.{mon-id}

    3. 将 monmap 注入已停止的监视器

      ceph-mon -i ID --inject-monmap /tmp/monmap

    4. 启动监视器。

      警告

      将 monmap 注入监视器可能会导致严重问题。注入 monmap 会覆盖存储在监视器上的最新现有 monmap。小心！

时钟偏移

Paxos 共识算法需要密切的时间同步，这意味着法定人数中的监视器之间的时钟偏移会对监视器操作产生严重影响。由此产生的行为可能令人困惑。为避免此问题，请在您的监视器节点上运行时钟同步工具：例如，使用 Chrony 或旧版 ntpd 实用程序。配置每个监视器节点，使 iburst 选项生效，并使每个监视器有多个对等点，包括以下内容

  • 彼此

  • 内部 NTP 服务器

  • 多个外部公共池服务器

注意

iburst 选项发送八个数据包而不是通常的单个数据包突发，用于使两个对等点进入初始同步过程。

此外，建议将集群中的所有节点与内部和外部服务器同步，甚至可能与您的监视器同步。在裸机上运行 NTP 服务器：VM 虚拟化时钟不适合稳定的计时。有关网络时间协议 (NTP) 的更多信息，请参阅 https://www.ntp.org。您的组织可能已经有可用的高质量内部 NTP 服务器。 NTP 服务器设备的来源包括以下内容

时钟偏移问题与解答

最大容忍时钟偏移是多少？

默认情况下，监视器允许时钟漂移最大为 0.05 秒（50 毫秒）。

我可以增加最大容忍时钟偏移吗？

是的，但我们强烈建议不要这样做。最大容忍时钟偏移可以通过 mon_clock_drift_allowed 选项配置，但更改此选项几乎肯定是一个坏主意。时钟偏移最大值之所以存在，是因为不能依赖时钟偏移的监视器。当前的默认值已证明其价值，可以在监视器遇到严重问题之前提醒用户。更改此值可能会对监视器的稳定性和整体集群健康状况产生不可预见的影响。

我如何知道是否存在时钟偏移？

监视器将通过集群状态 HEALTH_WARN 向您发出警告。存在时钟偏移时，ceph health detail 和 ceph status 命令返回类似于以下的输出

mon.c addr 10.10.0.1:6789/0 clock skew 0.08235s > max 0.05s (latency 0.0045s)

在此示例中，监视器 mon.c 已被标记为存在时钟偏移。

在 Luminous 及更高版本中，可以通过运行 ceph time-sync-status 命令来检查时钟偏移。请注意，主监视器通常具有最低的 IP 地址数值。它将始终显示 0：报告的其他监视器的偏移量是相对于主监视器的，而不是相对于任何外部参考源。

如果存在时钟偏移，我该怎么办？

同步您的时钟。使用 NTP 客户端可能有所帮助。但是，如果您已经在使用 NTP 客户端，并且仍然遇到时钟偏移问题，请确定您正在使用的 NTP 服务器是远程的还是托管在您的网络上。托管您自己的 NTP 服务器往往会减轻时钟偏移问题。

客户端无法连接或挂载

如果客户端无法连接到集群或挂载，请检查您的 iptables。某些操作系统安装实用程序会向 iptables 添加 REJECT 规则。 iptables 规则将拒绝所有尝试连接到主机的客户端（ssh 除外）。如果您的监视器主机的 iptables 中有 REJECT 规则，则从单独节点连接的客户端将失败，这将引发超时错误。查找拒绝尝试连接到 Ceph 守护进程的客户端的 iptables 规则。例如

REJECT all -- anywhere anywhere reject-with icmp-host-prohibited

可能还需要在 Ceph 主机上向 iptables 添加规则，以确保客户端能够访问与 Ceph 监视器（默认值：端口 6789）和 Ceph OSD（默认值：6800 到 7568）关联的 TCP 端口。例如

iptables -A INPUT -m multiport -p tcp -s {ip-address}/{netmask} --dports 6789,6800:7568 -j ACCEPT

监视器存储故障

存储损坏的症状

Ceph 监视器将集群地图维护在一个键值存储中。如果键值存储损坏导致监视器失败，则监视器日志可能包含以下错误消息之一

Corruption: error in middle of record

或

Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.foo/store.db/1234567.ldb

使用健康监视器恢复

如果集群包含存活的监视器，则可以使用新监视器替换损坏的监视器。新监视器启动后，它将与健康的对等点同步。新监视器完全同步后，它将能够为客户端提供服务。

使用 OSD 恢复

即使所有监视器同时失败，也可以使用存储在 OSD 中的信息来恢复监视器存储。建议您在 Ceph 集群中部署至少三个（最好是五个）监视器。在这种部署中，监视器完全失败的可能性很小。然而，如果磁盘设置或文件系统设置配置不当，数据中心意外断电可能会导致底层文件系统失败，从而导致所有监视器崩溃。在这种情况下，可以使用 OSD 中的数据来恢复监视器。以下是一个可用于在这种情况下恢复监视器的脚本

ms=/root/mon-store
mkdir $ms

# collect the cluster map from stopped OSDs
for host in $hosts; do
  rsync -avz $ms/. user@$host:$ms.remote
  rm -rf $ms
  ssh user@$host <<EOF
    for osd in /var/lib/ceph/osd/ceph-*; do
      ceph-objectstore-tool --data-path \$osd --no-mon-config --op update-mon-db --mon-store-path $ms.remote
    done
EOF
  rsync -avz user@$host:$ms.remote/. $ms
done

# rebuild the monitor store from the collected map, if the cluster does not
# use cephx authentication, we can skip the following steps to update the
# keyring with the caps, and there is no need to pass the "--keyring" option.
# i.e. just use "ceph-monstore-tool $ms rebuild" instead
ceph-authtool /path/to/admin.keyring -n mon. \
  --cap mon 'allow *'
ceph-authtool /path/to/admin.keyring -n client.admin \
  --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *'
# add one or more ceph-mgr's key to the keyring. in this case, an encoded key
# for mgr.x is added, you can find the encoded key in
# /etc/ceph/${cluster}.${mgr_name}.keyring on the machine where ceph-mgr is
# deployed
ceph-authtool /path/to/admin.keyring --add-key 'AQDN8kBe9PLWARAAZwxXMr+n85SBYbSlLcZnMA==' -n mgr.x \
  --cap mon 'allow profile mgr' --cap osd 'allow *' --cap mds 'allow *'
# If your monitors' ids are not sorted by ip address, please specify them in order.
# For example. if mon 'a' is 10.0.0.3, mon 'b' is 10.0.0.2, and mon 'c' is  10.0.0.4,
# please passing "--mon-ids b a c".
# In addition, if your monitors' ids are not single characters like 'a', 'b', 'c', please
# specify them in the command line by passing them as arguments of the "--mon-ids"
# option. if you are not sure, please check your ceph.conf to see if there is any
# sections named like '[mon.foo]'. don't pass the "--mon-ids" option, if you are
# using DNS SRV for looking up monitors.
ceph-monstore-tool $ms rebuild -- --keyring /path/to/admin.keyring --mon-ids alpha beta gamma

# make a backup of the corrupted store.db just in case!  repeat for
# all monitors.
mv /var/lib/ceph/mon/mon.foo/store.db /var/lib/ceph/mon/mon.foo/store.db.corrupted

# move rebuild store.db into place.  repeat for all monitors.
mv $ms/store.db /var/lib/ceph/mon/mon.foo/store.db
chown -R ceph:ceph /var/lib/ceph/mon/mon.foo/store.db

此脚本执行以下步骤

  1. 从每个 OSD 主机收集地图。

  2. 重建存储。

  3. 使用适当的功能填充密钥环文件中的实体。

  4. 将 mon.foo 上的损坏存储替换为恢复的副本。

已知限制

上述恢复工具无法恢复以下信息

  • 某些添加的密钥环：所有使用 ceph auth add 命令添加的 OSD 密钥环都会从 OSD 的副本中恢复，并且 client.admin 密钥环是使用 ceph-monstore-tool 导入的。然而，MDS 密钥环和所有其他密钥环将在恢复的监视器存储中丢失。可能需要手动重新添加它们。

  • 创建池：如果任何 RADOS 池正在创建过程中，则该状态会丢失。恢复工具操作的假设是所有池都已创建。如果部分创建的池在恢复后有 PG 卡在 unknown 状态，您可以通过运行 ceph osd force-create-pg 命令强制创建空 PG。这会创建一个空 PG，因此只有在您确定该池为空时才执行此操作。

  • MDS 地图：MDS 地图丢失。

所有都失败了！现在怎么办？

寻求帮助

您可以在 OFTC 上的 #ceph 和 #ceph-devel（服务器 irc.oftc.net）IRC 频道中找到帮助，或者通过 dev@ceph.io 和 ceph-users@lists.ceph.com 寻求帮助。确保您已准备好日志，并应要求提供。

上游 Ceph Slack 工作区可以通过此地址加入：https://ceph-storage.slack.com/

有关如何联系上游 Ceph 社区的最新信息（截至 2023 年 12 月），请参阅 https://ceph.net.cn/en/community/connect/。

准备您的日志

监视器日志的默认位置是 /var/log/ceph/ceph-mon.FOO.log*。监视器日志的位置可能已从默认值更改。如果监视器日志的位置已从默认位置更改，请通过运行以下命令查找监视器日志的位置

ceph-conf --name mon.FOO --show-config-value log_file

日志中的信息量由集群配置文件中的调试级别确定。如果 Ceph 使用默认调试级别，则您的日志可能缺少重要信息，这些信息将帮助上游 Ceph 社区解决您的问题。

提高调试级别以确保您的监视器日志包含相关信息。在这里我们对来自监视器的信息感兴趣。与其他组件一样，监视器具有不同的部分，这些部分会在不同的子系统上输出其调试信息。

如果您是一位经验丰富的 Ceph 故障排除人员，我们建议提高最相关子系统的调试级别。这种方法对于初学者来说可能并不容易。然而，在大多数情况下，如果输入以下调试级别，将记录足够的信息来解决问题

debug_mon = 10
debug_ms = 1

有时这些调试级别不会产生足够的信息。在这种情况下，上游 Ceph 社区成员会要求您对这些或其他调试级别进行额外更改。无论如何，我们收到一些有用的信息总比收到空日志要好。

我需要重新启动监视器来调整调试级别吗？

不需要。调整调试级别时不需要重新启动监视器。

有两种不同的方法来调整调试级别。一种方法用于有法定人数时。另一种方法用于没有法定人数时。

有法定人数时调整调试级别

要么将调试选项注入到需要调试的特定监视器中

ceph tell mon.FOO config set debug_mon 10/10

要么一次性注入到所有监视器中

ceph tell mon.* config set debug_mon 10/10

没有法定人数时调整调试级别

使用需要调试的特定监视器的管理套接字并直接调整监视器的配置选项

ceph daemon mon.FOO config set debug_mon 10/10

将调试级别返回到其默认值

要将调试级别返回到其默认值，请使用调试级别 1/10 而不是调试级别 10/10 运行上述命令。要检查监视器的当前值，请使用管理套接字并运行以下任一命令

ceph daemon mon.FOO config show

或

ceph daemon mon.FOO config get 'OPTION_NAME'

我使用适当的调试级别重现了问题。现在怎么办？

只向上游 Ceph 社区发送与您的监视器问题相关的日志部分。因为您可能不容易确定哪些部分相关，上游 Ceph 社区接受完整且未经删节的日志。但不要发送包含数十万行且没有额外澄清信息的日志。帮助 Ceph 社区帮助您的一个常识性方法是，在重现问题时记下当前时间和日期，然后根据该信息提取日志部分。

在邮件列表、IRC 或 Slack 上联系上游 Ceph 社区，或在跟踪器上提交新问题。

由 Ceph 基金会为您呈现

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