有效监控的十个原则

重点推荐最后几个建议

1. 不要依赖单个数据

2. 从实用角度 业务角度（避免单纯技术角度）进行监控

3. 不要孤立数据

4. 注意观察细节

5. 综合分析

6. 直方图式分析

   对于稳健的服务，你需要存储直方图以进行分析处理。

百分位数是工程师经常用的统计聚合，但不应将它们与直方图混淆。

百分位数示例：过去 28 天内我们网站请求的 95% 的延迟为 98 毫秒。

除了这个数字之外，这个百分位数本身不会产生任何额外的信息。例如，它不提供延迟数据的分布，例如第 97 个或第 98 个百分位数。然而，直方图会产生这个甚至更多。

直方图是连续变量分布的表示，其中整个值范围被划分为一系列区间，并且表示显示落入每个区间的值的数量。直方图是计算延迟的最佳方式，因为它们有效地存储了所有原始延迟数据，并且可以轻松计算出你希望看到的任何百分位数。想看到第 85 个百分位数吗？第78个？第94个？所有这些都是可能的。直方图可视化了延迟数据的分布，因此工程师可以轻松识别分析判断，系统是否满足性能要求。

7. 历史数据至关重要

   不是数周或数月，而是多年的详细历史数据。容量规划和建模依赖于准确、高保真的历史记录。

很多监控厂商，尤其是开源厂商，都低估了历史数据的重要性。他们将数据存储一个月，认为任何超过一个月的数据都没有价值，这简直是大错特错。这些解决方案不会长期存储数据，因为它们不是专门设计的，但这并不意味着它不重要。

你应该拥有数年，而不仅仅是数周或数月的历史数据，以便你进行事后分析。没有什么比在事后分析中, 没有相关历史数据更令人恼火的了。因此你的数据粒度, 也要尽可能细, 而不是一个大的时间段。

你今天拥有的数据格式在 6 个月后和 12 个月后应该完全相同。这对于理解容量规划也很重要。你需要细粒度数据来进行长期容量规划。这方面的一个例子是带宽利用率。

你可能不会整天提供相同的带宽。如果你查看带宽利用率的历史记录，并在一天内对其进行平均，那么你的最大值就完全被掩盖了。所有的最大值都消失了，你正在规划这条根本不适合你的峰值的轨迹曲线。拥有这些细粒度数据可确保你可以正确回答所有未来的问题。

8. 警报需要文档

如果没有人类可读的解释说明文档、故障影响描述文件、补救程序和升级文档，任何规则都不应触发警报。

每个监控人员都遭受过警报疲劳，因此只创建必要的警报很有必要。

例如，假设你创建了一个 85% 的磁盘空间警报，你需要描述为什么这很重要以及对业务的影响是什么，同时还包括完整的补救程序和关键领导者或利益相关者的列表，如果出现问题，你需要与之交谈对策。一旦附加了这些规则，就不太可能在 85% 的磁盘空间上创建警报。

除非故障发生时，有人应该采取实际行动，否则你不应该发出警报。

9. 健壮的监控系统

监控的目的是检测行为变化并协助回答操作问题。

我在监控系统看到的最常见的错误之一是，工程师在系统内设置了警报，然后系统崩溃了。因此，他们无法使用它或看到任何东西，直到他们再次重新上线。

监控系统的健壮性至关重要，这样当系统出现故障或故障时，你的监控、警报、可视化和分析系统仍然可用。事实上，监控解决方案需要比它们所监控的系统更可用，并且它们需要在系统业务之外的服务器独立部署。

10. 有总比没有好先搭建起来@

不要让完美成为美好的敌人。你必须从某个地方开始。

我经常看到工程师力求监控系统的尽善尽美，让完美成为优秀的敌人。你不可能有完美的监控。开始很重要，最好从顶层开始——那些对顶层业务指标影响最密切的系统或服务。如果是TOC系统，那么网络延迟可能是最重要的衡量指标。

在确定从哪里开始监控时，瞄准那些为你的业务提供最高价值的事情。从那里，你可以深入了解监控，直至监控每个 IOP 和服务调用的延迟。一旦到了这一步，你就可以确定需要性能改进的地方。
总结

在我们这个微服务、分布式系统和期望永远在线的新时代，监控对于业务成功来说从未如此重要。它可能既复杂又难以抗拒，希望此清单可以在你试试监控过程时提供一些快速、实用的帮助。