theme: smartblue

原文链接：What Is Observability? Comprehensive Beginners Guide

如果你想了解什么是可观测性、其重要性、好处及其组成部分，本指南非常适合你。

什么是可观测性？

可观测性的字面意思是可观测的状态。

在 IT 领域，可观测性被定义为根据系统生成的输出数据（例如日志、指标和追踪）来测量系统当前状态的能力。

Opentelemetry 网站以一种很好的方式描述了可观测性。

可观测性让我们能够在不了解系统内部运作的情况下提出有关系统的问题，从而从外部了解系统。此外，它使我们能够轻松地排除故障并处理新问题（即「未知的未知 - unknown unknowns」），并帮助我们回答「为什么会发生这种情况？」 的问题。

opentelemetry.io

询问有关该系统的问题意味着收集有关系统如何执行和行为的信息和见解（insight）的能力。

让我们看一个实际的例子。

想象一下，你正在管理一个包含许多微服务的电商网站，例如前端服务、产品服务、购物车服务、订单服务、支付服务等。

网站的加载突然变得缓慢。

如果没有可观测性，你可能必须深入研究代码、数据库响应时间、API 延迟、第三方服务延迟并手动检查各种组件才能找到问题。

然而，有了可观测性工具，你可以「提出问题」，例如：

1. 过去一小时网站的平均响应时间是多少？
2. 错误率是否出现峰值（spike）？
3. 哪个特定服务或组件响应时间最长？
4. 数据库查询响应时间如何？
5. 是否有特定类型的请求或事务遇到延迟？
6. 速度下降是所有用户都一样的还是特定于某个区域的？

这些问题可以通过应用日志、指标和追踪提供的数据来回答。

1. 日志通过日志库记录应用中发生的事件。
2. 指标提供有关系统操作的数值数据（例如响应时间、请求数量等）。使用库对应用进行仪表化（instrumented - 仪表化是一种对现实的类比，就像给应用安装上可以显示各种数据的仪表，类似于现实中仪器或机器上的仪表）以生成指标。
3. 追踪使用 OpenTelemetry 或 APM（应用性能监控）代理等库来追踪请求通过分布式系统中的各种服务的过程。

例如，通过分析这些数据，你可以定位出速度下降是由于某个特定服务响应时间过长造成的，可能是由于最近的代码更改或负载增加造成的。这样可以更快、更有效地解决问题。

现在你可能会想，这听起来像是典型的监控。但事实并非如此。让我们了解监控和可观测性之间的区别。

可观测性与监控之间的区别

对于 DevOps 工程师或刚刚开始 SRE 的人来说，彻底理解可观测性与监控之间的区别非常重要。

以下是 DORA 的研究——关于可观测性和监控的区别：

监控是一种工具或技术解决方案，允许团队观察和了解其系统的状态。监控基于收集预定义的指标或日志集。

可观测性是允许团队主动调试其系统的工具或技术解决方案。可观测性基于探索未预先定义的属性和模式。

devops-research.com

监控是指密切关注已知问题和应用 / 系统指标。

它涉及为特定指标（如 CPU 使用率、内存使用率、响应时间、数据库查询执行时间、4xx、5xx 错误率等）设置告警和阈值，以及其他记录在案的监控 KPI，以便在出现问题时通知团队。

因此，监控的重点是根据预定义的指标和日志来追踪系统的状态和运行状况。

例如，当服务器的 CPU 使用率超过 80% 或 API 的响应时间超过 2 秒时，监控工具会发送告警。

另一方面，可观测性则更进一步。

它是通过查看应用和系统的输出（如日志、指标和追踪）来了解应用和系统的内部状态。这不仅是要知道何时出现问题，还要了解为什么会出现问题。

可观测性的关键焦点更具探索性和调查性，允许你提出有关应用行为的任意问题并诊断你没有预料到的问题。

例如，当网站开始意外变慢时，你可以使用可观测性工具来分析数据模式、追踪请求并查看日志，以定位出是由于最近的代码部署导致内存泄漏，从而导致响应时间变慢。

简而言之，监控告诉你系统发生了故障，而可观测性可以帮助你找出系统故障的原因。

现在我们对可观测性有了全面的了解，让我们看看关键的可观测性概念。

可观测性概念

以下是可观测性的三个关键垂直领域。

1. Metrics
2. Logs
3. Traces

日志

日志是应用中事件的记录。日志条目（entry）通常包含有关发生的事件的信息，包括时间戳、事件描述、严重级别，有时还包含其他上下文，例如用户 ID 或会话 ID。

2023-11-20 10:15:32 INFO  UserService: Starting getUserById for userId=12345
2023-11-20 10:15:32 DEBUG UserService: Fetching user data from database for userId=12345
2023-11-20 10:15:33 INFO  UserService: User data retrieved successfully for userId=12345
2023-11-20 10:15:34 WARN  UserService: User 12345 has outdated profile information
2023-11-20 10:15:35 ERROR UserService: Failed to send notification email to userId=12345, [email protected]
2023-11-20 10:15:35 INFO  UserService: getUserById completed for userId=12345

