监控与观测

随着软件应用从单片架构向分布式微服务体系转变，应用监控(Monitoring)和观测(Observability)的需求也随之提升。两者存在相同的定义，目的都是为了发现应用程序中的问题。但还是有差别：

监控：目的是为了捕获已知的问题，并将其显示在仪表盘上，用以了解其发生问题的原因和其发生的具体时间；
观测：采用更底层的方式，即开发人员通过调试代码的方式从而了解程序的内部状态。为了帮助监控应用程序的未知问题的最新发展。

在这里插入图片描述
应用观测的三大支柱：

指标(metrics)：指出是否存在问题，通常是通过告警「发现」
调用链(traces)：标明问题点在哪里，「定位」
日志(logs)：协助定位产生问题的根本原因，「分析」

在这里插入图片描述
应用可观测的好处：

找出潜在隐患
降低告警疲劳
更快发布产品
提高自动化程度
提高开发生产力

OpenTracing

OpenTracing，制定一套无关厂商、无关平台的协议标准，使开发人员只需要修改Tracer就可以更迅捷的添加或更换底层监控的实现。2016年CNCF正式接纳OpenTracing，顺利成为CNCF第三个项目，前两个项目都已成为云原生及开源领域的事实标准：Kubernetes和Prometheus。由此也可以看到行业对于可观测及统一标准的重视程度。GitHub。

OpenTracing由API规范、实现该规范的框架和库，以及项目文档组成，并进行以下努力：

后台无关的API接口标准化：被追踪的服务只需要调用相关API接口，就可被任何实现这套接口的追踪后台支持；
对跟踪最小单位Span管理标准化：定义开始Span，结束Span和记录Span耗时的API；
进程间跟踪数据传递方式标准化：定义API方便追踪数据的传递；
多语言应用支持；多跟踪器支持，Zipkin、LightStep、Appdash；可轻松集成到gRPC、Flask、DropWizard、Django和Go Kit等框架中。

术语

包括：

Traces：记录经过分布式系统的请求活动，一个Trace是Spans的有向无环图；
Spans：一个Trace中表示一个命名的，基于时间的操作。Spans嵌套形成Trace树。每个Trace包含一个根Span，描述端到端的延迟，其子操作也可能拥有一个或多个子Spans；
Metrics：在运行时捕获的关于服务的原始度量数据。Observer支持通过异步API来采集数据，每个采集间隔采集一个数据；
Context：一个Span包含一个Span Context，它是一个全局唯一的标识，表示每个Span所属的唯一请求，以及跨服务边界转移Trace信息所需的数据。OpenTelemetry也支持correlation context，可以包含用户定义的属性。correlation context不是必要的，组件可以选择不携带和存储该信息；
Context Propagation：表示在不同的服务之间传递上下文信息，通常通过HTTP首部。除Tracing外，还可用于执行A/B测试。支持通过多个协议的Context Propagation来避免可能发生的问题，但需要注意的是，在自己的应用中最好使用单一的方法；
References：Spans之间建立连接的描述，目前有两种类型，ChildOf和FollowsFrom。

Maven

io.opentracing是官方核心库，包含主要的接口和规范，如Tracer、Span、SpanContext等，其下的artifactId包括：

opentracing-api：定义OpenTracing的核心API；
opentracing-util：提供帮助工具，如GlobalTracer；
opentracing-noop：提供无操作的实现，用于无跟踪时的默认行为。

最后发布日期停留在2019年5月份，Maven依赖如下：

<dependency><groupId>io.opentracing</groupId><artifactId>opentracing-api</artifactId><version>0.33.0</version>
</dependency>
<dependency><groupId>io.opentracing</groupId><artifactId>opentracing-noop</artifactId><version>0.33.0</version>
</dependency>

io.opentracing.contrib是OpenTracing社区贡献的扩展库组件，用于与各种第三方框架和工具进行集成。目的是简化OpenTracing与常见工具和框架的集成，降低接入成本。

其下的artifactId包括：

