为什么更倾向“可观测性”？

Hello folks，我是 Luga，今天我们来聊一下云原生生态核心技术之一-云原生可观测性。

当我们真正融入到云原生生态场景中时，我们将会深切地体会到：“可观测性”的价值所在！

关于监控的引入

成功的 云原生堆栈往往是一种微妙的平衡行为，我们必须不断利用新的和令人兴奋的技术来保障业务运营的稳定可靠。

而现实是：这并不容易。

基于容器的基础设施采用微服务架构意味着我们可以快速迭代更改并快速透视，以满足客户日益增长的业务诉求。

但每次当我们引入新工具、进行流程调整或更改应用程序或基础设施组件时，我们通常都有在环境中造成各种问题或风险：改动了什么？问题在哪里？云原生中经常有太多的复杂性和变量，使得我们无法进行快速梳理。

此时，“监控”或许是解决我们面前的一颗可以 依托的“稻草”～

理解“监控”与“可观测性”的本质所在

监控只是观察和记录系统活动的过程。监控工具收集有关应用程序如何运行的数据。然后，软件将该数据发送到仪表盘进行分析，如果超过之前建立的阈值，可能会触发警报。

监控可以控制应用程序的运行状况，帮助我们对已知的故障点保持警惕。

作为监测的超集，可观测性包括所有这些功能，以及更多功能。这是因为在对复杂的云原生分布式系统进行故障排除时，我们可能需要更多、更多样化的工具。毕竟，有的时候，我们所遇到的问题类型可能是不可预测的，甚至也无法提前知道。可观测性可帮助我们的团队在新的云原生世界中捕捉和修复所谓的“未知+未知”。

作为用于管理和分析复杂系统的两种方法， 监控和可观测性的对比分析主要体现在如下：

1. 数据收集：监控收集预定义的指标，而可观测性收集所有对分析有用的数据。
2. 数据分析：监控使用预定义的阈值来触发警报，而可观测性使用日志和跟踪来识别异常和模式。
3. 关注对象：监控侧重于系统指标，而可观测性侧重于整体系统行为和交互。
4. 根本原因分析：监控提供孤立在孤岛中的数据，而可观测性提供系统的整体视图，允许更快、更准确的根本原因分析。
5. 模式差异：监控通常表现为被动的，而可观测性则是主动的。
6. 可扩展性：监控不容易扩展到大型和复杂的系统，而可观测性是为处理复杂系统而设计的，可以水平扩展。
7. 协作模式：监控通常是孤立进行的，而可观测性则偏重促进团队之间的分工与协作。
8. 工具使用：监控通常依赖于一组有限的工具，而可观测性需要广泛的工具和技术来收集数据、分析和可视化。
9. 成本分析：监控通常比可观测性更便宜，因为它需要更少的工具和更少的专业知识来设置和维护。

总体而言， 监控提供了系统的有限和预定义视图，而可观测性提供了系统行为和交互的整体和综合视图。

然而，可观测性需要对工具、流程和专业知识进行大量投资才能充分发挥其优势。 对于希望管理其系统的组织而言，监控通常是一个很好的起点，而可观测性是一种更为高级的方法，可以随着时间的推移提供更深入的见解和价值。最终，监控和可观察性之间的选择取决于系统的复杂性、所需的洞察力水平以及可用于管理和分析系统的资源。

其实，从本质而言，可观测性不是一个全新的概念或技术类别。它的根源在于监测。监测和可观测性都是控制理论的演变，控制理论是一个数学概念，即使用复杂系统的反馈来改变其行为，以便操作员能够达到预期目标。

毕竟，回归本质，可观测性的基本原则是为了服务于：系统 的可见“输出”可以帮助用户推断内部发生了什么。

可观测性核心“要素”

领先的可观测性生态体系往往具有某些特征。通常而言，基于实际的业务场景，评估可观测性平台时，我们需要关注的四个关键因素，具体可参考如下所示：

1. 拥抱互操作

输入可观测性工具（度量、日志和跟踪）的数据来自广泛的来源或仪器。这些数据提供了对应用程序和基础设施的可见性，并且可以来自应用程序、服务、云、移动应用程序或容器中的仪器。数据还有各种格式：开源、行业标准或专有。