开发人员负责在代码中记录日志。由于大多数软件库和语言都有内置的日志功能，因此实现日志很容易。以下是不同类型日志格式的几个示例。

1. 纯文本：以人类可读文本记录的最简单形式。
2. 结构化：以机器可读格式（JSON、XML 等）构建的日志
3. 二进制格式：以二进制格式存储的日志（Protobuf 日志、MySQL 二进制日志、Systemd 日志等）
4. 自定义格式：满足特定项目要求。

指标

指标是以一段时间间隔内测量的数值表示的数据。

例如，Prometheus 中的 node_memory_MemAvailable_bytes 指标显示可用内存量（以字节为单位）。 http_request_duration_seconds 指标追踪 HTTP 请求的持续时间。

以下是 Prometheus 导出器（exporter）生成的指标示例。

http_requests_total{method="post",code="200"} 1027
http_requests_total{method="post",code="400"} 3
http_request_duration_seconds_bucket{le="+Inf"} 134091
http_request_duration_seconds_sum 52123
http_request_duration_seconds_count 134091
node_memory_MemAvailable_bytes 2.147483648e+09
node_cpu_seconds_total{mode="user"} 9123.42

指标在可观测性方面发挥着关键作用。通过指标，你可以一目了然地了解系统的长期状态，并帮助你发现不同时间系统行为的趋势和模式。

追踪和跨度

追踪（trace）和跨度（span）是主要用于分布式追踪的术语。

分布式追踪是一种用于追踪和监控分布式系统中的请求流的方法，特别是在微服务架构中。

让我们看一个使用微服务构建的电商应用的示例。

当用户下单时，请求会经过多个服务：它首先到达订单处理服务，然后与库存、付款和用户帐户服务进行通信。

分布式追踪将在所有这些服务中追踪此请求。

在这里，追踪代表单个订单请求通过系统的整个旅程。每个追踪由多个跨度组成，其中每个跨度代表追踪内的特定操作或进程。

跨度可以是对微服务的调用、数据库查询或任何其他离散的工作单元。

通过分析追踪，开发人员可以定位系统性能瓶颈，了解不同组件对系统性能的影响，并解决问题。

Jaeger 或 Zipkin 等开源分布式追踪工具可以将跨度序列显示为时间线，从而更容易理解请求的流程和延迟。

可观测性如何运作？

可观测性平台通过将嵌入到应用和基础设施组件中的现有仪器集成并提供向这些组件添加仪器的工具，不断识别和收集性能遥测数据。

可观察性平台通过集成应用和基础架构组件中的现有的仪表（instrumentation）来识别和收集性能遥测数据，并提供工具来为这些组件添加仪表。

大多数平台都会收集指标、追踪和日志。然后，实时连接它们，为 DevOps 团队、站点可靠性工程 (SRE) 团队和 IT 人员提供全面的上下文信息 — 每个可以指示、促成或使用的事件的内容、地点和原因解决应用性能问题。

为什么可观测性很重要？

借助可观测性，在高度分布式系统上工作的跨职能团队（尤其是在企业环境中）可以更快、更有效地对精确查询做出反应。

我们可以确定是什么降低了应用的性能，并努力在它影响整体性能或导致宕机之前修复它。

可观测性的好处不仅限于 IT 的使用场景。当你收集和检查可观测性数据时，你可以了解数字服务对组织的影响。通过此访问权限，你可以监控用户体验 SLO 的结果，检查软件版本是否满足业务目标，并根据最重要的内容确定业务选择的优先级。

根据 Observe 可观测性状态报告，91% 的组织表示他们目前正在实践可观测性。然而，只有 11% 的组织认为他们的整个环境目前是可观测的

可观测性有什么好处

可观测性为最终用户、企业和 IT 团队提供了显著的优势。以下是显著的好处以及可观测性为何如此重要：

1. 应用性能监控：完整的端到端可观测性使企业能够更快地识别性能问题，甚至是由云原生和微服务架构带来的问题。使用先进的可观测性解决方案可以自动化更多任务，这将提高运维和应用团队的生产力和创造力。
2. DevSecOps 和 SRE：可观测性是应用及其支持基础设施的基本特征，而不仅仅是实施创新工具的结果。软件的设计者和开发者必须使其易于观察。然后，在软件交付生命周期中，DevSecOps 和 SRE 团队可以使用和理解可观测的数据来创建更强大、更安全、更弹性的应用。
3. 监控基础设施、云和 Kubernetes：使用可观测性的几个好处之一是它有助于基础设施监控。它使基础设施和运维 (I&O) 团队能够利用可观测性解决方案提供的改进环境来增加应用正常运行时间和性能、减少识别和修复问题所需的时间、检测云延迟问题并优化资源利用率，从而改善对应用的管理。他们的 Kubernetes 环境和现代云架构。
4. 最终用户体验：积极的用户体验可以提高企业的声誉和收入，从而赋予其竞争优势。公司可以通过在最终用户发现问题之前识别并解决问题，并在最终用户提出要求之前实施改进来提高客户满意度和留存率。

