13 Ceph的 Json格式输出解析

http://xuxiaopang.com/2016/12/08/ceph-command-output-analyze/

发表于 2016-12-08 | | 阅读次数

最近在做Ceph的监控，使用Grafana+Graphite+Collectd，需要对Ceph的Json格式输出进行解析，对解析的结果进行一个总结，供他人参考。所有指令添加了--format json-pretty格式输出。

敲得最多的Ceph指令，查看下它的Json输出，为了不把文章拉很长，我把输出放在了Json-Tree这个网站解析了之后，再截图看下主要的结构：

如题，集群的fsid，很多信息我修正过，因为都来自生产集群。

这是monmap的版本号，没啥用处。主要是Ceph里面的很多Map都会有一个epoch也就是版本号，在Map成员发生异动时，版本号会自增加，以记录每次变化的信息。

扩展如下，细分为以下三块：

这里面的mons保存了集群的三个MON的数据：

• mons

  0

  • kb_total: 是MON所处磁盘的总容量，这里是221GB。
  • kb_used`: 是这个磁盘总共使用的百分比，这里是27.57GB。
  • avail_percent: 可使用的百分比，这里是87%，需要监控，防止磁盘爆满。
  • store_stats

• epoch: monmap的版本号。

• round: 我猜测是选举的轮次，具体意义不详。

• mons[0]
  

  ：

  • skew: 时钟偏移量。
  • latency: 延时值，一般都会把MON放在SSD盘上，如果在OSD上，估计会大点，这里是0.
  • health: MON的健康状态。

这里面给出了一个数组，里面保存着相同状态的PG的个数。如果需要查看卡了多少个slow request可以在这里面查看到： 需要做一个正则去过滤下request前面的数字就可以了。

这里给出的集群的三个状态，HEALTH_OK,HEALTH_WARN,HEALTH_ERR。

以及下面的quorum_names，这里面给出了集群的monitor的名称：

集群的monmap，保留了简单的MON的信息：

• epoch：这个值我也不知道是什么了字面意思版本号，不过和这里是3实际版本号不是这个。。。

• created: MON建立的时间

• mons[0]
  

  :

  • rack: 不详。
  • name: MON的主机名
  • addr: MON的IP

OSD的map，记录了最简单的UP&IN状态：

• epoch: osdmap的版本号。每次OSD状态发生变化都会增加。
• num_osds: 总共有50个OSD，不论这个OSD是否好坏对应磁盘，我的理解就是对应的OSD的ID的最大值。
• num_up_osds : UP的OSD，需要监控。
• num_in_osds: IN的OSD，需要监控。
• num_remapped_pgs： 实际上ceph -s的OSD一行只显示了需要remap的PG。

记录了当前集群的所有PG的状态集合，以及恢复状态。

• pgs_by_state:
  • [0][state_name] : PG的状态。
  • [0][count]： 这种状态的PG总数。
• num_pgs: PG总数
• degraded_ratio:被降级的对象比例，可以监控。和恢复过程相关。
• misplaced_ratio: 需要迁移的对象比例，可以监控。
• recovering_bytes_per_sec: 每秒恢复的字节数，需要监控。
• read_bytes_sec: 读速率，需要监控。
• write_bytes_sec: 写速度。
• read_op_per_sec和write_op_per_sec，每秒的操作数(Operation),在jewel里面，分读写，在Hammer及之前，统一叫op_per_sec，需要注意下。

在Jewel里面更名为fsmap，在Hammer及之前叫做mdsmap。我不用这个所以就没有数据。

该指令可以查看集群的OSD状态，还有pool的容量参数等：

osdmap的版本号。

OSD建立的时间，可以用来怀念那个不眠夜。。。

OSD的标记，sortbitwise是bluestore的一种排序方式可以忽视，如果设置了noout和norecover,会显示成: "flags": "noout,norecover,sortbitwise"。

说白了就是建立下一个pool的ID-1，也就是下一个pool的ID为8，有个比较坑的就是pool的ID只会增加，不会减小，比如有ID为1、2、3的pool，删除了所有的pool，再建一个pool的ID为4，不会重新编号。真是深坑。

这个是下一个建的OSD的ID，但是和pool的ID不一样的是，如果1，2，3删了1，2,那么ID会从不存在的最小的开始也就是1，再是2，再是4。

这个数组，罗列了集群的所有pool的数据，我只介绍下我知道的，有的参数以后学习了再来补充：

• 0

  数组索引值

  • pool: pool的ID，和索引无关。
  • pool_name: pool的名称。
  • size: 副本数为3。
  • min_size: 该pool提供IO最小存活副本数，这里的1表示，只要还有一份副本存活，该pool还能正常读写。
  • crush_ruleset: 对应的CRUSH的rule的ID。
  • object_hash: 2, HASH算法的一个宏定义。
  • pg_num: 1024, pool的PG总数。
  • pg_placement_num: 1024，一般等于pg_num，OSD组成PG的组合数。
  • quota_max_bytes: 0，该pool的最大存储字节数。0为不限定，可通过指令ceph osd pool set-quota <poolname> max_ objects|max_bytes <val>设定。
  • quota_max_objects:0，不限定，最大对象个数。

剩下的我也不知道做什么用的，以后用到了再说吧。

这个是一个数组，记录着OSD的状态信息：

• • osd: OSD的ID值。
  • uuid: OSD的UUID，这是OSD在Ceph集群中的UUID，和磁盘的UUID是没有关系的。
  • up: UP为1，DOWN为0。
  • in: IN为1， OUT为0。
  • up_from: 后面的数值是epoch值，OSD使用epoch来记录状态变化。
  • public_addr: 公网IP，和MON沟通用的。
  • cluster_addr: 内网IP，用于副本的1->3的克隆，recover等。

给个截图吧：

剩下的都是空的。

这个是每个pool的读写速率和恢复速率，以数组形式组织，监控必备！

恢复对象数，注意如果没有恢复则为空，Python解析需要附空值。

• misplaced_ratio:需要迁移的对象比例。
• misplaced_objects:需要迁移的对象个数。

恢复速率，也可能为空。

• recovery_objects_per_sec: 不用解释了，需要监控。
• recovery_bytes_per_sec: 主要监控的值。

每个pool的读写速度。可能为空。

• read_bytes_sec:读速度。
• write_bytes_sec:写速度。
• read_op_per_sec: 读OP。
• write_op_per_sec: 写OP。

这个指令给出了集群的数据使用量和每个pool的使用量：

- `total_bytes`: 集群总共的字节数，163TB。
- `total_used_bytes`:  使用的字节数，12.8TB。
- `total_avail_bytes`:  剩余字节数，150.7TB。

是个数组

• • name: pool名称。

  • id: pool的ID，依旧和索引无关。

  • stats
    

    :

    • bytes_used: pool的使用量。
    • objects：pool内的对象数。

数据结构比较简单，在osd_perf_infos下面是一个数组，数组里面有OSD的ID，还有一个perf_stats，里面是commit和apply的延时。

主要查看OSD的使用率，不需要监控的比较频繁，一小时一次就够了。

这里面是OSD的数组，信息如下，OSD的权重等信息都在里面，我主要关心的就是一个使用率:utilization,至于pgs在新的jewel里面才有，之前的hammer是没有的：