微信号:Cloudify

介绍:高可用、分布式系统研究,数据中心技术以及生产环境最佳实践,云计算前沿技术剖析

贵司的监控系统处于什么时代?

2016-03-11 15:56 吕宏利

说到监控,开发的同学可能会说不就是开发应用的时候多打几条日志,然后运维同学写脚本统计分析某个关键字出现的次数,如果一定时间内某关键词出现次数超过设定的阈值就发邮件或短信告警吗。

没错,这就是基本的逻辑。但是如果你们公司的监控像这位开发同学描述的一样,那我只能说你们的监控如果用人类社会的发展阶段来说,还处于原始社会。

根据系统的完善程度,我把监控系统简单的划分成三个阶段:

  • 原始社会

  • 工业时代

  • 信息时代


TL; DR 如果你认为公司的监控系统已经非常好了,你可以移步他处了;如果你觉的公司的监控系统还有需要改善的地方,请继续读,保证读有所值。


准备知识

在介绍监控系统之前,有两个至关重要的概念需要先讲清楚:第一个是时间序列,第二个是监控类型。


时间序列

简单定义就是数据格式里包含时间字段的数据,一般和某一个目标关联,且2个数据点按固定时间间隔分开。时间序列被用于不同学科,在监控中目标一般是监控的某一指标,比如系统负载的每分钟采样。绝大部分监控系统采集数据后,是用时间序列的方式存储监控数据。


监控类型

监控分为两种:白盒还是黑盒。

白盒监控善于发现系统中单个组件的问题,但是很难覆盖系统端到端的健康检查。

黑盒监控可以提供最接近真实用户的系统端到端的检测。


准备知识介绍完了,进入正题,这篇文章主要讲白盒监控

谈到监控,为什么我们一般会说“监控系统”呢?是因为做好监控需要有一个完善的生态系统来支撑。基本的监控系统需要具备以下功能:数据采集、数据存储、数据展示、异常触发、报警发送。


数据采集

以被监控对象为行为主体,数据采集主要有2种模式,分为:主动推送和被动拉取,这两种采集方式各有利弊。


主动推送

优点

  • 不存在目标发现问题,新应用上线后自动可以加入监控

  • 监控系统架构简单,应用只需调用接口上报数据即可

缺点

  • 缺乏准确的需要监控的目标数

  • 难以区分合法和非法的数据上报(权限验证可以有所帮助)

  • 当数据没有准时推送时,监控很难判断是应用overload或者dead了

  • 时钟不同步导致的时间序列对齐问题


被动拉取

优点

  • 所有时间序列都是对齐的

  • 知道需要抓取的准确目标数

  • 容易区分应用overload或者dead,通过记录每次抓取花费的时间

缺点

  • 需要额外机制发现新添加的监控目标

  • 需要更复杂的library或者agent给应用吐数据

  • 难以监控short-live的应用,比如cronjob


上面两种采集方法的缺点都是可以被改善的,取决于愿意为之花费的工程师时间。

总体来说被动拉取方式在体现监控的完备性上更好一些,其最大的短板是监控short-live应用,可以让这些应用主动推送到proxy应用,之后被动拉取。目标发现则可以结合公司内部名字系统实现。


数据存储

时间序列采集之后就是怎么存储的问题了,主流存储有3种方式:

  1. RRD(Round Robin Database)

    老牌的Nagios,collectd和Ganglia采用的是这种存储方式;graphite采用的Wisper也是基于RDD的基本思想设计的。特点是采用基于圆形队列的数据库(Circular buffer based database),数据库大小在系统初始化后是恒定的,不用担心数据存储空间不足。缺点也是在于数据库大小恒定,因此只能保存一定时间的数据,而且时间序列的间隔在数据库初始化后不能调整。另外一个致命的缺点是受单机磁盘限制,当需要监控的规模很大时数据存储和读取瓶颈。

  2. MySQL

  3. Zabbix使用MySQL存储时间序列数据。MySQL也收到单机磁盘大小和性能限制,但是可以通过partition缓解。

  4. No-SQL

    用No-SQL存储时间序列的应用有很多:Opentsdb,kairosdb,newts。使用No-SQL存储时间序列没有单机磁盘限制,数据量大时不存在扩展问题。

