注意
本文档适用于 Ceph 的开发版本。
健康报告
如何获取报告
一般来说，有两种渠道可以获取健康报告
- ceph (命令行)
它发送
healthmon 命令来检索集群的健康状态- mgr 模块
它调用
mgr.get('health')以 JSON 编码字符串的形式获取相同的报告
以下图表概述了相关方以及当客户端查询报告时它们如何交互
报告在哪里生成
聚合器的聚合器
健康报告是从多个 Paxos 服务聚合而来的
AuthMonitor
HealthMonitor
MDSMonitor
MgrMonitor
MgrStatMonitor
MonmapMonitor
OSDMonitor
当在各自的域中持久化待处理的更改时，它们每一个都会识别出与健康相关的问题，并使用相同的事务将其存储到 monstore 中，前缀为 health。例如，OSDMonitor 会检查待处理的新 osdmap 中可能存在的问题，例如 OSD down 和池中缺少 scrub 标志，然后将健康报告的编码形式连同新的 osdmap 一起存储。这些报告随后会被加载和解码，以便可以按需收集。对于 MDSMonitor，它将 MDS 守护程序发送的信标中的健康指标持久化，并在存储待处理更改时准备健康报告。
因此，如果我们想添加一个新的与 cephfs 相关的警告，最好的起点可能是 MDSMonitor::encode_pending()，其中从最新的 FSMap 和 MDS 守护程序报告的健康指标中收集健康报告。
但值得注意的是，MgrStatMonitor 不会 自己准备报告，它只是存储从 mgr 收到的健康报告！
ceph-mgr -- 委托聚合器
在 Ceph 中，创建 mgr 是为了分担 monitor 的负担，monitor 用于建立对保持集群功能至关重要的信息的共识。显然，osdmap、mdsmap 和 monmap 属于这一类。但是集群的聚合统计信息呢？它们对于管理员了解集群状态至关重要，但对于保持集群运行可能并不那么重要。为了解决这个可伸缩性问题，我们将收集和聚合指标的工作分派给了 mgr。
现在，mgr 负责接收和处理来自 OSD 的 MPGStats 消息。我们还开发了一种协议，允许守护程序使用 MMgrReport 定期向 mgr 报告其指标和状态。在 mgr 端，它会定期向 mon 上的 MgrStatMonitor 服务发送聚合报告。如前所述，该服务只是将聚合报告中的健康报告持久化到 monstore。