一份来自滴滴运维工程师的监控系统建设心得

高家升 2018-11-15 10:10:47

本文根据dbaplus社群第169期线上分享整理而成

 

监控,是运维的眼睛,是稳定性建设中最重要的一环。

 

一般来讲,基础监控系统的主要功能就是发现问题。

 

故障发生前,通过监控的看图巡检,发现隐患;故障发生时,通过实时的告警,快速发现问题,定位问题所在;故障发生后,使用过去的历史数据图表,进行事后复盘,避免下次发生。

 

本篇文章,我们不讨论根因定位、故障自愈之类的高端主题,只跟大家聊一下笔者关于基础监控系统的一些建设心得。

 

一、一般监控系统的功能

 

一般的基础监控系统,主要有看图和告警两大功能,通过这两大功能,满足上述的发现问题的需求。

 

 

 

看图的功能,在看单张图的基础上,大部分监控系统会定制一个监控大盘的功能,将多张定义好的监控图,放在一个页面,记录一个URL,每次只要打开这个URL,就能看到自己定义好的所有监控图。

 

Open-Falcon监控大盘

 

监控大盘主要适合运维定时巡检的场景。比方说,运维同学把所有业务的核心指标都放在一个监控大盘里,每天早上只要打开这个页面,就可以看到自己业务最核心指标的情况,流量变化、稳定性隐患,一目了然。

 

二、监控系统模块拆解

 

我们以Open-Falcon架构图为例,其实这张图看起来复杂,拆解起来却很简单:

 

Open-Falcon架构图

 

绿色的实线是数据的上报流;橙色的虚线是策略的分发流;蓝色的虚线是看图的数据流。

 

一般监控系统架构图

 

整体来看,一般的监控系统分为四部分:

 

  • 采集:对应Open-Falcon的Agent以及App library;

  • 存储:对应Open-Falcon的Transfer、Query和Graph;

  • 告警:对应Open-Falcon的Judge、Alarm;

  • 绘图:对应Open-Falcon的Dashboard。

 

 

1、数据采集的原则
 

 

数据采集,说起来比较简单,只要把数据报上来就行,具体怎么采集,那就八仙过海各显神通了。但是我们作为平台的设计者,必须要考虑标准化与规范化。

 

标准化,即抽象出统一的数据模型,用以支持各种自定义的采集数据。

 

Open-Falcon数据模型

 

这里值得一提的是,确定统一的数据模型,非但不会影响各种自定义的采集需求,反而能更灵活的支撑各种自定义的需求。

 

采集标准化一览

 

另一个需要注意的,就是采集方式的标准化。

 

我们采集端口、进程、日志、流量的各方面数据的方式,这个做好标准之后,监控的数据就会很规范。我们在一个业务线所做的稳定性建设方案,就可以无缝地迁移到另一个业务线,无需重复造轮子,而且是摸索很久之后的最佳实践。

 

2、存储建设的关键点
 

 

存储的建设,我觉得很重要的有三点:

 

功能

 

从功能上来讲,数据的存储比较简单,只要能存取时间序列数据即可,这一点,业界所有的时序数据库都可以做到。

 

但是,高端的绘图能力和强大的告警能力,大都会依赖动态的tag关联补全,这个索引能力要根据设计的功能来酌情建设。

 

Open-Falcon的索引是放在MySQL里的,而且数据结构比较固定,在这方面的能力还有待加强。笔者公司为了满足需求,是自建了一套索引模块的。

 

性能

 

一般来讲,我们自己建设一套时间序列存储,成本还是很高的。因此对于大多数同学来说,大家经历的都是时间序列数据库的选择。

 

大家在选择合适的时序数据库时,在性能上主要要考虑两点:

 

  • 一是数据的读写性能,尤其是并发读写时的性能,在建设之出,要做好压测和QPS的容量规划。

  • 二是监控的时序数据必须要做好降采样,也就是数据的定时归档。将过去一段时间的N个点,聚合成一个粗时间粒度的点。这里要注意,千万不要做定时任务,InfluxDB的定时降采样会带来非常大的CPU高峰,对于要应对高并发查询和写入的监控存储来说,这种性能的潮汐是非常危险的。

 

降采样这一点,Open-Falcon底层的RRDTool技术就非常优秀,采用的是写时降采样,数据点在写入的过程中,降采样已经做好了,虽然会一定程度上带来一点性能消耗,但不会出现性能的瓶颈。

 

容量

 

无论什么样的存储,无论效率和压缩比有多高,总是会满的。这种时候,扩展就变成了一个绕不过去的命题。

 

关于容量方面,要强调的是,必须要有分布式的架构,可以随时扩容。

 

3、绘图功能的考量
 

 