opentracing-tracerresolver：帮助在运行时解析和加载具体的Tracer实现，如Jaeger或Zipkin；
opentracing-spring-cloud：为Spring Cloud应用提供OpenTracing集成；
opentracing-jdbc：为JDBC提供数据库调用的自动跟踪；
opentracing-kafka：用于跟踪Kafka消息的生产和消费。

一张图感受一下到底有多少个artifactId：
在这里插入图片描述
最后发布日期停留在2019年6月份。

Jaeger和OpenTracing

Jaeger是最早实现OpenTracing API的分布式追踪系统之一，由Uber开发，后来捐赠给CNCF。

Jaeger 1.x和2.x版本都支持OpenTracing API，可直接使用opentracing-api库进行分布式追踪开发。

OpenCensus

官网，其发起者是谷歌，也就是最早提出Tracing概念的公司，可理解为Google Dapper的社区版。和OpenTracing最大的不同在于除Tracing外，还包括Metrics指标监控；并不是单纯的规范制定，还包括数据采集的Agent、Collector等。有众多追随者，如微软。GitHub。

除沿用OpenTracing的相关术语之外，OpenCensus也定义一些新术语：

Tags：允许在记录时将指标与维度相关联。从而能够从不同角度分析测量结果；
Stats：收集库和应用记录的可观测结果，汇总、导出统计数据，并包括Recording、Views（聚合度量查询）两部分；
Trace：除Opentracing所提供的Span属性之外，OpenCensus还支持Parent SpanId、Remote Parent、Attributes、Annotations、Message Events、Links等属性；
Agent：OpenCensus Agent是一个守护进程，允许OpenCensus的多语言部署使用Exporter。与传统上为每个语言库和每个应用程序删除和配置OpenCensus Exporter不同，使用OpenCensus Agent，只需为其目标语言单独启用OpenCensus Agent Exporter。对于运维团队而言，实现单个Exporter管理并从多语言应用程序中获取数据，将数据发送到所选择的后端。与此同时，尽可能的减少反复启动或部署对于应用的影响。Agent还附带Receivers，使Agent直通后端，去接收可观测数据并将其路由到所选择的Exporter。如Zipkin、Jaeger或Prometheus。
Collector：OpenCensus的重要组成部分，由Go编写，可从任何可用Receivers的应用中接受流量，而不用关注编程语言以及部署方式。对于提供Metrics和Trace的服务或应用而言，只需要一个Exporters导出组件，就能从多语言应用中获取数据。对于开发者而言，只需要管理维护单个Exporter，所有应用都使用OpenCensus Exporter发送数据。开发人员自由选择将数据发送到业务所需的后端，并随时进行更好。为了解决通过网络发送大量数据可能需要处理发送失败的问题，Collector具有缓冲和重试功能，可确保数据完整性与可用性。
Exporters：OpenCensus 可通过各种 Exporter 实现将相关数据上传到各种后端，比如：Prometheus for stats、OpenZipkin for traces、Stackdriver Monitoring for stats and Trace for traces、Jaeger for traces、Graphite for stats。

遵循OpenCensus协议的产品有Prometheus、SignalFX、Stackdriver和Zipkin。

OpenTelemetry

OpenTracing项目在2019年停止更新，后续其功能被OpenTelemetry，简称OTel，所取代。GitHub。

遥测数据(Telemetry Data)是跨科学领域的通用术语，描述一种从远程位置收集数据集用于测量系统健康状况的行为。在DevOps中，系统指的就是软件应用，要收集的数据就是日志、调用链和指标。

架构简图
在这里插入图片描述

在OpenTracing基础上引入的术语：

Metrics：在运行时捕获的关于服务的原始度量数据。Observer支持通过异步API来采集数据，每个采集间隔采集一个数据；

OpenTracing、OpenCensus和OpenTelemetry

