Day 6：监控系统的设计

昨天稍微谈到了一些有关警报的设计，然而，警报的发出与否，应是建立在我们观测到的一些系统的行为，例如说在 Day 3 架设的 status page，就是基於「是否可以连上网页」这个条件来判断。但是像昨天提到的硬碟使用率，就不是一个可以透过客户端观测到的数值，既然观测不到，那麽就更无从谈起如何做警报。

监控的目的

为什麽要监控？软件开发完部署上去不是就跑得好好的了吗？在我当初修软件工程的时候，完全没有考虑到相关的问题。直到 NOJ 真的上线跑了一阵子之後，才发现有些问题，是必须得要在服务运行时，收集一些数据後才能处理的，举几个例子来说：

• 警报：有东西故障了，需要有人修复。这当然要随时监控服务的状态才可以做到。
• 检测效能改善：当我今天对系统做了某些更新，或许是改变了使用的资料库，加上了一些快取，更改了一些流程等等...有时候我们或许可以透过数学的方法证明它会比较快（e.g. 时间复杂度明显低一个数量级），然而更多时候是需要实际运行过後才能确定前後的差别的。所以若是可以收集一些运行时的数据，像是使用者等待的时间等等，便可以有充分的证据证明改善与否。
• 容量规划：当服务需要提供给更多人使用的时候，我该如何确定当前的硬体设备是否足够？有需要更换更好的电脑吗？就算服务有自动扩展的能力，那也需要确定流量上升之後是否会超出预算，毕竟机器也是要钱的。若是在平时就有监测相关的硬体数据的话，就可以有足够的信心去规划。
• 寻找效能瓶颈：有时候我们可能会遇到一些效能的问题，可是却没有办法直接指出是服务中的哪个元件拖慢了效能，若是有统计一些效能相关的数据，可能可以帮我们找出效能的瓶颈在哪。

现象与原因

监控系统需要指出两个问题：谁坏了，以及为什麽。这两件事情分别对应到了现象 (symptom) 以及原因 (cause)，一个现象背後可能会有多个原因。举例来说今天使用者连不上网页，可能是因为 DNS 出了问题、实体机器故障，server 的 process 没有成功跑起来、防火墙设定失误等等，族繁不及备载。

理解这点对於降低警报的杂讯很有帮助，一个可能的策略是仅在确定使用者会受到影响的时候发出警报，并把已知的潜在原因列出来，这样在处理问题的时候会更有效率。

而且另外一点，现象容易从外部观测，也就是说我不必知道系统内部的架构，就可以确定现在「发生了一个问题」，所以会让警报的规则较容易维护，而不会随着系统的迭代需要时常修改。

四个黄金讯号 (Four Golden Signals)

那麽，我们应该监控哪些东西呢，在 SRE books 里面，google 提出了「四个黄金讯号」：

延迟

延迟表示处理某个请求所花的时间，这项指标会直接的影响使用者的体验，毕竟我们都不喜欢等待。所以当延迟开始异常的升高，那麽就是一个发出警报的合理时机。然而需要注意的是，在统计延迟的时候把成功跟失败的请求分开会比较好，因为失败的请求通常会因为不需进行後续处理而有偏低的延迟。

流量

流量通常直接代表系统承受了多大的压力，像是以一个网路服务来说，它可能是单位时间的 HTTP 请求数量，纪录流量并配合其他指标可以帮助我们判断系统具体的承受能力。

错误

服务产生的错误，又会被分类为显示错误，例如一个 HTTP 500 的回覆；或是隐式的错误，例如内容错误的 HTTP 200 回覆，虽然後者通常较难统计（因为可能含有一些复杂的规则），但若是可以把这些类型的错误都记录下来的话可以更好的监测到服务中的错误。

另外一点是，比起错误的数量，比例可能更为重要，因为数量会随着收到请求数量上升，例如说今天在十万笔请求中含有一千笔错误，跟在一万笔请求中含有一千笔错误是不同的意义，後者对於使用者的影响显然更为严重。

饱和度

饱和度直接地指出了服务现在有多「满」，通常会是 CPU、记忆体或是硬碟等用量资讯，监控这些指标可以帮助我们即早准备处理接下来即将发生的问题，或是透过自动化的手段去处理他们。

长尾问题

收集到了数据之後，我们应该如何去理解它呢？有些人或许会选择观察平均值，然而这不是一个好主意，因为离群值可能会对它造成严重的波动，举 HTTP 请求的延迟来当例子，若是有 1% 的请求花了十倍於平均值的时间，那麽剩下的请求只需要花平均时间的一半。

所以考虑使用百分位数 (percentile) 可能是个比较好的选择，在看人家设计监控的指标时会听到的那些 p99、p95 之类的术语，指得就是这个概念。也就是说统计时我们只看比较快的那部分资料，因为这可以有效反应出「大部分」使用者的体验。

小结

今天讨论了监控系统以及指标的设计有哪些相关概念，老实说在看这一部份的时候对我来说真的是像在看天书，有不少概念都难以理解，需要自己额外查不少补充资料，都没时间做迷因图了。接下来的几天，就来纪录架设监控系统的过程吧。

参考资料

• Black Box vs. White Box Monitoring: What You Need To Know
• How to monitor Golden signals in Kubernetes
• Anomaly Detection on Golden Signals
• Introduction to Symptomatic Alerts in Monitoring
• Symptoms Not Causes
• Monitoring 101: Alerting on what matters