Ceph 监控集群
一旦你有一个正在运行的集群，你就可以使用该ceph工具来监控你的集群。监控集群通常包括检查 OSD 状态、监控状态、归置组状态和元数据服务器状态。
使用命令行
交互模式
要在交互模式下运行ceph工具，请在不带参数的命令行中键入ceph。例如：
ceph
ceph> health
ceph> status
ceph> quorum_status
ceph> mon stat
非默认路径
如果您为配置或密钥环指定了非默认位置，则可以指定它们的位置：
ceph -c /path/to/conf -k /path/to/keyring health
检查集群状态
启动集群后，开始读取和/或写入数据之前，请先检查集群的状态。
要检查集群的状态，请执行以下命令：
ceph status
要么：
ceph -s
在交互模式下，键入status并按Enter。
ceph> status
Ceph 将打印集群状态。例如，带有每个服务之一的小型 Ceph 演示集群可能会打印以下内容：
cluster:
id: 477e46f1-ae41-4e43-9c8f-72c918ab0a20
health: HEALTH_OK
services:
mon: 3 daemons, quorum a,b,c
mgr: x(active)
mds: cephfs_a-1/1/1 up {0=a=up:active}, 2 up:standby
osd: 3 osds: 3 up, 3 in
data:
pools: 2 pools, 16 pgs
objects: 21 objects, 2.19K
usage: 546 GB used, 384 GB / 931 GB avail
pgs: 16 active+clean
Ceph 如何计算数据使用量？
usage值反映了实际使用的原始存储量。该 xxx GB / xxx GB 值表示集群整体存储容量的可用数量（较小的数量）。名义数量反映了在复制、克隆或快照之前存储的数据的大小。因此，实际存储的数据量通常会超过名义存储量，因为 Ceph 会创建数据的副本，并且还可能使用存储容量进行克隆和快照。
观察集群
除了每个守护进程的本地日志之外，Ceph 集群还维护一个集群日志，记录有关整个系统的高级事件。这会记录到MON服务器上的磁盘（默认情况下为 /var/log/ceph/ceph.log），但也可以通过命令行进行监控。
要跟踪集群日志，请使用以下命令
ceph -w
Ceph 将打印系统的状态，然后是发出的每条日志消息。例如：
cluster:
id: 477e46f1-ae41-4e43-9c8f-72c918ab0a20
health: HEALTH_OK
services:
mon: 3 daemons, quorum a,b,c
mgr: x(active)
mds: cephfs_a-1/1/1 up {0=a=up:active}, 2 up:standby
osd: 3 osds: 3 up, 3 in
data:
pools: 2 pools, 16 pgs
objects: 21 objects, 2.19K
usage: 546 GB used, 384 GB / 931 GB avail
pgs: 16 active+clean
2017-07-24 08:15:11.329298 mon.a mon.0 172.21.9.34:6789/0 23 : cluster [INF] osd.0 172.21.9.34:6806/20527 boot
2017-07-24 08:15:14.258143 mon.a mon.0 172.21.9.34:6789/0 39 : cluster [INF] Activating manager daemon x
2017-07-24 08:15:15.446025 mon.a mon.0 172.21.9.34:6789/0 47 : cluster [INF] Manager daemon x is now available
除了ceph -w用于在发出日志行时打印它们，ceph log last [n]n 还可以用于查看集群日志中的最新行。
监控健康检查
Ceph 不断地根据自己的状态运行各种健康检查。当健康检查失败时，这会反映在(ceph status 或 ceph health) 的输出中。此外，还会向集群日志发送消息以指示检查何时失败以及集群何时恢复。
例如，当 OSD 出现故障时，health状态输出部分可能会更新如下：
health: HEALTH_WARN
1 osds down
Degraded data redundancy: 21/63 objects degraded (33.333%), 16 pgs unclean, 16 pgs degraded
这时候也会发出集群日志消息来记录健康检查的失败：
2017-07-25 10:08:58.265945 mon.a mon.0 172.21.9.34:6789/0 91 : cluster [WRN] Health check failed: 1 osds down (OSD_DOWN)
2017-07-25 10:09:01.302624 mon.a mon.0 172.21.9.34:6789/0 94 : cluster [WRN] Health check failed: Degraded data redundancy: 21/63 objects degraded (33.333%), 16 pgs unclean, 16 pgs degraded (PG_DEGRADED)
当 OSD 重新上线时，集群日志会记录集群恢复到健康状态：
2017-07-25 10:11:11.526841 mon.a mon.0 172.21.9.34:6789/0 109 : cluster [WRN] Health check update: Degraded data redundancy: 2 pgs unclean, 2 pgs degraded, 2 pgs undersized (PG_DEGRADED)
2017-07-25 10:11:13.535493 mon.a mon.0 172.21.9.34:6789/0 110 : cluster [INF] Health check cleared: PG_DEGRADED (was: Degraded data redundancy: 2 pgs unclean, 2 pgs degraded, 2 pgs undersized)
2017-07-25 10:11:13.535577 mon.a mon.0 172.21.9.34:6789/0 111 : cluster [INF] Cluster is now healthy
网络性能检查
Ceph OSD 在它们之间发送心跳 ping 消息来监控守护进程的可用性。我们还使用响应时间来监控网络性能。虽然繁忙的 OSD 可能会延迟 ping 响应，但我们可以假设如果网络交换机发生故障，将在不同的 OSD 对之间检测到多个延迟。
默认情况下，我们将警告超过 1 秒（1000 毫秒）的 ping 时间。
HEALTH_WARN Slow OSD heartbeats on back (longest 1118.001ms)
运行状况详细信息将添加 OSD 组合看到的延迟和多少。有 10 个明细行项目的限制。
[WRN] OSD_SLOW_PING_TIME_BACK: Slow OSD heartbeats on back (longest 1118.001ms)
Slow OSD heartbeats on back from osd.0 [dc1,rack1] to osd.1 [dc1,rack1] 1118.001 msec possibly improving
Slow OSD heartbeats on back from osd.0 [dc1,rack1] to osd.2 [dc1,rack2] 1030.123 msec
Slow OSD heartbeats on back from osd.2 [dc1,rack2] to osd.1 [dc1,rack1] 1015.321 msec
Slow OSD heartbeats on back from osd.1 [dc1,rack1] to osd.0 [dc1,rack1] 1010.456 msec
要查看更多详细信息和网络性能信息的完整转储，可以使用 dump_osd_network 命令。通常，这将被发送到一个MGR，但它可以通过将它发送到任何 OSD 来限制特定 OSD 的交互。默认为 1 秒（1000 毫秒）的当前阈值可以被覆盖为以毫秒为单位的参数。
以下命令将通过指定阈值 0 并发送到MGR来显示所有收集的网络性能数据。
$ ceph daemon /var/run/ceph/ceph-mgr.x.asok dump_osd_network 0
{
"threshold": 0,
"entries": [
{
"last update": "Wed Sep 4 17:04:49 2019",
"stale": false,
"from osd": 2,
"to osd": 0,
"interface": "front",
"average": {
"1min": 1.023,
"5min": 0.860,
"15min": 0.883
},
"min": {
"1min": 0.818,
"5min": 0.607,
"15min": 0.607
},
"max": {
"1min": 1.164,
"5min": 1.173,
"15min": 1.544
},
"last": 0.924
},
{
"last update": "Wed Sep 4 17:04:49 2019",
"stale": false,
"from osd": 2,
"to osd": 0,
"interface": "back",
"average": {
"1min": 0.968,
"5min": 0.897,
"15min": 0.830
},
"min": {
"1min": 0.860,
"5min": 0.563,
"15min": 0.502
},
"max": {
"1min": 1.171,
"5min": 1.216,
"15min": 1.456
},
"last": 0.845
},
{
"last update": "Wed Sep 4 17:04:48 2019",
"stale": false,
"from osd": 0,
"to osd": 1,
"interface": "front",
"average": {
"1min": 0.965,
"5min": 0.811,
"15min": 0.850
},
"min": {
"1min": 0.650,
"5min": 0.488,
"15min": 0.466
},
"max": {
"1min": 1.252,
"5min": 1.252,
"15min": 1.362
},
"last": 0.791
},
...
静音健康检查
运行状况检查可以静音，这样它们就不会影响集群的整体报告状态。使用健康检查代码指定警报（请参阅健康检查）：
ceph health mute <code>
例如，如果有健康警告，将其静音将使集群报告整体状态为HEALTH_OK. 例如，要使OSD_DOWN警报静音，请执行：
ceph health mute OSD_DOWN
静音报告为命令的短格式和长格式的一部分。例如，在上述场景中，集群会报告：
$ ceph health
HEALTH_OK (muted: OSD_DOWN)
$ ceph health detail
HEALTH_OK (muted: OSD_DOWN)
(MUTED) OSD_DOWN 1 osds down
osd.1 is down
可以通过以下方式显式删除静音：
ceph health unmute <code>
例如：
ceph health unmute OSD_DOWN
健康检查静音可以选择有一个与之关联的 TTL（生存时间），这样静音将在指定的时间段过去后自动过期。TTL 被指定为可选的持续时间参数，例如：
ceph health mute OSD_DOWN 4h # mute for 4 hours
ceph health mute MON_DOWN 15m # mute for 15 minutes
通常，如果静音的健康警报得到解决（例如，在上面的示例中，OSD 重新启动），静音就会消失。如果警报稍后再次出现，则会以通常的方式进行报告。
可以将静音设置为“粘性”，这样即使警报清除，静音也将保持不变。例如：
ceph health mute OSD_DOWN 1h --sticky # ignore any/all down OSDs for next hour
如果警报的程度变得更糟，大多数健康静音也会消失。例如，如果有一个 OSD 关闭，并且警报被静音，则如果一个或多个额外的 OSD 关闭，静音将消失。对于任何涉及计数的健康警报都是如此，该计数指示有多少或多少事物触发了警告或错误。
检测配置问题
除了 Ceph 在自身状态下持续运行的健康检查之外，还有一些配置问题可能只能由外部工具检测到。
使用 ceph-medic 工具对 Ceph 集群的配置运行这些附加检查。
检查集群的使用情况
要检查集群的数据使用情况和池之间的数据分布，您可以使用该df选项。它类似于 Linux df。执行以下操作：
ceph df
输出如下所示：
CLASS SIZE AVAIL USED RAW USED %RAW USED
ssd 202 GiB 200 GiB 2.0 GiB 2.0 GiB 1.00
TOTAL 202 GiB 200 GiB 2.0 GiB 2.0 GiB 1.00
--- POOLS ---
POOL ID PGS STORED (DATA) (OMAP) OBJECTS USED (DATA) (OMAP) %USED MAX AVAIL QUOTA OBJECTS QUOTA BYTES DIRTY USED COMPR UNDER COMPR
device_health_metrics 1 1 242 KiB 15 KiB 227 KiB 4 251 KiB 24 KiB 227 KiB 0 297 GiB N/A N/A 4 0 B 0 B
cephfs.a.meta 2 32 6.8 KiB 6.8 KiB 0 B 22 96 KiB 96 KiB 0 B 0 297 GiB N/A N/A 22 0 B 0 B
cephfs.a.data 3 32 0 B 0 B 0 B 0 0 B 0 B 0 B 0 99 GiB N/A N/A 0 0 B 0 B
test 4 32 22 MiB 22 MiB 50 KiB 248 19 MiB 19 MiB 50 KiB 0 297 GiB N/A N/A 248 0 B 0 B
字段说明：
CLASS：例如，“ssd”或“hdd”。
SIZE：集群管理的存储容量。
AVAIL：集群中可用的存储容量。
USED：用户数据消耗的原始存储量（**不包括BlueStore的数据库**）。
RAW USED：用户数据、内部开销或保留容量消耗的原始存储量。
%RAW USED：使用的原始存储的百分比。**将此数字与 full ratio 和 near full ratio 结合使用，以确保您没有达到集群的容量。**有关其他详细信息，请参阅存储容量。
池：
输出的POOLS部分提供了池列表和每个池的名义使用情况。本节的输出不反映副本、克隆或快照。例如，如果您存储一个具有 1MB 数据的对象，则名义使用量将为 1MB，但实际使用量可能为 2MB 或更多，具体取决于副本、克隆和快照的数量。
ID：池中节点的编号。
STORED：用户/Ceph 存储在池中的实际数据量。这类似于早期版本的 Ceph 中的 USED 列，但计算（对于 BlueStore！）更精确（间隙处理得当）。
(DATA)：用于 RBD（RADOS 块设备）、CephFS 文件数据和 RGW（RADOS 网关）对象数据。
(OMAP)：键值对。主要由 CephFS 和 RGW（RADOS 网关）用于元数据存储。
OBJECTS：每个池中存储的对象的名义数量。“名义”在上文“池”下的段落中定义。
USED：为所有 OSD 上的池分配的空间。这包括复制、分配粒度和纠删码开销。压缩节省和对象内容差距也被考虑在内。BlueStore 的数据库不包括在这个数量中。
(DATA)： RBD（RADOS 块设备）、CephFS 文件数据和 RGW（RADOS 网关）对象数据的对象使用情况。
(OMAP)：对象键值对。主要由 CephFS 和 RGW（RADOS 网关）用于元数据存储。
%USED：每个池使用的存储空间的名义百分比。
MAX AVAIL：估计可以写入此池的名义数据量。
QUOTA OBJECTS：配额对象的数量。
QUOTA BYTES：配额对象中的字节数。
DIRTY：缓存池中已写入缓存池但尚未刷新到基本池的对象数。此字段仅在使用缓存分层时可用。
USED COMPR：为压缩数据分配的空间量（即，这包括压缩数据加上所有分配、复制和纠删码开销）。
UNDER COMPR：通过压缩传递的数据量（所有副本的总和）并且足以以压缩形式存储。
笔记：POOLS 部分中的数字是名义上的。它们不包括副本、快照或克隆的数量。因此，USED 和 %USED 的总和不会与输出的 RAW 部分中的 USED 和 %USED 相同。
笔记：MAX AVAIL 值与所使用的复制或纠删码、将存储映射到设备的 CRUSH 规则、这些设备的利用率以及配置的 mon_osd_full_ratio 有关。
检查 OSD 状态
您可以通过执行以下命令检查 OSD 以确保它们是up和in状态：
ceph osd stat
要么：
ceph osd dump
您还可以使用以下命令根据它们在 CRUSH 图中的位置检查视图 OSD：
ceph osd tree
Ceph 将打印出一个 CRUSH 树，其中包含一个主机、它的 OSD、它们是否启动以及它们的权重：
#ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 3.00000 pool default
-3 3.00000 rack mainrack
-2 3.00000 host osd-host
0 ssd 1.00000 osd.0 up 1.00000 1.00000
1 ssd 1.00000 osd.1 up 1.00000 1.00000
2 ssd 1.00000 osd.2 up 1.00000 1.00000
有关详细讨论，请参阅监控 OSD 和归置组。
检查MON状态
如果您的集群有多个MON（可能），您应该在启动集群之后和读取和/或写入数据之前检查MON仲裁状态。运行多个MON时必须存在仲裁。您还应该定期检查MON状态以确保它们正在运行。
要查看显示MON图，请执行以下操作：
ceph mon stat
要么：
ceph mon dump
要检查监控集群的仲裁状态，请执行以下命令：
ceph quorum_status
Ceph 将返回仲裁状态。例如，由三个MON组成的 Ceph 集群可能会返回以下内容：
{ "election_epoch": 10,
"quorum": [
0,
1,
2],
"quorum_names": [
"a",
"b",
"c"],
"quorum_leader_name": "a",
"monmap": { "epoch": 1,
"fsid": "444b489c-4f16-4b75-83f0-cb8097468898",
"modified": "2011-12-12 13:28:27.505520",
"created": "2011-12-12 13:28:27.505520",
"features": {"persistent": [
"kraken",
"luminous",
"mimic"],
"optional": []
},
"mons": [
{ "rank": 0,
"name": "a",
"addr": "127.0.0.1:6789/0",
"public_addr": "127.0.0.1:6789/0"},
{ "rank": 1,
"name": "b",
"addr": "127.0.0.1:6790/0",
"public_addr": "127.0.0.1:6790/0"},
{ "rank": 2,
"name": "c",
"addr": "127.0.0.1:6791/0",
"public_addr": "127.0.0.1:6791/0"}
]
}
}
检查 MDS 状态
元数据服务器为 CephFS 提供元数据服务。元数据服务器有两组状态：up|down 和 active|inactive。要确保您的元数据服务器是 up 和 active，请执行以下操作：
ceph mds stat
要显示元数据集群的详细信息，请执行以下命令：
ceph fs dump
检查PG（放置组/归置组）
放置组将对象映射到 OSD。当你监控你的归置组时，你会希望它们是active和clean. 有关详细讨论，请参阅监控 OSD 和归置组。
使用管理套接字
Ceph 管理套接字允许您通过套接字接口查询守护进程。默认情况下，Ceph 套接字位于/var/run/ceph. 要通过管理套接字访问守护程序，请登录到运行守护程序的主机并使用以下命令：
ceph daemon {daemon-name}
ceph daemon {path-to-socket-file}
例如，以下是等价的：
ceph daemon osd.0 foo
ceph daemon /var/run/ceph/ceph-osd.0.asok foo
要查看可用的管理套接字命令，请执行以下命令：
ceph daemon {daemon-name} help
admin socket 命令使您能够在运行时显示和设置您的配置。有关详细信息，请参阅在运行时查看配置。
此外，您可以在运行时直接设置配置值（即：ceph tell {daemon-type}.{id} config set，管理套接字绕过MON，不像它依赖于MON但不需要您直接登录到有问题的主机）。
浙公网安备 33010602011771号