基础监控系统建设

3字数 2730阅读 2754

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

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

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

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

一般监控系统的功能

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

可视化绘图

告警配置页面

看图的功能,在看单张图的基础上,大部分监控系统会定制一个监控大盘的功能,将多张定义好的监控图,放在一个页面,记录一个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

数据采集的原则

数据采集,说起来比较简单,只要把数据报上来就行,具体怎么采集,那就八仙过海各显神通了。

但是我们作为平台的设计者,必须要考虑标准化与规范化。

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

Open-Falcon数据模型

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

采集标准化一览

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

我们采集端口、进程、日志、流量的各方面数据的方式,这个做好标准之后,监控的数据就会很规范。

我们在一个业务线所做的稳定性建设方案,就可以无缝地迁移到另一个业务线,无需重复造轮子,而且是摸索很久之后的最佳实践。

存储建设的关键点

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

  • 功能

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

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

open-falcon的索引是放在MySQL里的,而且数据结构比较固定,在这方面的能力还有待加强。

笔者公司为了满足需求,是自建了一套索引模块的。

  • 性能

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

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

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

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

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

  • 容量

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

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

绘图功能的考量

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

监控与服务树的打通
  • 与资源管理(服务树系统)打通

监控系统,看的是机器的资源与运行的服务情况。

资源管理,管理的是资源的归属情况。

因此,通过资源管理树,快速筛选出机器列表,进而一键查看监控图,可能是每个公司都会有的需求。

监控看图案例
  • 数据横向的比较

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

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

  • 数据纵向的聚合

假设我有一个节点,下有十台机器,我显示这十台机器的情况,就要有十条曲线。但我现在想要看一个整个节点的总体情况,那曲线的聚合,就必不可少了。

可以通过将多条曲线,同一时刻的数据相加或者求平均,来进行数据的聚合,用以体现出一个总体的情况。

如何让报警能力更加强大

告警一般来讲,需要两部分数据,一部分是配置数据,一部分是监控数据。

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

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

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

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

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

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

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

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

监控的稳定性架构

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

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

使用消息队列来应对流量潮汐

在数据上报的链路建设中,可以考虑使用消息队列来应对流量的潮汐。因为监控数据的上报,尤其是用户自定义数据的上报,很可能不是均匀的,会与流量、业务峰谷有关。

此时,通过一个消息队列,来缓冲大批量的没有时间处理的数据,是一个不错的选择。

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

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

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

告警其实是比较难做双活的,尤其是alarm这种报警的收敛模块。

因为双活意味着两份,两份服务,也意味着同一条报警发两次。这明显不符合预期。

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

以上就是笔者关于监控系统的一些建设心得的大纲,后续笔者会针对每一个方向写一篇深入的专题。

欢迎大家随时讨论交流。

推荐阅读更多精彩内容