可观察性

可观察性是从外部输出知识中推断所获得，可理解为衡量一个系统内部状态的方法。

可观察性实际上是关于理解系统在生产环境中的表现， “可观察性”旨在提供对系统行为的高度细化的见解以及丰富的上下文，非常适合提供隐式故障模式所需的信息和调试所需的信息。

可观察系统是一种能够自行公开足够数据的系统，以便生成信息（找到尚未制定的问题的答案）并以简单的方式轻松访问这些信息。

它可以帮助运维团队获得：

• 在关键事件中尽早发现问题、进行控制并发出警告
• 更有效地查找出问题的根源
• 获得实时反馈，更快地采取措施修复事件
• 进行准确的事后审查和检查
• 更好地了解追溯问题产生的根源，防止其复发
• 保证获得紧密的反馈，进行持续不断的改善
• 通过分析和机械学习，预测并预防问题

“可观察性”衡量的是我们仅通过外部输出就能很好地理解给定系统的内部。为了理解一个复杂的系统的性能和行为，我们需要合适的外部输出，唯一方法是使用高质量的遥测技术：可观察性的三大支柱：日志log，指标metric和跟踪trace。

logging

日志是随时间发生的离散事件的不可变记录，展现的是应用运行而产生的事件，可以详细解释系统的运行状态。

事件日志一般有三种形式：明文（自由文本记录），结构化（通常以json格式发出），二进制（protobuf，mysql binlog等等）。

日志的存储和查询需要消耗大量的资源。所以往往使用过滤器减少数据量。tracing和metrics可以看作在日志上进一步的抽象。

tracing

Tracing，是一系列因果相关的分布式事件的表示，这些事件通过分布式系统对端到端请求流进行编码。面向的是请求，可以轻松分析出请求中异常点，但与 logging 有相同的问题就是资源消耗较大。通常也需要通过采样的方式减少数据量。

Trace通常表示为有向非循环图，它们用于识别在每个层完成的工作量，同时使用发生在语义之前保留因果关系。收集此信息并重建执行流程，同时保留因果关系以进行回顾性分析和故障排除，使人们能够更好地了解请求的生命周期。了解整个请求生命周期可以调试跨多个服务的请求，以查明增加响应时间或资源利用率的来源。

metrics

Metrics，是一种聚合数值，存储空间很小，可以观察系统的状态和趋势，但对于问题定位缺乏细节展示。这个时候使用等高线指标等多维数据结构来增强对于细节的表现力。

metrics是数据的数字表示，因此可以充分利用数学建模和预测的力量，在当前和未来的时间间隔内推导出我们系统行为的知识 。

如果要为微服务添加度量，

首先，建议捕获请求数，以观察你的服务有多繁忙以及每秒/分钟收到多少请求，即请求数。

其次，捕获服务的服务时间。本质上是每个请求的持续时间，来捕获服务的延迟，即服务响应时长。

然后，捕获错误请求的数量，以观察请求服务失败的百分比，即请求错误率。

最后，如果你不确定要检查的百分位数，将其设置为95％百分位数。

OpenTelemetry

OpenTelemetry是一组集成的API和库，用于生成、收集和描述关于分布式系统的遥测技术。这些数据包括基本的上下文传播、分布式跟踪、度量和未来的其他信号。OpenTelemetry能够轻松地从您的服务中获取关键的遥测数据：对于每种语言，它都提供一组API、库和数据规范，开发者可以使用他们认为合适的组件。

OpenTelemetry非常适合于各种软件系统，从客户端应用程序、大型单体或高度分布式的微服务。它还提供了一个收集器组件，可以在将其导出到后端之前代理、聚合和丰富遥测。

在技术上和组织上，OpenTelemetry是OpenTracing和OpenCensus项目的融合，并将随着时间而取代这两者。OpenTelemetry庞大的生态系统由以下几部分组成：

• 标准/规范
• API
• SDK具体实现了的API
• Metrics（指标）
• Tracing（跟踪）
• Auto-Instrumentation（自动检测）
• Exporters（导出器）
• Collector（收集器）

标准和规范

OpenTelemetry采用了一种基于标准的实现方法。对标准的关注对于OpenTelemetry来说尤其重要，因为它需要追踪跨语言的互操作性。许多语言都带有类型定义，可以在实现中使用，例如用于创建可重用组件的接口。

特定于API语言的类型和接口

每种语言都通过其API实现规范。API包含特定于语言的类型和接口定义，它们是抽象类、类型和接口，由具体的语言实现使用。它们还包含无操作（no-op）实现，以支持本地测试并为单元测试提供工具。API的定义位于每种语言的实现中。正如OpenTelemetry Python客户端所述：

“opentelemetry-api包包括抽象类和无操作实现，它们组成了遵循规范的OpenTelemetry API。”

你可以在OpenTelemetry Javascript客户端中看到类似的定义：

“这个包提供了与OpenTelemetry API交互所需的所有东西，包括所有TypeScript接口、枚举和no-op实现。它既可以在服务器上使用，也可以在浏览器中使用。”

SDK规范实现

SDK是将导出器与API结合在一起的粘合剂。SDK是具体的、可执行的API实现。本节的其余部分将探索每个主要的OpenTelemetry组件：导出器、指标、跟踪、自动检测和收集器。

Exporters（导出器）

导出器使你能够从应用程序中提取数据，并将数据转换为特定的检测协议和供应商。这里的导出器概念与OpenCensus和OpenTracing是相同的。因此，你可以使用OpenTelemetry来测试应用程序，然后配置一个导出器来确定OpenTelemetry数据被发送到哪里。这样可以将工具与任何特定的供应商或协议解耦，避免供应商锁定。

Metrics（指标）

如果你已经使用过OpenCensus，那么你应该非常熟悉指标。将指标（实际指标事件）与输出器组合在一起的基本特性在OpenTelemetry中称为Meter。指标特性是通用的，用于捕获各种指标事件，如下所示：

Meter的使用例子

Tracing（跟踪）

在OpenTelemetry中追踪与OpenTracing非常相似。OpenTelemetry引入了TracerProvider的概念，它可以以单例模式为全局跟踪器实例建模，类似于OpenTracing的全局跟踪器。OpenTelemetry还引入了额外的抽象，比如SpanProcessor，它将导出器连接到OpenTelemetry API调用：

Tracer/exporter配置

Auto-Instrumentation（自动检测）

自动检测是动态检测用于跟踪的特定于语言的库的能力。检测用于跟踪的库需要在所有调用站点中传播跟踪上下文。在遗留项目和大型项目中，修改代码来传播这一点可能非常困难，在node.js这样的语言中更是难上加难，它一直缺乏线程本地存储。自动检测将自动修补公共库（如HTTP客户端/服务器、web框架和数据库客户端）以自动添加跟踪！

Epsagon还将其特定于语言的自动检测框架集成到Python、Ruby、Java、Go和Node.js、PHP和.NET中，这大大减少了检测跟踪所需的时间。

Collector（收集器）

OpenTelemetry最大的新功能之一就是代理的概念。代理是收集指标的独立守护进程。为了支持代理，OpenTelemetry创建了它的提供者无感协议：collector。这就将遥测技术的输出和转换与采集分离开来。OpenTelemetry还提供了一种新的与供应商无关的协议来支持收集器。虽然该协议仍处于起步阶段，但其目标是进一步将可观察性工具与特定供应商分离。

思维导图：