监控与可观察性：有什么区别？

发表于 3年以前 | 总阅读数：581 次

现代分布式应用程序，无法再通过基于可预见故障的传统方法进行有效监视。随着微服务架构成为Web应用程序的标准，有效的调试和诊断被需要，这就要求软件系统是可观察的，即可以通过观察其输出来推断其内部状态。但是，对于开发团队而言，可观察性与监视之间的界限通常是模糊的。在这篇文章中，我们将会讨论监视，可观察性以及两者之间的关系。我们还提到了一些实现可观察性的工具。

监控方式

拥护DevOps思维方式的组织通常会开始将应用程序分解为微服务架构，以便在故障发生时获得可操作性并减少维修时间。但是，随着他们的系统变得越来越复杂，他们必须确保他们仍然可以了解系统故障并及时做出反应。

根据Google的SRE报告，你的监视系统需要回答两个简单的问题：“有什么问题，为什么？” 通过监视，你可以使用一组预定义的指标和日志来观察和了解系统的状态。监视应用程序使你可以检测一组已知的故障模式。

监视对于分析系统的长期趋势，构建仪表板和发出警报至关重要。它可以让你知道你的应用程序如何运行，它们如何增长以及如何被侵入破坏。但是，监视复杂的分布式应用程序是很难的，因此很难预测。

话虽这么说，监视仍然是构建和运行基于微服务的系统必不可少的工具。如果监视规则和度量标准简单明了，并且是可操作的数据，则它们将为你的系统运行状况提供清晰的视图。

尽管监视可能无法使你的系统完全不受故障的影响，但它可以提供软件系统行为和性能的全景视图，使你可以快速有效明确任何故障的影响，寻找相应的修复程序。

可观察性

可观察性源于控制理论(control theory)，它衡量了从系统外部输出中了解系统内部状态的能力。监视是你在观察系统之后要做的事情，没有某种程度的可观察性，就无法进行监视。

具备可观察的系统使你能够理解和衡量系统的内部，从而即使在复杂的微服务体系结构中，也可以更轻松地从故障定位到原因。它可以帮助你找到以下问题的答案：

请求经过什么服务，性能瓶颈在哪里？
系统的执行与预期的系统行为有何不同？
为什么请求失败？
每个微服务如何处理请求？

可观察性可以分为三个方面：

日志：带有时间戳标志，不可变的事件记录，可以识别系统中不可预测的行为，并洞悉发生错误时系统行为的变化。强烈建议以结构化方式（例如JSON格式）提取日志，以便日志可视化系统可以自动索引并使日志易于查询。
指标：监控的基础，指标是一段时间内累计的计数或度量。指标将告诉你某个方法使用了多少内存总量，或者服务每秒处理了多少个请求。
跟踪：跟踪使你能够了解特定请求的详细信息，以确定是哪些组件导致系统错误，监视通过模块间的流量，可以查找性能瓶颈。

可观察性与监视之间的关系

可观察性和监视是相辅相成的，每个都有不同的目的。监视告诉你什么时候出了问题，而可观察性则使你能够了解原因。

监视是可观察性的子集和关键措施。你只能监视可观察的系统。

监视，会跟踪应用程序的整体运行状况，它根据访问速度，连接性，停机时间和瓶颈汇总有关系统性能的数据。另一方面，可观察性通过提供其特定故障模式的细粒度和上下文洞察力，深入研究了应用程序操作的“内容”和“原因”。

监视仅提供已知问题或故障的答案，而具备可观察性的软件允许开发人员提出新问题。

建立持续可观察的系统

实现可观察性并不难。你可以从多个与你的应用程序有关的关键指标入手。例如应用程序的CPU，网络和内存。

系统日志对于确保系统的可观察性也至关重要。尽管日志可能越来越多并且变得难以管理，并且存储起来昂贵，但是有些工具可以提高日志记录的效率。一个示例是OpenTelemetry，它不仅用于日志记录，还用于度量标准排序和跟踪。OpenTelemetry还与流行的框架和类库集成，例如Spring，ASP.NET Core和Express。

跟踪使你的可观察系统更加有效，并使你能够确定分布式系统中问题的根本原因。跟踪可以看作是可观察性实现的最重要部分：了解微服务体系结构中的因果关系，并能够从结果到原因跟踪问题，反之亦然。

持续的自动化可观察性使你可以在整个软件开发生命周期中始终掌控所有风险或问题。它提供了整个CI/CD流水线和基础架构的可见性，可随时为你提供相关环境的运行状况。