白话运维监控系统-1.1 运维监控系统概述

写在前面

笔者从Open-Falcon开源到现在，从事运维监控领域相关工作差不多7年，在做Open-Falcon和Nightingale的社区答疑过程中发现，有大量的小白问题，很多是因为对这个领域缺乏基础认识，所以，想写一个针对入门级用户的系列文章，做一下知识的普及。

另外，监控这个事情，其实也是研发人员走到某个段位之后必须要了解的。因为监控是稳定性体系建设中最重要的一环，普通研发人员往架构师转变，需要了解更多横向的知识，比如持续集成、服务治理、稳定性保障等等，所以了解一下监控，也很有必要。

这是一个很公益的事情，希望大家一起参与讨论，分享经验，为小白领路，功德无量~

监控的价值

监控是保障业务稳定性的重要手段，那怎么提升稳定性呢？简单来说，就是减少故障，一个是减少故障的数量，一个是减少单一故障的影响时长，即出现故障后快速止损。减少故障这个方面，更多的要诉诸于鲁棒的业务系统架构和稳定的基础设施，监控在这个方面没有办法提供太多助力。对于减少单一故障的影响时长，监控是非常有价值的。

在出现故障时，监控系统可以及时感知，及时发告警通知相关人员，让值班的人快速响应，处理故障。处理故障的第一步就是要定位问题，定位问题需要有数据支撑，监控系统的另一个重要职能，就是要提前收集详实的数据，比如日志数据、指标数据等等。

另外，有人可能会想，监控系统能不能通过数据分析手段，提前预测未来可能发生的故障，不要等到故障发生了才来通知我。这个想法很性感，但是，现实很骨感，据笔者了解，业界目前有这方面的尝试，但是场景相对有限，姑且可以作为一个噱头跟不懂的老板吹牛吧。

监控都是在监控什么

监控分很多方向，总体来看，所有影响终端用户使用体验的方面，都可以考虑增加监控。比如某个手机app的产品，要监控哪些东西？比如：app本身是不是crash了、app是不是有卡顿、app到服务端的网络链路是不是质量差了、服务端公网出口是不是拥塞了、多个机房之间专线是不是抖动了、服务提供的接口成功率是不是下降了、服务依赖的第三方组件是不是挂了、机器负载是不是太高了、磁盘空间是不是满了、系统是不是打印了一些错误日志、硬件是不是产生了故障事件，等等等等

笔者主要精力在服务端监控，要监控的方向整体如下：

基础设施类：网络链路、网络设备、硬件、操作系统
存储中间件：MySQL、Redis、RabbitMQ、Kafka、Tomcat、Zookeeper、Ceph等等等等
应用层监控：接口QPS、成功率、延时等
业务层监控：订单量、交易支付量、在线用户量等等

监控系统分类

监控大致分四个方向：指标监控、日志监控、链路追踪、事件监控，即metrics、logging、trace、event。指标监控相关的开源软件比如：Zabbix、Prometheus、Open-Falcon、Nightingale，日志监控相关的开源软件比如：ELK、Grafana Loki，链路追踪相关的开源软件比如：Zipkin、Skywalking，事件监控相关的开源软件比如：呃，笔者没找到专门针对这个方向的开源软件。

指标监控主要是监控数值类型的时序数据，比如某个机器的CPU空闲率、某个机器的内存使用率、某个接口的QPS，这些数据通常是按照一个固定的频率采集上报给监控系统，上报的时候会带上指标名字、时间戳、值等信息。

日志监控主要是收集日志的，比如操作系统日志、各类中间件的日志、业务系统打印的日志，日志收集到中心之后，提供检索分析能力，可以从日志中提取到一些指标，辅助业务决策，也可以用这些指标做告警。

链路追踪即Trace，是说把用户端触发的一次请求，分配一个requestid，这个请求相关的所有的模块，都可以用这个requestid串联起来，然后我们就可以拿着这个requestid，去追踪这个请求，看这个请求流经的各个模块的耗时情况、成功失败情况。

事件监控比较典型的是ipmi吐出的硬件故障事件，或者交换机trap事件，或者在应用程序的逻辑里遇到一个异常状况，也可以生成一个事件，所有的事件统一发给事件监控管理系统，在这个系统里做分类通知、合并降噪等。

其中，指标监控系统通常是最基础的监控系统，也是笔者最有经验的一个系统，后续的文章大都是围绕指标监控的体系来进行讲解。

---

欢迎大家转发、参与讨论、分享经验~