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

写在前面

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

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

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

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

监控的价值

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

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

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

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

监控都是在监控什么

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

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

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

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

监控系统分类

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

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

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

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

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

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


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