绘图功能的定制,因人和业务而异。从笔者公司的建设经验来看,给大家三条建议:

 

监控与服务树的打通

 

与资源管理(服务树系统)打通

 

监控系统,看的是机器的资源与运行的服务情况;资源管理,管理的是资源的归属情况。因此通过资源管理树,快速筛选出机器列表,进而一键查看监控图,可能是每个公司都会有的需求。

 

监控看图案例

 

数据横向的比较

 

在一张监控图中,同时显示当前与一段时间的环比,是一种发现问题的非常好的手段。

 

如上图,绿线代表今天的数据情况,蓝线代表一天前,红线代表7天前,通过对趋势的比较,可以很容易把握住服务的状态,哪里出问题一目了然。

 

数据纵向的聚合

 

假设我有一个节点,下有十台机器,我显示这十台机器的情况,就要有十条曲线。但我现在想要看一个整个节点的总体情况,那曲线的聚合就必不可少了。可以通过将多条曲线,同一时刻的数据相加或者求平均,来进行数据的聚合,用以体现出一个总体的情况。

 

4、如何让报警能力更加强大
 

 

告警一般来讲,需要两部分数据:

 

  • 配置数据,其获取见仁见智,不涉及性能问题,可以通过队列来通知,也可以定时拉取,只要保证好一致性和实时性就好了。

  • 监控数据,其获取一般来讲,分为“推”和“拉”两种模式:

 

推模式——告警数据在上报时,自动推往告警模块

 

这种模式最大的一个优点就是实时性好,因为报警的模块可以第一时间拿到这个数据。

 

但是“推模式”有很致命的缺点:首先数据是全量灌过来的,解析和暂存会消耗大量的内存;而且这种模式,报警模块只能按照数据来进行分片,如果需要聚合场景计算,很可能这部分数据推往了不同的报警节点,就无法满足了。

 

拉模式——由告警模块定时从存储拉取监控数据

 

“拉”模式最大的好处在于,报警分片可以按照策略来分片,这样报警模块只需要拉取自己需要的数据即可,而且可以完美支持聚合场景,减少了很大一部分内存消耗。

 

而“拉模式”的缺点在于,监控的数据体量非常庞大,高并发的查询会对存储集群造成极大的压力。此处如果出现性能瓶颈,可以考虑监控数据的冷热分离。

 

三、监控的稳定性架构

 

监控系统,是稳定性工作的基石。如果监控系统都不够稳定,那我们依赖监控系统进行稳定性建设就无从谈起。

 

最后,给大家分享几个笔者公司在建设监控系统时的稳定性架构,有问题大家可以随时指出:

 

 

在数据上报的链路建设中,可以考虑使用消息队列来应对流量的潮汐。因为监控数据的上报,尤其是用户自定义数据的上报,很可能不是均匀的,会与流量、业务峰谷有关。此时通过一个消息队列来缓冲大批量的没有时间处理的数据,是一个不错的选择。

 

双活可应对实例故障与专线断开

 

存储的稳定性,可以考虑数据双写。两个集群分开部署。可以应对专线断开以及分片挂掉两种情况。

 

告警的稳定性可考虑主从模式

 

告警其实是比较难做双活的,尤其是Alarm这种报警的收敛模块。因为双活意味着两份,两份服务,也意味着同一条报警发两次。这明显不符合预期。

 

因此,对于告警体系,给大家推荐我们的主从模式:从集群平时处于休眠状态,会定时的对主集群进行探测,一旦发现主集群挂掉,或探测不通,就将自身拉起,达到一个故障时间内的双活。

 

以上就是笔者关于监控系统的一些建设心得的大纲,欢迎大家下方留言讨论交流。后续会针对每一个方向写一篇深入的专题,欢迎继续关注dbaplus社群内容分享。

 

Q & A
 

 

Q1:请问你们的服务器都在机房还是云?针对阿里云上的服务器有什么好的办法采集吗?

 

A:监控的标准化做好之后,无论是物理机还是云服务器,都是一样的。只是数据上报的通路可能需要费心建设。云主机理论上也可以通过部署Agent的方式来进行采集,监控系统也最好放在他们本机房内。或者如果网络资源允许,数据回源也是一个不错的选择。

 

Q2:对于中小企业监控建设有什么建议吗?比如从哪开始,如何进化?

 

A2:中小企业、人力资源、服务器资源都会有建设的掣肘。因此我建议前期先采用开源的解决方案,理论上可以支撑公司发展很长一段时间。开源的Open-Falcon和Zabbix都是不错的选择。当机器数量超过5k或者公司业务发展已经明显感觉到监控系统功能不够的时候,可以再进行一次全面的重构。

 

直播回放
 

 

https://m.qlchat.com/topic/details?topicId=2000002389477419

活动预告