opentelemetry是一套由CNCF主导的云原生可观测性的标准协议,全称:OpenTelemetry Protocol
,简称OTLP
。
可观测性一个很重要的领域 Trace
有两个业界标杆: 一个是OpenTracing,另一个OpenCensus
同时opentelemetry也致力于trace、logging、metrics间的关联性.
opentrace+openCensus=openTelemetry
OpenTelemetry要解决的是对可观测性的大一统,它提供了一组API和SDK来标准化遥测数据的采集和传输,opentelemetry并不想对所有的组件都进行重写,而是最大程度复用目前业界在各大领域常用工具,通过提供了一个安全,厂商中立的能用协议、组件,这样就可以按照需要形成pipeline将数据发往不同的后端。
opentelemetry也是个插件式的架构,针对不同的开发语言会有相应的Client组件,叫Instrumenttation,也就是在代码中埋点调用的api/sdk采集telemetry数据
这是go版本sdk https://github.com/open-telemetry/opentelemetry-go
metrics
: https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/metrics/v1/metrics.protologs
: https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/logs/v1/logs.prototrace
:https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/trace/v1/trace.protoresources
:https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/resource/v1/resource.protorpc_server_handled_seconds_bucket分布式追踪是一组事件,由单个逻辑操作触发,并跨应用程序中的各个组件合并。一个分布式追踪包含跨进程、网络和安全边界的事件。
Trace 由 Span 隐式定义,可以认为是 Span 的有向无环图(Directed Acyclic Graph, DAG)。
Span 代表了事务中的操作,每个 Span 封装了以下状态:
表示标识 Trace 中的 Span 的所有信息,必须传播到子 Span 和跨进程边界。一个 SpanContext 包含从父 Span 传播到子 Span 的跟踪标识符和选项。
0x1
)一个 Span 必须和 0 个或多个因果关联的其他 Span 链接(由 SpanContext 定义)。链接可以指向一个 Trace 内的 Span 或跨 Trace 。
当 Trace 进入服务的可信边界,并且服务策略要求生成新的 Trace 而不信任传入的 Trace 上下文时,可以用来表示原始 trace 和接下来的 trace 之间的关系。新链接的 Trace 还可以表示一个长时间运行的异步数据处理操作,由传入的许多请求之一发起。
OpenTelemetry 允许用预定义的聚合和标签集记录原始测量或度量。
使用 OpenTelemetry API 记录原始测量允许最终用户决定应该为这个度量用什么聚合算法,以及定义标签(维度)。它将被用于像 gRPC 的客户端库,记录原始测量 server_latency 和 received_bytes 。因此最终用户将决定应该从这些原始测量数据中收集哪种类型的聚合值,也可能是简单的平均值或精细的直方图计算。
使用 OpenTelemetry API 记录预定义聚合的度量同样重要。它允许收集 CPU 和内存使用,或者是像队列长度这样的简单度量。
用于记录原始测量的主要类是 Measure
和 Measurement
。可以使用 OpenTelemetry API 记录附加上下文的 Measurement
列表。因此,用户可以通过定义来聚合这些 Measurement
,并使用传递上下文来定义结果度量的额外维度。
Measure
描述库记录的单个值的类型。定义了公开测量方法的库和聚合独立测量到 Metric
中的应用之间的关系。Measure
由名称、描述和一个值的单位标识。
Measurement
描述为 Measure
收集的单一值,Measuremrnt
是一个空接口,在 SDK 中定义。
所有类型的预定义聚合度量的基类称为 Metric
,它定义了基本的度量属性,例如名称和标签。继承 Metric
的类定义自己的聚合类型和单个测量或点的结构。API 定义了以下类型的预定义聚合度量:
double
和 long
。double
和 long
。API 允许构造选定类型的 Metric
,SDK 定义了要导出的 Metric
值的查询方式。
每种类型的 Metric
拥有自己的 API 记录将要聚合的值。API 支持推拉模型(push and pull model)来设置 Metric
值。
基于 metrics.proto 建立度量数据模型(Metrics Data Model),这个数据模型定义了三种语义:API 使用的事件模型(Event model)、SDK 和 OTLP 使用的 in-flight 数据模型、表示导出工具如何解释 in-flight 数据模型时间序列模型(TimeSeries model)。
不同的导出工具有不同的能力(例如,支持的数据模型)和约束(例如,哪些字符允许作为标签键)。所有导出工具都通过 OpenTelemetry SDK 中定义的度量生产者接口(Metric Producer interface)从度量数据模型中消费数据。
因此,Metrics 对数据的约束最小(例如,键中允许哪些字符),处理 Metrics 的代码应该避免对其进行验证和清洗。相反,将数据传递给后端,依赖后端执行验证,并从后端返回错误。
数据模型定义了 OpenTelemetry 如何理解日志和事件
除了 trace 的传播,OpenTelemetry 还提供了 Baggage
来传播键值对。Baggage
用于索引一个服务中的可观察事件,该服务包含同一事务中先前的服务提供的属性,有助于在事件之间建立因果关系。
虽然 Baggage
可以用作其他横切关注点的原型,但这种机制主要是为了传递 OpenTelemetry 可观测性系统的值。
这些值可以从 Baggage
中消费,并作为度量的附加维度,或日志和跟踪的附加上下文使用。一些例子:
Resources
获取关于被记录的遥测数据实体信息。例如,Kubernetes 容器公开的度量可以链接到指定集群、名称空间、pod 和容器名称的资源。Resources
可以捕获实体标识的整个层次结构,它可以描述云中的主机和特定的容器或进程中运行的应用程序。
所有 OpenTelemetry 横切关注点,例如 trace 和 metric ,共享底层的 Context
机制,用于在分布式追踪中存储状态和访问跨 Span 生命周期的数据。
OpenTelemetry 使用 Propagators
来序列化和反序列话横切关注点的值,例如 Span
(通常只有 SpanContext 的部分)和 Baggage
。不同的 Propagators
类型定义了特定传输和绑定到数据类型的限制。
传播器 API 定义了一个 Propagator
类型
TextMapPropagator
将值注入载体并从载体中提取值为文本。OpenTelemetry 收集器是一套组件,可以从 OpenTelementry 或其他监测/追踪库(Jaeger、Prometheus 等)执行的进程收集 traces、metrics 和其他遥测数据(例如,日志),并进行聚合和智能采样,导出 traces 和 metrics 到一个或多个监控/追踪后端。收集器允许丰富和转换所收集的遥测数据(例如,添加额外的属性或删除个人信息)。
OpenTelemetry 收集器有两种主要的操作模式:代理(与应用程序一起在本地运行的守护进程),收集器(独立运行的服务)。
被调用为另一个库启用 OpenTelemetry 可观测性的库称为工具库。各语言工具库
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。