整理一些有关监控的一些事情

整理一些有关监控的一些事情

四月 09, 2019

之前整理过现在线上使用的监控搭建过程,然鹅当时并没有深入理解,只是会照葫芦画瓢的搭建出来使用而已,近期线上出现了一些有关监控方面的问题才开始深入去了解

现在监控的架构是这样的;

1
2
3
4
collectd+graphite+grafana

graphite数据流向
collectd(收集数据可以配置使用哪些监控项) ----> carbon-c-relay(过滤聚合转发) ----> go-carbon(存储设置) ----> graphite(whisper、uswgi、nginx) ----> granfana(展示)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
问题一 carbon-c-relay :

现在版本: carbon-c-relay-1.10-1.el6.x86_64.rpm

发现问题:程序崩溃

系统报错:

Feb 3 03:10:03 ip-10-33-3-12 kernel: [8905913.334999] carbon-c-relay[5707]: segfault at 2fce8 ip 000000000040dacf sp 00007f9ecaf5bcd0 error 6 in carbon-c-relay[400000+17000]
Feb 3 03:10:03 ip-10-33-3-12 kernel: [8905913.359297] carbon-c-relay[5708]: segfault at 2fcf0 ip 000000000040dacf sp 00007f9eca75acd0 error 6 in carbon-c-relay[400000+17000]
Feb 3 03:10:03 ip-10-33-3-12 kernel: [8905913.377903] carbon-c-relay[5709]: segfault at 2fcf8 ip 000000000040dacf sp 00007f9ec9f59cd0 error 6 in carbon-c-relay[400000+17000]
Feb 3 03:10:03 ip-10-33-3-12 kernel: [8905913.393349] carbon-c-relay[5710]: segfault at 2fd00 ip 000000000040dacf sp 00007f9ec9758cd0 error 6 in carbon-c-relay[400000+17000]

carbon-c-relay: *** Error in `/usr/bin/carbon-c-relay': corrupted double-linked list: 0x00007fbde00a4740 ***、


升级版本: carbon-c-relay-2.6-1.el6.x86_64.rpm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
问题二 IOPS :
问题原因: 服务器发送数据多,每当触发数据库操作,gamex就会发送一条数据到go-carbon,go-carbon一直处于读写状态,IO处理不过来,机器CPU正常,内存正常,但是load高,是因为写磁盘压力大

[root@ip-10-33-3-152 whisper]# iostat -x 2
Linux 3.14.48-33.39.amzn1.x86_64 (ip-10-33-3-152) 03/29/2019 _x86_64_ (4 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
5.99 0.00 3.42 28.05 0.14 62.41

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvda 0.01 56.77 1.09 144.61 45.80 1639.67 11.57 0.02 0.14 0.00 0.07
xvdf 0.10 653.70 62.43 1524.71 1069.56 17813.12 11.90 0.02 0.01 0.01 2.37

avg-cpu: %user %nice %system %iowait %steal %idle
6.97 0.00 2.19 68.13 0.39 22.32

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
xvda 0.00 1.50 0.50 1.00 8.00 20.00 18.67 0.00 0.00 0.00 0.00
xvdf 1.50 2457.50 595.00 3657.50 8672.00 49832.00 13.76 133.24 31.67 0.24 100.00

发现问题: go-carbon进程奔溃

解决办法: 磁盘为700G IOPS原来是3000,调高了磁盘的IOPS为4000,情况稍有缓解但并没有彻底解决,go-carbon进程每隔一段时间依旧会挂掉,等维护时更新了服务器,减少了一半的数据发送,磁盘的读下降,写升高。进程奔溃的问题才得以解决,但go-carbon占用系统的CPU依旧不低,大概在70%-80%左右。
1
2
3
4
5
6
7
8
9
10
11
12
13
问题三 go-carbon升级 and 修改storage存储策略 :
问题原因: 监控部分数据只能保留7天,当线上出现问题想要看近一个月的监控数据走向时很不方便
现在版本: go-carbon-0.8.1-1.el6.x86_64.rpm
升级版本: # rpm -Uvh go-carbon-0.13.0-1.x86_64.rpm (为了减小对监控业务使用的影响使用了 rpm -Uvh 直接升级)
go-carbon从 0.10版本 以后就更改了很多配置文件的路径,具体版本更改了什么可以到github上查询 https://github.com/lomik/go-carbon/releases ,go-carbon升级后发现磁盘的IOPS恢复了正常值,系统的load也降低了,go-carbon占用系统CPU在30%-40%,可能作者对go-carbon做了优化~~~~

再来说storage-schemas.conf存储策略的问题,因为之前更改了好几次发现并没有生效,数据依旧只能保留7天,因此还给go-carbon提了一个issue...
其实是这样的,查了一些文档和别人使用的一些经验得知 :
“ whisper是一个固定大小的数据库,所以当 storage-schemas.conf 设定以后,一个metrics所占的磁盘空间就已经确定了。在系统运行的周期中只要根据 metrics 的增加进行适当扩容即可 ” “ storage-schemas.conf修改以后对于已经在磁盘上进行记录的Metrics不会生效,需要删除数据重新写入或者进行数据迁移才行 ” “ 修改完毕,页面指标数据依然保持一天的量,当时想当然的以为需要重启graphite使配置生效。后来验证表明,调整这里的配置后,必须删除以前生成的wsp文件,生成新的wsp文件后方可生效。 ”

大概是因为监控搭建初期,其中部分数据设定值就是保留7天,所以我将collectd下的数据备份后全部删除,使其发送过来的数据全是新生成的,期待能看到第8天的数据。。。

还有有关我给go-carbon提了一个issue,报错是一条“bad message”,是因为carbon不支持存储 “nan”格式的数据

gocarbon.png