本文是从我自己作为站点可靠性工程师的经验中，总结了有效监控的10 条基本原则。
1. 不要衡量速率
你可以在查询时推导出随时间变化的速率。
监控的第一条规则是永远不要测量速率，而是测量数量。
我们以 CPU 为例。如果你的系统显示 CPU 使用率为 35%，但实际使用率超过 35%，那么你得到的答案是错误的。你需要跟踪 CPU 的变化。例如，Linux 就是这样做的，它跟踪花费的厘秒数，并且不断地计数。如果你想知道特定时间段内的速率，则可以在开始时进行测量，在结束时进行测量，然后减去，然后除以时间间隔以计算每秒的速率。当你将经过的厘秒数除以秒数时，你会得到 100 倍的比率，这是一个百分比。因此，你应该始终监控事物的数量而不是速率。
2. 在技术之外进行监控
如果没有满意的客户和销售渠道，你的技术价值也不大。因此除了技术指标，也要对业务数据进行监控。
如果你只从技术角度进行监控，那么你可能无法很好地为你的企业提供服务。无论你的企业有什么关键绩效指标，都应该受到监控。因为，你的营销部门正在分析这些数据以确定他们的活动是否成功，所以，它应该在你的监控解决方案中。
如果某个系统宕机但不影响业务，但某些数据包的丢失会导致用户极差的体验，那就说明业务相关的数据，是你需要持续监控的。
3. 不要孤立数据
数据必须放在上下文中进行分析。关联不同的系统或业务的数据，至关重要。
这一原则是上一条原则的完美后续：今天的 IT 组织希望所有东西都是分布式的，但是如果你没有将相关的数据放在一起，那么你就无法将系统和业务相关联。
当你将监控系统、数据库、用户等的所有数据放在一起时，你就可以开始围绕该数据分析你遇到的任何业务问题、并尝试寻找解决方案。这就是为什么---软件行业在构建高度可扩展的时间序列数据库方面---进行了大量投资的原因。
4. 实时观察
用于关键业务的高频事件。
你没有理由不观察实际工作负载，而不是观察综合指标数据。我见过组织完全依赖综合指标，甚至是该平均测量值，这是绝不能提供真实、准确的见解的。
在关键业务的高频事件中，很有可能不能从观察综合指标数据得出平均延迟，你应该测量每个真实用户请求的延迟，并使用该分析来指导你的决策。因此，始终重视对实时观察，而不是综合分析和平均测量。
5. 综合分析
用于关键业务的低频事件。
综合分析，用于关键业务的低频事件。关键业务的低频事件，可能是相隔很久才点击一次的API。当低频事件被触发时，我们往往不急于得知他的网络延迟等信息，我们往往通过对多个周期数据的综合分析，以确保服务实际运行是否健康。
6. 直方图式分析
对于稳健的服务，你需要存储直方图以进行分析处理。
百分位数是工程师经常用的统计聚合，但不应将它们与直方图混淆。
百分位数示例：过去 28 天内我们网站请求的 95% 的延迟为 98 毫秒。
除了这个数字之外，这个百分位数本身不会产生任何额外的信息。例如，它不提供延迟数据的分布，例如第 97 个或第 98 个百分位数。然而，直方图会产生这个甚至更多。
直方图是连续变量分布的表示，其中整个值范围被划分为一系列区间，并且表示显示落入每个区间的值的数量。直方图是计算延迟的最佳方式，因为它们有效地存储了所有原始延迟数据，并且可以轻松计算出你希望看到的任何百分位数。想看到第 85 个百分位数吗？第78个？第94个？所有这些都是可能的。直方图可视化了延迟数据的分布，因此工程师可以轻松识别分析判断，系统是否满足性能要求。
7. 历史数据至关重要
不是数周或数月，而是多年的详细历史数据。容量规划和建模依赖于准确、高保真的历史记录。
很多监控厂商，尤其是开源厂商，都低估了历史数据的重要性。他们将数据存储一个月，认为任何超过一个月的数据都没有价值，这简直是大错特错。这些解决方案不会长期存储数据，因为它们不是专门设计的，但这并不意味着它不重要。
你应该拥有数年，而不仅仅是数周或数月的历史数据，以便你进行事后分析。没有什么比在事后分析中, 没有相关历史数据更令人恼火的了。因此你的数据粒度, 也要尽可能细, 而不是一个大的时间段。
你今天拥有的数据格式在 6 个月后和 12 个月后应该完全相同。这对于理解容量规划也很重要。你需要细粒度数据来进行长期容量规划。这方面的一个例子是带宽利用率。
你可能不会整天提供相同的带宽。如果你查看带宽利用率的历史记录，并在一天内对其进行平均，那么你的最大值就完全被掩盖了。所有的最大值都消失了，你正在规划这条根本不适合你的峰值的轨迹曲线。拥有这些细粒度数据可确保你可以正确回答所有未来的问题。
8. 警报需要文档
如果没有人类可读的解释说明文档、故障影响描述文件、补救程序和升级文档，任何规则都不应触发警报。
每个监控人员都遭受过警报疲劳，因此只创建必要的警报很有必要。
例如，假设你创建了一个 85% 的磁盘空间警报，你需要描述为什么这很重要以及对业务的影响是什么，同时还包括完整的补救程序和关键领导者或利益相关者的列表，如果出现问题，你需要与之交谈对策。一旦附加了这些规则，就不太可能在 85% 的磁盘空间上创建警报。
除非故障发生时，有人应该采取实际行动，否则你不应该发出警报。
9. 健壮的监控系统
监控的目的是检测行为变化并协助回答操作问题。
我在监控系统看到的最常见的错误之一是，工程师在系统内设置了警报，然后系统崩溃了。因此，他们无法使用它或看到任何东西，直到他们再次重新上线。
监控系统的健壮性至关重要，这样当系统出现故障或故障时，你的监控、警报、可视化和分析系统仍然可用。事实上，监控解决方案需要比它们所监控的系统更可用，并且它们需要在系统业务之外的服务器独立部署。
10. 有总比没有好
不要让完美成为美好的敌人。你必须从某个地方开始。
我经常看到工程师力求监控系统的尽善尽美，让完美成为优秀的敌人。你不可能有完美的监控。开始很重要，最好从顶层开始——那些对顶层业务指标影响最密切的系统或服务。如果是TOC系统，那么网络延迟可能是最重要的衡量指标。
在确定从哪里开始监控时，瞄准那些为你的业务提供最高价值的事情。从那里，你可以深入了解监控，直至监控每个 IOP 和服务调用的延迟。一旦到了这一步，你就可以确定需要性能改进的地方。
总结
在我们这个微服务、分布式系统和期望永远在线的新时代，监控对于业务成功来说从未如此重要。它可能既复杂又难以抗拒，希望此清单可以在你试试监控过程时提供一些快速、实用的帮助。
译文连接: 10 Fundamental Principles of Effective Monitoring – The New Stack
