要怎么监控

众所周知，在生产的程序都需要有监控，但估计大部分人都没有认真考虑过怎么监控。

我们也实施了监控，但其实我们都没有认真设计过，自然也没有什么原则，所以即使有了告警，像是游离在一个只“监”不“控”的状态：

1. 各种各样，从各个渠道弹出来的告警信息，很多时候恨不得把告警都直接弹到运维的眼前。
2. 各种五颜六色的指数、图表、电视屏，怎么才能一眼就看出问题呢。
3. 告警多了也很烦，同一个问题收到好几个告警，又或者这个告警其实不需要处理，但又不能完全忽略。
4. 收到告警，也不知道要找谁，下一步要干什么。
5. 一个系统很大，看上去好像全身上下都是监控点，要从哪里开始定义监控点比较合适呢？

…………

最近看了一本书，《监控运维时间：原则与策略》，书很薄，100多页，没有什么深入经验和理论，但就专门介绍了「监控」这件事，都是直接实战实操，指导如何更好地监控。

---

「监控」是一个管理过程，其管理的对象就是「告警」，管理「告警」产生直到消亡的一生。

在讨论「告警」一生之前，我们先看「告警」的意义何在。我们都知道要监控，但有没有想过为什么要监控呢？

我们监控一个系统的意义在于，证明这个系统在“正常运行”，在理想状态下，如果一个系统没有告警，我们就可以认为他是在正常运作的状态；反之，那就是系统哪里出了问题。如果没有告警，但又收到用户的保障，那只能说告警缺失，需要补充；也有反面的情况，有告警，但用户其实又没有影响，那其实这个告警就需要裁剪。

补充一下，这个“正常运行”是站在用户的角度上来看的，用户从这个系统获得预期结果，那就是正常。这个讲得太抽象，因为无论是系统、还是正常的定义对于每个系统都不一样，我举一个例子。

比如，现在要监控一个web应用，而web应用有一个http的api，那这个系统怎么为之正常呢。我们可以直接调用这个api，看是否返回200；但200就是完全正常吗，不是，我们还要在一定的时间内返回200才正常，比如5秒内。那这时候需要监控的内容就是，调用这个api在5秒内返回200，我们就认为这个web应用是正常的。所以，监控服务器等其他参数，就变成次要，因为内存高并不表示用户不能用；而cpu低也不是表示一定用户可用。所以这个“正常运行”是站在用户的角度来说；当然，我们可以继续对返回的内容进行监控以进一步完善“正常”的定义。

讨论完意义，我们要看一下「告警」的一生，先说产生。

假如现在要重新设计系统的告警，要从哪里开始呢，服务器的cpu内存硬盘这些基础指标吗？HTTP返回码吗？异常日志吗？我们回到上面说的监控的「意义」，是证明这个系统在用户的角度来说正常运行。

所以一开始要定义监控点的话，添加监控的最佳地点，首先就是用户和应用程序交互的点。用户不会关心应用程序实现的细节，比如运行着多少节点、或者有多少后台任务，而会关心应用程序是否可用。因此，首先要从他们的角度看问题。不是说这是监控唯一的点，只是说可以从这里开始考虑。

「告警」的点找到了，那「告警」应该长什么样子。

我们平常遇到的告警其实分为2类，一类是不管时间地点，都需要马上通知运维人员并行动的，比如服务器宕机了；另一类是通知，问题不会产生立即影响，关注即可，比如某个定时备份服务失败了。现在关注的是第一类告警，要马上行动的。

关于立项的的告警要素，有6点：

1. 停止使用电子邮件发送告警

• 邮件容易被其他信息淹没
• 建议用即使通信，而且需要有专门的告警群，避免跟其他消息混在一起。

2. 针对每个告警撰写运行手册，其实就是SOP，这个告警来了要怎么行动。手册包含以下几点

• 这是什么服务，这个服务做什么？这是起码知道告警影响到哪个系统。
• 谁负责这个服务？相关负责人。
• 这个服务有什么依赖关系？知晓影响范围。
• 它的基础设施什么样？这是系统相关的各种架构图，可以定位告警所在的位置。
• 它会产生什么样的指标以及日志，这些指标和日志的含义是什么？就是告警的具体含义。
• 应该为它设置哪些告警，为什么要设置这些告警？这个我理解是站在用户角度阐述影响范围。

3. 任意的静态阈值不是唯一的方法

• 涉及到统计数学的方法，主要是从诸多采集到的数据，使用一些数学手段，把数据可视化，从中看到一些暗藏的趋势和规律。
• 比如平均值、中位数的统计会把波动较大的数据平滑化，让我们更容易看出规律。

4. 删除告警和优化告警；

• 需要不断定时检视告警，以删减精简出没有必要的告警，以避免告警疲劳。

5. 使用维护周期；

• 发布维护期间，需要添加“维护周期”，否则正常运维期间的告警也是一种冗余告警。

6. 优先尝试自动修复。

• 有的告警紧急SOP可以尝试使用程序自动修复，减少人工参与的风险，自动修复也可以节省响应时间。

那定义的告警在生产真的触发了，肯定不能置之不理，那要怎么做呢。

这个其实在业界里面，叫「事件管理」，最出名的就是传说的ITIL里面的「事件管理框架」，我们先看看ITIL教科书上完整的事件管理流程是如何的。

asset.png

1. 第1步：事件日志记录。
2. 第2步：事件分类。
3. 第3步：事件优先级。
4. 第4步：事件的任务。
5. 第5步：任务创建和管理。
6. 第6步：SLA管理和升级。
7. 第7步：事件解决。
8. 第8步：事件关闭

这个框架很完整，但我们实际可能未必用到这么完整的框架，我们可以简化必须的要素。告警事件处理建议流程，如下：

1. 事件定义（监控识别一个问题）
2. 事件记录（监控自动为该事件打开一个工单）
3. 事件诊断、分类、解决，以及关闭（待命值班人员排查故障，解决问题，通过注释和其他数据解决该工单）
4. 根据需要，在整个事件中进行沟通
5. 在事件解决后，想出补救计划以便增强系统弹性

参与事件处理也要分清以下的角色：

1、事件指挥官（IC）

事件指挥官的工作就是做决定。他们既不会参与任何调查和修复工作，也不会与客户或内部进行沟通，只会监督中断调查。

2、记录员

记录员的工作就是记下发生的一切。什么人在什么时候说了什么，做出了哪些决定，后续事项有哪些被确定下来了。同样，这个角色也不应该参与任何调查和修复工作。

3、通信联络人

通信联络人的工作就是向干系人（不管是内部人员还是外部人员）传达情况更新。在某种意义上，他们是处理事件的人与想要了解事态进展的人之间的唯一联络人。这个角色的一个作用是防止干系人（例如经理）直接向努力解决问题的人询问情况更新，进而干扰事件调查。

4、领域专家（SME）

这些人才是真正在处理事件的人。

其实说到这里，监控从它的意义开始，讲到监控对象的「告警」的定义、产生、管理，都有了一个闭环，基本上我们就可以做到「监」和「控」都具备了。

书中后面还细分讲了前端、安全、网络、服务器等各自细分领域的监控策略，以及一些推荐的工具，大家有兴趣可以翻一下。

里面提到一个StatsD的工具，蛮有趣，后续有需要可以研究一下。

image.png