本文是从我自己作为站点可靠性工程师的经验中,总结了有效监控的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 和服务调用的延迟。一旦到了这一步,你就可以确定需要性能改进的地方。
总结
在我们这个微服务、分布式系统和期望永远在线的新时代,监控对于业务成功来说从未如此重要。它可能既复杂又难以抗拒,希望此清单可以在你试试监控过程时提供一些快速、实用的帮助。
译文连接: https://thenewstack.io/the-10-fundamental-principles-of-effective-monitoring/
登录后评论
立即登录 注册