可观察性工程

第 9 章. 可观察性与监测如何结合

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在本书中，我们已经探讨了可观测系统的不同功能、可观测性所需的技术组件，以及可观测性如何融入技术领域。可观测性从根本上有别于监控，两者的目的也不尽相同。在本章中，我们将探讨如何将两者结合起来，以及确定两者如何在企业中共存的注意事项。

许多组织在其生产软件系统中积累了数年甚至数十年的度量数据和监控专业知识。如前几章所述，传统的监控方法对于传统系统是足够的。但在管理现代系统时，这是否意味着你应该抛弃这一切，重新开始使用可观察性工具呢？这样做既轻率又鲁莽。对于大多数组织来说，事实是他们应该根据所承担的责任来决定共存的方法。

本章通过研究可观察性和监控的各自优势、最适合的领域以及它们相互补充的方式，探讨可观察性和监控是如何结合在一起的。每个组织都不尽相同，可观察性与监控并存的秘诀也不可能放之四海而皆准。不过，一个有用的指导原则是，可观察性最适合用于了解应用层面的问题，而监控最适合用于了解系统层面的问题。通过考虑您的工作负载，您可以找出二者的最佳结合点。

监控的适用范围

在第 2 章中，我们重点讨论了可观测性与监测的区别。该章主要关注监测系统的缺陷以及可观测性如何弥补这些缺陷。但是，监控系统仍然可以提供有价值的见解。让我们先来看看传统监控系统在哪些方面仍然是最合适的工具。

了解系统状态的传统监控方法是一个成熟而完善的过程。经过数十年的迭代改进，监控工具的发展已经超越了，从最初的简单度量和轮循数据库 (RRD)，发展到 TSDB 和精心设计的标记系统。此外，还有大量先进的选择来提供这种服务--从开源软件解决方案、初创公司到上市公司。

除了围绕特定工具形成的专家群体外，监控实践也是众所周知、广为人知的。在整个软件行业，监控最佳实践的存在是任何在生产中运行过软件的人都可能认同的。

例如，一个广为接受的监控核心原则是，人不需要整天坐在那里看图表；系统应该在出现问题时主动通知用户。因此，监控系统是被动的。它们对已知的故障状态做出反应，提醒人类问题正在发生。

监控系统和衡量标准已经发展到可以优化自身以完成这项工作。它们会自动报告已知故障条件是否正在发生或即将发生。它们对进行了优化，以报告已知故障模式的未知情况（换句话说，它们旨在检测已知未知情况）。

对监控系统进行优化以发现已知-未知因素，这意味着监控系统最适合用于了解系统状态，因为系统的变化频率和可预测性远低于应用程序代码。我们所说的系统指的是基础架构、运行时或计数器，它们可以帮助您了解何时会遇到运行限制。

如第 1 章所述，度量和监控是为检查硬件级性能而创建的。随着时间的推移，它们已被调整为涵盖更广泛的基础架构和系统级问题。本书的大多数读者都在技术公司工作，他们应该认识到，底层系统并不是业务的关键所在。归根结底，对企业来说，重要的是你编写的应用程序在客户手中的表现。企业关注底层系统的唯一原因是，它们可能会对应用程序的性能产生负面影响。

例如，你想知道一个虚拟实例的 CPU 利用率是否与一个吵闹的邻居挂钩，因为这告诉你，你所看到的延迟并不是代码内部的问题。或者，如果你发现整个机群的物理内存接近耗尽，那就说明即将发生的灾难可能源于你的代码。将系统限制与应用程序性能联系起来很重要，但系统性能主要是作为一种警告信号或排除代码问题的方法。

随着时间的推移，衡量标准也被调整为，以监控应用程序级问题。但是，正如您在第一部分中所看到的，这些综合度量过于粗糙，因为它们无法分解以显示服务中单个请求的性能。在预警信号的作用下，像度量指标这样的综合衡量标准效果很好。但是，度量指标并不能，也从来都不能很好地显示您编写的代码在单个用户手中的表现。 ...