使用 OpenTelemetry 构建 .NET 应用可观测性（1）：什么是可观测性
目录
- 什么是系统的可观测性（Observability）
- 为什么软件系统需要可观测性
- 可观测性的三大支柱
- Unknow Unknows VS Known Unknowns
- 数据的关联 - 实现可观测性的关键
- 总结
什么是系统的可观测性（Observability）
对软件行业来说，可观测性（Observability）是一个舶来词，出自控制论（Control Theory）。
可观测性是系统的一个属性，它是指系统的状态能否被观测，也就是说，系统的状态能否被监控、收集、分析、查询、可视化。
例如汽车的速度、转速、油量、温度等等，都是汽车的状态，这些状态能否被观测，就是汽车的可观测性。
可观测性可以帮助我们了解系统的状态，从而帮助我们诊断系统的问题，或者优化系统的性能。
例如我们通过汽车仪表盘发现汽车的油量很低，那么我们就可以去加油，从而避免汽车熄火。
为什么软件系统需要可观测性
在软件开发和运维领域，可观测性是确保软件系统稳定、高效运行以及快速排除问题的关键因素。以下是软件系统需要可观测性的几个重要原因：
-
故障诊断和排除问题： 软件系统中可能会出现各种故障和问题，如崩溃、性能下降、错误等。通过可观测性工具，可以监控系统的各个组件和指标，快速识别问题并定位根本原因，从而缩短故障修复时间。
-
性能优化： 软件系统的性能问题可能导致响应时间延迟、资源浪费等。通过监控和分析系统的性能指标，开发人员可以识别瓶颈并进行优化，以确保系统高效运行。
-
自动化和自动恢复： 可观测性是实现自动化操作和自动恢复的基础。当系统监测到异常或问题时，可以自动触发恢复机制，减少人工干预的需要，提高系统的稳定性。
-
用户体验改进： 可观测性可以帮助开发人员了解用户如何使用软件以及用户的体验如何。通过收集用户行为数据和反馈，开发团队可以做出相应的改进，提升用户满意度。
-
持续交付和持续集成： 可观测性有助于实现持续交付和持续集成流程。通过监控代码部署、集成测试和应用性能，团队可以及时发现问题，确保每次部署都是可靠的。
-
容量规划和资源管理： 可观测性可以提供关于系统资源使用情况的洞察。这有助于进行容量规划，确保系统能够满足未来的需求，并避免资源瓶颈。
-
安全监控： 软件系统的安全性至关重要。通过可观测性工具，可以监控潜在的安全漏洞、入侵行为和异常活动，及时采取措施保护系统安全。
-
分析和决策支持： 可观测性数据可以用于分析趋势、用户行为、系统健康状况等。这些数据可以帮助管理层做出更明智的决策，制定战略和规划。
可观测性的三大支柱
日志（Logging）
日志是软件系统中最常见的可观测性工具。它可以记录系统中发生的事件和异常，以及事件发生的时间、位置、原因等信息。日志可以帮助开发人员了解系统的运行情况，识别问题并进行排查。
指标（Metrics）
指标是可观测性的另一个重要组成部分。它可以提供关于系统状态的实时信息，如CPU使用率、内存使用率、网络流量等。指标可以帮助开发人员了解系统的性能和健康状况，从而进行优化和改进。
分布式追踪（Distributed Tracing）
分布式追踪是一种用于监控和诊断分布式系统的技术。它可以跟踪请求在系统中的传播路径，记录请求的处理时间和状态，以及请求经过的组件和服务。分布式追踪可以帮助开发人员了解系统的运行情况，识别瓶颈并进行优化。
Trace 和 Span
分布式追踪的核心概念是 Trace 和 Span，一个 Trace 由多个 Span 组成，每个 Span 代表一个请求或者操作。
Span 通过 Parent-Child 等关系组成了一个树状结构，这个树状结构就是 Trace，它描述了请求在系统中的传播路径。
一个Span通常包含以下信息：
- Trace ID：标识一个Trace
- Span ID：标识一个Span
- Parent ID：标识当前Span的父Span
- Operation Name：Span的操作名称
- Start Time：Span的开始时间
- Duration：Span的持续时间
- Tags：Span的标签
- ...
Span 的信息需要足以描述一个请求或者操作，但是不应该包含过多的信息，因为这会增加系统的开销。
[Span A] ←←←(the root span)
|
+------+------+
| |
[Span B] [Span C] ←←←(Span C is a `ChildOf` Span A)
| |
[Span D] +---+-------+
| |
[Span E] [Span F] >>> [Span G] >>> [Span H]
↑
↑
↑
(Span G `FollowsFrom` Span F)
Trace 通常用时间轴来表示，如下图所示，每个 Span 的持续时间用一个矩形表示，矩形的宽度代表持续时间的长短，矩形的位置代表 Span 的开始时间，这样就可以很直观地看到请求在系统中的传播路径。
––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time
[Span A···················································]
[Span B··············································]
[Span D··········································]
[Span C········································]
[Span E·······] [Span F··] [Span G··] [Span H··]
下面是 Jaeger 的 Trace UI，可以看到每个 Span 的持续时间和传播路径，以及每个 Span 的详细信息。
Unknow Unknows VS Known Unknowns
与传统的监控系统相比，可观测性的一个重要特点是它可以帮助开发人员发现未知的未知（Unknown Unknowns）。
传统的监控系统通常只能帮助开发人员发现已知的未知（Known Unknowns），也就是说，开发人员必须知道问题的存在，才能通过监控系统来识别和解决问题。
传统监控中，开发人员通常会定义一些阈值，当指标超过阈值时，就会触发警报。或者在觉得可能出问题的地方通过日志打印一些信息，当问题发生时，就可以通过日志来定位问题。
但是，这些方法都有一个共同的缺点，就是开发人员必须知道问题的存在，才能通过监控系统来识别和解决问题。
就打日志来说，开发人员必须知道可能出问题的地方，才会在这些地方打日志，当问题发生时，才能通过日志来定位问题。但有时候，开发人员一开始记录的日志可能不够，或者记录的日志不够详细，这样就会导致问题无法定位，为此可能还要补充日志重新部署，这样就会浪费大量的时间和精力。
可观测性通过高基数和高维度的数据，帮助开发人员发现未知的未知，从而提高系统的稳定性和可靠性。
- 高基数（high cardinality）：基数指的是数据的唯一性，高基数指的是数据的唯一性很高，例如客户端的IP地址，用户的ID， Trace ID等等，能够快速帮我们确定问题发生的上下文。低基数的数据通常是不够用的，例如一堆只记录了异常类型的日志，因为缺少上下文，那很可能无法定位问题。
- 高维度（high dimensionality）：高维度指的是数据的多样性，例如服务的名称，请求的参数，客户端app的版本号等等。
数据的关联 - 实现可观测性的关键
高基数和高维度的数据正是实现数据关联的基础。
可观测性的三大支柱（日志、指标和分布式追踪）可以提供丰富的信息，但是这些信息通常是分散的，开发人员需要花费大量的时间和精力去分析和关联这些信息。因此，数据的关联是实现可观测性的关键。
Trace 代表了个完整的处理过程，将 Logging、Metrics 围绕 Trace 进行关联，可以帮助开发人员快速定位问题，从而缩短故障修复时间。
Logging 与 Trace 关联后，Logging 就成了一次处理上下文里的连续事件。
Metrics 与 Trace 关联后，Metrics 就成了一次处理上下文里指标的连续变化。
例如在电商平台中，用户在下单时，可能会遇到各种问题，如下单失败、下单超时、下单异常等。为了能通过日志定位这些问题，我们需要在下单的各个环节打印日志。
但是日志通常是分散的，如果日志中没有记录用户ID或者订单ID，那么就很将离散的日志关联起来，从而定位问题。
通过在日志中统一记录 Trace ID, 我们可以很好的将离散的日志关联起来，我们也不再需要在每条日志中打印完整的请求上下文。
总结
可观测性是软件系统的一个重要属性，它可以帮助开发人员了解系统的运行情况，识别问题并进行排查。
想要构建系统的可观测性，不仅需要收集日志、指标和分布式追踪等信息，更需要将这些信息进行关联，从而帮助开发人员快速定位问题。
后续我们会介绍如何通过 OpenTelemetry 来构建系统的可观测性。