Ceph 集群状态监控细化

需求
在做Ceph的监控报警系统时,对于Ceph集群监控状态的监控,最初只是简单的OK、WARN、ERROR,按照Ceph的status输出来判断的,仔细想想,感觉这些还不够,因为WARN、ERROR状态中,是包含多种状态的,如果在大晚上收到一条关于Ceph health的报警信息,只知道了集群有问题,但具体是什么问题呢,不得而知。这个事情发生在工作时间,就还好处理,直接到Ceph环境中查看一下就OK。但是在晚上,有些报警没有那么紧急,可以第二天再处理。所以,就需要细化这些健康状态。

因此,从代码中将HEALTH_OK、HEALTH_WARN、HEALTH_ERR的相关描述输出拉出来,进行判断,分类处理,然后用状态码(status code)的方式来进行Level化。

Ceph本身的健康状态信息:
HEALTH_WARN:

集群健康状态描述信息 代表的现象
Monitor clock skew detected 时钟偏移
mons down, quorum Ceph Monitor down
some monitors are running older code 部署完就可以看到,运行过程中不会出现
in osds are down OSD down后会出现
flag(s) set 标志位设置,可以忽略
crush map has legacy tunables 部署完就可以看到,运行过程中不会出现
crush map has straw_calc_version=0 部署完就可以看到,运行过程中不会出现
cache pools are missing hit_sets 使用cache tier后会出现
no legacy OSD present but 'sortbitwise' flag is not set 部署完就可以看到,运行过程中不会出现
has mon_osd_down_out_interval set to 0 将mon_osd_down_out_interval参数设置为0会出现,这个参数设置为0,和noout效力一致
'require_jewel_osds' osdmap flag is not set 部署完就可以看到,运行过程中不会出现
is full pool满后会出现
near full osd OSD快满时警告
unscrubbed pgs 有些pg没有scrub
pgs stuck PG处于一些不健康状态的时候,会显示出来
requests are blocked slow requests会警告
osds have slow requests slow requests会警告
recovery 需要recovery的时候会报
at/near target max 使用cache tier的时候会警告
too few PGs per OSD 每个OSD的PG数过少
too many PGs per OSD 每个OSD的PG数过多

pgp_num pg_num大于pgp_num
has many more objects per pg than average (too few pgs?) 每个Pg上的objects数过多
HEALTH_ERR:

集群健康状态描述信息 代表的现象
no osds 部署完就可以看到,运行过程中不会出现
full osd OSD满时出现
pgs are stuck inactive for more than Pg处于inactive状态,该Pg读写都不行
scrub errors scrub 错误出现,是scrub错误?还是scrub出了不一致的pg
当前监控代码中处理
从上述输出里选出所有关键的几项,作为一些单独的状态码,也就是只关注这些,其他的要么运行过程中不出现,要么目前没有使用,即忽略。

Ceph Health Status Code:

代码 10进制数值
其他警告 0
HEALTH_OK 1
HEALTH_CLOCK_SKEW = 1 << 1 2
HEALTH_NEAR_FULL = 1 << 2 4
HEALTH_FULL = 1 << 3 8
HEALTH_SLOW_REQUEST = 1 << 4 16
HEALTH_PG_STALE = 1 << 5 32
HEALTH_SCRUB_ERROR = 1 << 6 64
注: 在报警的描述中增加基本的状态码说明:

ceph cluster not health; clock skew:2,nearfull:4,full:8,slow_request:16,pg_stale:32,scrub_error:64,others:0

链接
https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2/html/troubleshooting_guide/initial-troubleshooting

具体代码
附:

注: 每行最后含detail的,说明是ceph health detail能看到的描述
HEALTH_WARN:

【Monitor.cc:】
Monitor clock skew detected

【MonmapMonitor.cc:】
mons down, quorum
is down (out of quorum) [detail]
some monitors are running older code
only supports the "classic" command set [detail]

【OSDMonitor.cc:】
osd." << i << " is down since epoch [detail]
in osds are down
flag(s) set
crush map has legacy tunables (require
see http://ceph.com/docs/master/rados/operations/crush-map/#tunables [detail]
crush map has straw_calc_version=0
see http://ceph.com/docs/master/rados/operations/crush-map/#tunables [detail]
with cache_mode needs hit_set_type to be set but it is not [detail]
cache pools are missing hit_sets
no legacy OSD present but 'sortbitwise' flag is not set
has mon_osd_down_out_interval set to 0
this has the same effect as the 'noout' flag [detail]
'require_jewel_osds' osdmap flag is not set
is full
near full osd

【PGMonitor.cc:】
current state/last acting [detail]
ops are blocked > [detail]
deep-scrubbed, last_deep_scrub_stamp [detail]
unscrubbed pgs
pgs stuck
min_size from / may help; search ceph.com/docs for 'incomplete [detail]
requests are blocked >
osds have slow requests
recovery
objects at/near target max [detail]
B at/near target max [detail]
at/near target max
too few PGs per OSD
too many PGs per OSD

pgp_num
has many more objects per pg than average (too few pgs?)

HEALTH_ERR:

【OSDMonitor.cc:】
no osds
full osd

【PGMonitor.cc:】
pgs are stuck inactive for more than
scrub errors

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,204评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,091评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,548评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,657评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,689评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,554评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,302评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,216评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,661评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,851评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,977评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,697评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,306评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,898评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,019评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,138评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,927评论 2 355

推荐阅读更多精彩内容