时间序列的存储一般不需要考虑数据存储的schema,客户端只通过简单API存取时间序列数据,具体的存储schema由底层存储系统(MySQL or No-SQL)决定,但是不同的存储schema决定了数据查询/展示的性能。

RRD和MySQL都受限于单机磁盘的性能,SSD可以显著提高数据的读取性能,在数据量大时MySQL可以通过partition进行扩展,RRD无法扩展。MySQL虽然可以进行paritition,但是复杂度和维护成本也很高。No-SQL天生就适合存储时间序列,可以提供超大的存储能力和读性能,但是也需要考虑维护成本,如果公司有No-SQL公共服务可以适用,那No-SQL存储时间序列是不二的选择。


数据展示

数据展示需要具备以下绘图能力:

  • 数据汇聚,根据原始数据计算生成新的时间序列并画图

  • 不同时间序列之间的合并计算,一般用来计算比例关系

  • 多条时间序列汇总展示,用来查找事件相关性。

  • 不同的图表样式,针对不同场景

数据展示有2个应用场景:一是提供给运维人员定位问题时使用,需要能够快速的编辑生成新的图表验证猜想,所以需要灵活易用;而是业务人员查看统计数据,需要强大的综合汇总以反映系统总体运行状况。

数据展示有时会涉及大量时间序列的短时间内读取,亦或是很多人同时有绘图查询需要读取数据,底层的数据存储格式是影响查询性能的主要因素。底层数据存储的schema影响查询性能,合理的架构设计能够极大的提升查询性能。

常见的优化点有:

  • 冷热数据分离:近期的数据是最容易被查询的,可以增加内存存储的replica数(Bigtable/HBase),历史数据可以放在硬盘上。

  • downsample:不仅减少存储,也降低了查询成本,但是需要好的策略降低对数据准确性的影响

  • 资源隔离:不同部门时间序列数据存储在不同server上,减少相互影响。


异常触发

数据采集到了,也存储好了,图表展示也没有问题了,但是没人会愿意每天盯着图表去发现问题,根据历史经验,通过定义一些条件触发某些动作的需求应运而生。 这需要一个rule evaluatoin引擎,可以是单独的进程也可以和数据采集集成在一起。输入是时间序列和用户定义的rule,当时间序列符合rule里定义的状态时执行指定的动作,一般的动作包括:执行一个命令(修复脚本),发送定义好的内容到外部系统,等。

对引擎系统的要求有:

  • 规则定制:灵活,强大。因为需要满足不同部门不同应用的需求,必须灵活且强大。

  • 规则依赖:service内部依赖、service外部依赖。很少有大的应用系统不依赖于其他系统,所以异常触发的判断一定要能够根据依赖系统的异常触发情况进行抑制,没有必要因为某个组件的异常而触发一系列其他组件的异常(这些异常根本原因是一个)。


报警发送

异常触发之后,可以自动修复的一定是自动化去解决,当自动化无法解决的异常发生之后,就需要发送警报给人来介入了。

最基本的报警发送是发送邮件,高级一点的可以支撑短信和语音呼叫,现在手机普及了有的公司可能有手机软件可以接收报警信息了。

发送的警报内容一般包含:

  • 发生问题的组件信息

  • 具体的问题描述,是error rate高了还是程序down了

  • 问题的持续时间

高级的报警内容还可能包含:

  • 产生这个警报的时间序列和触发的rule定义

  • 如何处理这个问题的文档链接

  • 如何暂时关闭这个报警(处理需要较长时间,不想再次收到同样的报警)


监控系统的三个时代及特征

监控系统的基本功能在所有时代都差不多,本质的差异在于不同功能模块的实现是否可高度扩展、是否可高度定制、是否服务化,监控系统整体是否形成闭环系统。一般来说,所处时代主要受其监控的集群规模和公司技术水平决定。


原始社会

当需要监控的机器数量在千台左右时,公司重心会放在核心业务功能开发,用于运维方面的开发投入可能没有,这时候一般是直接使用市面上成熟的监控软件,比如Nagios等,此时的监控系统看起来像下面这样。


