主动出击的监控——系统巡检和业务巡检该怎么做
这段时间负责公司一个软件系统的巡检工作，从最开始的小看，到后来被各种概念、图表趋势搞懵，再到现在懂得一些做巡检工作的门道，了解它的价值所在。
最近越发感受到做阶段总结的重要性，所以就把这阶段的工作经验做了以下总结。
巡检的本质
对于运维工作中的巡检，最准确的英文表达是 proactive monitoring。看到这个单词你也知道了，巡检就是一种积极主动的监控，而我们平常那种部署监控系统然后设置告警的方式，叫做响应式的监控(reactive monitoring)。
所以，巡检的本质就是主动式的监控。至于这个主动，我目前的理解就是要人肉参与了。
巡检/监控的层次
根据巡检的对象，可以把巡检分为四个层次：
-
系统巡检，或者称为基础设施巡检。主要是对服务所在的物理主机或者虚拟机的状态检查。 -
平台巡检，或者称为基础服务/中间件巡检。主要是对业务相关的应用所依赖的底层服务进行巡检，比如数据库、消息队列、注册中心。 -
应用巡检。应用巡检其实可以和上面的平台巡检合并为 服务/应用巡检。只是这里的应用主要针对那些跟业务相关的。 -
业务巡检。业务巡检的对象应该是支撑系统运行的那些关键流程。下面细讲。
巡检的目的
对于系统巡检来说，巡检的目的在于发现系统潜在的 缺陷 和 优化点（如资源使用不饱和），并根据这些信息在下次软件的开发、测试和部署环节进行优化调整。
比如通过检查 内存使用率 发现某个服务存在内存泄露的问题，就可以反馈给开发人员去排查和解决。
比如对于云上的服务器，有些区域的服务器的资源使用率低，或者长期空载，下次部署时就可以做相应的调整。
而对于业务巡检来说，巡检的目的则在于判断业务相关的工作流是否符合预期运行。
正式巡检工作前的准备
熟悉和掌握现有的监控资源
开发人员常提到一句话，“不要重复造轮子”，这句话在做监控时同样适用。
很多情况下，当你要做某个方面的监控时，并不总是需要从头开始做的。你想要实现的很多监控指标，可能原来遗留的监控系统已经部分覆盖了，这时候就需要你去熟悉和掌握现有的监控资源，并做进一步整合。
这一阶段的工作内容就是——了解现有的监控指标有哪些，它们的含义是什么？它们的实现方法又是怎样的？
相关文档的输出
在工作中写文档的好处有两个，一个是可以帮助你更好地梳理逻辑，另一个则是帮助后来者更好地了解和上手你的工作。
在正式巡检工作前，我主要写了三份文档：
- 监控指标的说明文档
- 巡检报告模板
- 巡检流程清单
监控指标的说明文档
在巡检前的准备过程中，我看了大量同事之前的做的监控。虽然监控指标很丰富，但是没几个是能一眼看懂的，也没有关于这些指标的说明文档。导致了解原有监控指标的过程主要在和同事的聊天和他一遍遍回忆中度过…（是的，时间过得久了都会忘的）
所以这次整合巡检相关的监控指标时，我对每个指标都写了相关的描述信息，主要包括 指标解释 和 健康判断 两个维度
- 指标解释，就是这个指标的含义是什么，它可以怎么查看，又或者是怎么得到的
- 健康判断，因为巡检主要还是看监控的对象有没有问题，所以对每个指标设置它是否健康的判断标准是很有必要的
比如在系统巡检中，对于CPU负载这个指标，我是这样写它的说明信息的：
CPU负载
指标解释： CPU负载越高，说明占用和等待使用CPU的进程总数越多
健康判断： 主要看最近15分钟的平均情况，在单核情况下，CPU负载高于0.7视为异常，双核情况下，CPU负载高于1.4视为异常，其他情况以此类推
巡检报告模板
这个没什么好说的，主要就是根据监控指标的说明文档写一个 Checklist，网上可以找到很多模板
巡检流程清单
主要是把巡检的完整流程写一个 Checklist。现阶段巡检的主要工作就是看报表，除了看报表外，其他那些附属的、琐碎的步骤也要写上。
比如我写的 Checklist（简化版）：
- 每天基于模板创建清单，写上巡检的时间范围
- 查看监控报表，根据监控指标的健康判断进行相应记录
- 若遇到异常情况则记录，需包含 xxx 等字段
- 若异常现象可能影响到业务，则反馈给相关人员并确定问题根因
- 将巡检结果整理并归档到 xxx
工具选择
报表工具选择的是 Grafana，主要是因为 Grafana 支持多数据源，可以很好地整合原来的各种监控系统，比如 Zabbix，ELK，Prometheus。
这里再推荐下 Grafana 的 Meta Queries 插件，可以在一个报表中引入多个数据源，还可以做些四则运算。
系统巡检和业务巡检该怎么做
系统巡检和业务巡检的对比
| 系统巡检 | 业务巡检 | |
|---|---|---|
| 监控对象 | 物理主机或虚拟机的资源使用情况 | 生产环境中系统的关键工作流的运行情况 |
| 监控目标 | 发现系统潜在的风险和优化点 | 确保关键工作流符合预期地运行 |
| 监控指标 | 主要包括 CPU、内存、网络流量、磁盘四个方面： CPU —— CPU使用率、CPU负载 内存 —— 内存使用率 网络流量 —— 带宽、包量 磁盘 —— 磁盘利用率、每秒读写操作数、读写数据速率 |
根据自身业务而定，一般从三个维度来看： xxx的请求量趋势 xxx的成功率 xxx的延时 |
系统巡检的监控指标分析
了解系统监控可以先看此文，受益匪浅
对于系统巡检的监控指标，我们看到的是各项底层资源（CPU、内存、网络流量、磁盘）的使用率，但应该把它们看做是对各个服务的调用量，也就是要从系统监控的上层——服务监控的角度来看这些指标。
- 看什么
如果某个服务主要消耗主机的计算资源，则应该主要关注服务所在主机的CPU使用情况，比如音视频编解码就是主要消耗CPU资源。
如果某个服务主要消耗主机的内存资源，则应该主要关注服务所在主机的内存使用情况，比如API服务器在调用API时要执行代码，消耗CPU资源。
注意： CPU使用率并不能简单地根据百分比的高低来判断有没有异常，应该结合具体的场景 - 怎么看
各个指标的资源使用率曲线，可以大致分为两种情况：跟业务相关的和跟业务无关的。跟业务相关的资源使用会在时间上呈现和业务的相关性，比如工作日的上班时间段某些资源的使用率高。
但不管跟业务是否有关，这些资源使用率曲线正常的情况下都会在一个范围内波动，而异常的出现往往会破坏过去的趋势。比如下面两张图：CPU使用率在平常稳定在10%左右，异常时CPU使用率曲线有突刺
内存使用率曲线正常情况下会在一个范围内波动，上图的内存使用一直在涨，说明存在内存泄露问题
业务监控的三个维度
业务监控需要根据自身情况来，没有统一的标准，这里主要提出可供参考的三个维度，顺便推荐几篇文章：
腾讯业务监控的修炼之路（一）
腾讯业务监控的修炼之路（二）
分分钟拯救监控知识体系
- xxx的请求量趋势
针对那些在意数量的指标，比如登录用户数、注册用户数、付费用户数 - xxx的成功率
针对那些在使用中可能出现问题的接口或者HTTP请求 - xxx的延时（服务质量）
针对那些在意延时等服务质量的请求，比如音视频服务的延时、抖动，核心API调用的请求延时等
引用推荐文章中一个电商行业的业务监控指标的例子：
每分钟产生多少订单，
每分钟注册多少用户，
每天有多少活跃用户，
每天有多少推广活动，
推广活动引入多少用户，
推广活动引入多少流量，
推广活动引入多少利润
业务监控项实现的三个层次
不同于CPU、内存等系统监控项，Zabbix 和 Prometheus 都提供了监控这些底层资源的模板，而业务监控项则需要运维或者开发动手去实现的。
业务监控的核心目标就是看业务是否符合预期运行，也就是某某功能模块是否能正常使用，在推广活动落地后注册量是否开始呈现上升趋势等。
一个有意思的说法是，业务监控就像是在生产环境上做功能测试，所以在不懂业务监控要怎么做时，可以先去了解下测试人员是怎么做功能测试的。
根据业务监控的实现程度可以分为三个层次：
- 行为模拟。例如通过 Selenium 脚本去模拟用户注册和登录自己的网站。这种方法最蹩脚，而且单一的用例不能代表普遍的情况。
- 日志采集与分析。开发人员将服务运行的状态以一定规范写入日志文件中，运维再通过ELK解析日志并生成报表。这种方法虽然能达到效果，但是效率不高，需要以日志文件为中介，而且还要考虑日志文件对磁盘的占用，日志采集对内网带宽的占用。
- 通过API上报服务自身的状态。这种方法需要开发人员编写接口，但是效率高，看起来最合理。
阶段总结反馈
最后，对于巡检中获取到的有用的信息，可以阶段性地相关的同事或Team Leader反馈。不管是监控、巡检，还是数据分析，通过数据来反过来影响决策、统筹调优，都应该作为最终目的。