什么是系统可观测性（Observability）

对于软件行业来说，可观察性是从控制理论借用的一个词。

可观测性是系统的一个属性。是指系统的状态是否可观察，即系统的状态是否可以监控、采集、分析、查询、可视化。

比如汽车的时速、转速、油位、温度等都是汽车的状态。这些状态能否被观察到就是汽车的可观察性。

可观测性可以帮助我们了解系统的状态，从而帮助我们诊断系统问题或优化系统性能。

例如，如果我们通过汽车仪表板发现汽车油位很低，那么我们就可以加油，避免汽车熄火。

为什么软件系统需要可观察性

在软件开发和运维领域，可观测性是保证软件系统稳定高效运行、快速排查问题的关键因素。以下是软件系统需要可观察性的几个重要原因：

1. 故障排查与排查：软件系统可能会出现各种故障和问题，如崩溃、性能下降、错误等。通过可观测性工具，可以监控系统的各个组件和指标，快速发现问题并解决问题。定位根本原因，从而缩短故障修复时间。

2. 性能优化：软件系统的性能问题可能会导致响应时间延迟、资源浪费等。通过监控和分析系统的性能指标，开发人员可以识别瓶颈并进行优化，以确保系统高效运行。

3. 自动化和自动恢复：可观察性是自动化操作和自动恢复的基础。当系统检测到异常或问题时，可以自动触发恢复机制，减少人工干预，提高系统稳定性。

4. 用户体验改进：可观察性帮助开发人员了解用户如何使用软件及其体验。通过收集用户行为数据和反馈，开发团队可以做出相应的改进，提高用户满意度。

5. 持续交付和持续集成：可观察性有助于实现持续交付和持续集成流程。通过监控代码部署、集成测试和应用程序性能，团队可以及时发现问题并确保每次部署都是可靠的。

6. 容量规划和资源管理：可观察性可以提供对系统资源使用情况的洞察。这有助于容量规划，以确保系统能够满足未来需求并避免资源瓶颈。

7. 安全监控：软件系统的安全至关重要。通过可观测性工具，您可以监控潜在的安全漏洞、入侵和异常活动，并及时采取措施保护系统安全。

8. 分析和决策支持：可观测性数据可用于分析趋势、用户行为、系统健康状况等。这些数据可以帮助管理层做出更明智的决策、制定战略和计划。

可观察性的三大支柱

记录

日志是软件系统中最常见的可观察工具。它可以记录系统中发生的事件和异常，以及事件发生的时间、地点、原因等信息。日志可以帮助开发人员了解系统的运行情况、发现问题、排除故障。

指标

指标是可观察性的另一个重要组成部分。它可以提供有关系统状态的实时信息，例如CPU使用率、内存使用率、网络流量等。指标可以帮助开发人员了解系统的性能和健康状况，以便他们对其进行优化和改进。

分布式追踪

分布式跟踪是一种用于监控和诊断分布式系统的技术。它可以跟踪请求在系统中的传播路径，记录请求的处理时间和状态，以及请求经过的组件和服务。分布式追踪可以帮助开发人员了解系统的运行情况，识别瓶颈并进行优化。

迹线和跨度

分布式追踪的核心概念是Trace和Span。一个Trace由多个Span组成，每个Span代表一个请求或操作。

Span通过Parent-Child等关系形成树形结构。这个树形结构就是Trace，描述了请求在系统中的传播路径。

一个 Span 通常包含以下信息：

• 迹线 ID：标识迹线
• 跨度 ID：标识跨度
• 父 ID：标识当前 Span 的父 Span
• 操作名称：Span的操作名称
• 开始时间：Span的开始时间
• 持续时间：Span
的持续时间
• 标签：Span的标签
• ...

Span 中的信息需要足以描述请求或操作，但不应该包含太多信息，因为这会增加系统开销。

 [跨度 A] ←←←（根跨度）
            |
     +------+------+
     | |
 [跨度 B] [跨度 C] ←←←（跨度 C 是跨度 A 的“ChildOf”）
     | |
 [跨度 D] +---+--------+
               | |
           [跨度 E] [跨度 F] >>> [跨度 G] >>> [跨度 H]
                                       ↑
                                       ↑
                                       ↑
                         （跨度 G `FollowsFrom` 跨度 F）