这时的监控系统有以下特点:

  • 有成熟的社区支持,部署起来很快

  • 支持众多设备种类和协议

  • 监控目标手工添加删除

  • 监控配置手工修改

  • 需要SSH登录或agent在目标机上运行采集脚本

  • 采集脚本简单粗暴

  • 报警触发规则简单

  • 监控粒度在机器层面


工业时代

随着公司业务规模的高速发展,在机器数达到万台左右时,即便是针对市面上现有方案进行过简单的二次开发也难以满足监控的需求。随着机器规模继续增长,一般公司有2个选择,继续对现有解决方案进行深度定制开发,或者自行开发符合公司架构的监控系统。这个阶段的监控系统可以支撑集群规模到几万台机器。

此时的监控系统看起来像这样:


相比于原始社会,此时的监控系统具有以下特点:

  • 成立专门的监控系统开发团队

  • 开始实行监控的标准化,尝试统一公司内部多套监控系统

  • 弱化脚本分析log采集监控数据的功能

  • 开始有agent从被监控应用直接采集数据,尝试采集协议收敛

  • 功能组件开始向分布式方向发展

  • 支持运维人员的轮流值班

  • 监控配置仍需手工修改,但是效率大大提高,轻松部署监控到千台机器


信息时代

监控系统的进化和关注点的演变是伴随着集群管理调度系统和软件开发框架的发展而来的,当公司的集群规模超过10万台的时候,机器本身的监控会逐渐被剥离出去由集群管理团队负责,上层应用更关注于在被分配的可用资源内的健康监控。成百上千个部门都在开发部署应用,对监控系统的要求是前所未有的,能发展到这个规模,公司肯定已经成立了所谓的运维开发部门或者基础设施部门,负责开发通用的监控平台、自动化平台等。此时对监控的需求是能够用最简单的途径尽量实现白盒化的监控,监控系统一定是根据公司的集群管理系统、软件开发框架高度定制的,目的是降低监控需求在开发过程中的负担并且能够支撑庞大的数据收集、存储和展示。在这种需求下,监控系统一定要能够提供灵活而有强大的配置能力才能适应众多应用的不同监控需求。


信息时代的监控系统从工业时代的监控系统进化而来,除了对基本功能进行细分和强化之外,还具有以下特点:

  • 软件库(monitoring library),让开发同学实现零负担的暴露系统运行数据。

  • 支持的数据采集协议进一步收敛,减少到一两种,以简化系统复杂度(对于已经存在各种协议的应用,提供proxy转换为监控系统支撑的统一采集协议)

  • 基本的监控功能服务化,时间序列存储、图表展示、报警发送等都是独立的服务

  • 监控粒度到具体的应用级别,弱化具体机器在监控数据中的影响(比如:应用在不同机器之间的迁移不影响监控数据的连续性,同时又能捕捉到此次迁移动作)

  • 对监控实时性要求提高,对数据丢失的容忍度降低,采集程序需要checkpoint数据到分布式文件系统

  • 增加故障生命周期管理服务,打造完整的闭环系统

  • 专门的监控系统运维团队


这个时代的监控系统足以支撑集群规模达到百万台机器,上亿的监控目标,每天产生的监控数据都以百TB计算。信息时代了之后,监控系统会怎么发展还不好说,但是我们现在可以看到市场上一个明显的趋势,就是监控功能的产品化。


趋势


一站式服务

  • datadog


完整的软件体系

  • Prometheus 


专业化服务

  • Pagerduty:报警发送和故障管理系统

  • opsgenie:报警发送和故障管理系统

  • grafana:图表展示

  • graphite:图表展示

  • influxdata:时间序列的存储

  • opentsdb:时间序列的存储

 
云中慢步 更多文章 2016 上海 GOPS 大会 SRE 图书签售 intel: CAT技术助力数据中心资源隔离 Google:如何分析和定位分布式环境下的慢请求(长尾请求)? Spotify的机器管理进化之路 谷歌生产环境的软件包管理系统
猜您喜欢 来自10位成功IT人士的23条经验教训。 FreeBSD 和 Linux 有什么不同? 图解HTTPS协议加密解密全过程 【技术蛋糕】Java 10大优点—Part3—开源 一种基于动态插件系统的移动测试黑科技