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

简介:

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

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

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

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

一、一般监控系统的功能

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

be55de45805d717acb3b195a3d121fc1c7c3d2d0

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

7479e56c42f0bb4cfca59d740092ac7daf565178

Open-Falcon监控大盘

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

二、监控系统模块拆解

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

05c0f8aace60561825c2157113d092efb0b9e4ff

Open-Falcon架构图

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

9393b1389193d65f1b63d1e460ede18c0386e9bc

一般监控系统架构图

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

 ●  采集: 对应Open-Falcon的Agent以及App library;
 ●  存储: 对应Open-Falcon的Transfer、Query和Graph;
 ●  告警: 对应Open-Falcon的Judge、Alarm;

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

1、数据采集的原则

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

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

54b119e05769271fa7d24d3799a834abd419b8f5

Open-Falcon数据模型

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

2447742a5b70bc4a505a435be7d8ad411bfc6be5

采集标准化一览

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

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

2、存储建设的关键点

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

功能

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

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

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

性能

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

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

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

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

容量

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

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

3、绘图功能的考量

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

65de9095b434cce771c3e84e3e9a458ec521983c

监控与服务树的打通

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

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

770d2cfd178fc6636e1c33187df6dea149f741e4

监控看图案例

数据横向的比较

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

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

数据纵向的聚合

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

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

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

 ●  配置数据, 其获取见仁见智,不涉及性能问题,可以通过队列来通知,也可以定时拉取,只要保证好一致性和实时性就好了。
 ●  监控数据, 其获取一般来讲,分为“推”和“拉”两种模式:

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

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

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

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

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

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

三、监控的稳定性架构

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

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

b42d4a2c3bb9182e40c23c7cabe71739fb80e4c4

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

13bce17a8edb87e70177fd735da02e0e9d49de13

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

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

7b59feea8372510324cb8e781b8a0eeb08ea241f

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

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

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

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

Q & A

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

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

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

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


原文发布时间为:2018-11-15

本文作者:高家升

本文来自云栖社区合作伙伴“DBAplus社群”,了解相关信息可以关注“DBAplus社群”。

相关文章
|
2月前
|
运维 安全 程序员
纵横“光明顶”,全靠这份全网独一份《数据中心设施运维指南》
数据中心设施运维,经常被与数据中心IT系统运维混为一谈。实际上,两者的工作虽然都以保证IT系统的可用性为最终目标,但在工作对象上,却是截然不同的。IT运维本质上是和比特(bit) 打交道,设施运维则主要和瓦特(Watt)打交道。
|
9月前
|
运维
《云上大型赛事保障白皮书》——第七章 保障阵型与流程管理——7.2 云上大型赛事流程管理——7.2.2 北京冬奥应急流转流程
《云上大型赛事保障白皮书》——第七章 保障阵型与流程管理——7.2 云上大型赛事流程管理——7.2.2 北京冬奥应急流转流程
|
安全 数据安全/隐私保护
|
运维 监控 数据中心
《JoyEye:京东大规模数据中心网络运维监控之眼》电子版地址
JoyEye:京东大规模数据中心网络运维监控之眼
79 0
《JoyEye:京东大规模数据中心网络运维监控之眼》电子版地址
《以架构视角解读和落实银行数字化转型的两份重磅指导文件》下载地址
2021年12月和2022年1月,两份关于银行数字化转型的重量级指导文件—中国人民银行的《金融科技发展规划(2022—2025 年)》和银保监会的《关于银行业保险业数字化转型的指导意见》先后印发,这对在积极筹备数字 化转型工作的各类银行而言,正是 2022 年开年布局的最好指导。两份文件都对银行的数字化转型提出了具体要求,二者各各有侧重、相辅相成、有机融合。
58 0
《以架构视角解读和落实银行数字化转型的两份重磅指导文件》下载地址
《以架构视角解读和落实银行数字化转型的两份重磅指导文件》下载
2021年12月和2022年1月,两份关于银行数字化转型的重量级指导文件—中国人民银行的《金融科技发展规划(2022—2025 年)》和银保监会的《关于银行业保险业数字化转型的指导意见》先后印发,这对在积极筹备数字 化转型工作的各类银行而言,正是 2022 年开年布局的最好指导。两份文件都对银行的数字化转型提出了具体要求,二者各各有侧重、相辅相成、有机融合。
60 0
《以架构视角解读和落实银行数字化转型的两份重磅指导文件》下载
|
移动开发 安全 小程序
顶象特别策划 | 2022双十一业务安全保卫战即日启动
各位白帽黑客们,来一场酣畅淋漓的正义守卫战吗?
99 0
顶象特别策划 | 2022双十一业务安全保卫战即日启动
|
Kubernetes 网络协议 容灾
关于高可用系统建设的一些思考——面向职场新兵的指南
高可用对于软件系统来说是很重要的一环,搭建一个高可用系统主要有哪些步骤呢?在参与公司几个多数据中心项目的容灾架构设计和落地后,积累了一些高可用和多数据中心容灾的实践经验和一些思考,希望总结和分享出来和大家一起学习。
208 0
关于高可用系统建设的一些思考——面向职场新兵的指南
|
人工智能 搜索推荐 小程序
面对疫情,如何用移动营销撬动线上业务
作为一款源于支付宝智能科技的APP运营平台,mPaaS已经积累了银行、政务、交通、零售等众多行业的成功客户案例,累计服务超过1亿终端用户。
1263 0
面对疫情,如何用移动营销撬动线上业务
|
流计算 监控 微服务
监控系统哪家强?eBay 在监控系统上的实践应用!
本文将分享监控系统 Flink 的现状,具体讲述 Flink 在监控系统上的实践和应用,希望给同业人员一些借鉴和启发。
监控系统哪家强?eBay 在监控系统上的实践应用!

相关产品

  • 云迁移中心