什么是数据可观察性以及为什么需要它？

可观察性一词源于控制理论。RE Kálmán 在 1960 年将其定义为衡量您从系统外部输出的知识推断系统内部状态的能力。可观察性是一个非常强大的概念，因为它可以让您了解系统的内部状态，而无需内部工作的复杂性。换句话说，您只需查看输出即可了解发生了什么。

在过去的十年中，软件和架构已经从运行单个进程的单一应用程序发展到复杂的架构，包括分布在众多节点上的数百甚至数千个服务。这种演变需要不同的工具和技术来推理构成现代软件的不同组件。当您使可观察性适应软件时，它允许您以新的方式与您编写的代码进行交互和推理。可观察的系统允许您回答开放式问题并理解：

应用程序的内部工作原理

系统的当前状态，无论多么极端或异常

用户当前遇到的问题

为什么系统会以某种方式运行——无需猜测

人们对可观察性的含义有不同程度的理解。对于一些人来说，这只是伪装成一个新流行词的老式监控。但究竟什么是可观察性，它与监控有何不同？

可观察性与监控有何不同

许多公司长期以来一直使用基于指标的工具系统和监控来推理他们的系统并解决问题。这些组织中的 IT 运营部门汇总了指标，并使用悬挂在其 IT 室周围的大屏幕显示大量仪表板。

在分布式架构时代之前，监控是一种反应式方法，适用于传统应用程序。但是，监控有一个缺陷：您无法完全查看或了解您的系统。监控迫使你做出反应，推测出了什么问题。

监控基于许多不再适用于现代应用程序的假设。例如，监控假设：

• 您的应用程序是单片的。
• 您有静态数量的节点或主机要监控。
• 只有当灾难发生时，你才会观察一个系统。
• 该应用程序在虚拟机或裸机上运行，??让您可以完全访问系统指标。
• 您可以通过仪表板和遥测满足运营工程师的需求。

由于以下原因，这些假设在现实中不再适用于现代架构：

• 有许多服务需要管理。
• 有许多具有不同技术的存储可供观察。
• 基础设施是高度动态的，容量的出现和消失取决于需求。
• 要监控的主机或节点的数量总是在变化和不可预测的。
• 自动仪器不足以了解复杂系统中正在发生的事情。
• 许多分散且松散耦合的服务正在管理中，其中许多服务不受站点可靠性工程团队的直接控制。

分布式系统中的故障模式是不可预测的。它们经常发生并且很少重复，以至于大多数团队无法设置适当且相关的仪表板来监控它们。这就是可观察性如此重要的地方。它使工程团队能够以各种方法收集遥测数据，从而使他们能够诊断问题而无需先预见错误是如何发生的。

为什么可观察性很重要

一个可观察的系统比不那么显眼的系统更容易了解（一般和非常详细）、监控、用新代码更新和修复。但除此之外，还有更多理由让您的系统可观察。可观察性将帮助您：

• 发现并解决“未知的未知”或您不知道的问题：监控系统最重要的限制之一是它们只寻找“已知的未知”或您已经知道的异常情况。可观察性识别您不会意识到或不会考虑搜索的情况。然后，它监控它们与特定性能问题的联系，为根本原因识别和解决提供上下文。
• 在开发过程的早期识别和解决问题：可观察性将使您深入了解软件开发过程的早期阶段。在新代码中的问题损害用户体验或服务水平协议 (SLA) 之前，开发团队能够发现并修复它们。
• 节省时间：没有可观察性，开发人员只能疯狂猜测 X 和 Y 发生的原因。就时间和资源而言，这是非生产性的并且成本高昂。
• 提供深刻见解：可观察性让您了解根本原因。

总而言之，您需要可观察性，以便让您的 DevOps 团队能够调查任何系统，无论您的系统有多复杂，而无需依靠经验或深入的系统知识来分析根本原因。

可观察性的支柱

可观察性为系统状态提供了无与伦比的可见性。但这种可见性伴随着一些指导支柱或原则。当您正确剖析可观察性时，它有两个关键要素。首先是需要理解复杂系统的人，其次是有助于理解的数据。如果不承认人员和技术以及它们之间存在的交互，您就无法获得适当的可观察性。

有了这种理解，问题就来了：如何收集数据并将其组合起来进行检查以提供所需的洞察力？处理和传输数据的技术要求是什么？

这就是被称为指标、日志和跟踪的三大可观察性支柱发挥作用的地方。让我们一一看看。

指标

指标（也称为时间序列指标）是跨时间的应用程序和系统运行状况的基本指标。一个指标可以是应用程序在特定时期内消耗了多少内存或 CPU 容量。度量将包括时间戳、名称和表示某个值的字段。

在监控方面，指标是一个显而易见的起点，因为它们对于描述资源状态很有用。也就是说，您可以根据已知问题提出问题，例如“系统是活的还是死的？”度量标准旨在提供对已知问题的可见性。对于未知问题，您需要的不仅仅是指标。您需要上下文，而该上下文的一个有价值的信息来源是日志。

日志

日志是应用程序事件的详细、不可变和带时间戳的记录。开发人员可以使用日志来创建每个事件的高保真、逐毫秒记录，并附上上下文，他们可以“回放”以进行故障排除和调试等。因此，事件日志对于检测分布式系统中的紧急和意外行为特别有用。因此，由于单个系统组件中发生单个事件，因此在复杂的分布式系统中很少发生故障。

系统应该通过日志记录任何给定时间它正在做什么的信息。因此，日志可能是 DevOps 团队工具箱中第二重要的项目。此外，日志提供了比指标更详细的资源信息。如果指标表明资源不再可操作，日志可帮助您找出原因。充分利用日志的关键是保持合理的收集。通过限制您收集的内容来做到这一点。此外，在可能的情况下，关注常见领域，以便更快地发现大海捞针。

痕迹

跟踪是一系列因果关联的分布式事件的表示，这些事件对分布式系统的端到端请求流进行编码。当请求进入应用程序时开始跟踪。随着用户请求从服务转移到服务，跟踪使整个系统的行为和状态更加可见和易于理解。

由于跟踪具有丰富的上下文，因此您可以全面了解系统所有不同部分中发生的情况，因为传统上对 DevOps 团队隐藏的请求通过。跟踪提供了对应用程序整体运行状况的重要可见性。

跟踪还可以分析和监控系统，例如容器化应用程序、无服务器架构和微服务架构。然而，它们主要关注应用层，仅提供底层基础设施健康状况的有限视图。因此，即使您收集了跟踪、指标和日志，仍然需要全面了解您的环境。

DevOps 团队需要什么

尽管可观察性这个术语是几十年前创造的，但它对软件系统的使用或适应提供了一种思考我们制作的软件的新方法。随着软件和系统变得越来越复杂，人们会遇到难以预测、调试或计划的问题。DevOps 团队现在必须能够以灵活的方式持续收集遥测数据，从而使他们能够诊断问题，而无需先预见错误可能发生的方式，以便对问题进行故障排除并构建可靠的系统。

虽然日志、指标和跟踪很重要，但除非您以正确的方式使用它们，否则它们不足以具有可见性。为了产生有助于故障排除和性能调整的理解，可观察性需要将此数据与丰富的上下文相结合。简而言之，如果仅使用来自状态和控制向量的所有可行发展的输出信息（物理上，这通常对应于传感器获得的信息），可以确定当前状态，则系统被认为是可观察的。