写点什么

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

用户头像
运维散兵
关注
发布于: 2021 年 04 月 25 日


写在前面

笔者从 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 事件,或者在应用程序的逻辑里遇到一个异常状况,也可以生成一个事件,所有的事件统一发给事件监控管理系统,在这个系统里做分类通知、合并降噪等。


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




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

发布于: 2021 年 04 月 25 日阅读数: 89
用户头像

运维散兵

关注

还未添加个人签名 2017.09.11 加入

还未添加个人简介

评论

发布
暂无评论
白话运维监控系统-1.1 运维监控系统概述