越来越多的源，包括定制和开源，这意味着可观测性工具必须从所有类型的仪器中收集所有数据，才能全面了解我们所构建的环境。

因此，DevOps 和 SRE 需要一个可观察性平台，该平台通过开放仪器拥有所有数据的全面互操作性，无论它来自哪里或什么。

2. 丰富的背景

IT 系统中的上下文与现实生活中相同。在没有上下文的情况下，很难解释我们人类每天所获取的“数据”信息。事情是如何说的，在哪里说的，甚至天气和我们是否饥饿之类的事情都会影响我们对现实生活信息的解释。

对于可观测性，同样适用。遥测数据非常重要，因为它可以深入了解应用程序和 基础设施的内部状态。但情境智能也很重要。

或许，在某一时刻，我们可能想知道系统上周或昨天的表现如何。系统运行的服务器的配置是什么？出现问题时，工作量有什么异常吗？

3. 用于可定制搜索和分析的可编程工具

首先，重要的是要了解，任何可观测性策略的关键是设置适当的成功指标并建立关键绩效指标（KPI），以告知我们的团队何时达到这些成功指标。

尽管如此，传统的 KPI 虽然对监控和衡量应用程序性能很有用，但并不表明问题如何影响依赖云原生环境的用户、客户和企业。没有人将这些点连接起来。

传统的答案或许是在仪表盘中可视化的 KPI。DevOps 和 SRE 专业人员必须超越仪表盘，将可观察性与业务成果完全联系起来。我们通常需要创建应用程序，与使用自动化工作流程的KPI提供互动体验，并实时将外部数据与内部指标集成。

这让企业同时深入了解技术、业务和用户。我们的团队可以做出针对特定改进 KPI 的数据驱动决策。并且可以优化新软件投资的投资回报率（ROI）和有效性。可编程的可观测性平台可帮助我们的团队了解数据、系统和客户，从而有助于我们将正确的数据提供给正确的人，以确保任何支持我们基础设施的业务顺利运行。

4. 准确的真相来源

通常而言，我们所构建的系统或平台来自很多地方的数据，所以在不同的可观测性工具之间切换有的时候着实让人有点蛋X。因此，我们潜意识地希望通过从任何地方 能够 实时查看所有内容来完全窥探整个系统的运行行为。

为什么更倾向“可观测性”？

在实际的业务场景中，监控和可观测性都是用于管理和分析复杂系统的两种核心方法。对于监控而言，其主要通过收集和分析指标提供对系统状态的洞察，而可观测性则通过分析系统的行为和交互提供对系统内部工作脉络的可见性。

基于笔者的实践经验，以下是组织应考虑从监控转向可观测性的一些核心原因，具体涉及：

1. 更好地洞察复杂系统

可观测性通过提供对系统内部状态和行为的可见性，可以更深入地洞察复杂系统，从而使用户能够更快、更准确、更主动地识别和解决问题。

2. 减少 MTTR

在实际的项目活动中，平均解决时间 (MTTR) 是 IT 运营团队的一个关键衡量指标。可观测性可以通过提供对系统性能的实时洞察来帮助减少 MTTR，从而使团队能够在问题升级之前主动识别以及规避风险从而解决问题。

3. 优化协作方式

通常而言，可观测性通过提供系统行为的共同视图促进团队之间的协作，使团队能够更有效地协同工作以识别和解决问题，从而可以更快地解决问题并提高系统稳定性。

4. 支持分布式架构

基于现代系统越来越分布式和复杂特性，可观测性提供了必要的工具和洞察力来有效地管理这些系统，使组织能够自信地扩展和操作复杂的系统。

5. 增强用户体验

通过可观测性，组织可以更深入地了解客户如何与其系统交互，从而识别和解决影响客户体验的问题。 这可以提高客户满意度和保留率。

总的来说，从监控转向可观测性可以为组织提供更全面、更有效的方法来管理复杂系统。可观测性提供对系统行为的更深入洞察、减少 MTTR、改进协作、支持分布式架构并增强客户体验。

通过采用可观测性，组织可以更好地满足现代系统的需求并在市场上获得竞争优势。然而，值得注意的是，可观测性需要对工具、流程和专业知识进行大量投资，并且可能需要文化转变才能充分发挥其优势。尽管如此，可观测性的好处使其成为希望有效管理复杂系统的组织的一种引人注目的方法。