可观测性面临哪些挑战？

尽管可观测性一直很困难，但云的复杂性和变化的加速使得企业必须解决这个问题。当涉及微服务和容器化应用时，云系统会产生更多的遥测数据。此外，它们生成的遥测数据范围比过去任何时候都更全面，团队需要解读这些数据。

尽管可观察性一直很困难，但云的复杂性和变化的加快使得企业必须解决这个问题。当涉及微服务和容器化应用程序时，云系统会产生更高的遥测数据。此外，它们生成的遥测数据范围比团队过去不得不破译的要全面得多。

关于可观测性，组织经常遇到以下困难：

1. 数据孤岛（Data Silos）：由于存在多个代理、不同的数据源和孤岛监控工具，理解应用、各种云和数值渠道（包括网络、移动和物联网）之间的相互依赖关系具有挑战性。
2. 数量、速度、种类和复杂性：在不断发展的现代云基础设施（如 AWS、Azure 和 Google Cloud Platform）中，每个组件生成的原始数据量巨大，几乎不可能找到答案（GCP）。 Kubernetes 和容器快速启动和停止的能力也证明了这一点。
3. 预生产环境的不足：尽管在预生产环境中进行了负载测试，在将代码发布到生产环境之前，开发人员仍然缺乏一种观察或理解真实用户如何影响应用和基础架构的方法。
4. 浪费时间进行故障排除：来自应用、运维、基础设施、开发和数字化经验的团队被派来进行故障排除并试图查明问题的根源。结果，宝贵的时间被浪费在进行有根据的猜测和试图理解遥测数据上。

可观测性与 DevOps 有何关系？

在 DevOps 中，可观测性是必须考虑的。它在 DevOps 流程中发挥着至关重要的作用，因为它允许团队

1. 实时检测问题
2. 使用可观测性工具进行调试以追踪根本原因
3. 性能优化
4. 持续改进软件和基础设施

如何开始可观测性？

为了实现可观测性，你的系统和应用必须合理的配置和实现来收集必要的遥测数据。你可以通过创建自己的工具、利用开源软件或购买营利性可观测性解决方案来创建可观测系统。

以下是有关如何开始使用可观测性的几个步骤：

1. 确定你的业务目标：通过减少基础设施支出、支持增长容量规划或增强关键业务 KPI（例如平均恢复时间），强大的可观测性配置可以帮助增加底线收入。通过为支持人员提供额外的上下文数据，可以提高透明度，甚至创造积极的客户体验。然而，每个目标的可观测性配置可能非常不同。创建可观测性策略，以在确定主要业务目标后实现它们。

2. 关注正确的指标：精心设计的可观测性方法不是在问题出现时就做出反应，而是使人们能够预测可能的错误或故障的开始，然后查明其根本原因的位置。追求透明度涉及多种数据收集和分析流程以及其他监控和测试技术。

3. 事件日志：对于架构和开发团队来说，事件日志提供了分布式系统可观测性的重要数据源。专为事件日志记录而设计的工具（例如 Prometheus、Middleware 和 Splunk）可捕获和存储事件。这些事件可能包括应用的成功结束、重大系统故障、意外停机或导致过载的流量涌入。由于它为开发人员提供了重要的取证信息，以发现有缺陷的组件或有问题的组件交互，因此这对于调试和错误处理尤其重要。

4. 可访问的数据可视化：当团队成功收集可观测性数据时，必须将其压缩为可用且可共享的格式。这通常是通过使用各种工具对数据进行可视化表示来完成的。从那里，团队成员可以与参与该计划的其他团队传播或共享该信息。

5. 选择合适的可观测平台：在选择合适的可观测平台时，请考虑以下因素；

   • 该工具是免费的吗？
   • 该工具是否使用开源代理？
   • 这个容易用吗？
   • 我是否具备充分发挥该工具潜力的技术知识？
   • 该工具可以处理的数据量是多少？

回答这些问题和其他特定于业务的问题将帮助你做出明智的决定。

结论

可观测性系统需要适合其预期平台。如果缺乏这一点，它可能会发展成为一个笨重的系统，从而增加运维成本，或者变得不起眼且几乎没有可见性。因此，该计划还必须指定并命名组织设计必须实现的主要调查。

如果没有这个方向，可观测性可能会变成一个由相互冲突的问题组成的混乱网络，可能无法提供预期的连贯一致的用户体验和支持。