特性	OpenTracing	OpenCensus	OpenTelemetry
简介	最早的分布式追踪标准，定义统一的接口和规范，允许用户切换具体的追踪器	Google发起，支持Tracing，Metrics，并提供数据采集Agent和Collector	OpenTracing和OpenCensus合并后产物，目的是构建一个统一的、全面的可观测性标准，支持分布式追踪和指标采集
覆盖范围	仅支持分布式追踪，不涉及Metrics或Logs	支持Traces、Metrics，但不包含Logs	支持分布式追踪、指标、日志；提供自动代码注入和Collector（Agent/Gateway模式）
生态兼容性	CNCF托管，被Jaeger、Zipkin等支持	微软等公司加入支持，生态较强；缺乏统一的CNCF支持	成为CNCF的标准，可被更多工具支持；兼容OpenTracing和OpenCensus，提供平滑迁移路径
标准化程度	API标准	SDK+采集架构	统一API+SDK+协议
数据采集	依赖第三方实现	自带Agent/Collector	自带OTLP Collector
当前状态	2019年停止发布Release，GitHub于2023年5月24日归档	GitHub于2023年8月1日归档	活跃开发中，逐步取代OpenTracing和OpenCensus

对应替代关系：

io.opentracing:opentracing-api→io.opentelemetry:opentelemetry-api；
io.opentracing:opentracing-util→io.opentelemetry:opentelemetry-sdk；
io.opentracing.contrib:opentracing-tracerresolver→无直接替代，OpenTelemetry提供标准化的SDK初始化方式；
其他io.opentracing.contrib库可被OpenTelemetry的自动检测和集成工具替代。

迁移指南：OpenTelemetry项目提供从OpenTracing迁移到OpenTelemetry的官方指南，其中列举关键变化和替代组件。

<dependency><groupId>io.opentelemetry.javaagent</groupId><artifactId>opentelemetry-javaagent-api</artifactId><version>0.16.1</version><scope>runtime</scope>
</dependency>

Jaeger和OpenTelemetry

互补：

OpenTelemetry：专注于数据采集和标准化，包括API、SDK、Collector；
Jaeger：Jaeger Exporter将数据从OpenTelemetry Collector或SDK导出到Jaeger后端；专注于追踪数据的存储、分析和可视化。

OTLP

OpenTelemetry Protocol，OpenTelemetry定义的标准数据格式。OTLP取代旧版协议（如Jaeger或Zipkin的专用协议），成为OpenTelemetry默认导出格式。

核心特性：

多数据类型支持：统一传输跟踪、指标和日志；
多传输协议：默认使用gRPC，支持HTTP/JSON；
高效编码：基于Protocol Buffers的二进制编码，减少带宽占用；
端到端可靠性：内置重试、队列和批处理机制。

架构
在这里插入图片描述

OTLP协议的关键优势：

统一三种遥测数据的传输方式；
通过PB实现高性能序列化；
灵活的传输层支持（gRPC/HTTP）。

Jaeger

版本

在这里插入图片描述
版本1.*和2.*，同时在更新release发布中。

版本区别：

在Jaeger 1.x中

前端API：
Jaeger提供完整的分布式追踪生态，包括一个实现OpenTracing标准的客户端（通过jaeger-client库）。开发者可以直接调用Jaeger的API（如JaegerTracer）来生成和发送追踪数据。
后端处理：
Jaeger同时作为追踪系统的后端，包含以下组件：
- Agent：接收应用程序发来的Span数据；
- Collector：处理和存储追踪数据到数据库；
- Query：提供数据查询和UI可视化。

Jaeger 1.x是全栈式分布式追踪解决方案，包括前端API和后端功能。

在Jaeger 2.x中：

前端API的弱化：不再专注于提供客户端API，而是转向支持OpenTelemetry的标准API和SDK。应用程序需要直接调用OpenTelemetry的API（如Tracer、Span），而不是依赖Jaeger的API。官方建议是使用OpenTelemetry SDK进行追踪数据的采集。
后端功能的强化：Jaeger 2.x专注于成为分布式追踪的后端系统，处理追踪数据的接收、存储和可视化：
- Collector：支持OpenTelemetry数据格式，兼容多种传输协议，如gRPC和HTTP；
- 存储：支持多种存储后端，如ES、Cassandra、Kafka等；
- Query和UI：继续提供可视化和分析功能，让开发者能查询和分析追踪数据。