轨迹通常用时间线来表示，如下图所示。每个 Span 的持续时间由一个矩形表示。矩形的宽度表示持续时间的长度，矩形的位置表示Span的开始时间。这使得它非常直观。可以清楚地看到请求在系统中的传播路径。

––|––––––––|––––––––|––––––|––––––––|––––––––| –––– –––|––––––––|–> 时间

 [跨度A··················································· ··]
   [跨度B·············································]
      [跨度D···················································· ·······
    [跨度C··········································]
         [跨度 E·······] [跨度 F··] [跨度 G··] [跨度 H··]

下面是Jaeger的Trace UI，在这里可以看到每个Span的持续时间和传播路径，以及每个Span的详细信息。

未知的未知 VS 已知的未知

与传统监控系统相比，可观测性的一个重要特点是可以帮助开发者发现未知的未知（Unknown Unknowns）。

传统的监控系统通常只能帮助开发者发现已知的未知（Known Unknowns）。也就是说，开发者必须知道问题的存在，才能通过监控系统来识别并解决问题。

在传统监控中，开发人员通常会定义一些阈值。当指标超过阈值时，就会触发警报。或者通过日志打印一些你认为可能有问题的信息。当出现问题时，可以通过日志来定位问题。

但是这些方法都有一个共同的缺点，那就是开发人员必须知道问题的存在，才能通过监控系统来识别问题并解决问题。

就日志记录而言，开发者在对这些地方进行日志记录之前，必须知道哪里可能会出现问题。当出现问题时，可以通过日志来定位问题。但有时候，开发者一开始记录的日志可能不够，或者记录的日志不够详细，这会导致问题无法定位。为此，可能需要对日志进行补充和重新部署，这会浪费大量的时间和精力。

可观测性帮助开发者通过高基数、高维数据发现未知的未知，从而提高系统的稳定性和可靠性。

• 高基数：基数是指数据的唯一性。高基数是指数据的高唯一性，比如客户端的IP地址、用户的ID、Trace ID等，可以帮助我们快速判断问题发生的上下文。低基数数据通常是不够的，比如一堆只记录异常类型的日志。由于缺乏上下文，很可能无法定位问题。
• 高维度：高维度是指数据的多样性，例如服务的名称、请求的参数、客户端应用程序的版本号等。

数据关联——实现可观察性的关键

高基数、高维数据是数据关联的基础。

可观察性的三大支柱（日志、指标和分布式追踪）可以提供丰富的信息，但这些信息往往是分散的，开发人员需要花费大量的时间和精力来分析和关联这些信息。因此，数据的相关性是实现可观察性的关键。

Trace代表一个完整的处理过程。围绕Trace关联Logging和Metrics可以帮助开发者快速定位问题，从而缩短故障修复时间。

Logging 与 Trace 关联后，Logging 就成为处理上下文中的连续事件。

Metrics与Trace关联后，Metrics就变成了处理上下文中持续变化的指标。

比如在电商平台中，用户下单时可能会遇到各种各样的问题，比如订单失败、订单超时、订单异常等，为了通过日志定位这些问题，我们需要在每个订单处打印日志下订单阶段。

但原木通常是分散的。如果日志中没有记录用户ID或订单ID，则很难关联离散的日志来定位问题。

通过在日志中统一记录Trace ID，我们可以很好地关联离散的日志，并且不再需要在每个日志中打印完整的请求上下文。

总结

可观察性是软件系统的一个重要属性。它可以帮助开发人员了解系统的运行情况、发现问题并排除故障。
为了构建系统的可观察性，我们不仅需要收集日志、指标、分布式追踪等信息，还需要将这些信息关联起来，帮助开发者快速定位问题。
稍后我们将介绍如何通过 OpenTelemetry 构建系统可观测性。

欢迎关注个人技术公众号