ASP.NET Core之关于OpenTelemetry概述

一、前言

  当前软件架构演变由单体架构=>分布式架构(SOA)=>微服务架构(mircoservice)=>云原生架构(cloud native),所以架构的演变导致对系统日志、监控、链路等统称为观测性方案提出巨大的挑战。在单体架构时代,借助丰富的日志库基本满足对日志管理,但是面对分布式、微服务的架构盛行,则要求在对服务的日志、监控、链路上提供好的解决方案,OpenTelemetry则满足上述要求,所以本章开始学习OpenTelemetry,通过ASP.NET Core构建的应用程序,使用OpenTelemetry完成日志方案、监控方案、链路方案。OpenTelemetry的官网是https://opentelemetry.io

二、OpenTelemetry的定义

  学习OpenTelemetry,首先了解清楚OpenTelemetry的是什么?定义是使用go语言编写的一个与供应商无关的开源可观测性框架,用于检测、生成、收集和导出遥测数据,如轨迹、度量、日志。目标是提供一套标准化与供应商无关的SDK、API、工具用于接收、转换数据并将数据发送到可观测系统(观测系统)后端,其允许开源或者商业。OpenTelemetry的出发点是解决系统观测性问题,主要包括日志、链路、监控,解决了观测性领域模型的统一、观测数据收集的统一、观测数据输出的统一主要体现在标准化上。但是OpenTelemetry不会提供观测数据存储,OpenTelemetry 定义来数据输出的规范,由各大厂商自行完成数据的持久化。

  原文:1、High-quality, ubiquitous, and portable telemetry to enable effective observability;2、OpenTelemetry is a collection of APIs, SDKs, and tools. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.3、OpenTelemetry is generally available across several languages and is suitable for use.

、OpenTelemetry的遥测类型

  <1>OpenTelemetry Trace:表示跨多个组件和服务的请求或操作的执行路径。它们提供详细的时间和上下文信息,允许开发人员了解请求流并确定性能瓶颈。

  关于Trace的组件,TracerProvider创建工厂,Tracer提供程序初始化一次,初始化还包括Resource和Exporter初始化;Tracer是Tracer(跟踪程序)用于创建span,其中包含有关给定操作(例如服务中的请求)所发生情况的更多信
息;Trace Exporters是跟踪导出器将跟踪发送给消费者。此使用者可以是调试和开发时的标准输出、OpenTelemetry收集器或您选择的任何开源或供应商后端;Context Propagation (上下文传播);spans(重要)跨度表示一个工作或操作单元。跨度是痕迹的组成部分。包括Name(名称)、Parent span ID(父级跨度ID)、Start and End Timestamps(开始与结束时间戳)、Span Context(跨度上下文)、Attributes(属性)、Span Events(事件)、Span Links(链接)、Span Status(状态)、Spand Kind(span 类型);具体内容查看官方网站。

  <2>OpenTelemetry Metrics:是对系统行为或资源利用率的定量测量。它们有助于监控和分析一段时间内的性能,并可用于警报、容量规划和趋势分析。

  关于Metrices的组件,metrics,度量是在运行时捕获的关于服务的度量;Meter Provider,是 Meters的工厂Meter Provider初始化一次,其生命周期与应用程序的生命周期相匹配。Meter Provider初始化还包括资源和导出程序初始化;Meter,Meter创建度量仪表,在运行时捕获有关服务的测量值;Metrics Exporter向消费者发送度量数据。此使用者可以是调试和开发时的标准输出、OpenTelemetry收集器或您选择的任何开源或供应商后端;Metrics Instruments,在OpenTelemetry中,测量由公制仪器捕获;Counter,一个随着时间积累的值——你可以把它想象成汽车上的里程表;它只会上升;Asynchronous Counter,与Counter相同,但每次导出都会收集一次。如果您不能访问连续增量,而只能访问聚合值,则可以使用;UpDownCounter,一种随着时间的推移而积累的值,但也可能再次下降;Asynchronous UpDownCounter,与UpDownCounter相同,但每次导出都会收集一次;(Asynchronous)Gauge;测量读取时的当前值。一个例子是车辆中的燃油表;Histogram,直方图是客户端值的集合,例如请求延迟;Aggregation,除了度量工具之外,聚合的概念也是一个需要理解的重要概念。聚合是一种技术,通过该技术,将大量测量值组合成关于在时间窗口期间发生的度量事件的精确或估计统计数据。OTLP协议传输这样的聚合度量(协议、字节、时长、大小、CPU、内存、请求处理);ViewsBaggageResources。

  <3>OpenTelemetry Logs:包含有关应用程序中发生的事件、错误和活动的结构化或非结构化文本信息。它们对于调试、审计和故障排除非常有用。

  关于logs的组件,Log Appender / Bridge,是日志库提供的用于构建日志附加程序/桥;Logger Provider,记录器提供程序(有时称为LoggerProvider)是记录器的工厂,Logger Provider初始化还包括Resource和Exporter初始化是Logs Bridge API的一部分,仅当您是日志库的作者时才应使用;Logger,Logger创建日志记录;Log Record Exporter,日志记录导出器将日志记录发送给使用者,此使用者可以是调试和开发时的标准输出、OpenTelemetry收集器或您选择的任何开源或供应商后端;Log Record,日志记录表示事件的记录,具体字段如Timestamp 事件发生的时间、ObservedTimestamp 观察到事件的时间、TraceId 请求跟踪ID、SpanId 请求跨度ID、TraceFlags W3C跟踪标志、SeverityText 严重性文本(也称为日志级别)、SeverityNumber 严重程度的数值、Body 日志记录的正文、Resource 描述日志的来源、InstrumentationScope 描述发出日志的作用域、Attributes 有关该事件的其他信息。

、OpenTelemetry的主要构件

  <1>Specification(规范):这个组件是与语言无关的,除术语定义外,定义如下规范,API规范,是一个编程接口,您可以使用它来检测代码以收集遥测数据,如跟踪、指标和日志;SDK规范是OpenTelemetry API 的官方实现,用于处理和将收集的遥测数据导出到后端;Data规范,是定义遥测后端可以支持与供应商无关语义约定的OpenTelemetry协议(OTLP)。

  <2>OpenTelemetry Protocol (OTLP、协议):这个组件是与语言无关的,这个组主要是定义了 OpenTelemetry 的 OTLP 协议定义,OTLP 协议是 OpenTelemetry 中数据传输的重要部分。如 SDK 到Collector,Collector 到 Collector,Collector 到 Backend这些过程的数据传输都是遵循了 OTLP 协议。作为传输协议,OTLP 可以使用 gRPC (OTLP/gRPC) 或 HTTP (OTLP/HTTP)。

  <3>OpenTelemetry Collector(收集器):是应用程序和后端之间的代理。它接收遥测数据,对其进行转换,然后将数据导出到可以永久存储数据的后端。Collector 还可以作为一个代理,从被监视的系统中提取遥测数据,例如,OpenTelemetry Redis 或文件系统指标。负责负责收集观测数据,处理观测数据,导出观测数据。其架构图如下所示:

  <4>Instrumentation Libraries(类库SDK):是根据 SDK 的开发规范开发的支持不同语言的 SDK,如 java,golang,c 等语言的 SDK。客户在构建观测性的时候,可以直接使用社区提供的已经开发好的 SDK 来构建观测能力。社区也在此基础上提供了一些工具,这些工具已经集成了常见软件的对接。

  <5>OpenTelemetry Backend(后端):负责持久化观测数据,Collector 本身不会去负责持久化观测数据,需要外部系统提供,在 Collector 的 exporter 部分,需要将 OTLP 的数据格式转换成 Backend 能识别的数据格式。目前很多云服务厂商都实现了 Collector 的 exporter 能力。它充当数据的中央存储库或处理管道,允许您聚合、查询、可视化并从应用程序生成的遥测数据中获得见解。

  

  总之:OpenTelemetry通过上述组件提供全面(日志、监控、链路),高扩展,统一标准。适应于所以组件的规范;定义遥测数据形状的标准协议;为常见遥测数据类型定义标准命名方案的语义约定;定义如何生成遥测数据的 API;实现规范、API 和遥测数据导出的语言SDK;实现常见库和框架的仪表化的库生态系统;可自动生成遥测数据的自动仪表化组件,无需更改代码;接收、处理和导出遥测数据的代理;各种其他工具, 如用于 Kubernetes 的 OpenTelemetry Operator、 OpenTelemetry Helm Charts 和 FaaS 的社区资产。

五、OpenTelemetry的数据流

  通过上述整个OpenTelemetry的日志、监控、链路三个类型的在应用中的数据流向到Collector数据收集器的接收处理,最后协议转换数据到各个后端的数据存储,清晰的展现了整个框架的数据流的一个示意图。

六、OpenTelemetry的概览图

  

七、总结

  通过如上的从定义、类型、构建、数据流、概览图基本对OpenTelemetry形成一个比较全面的认识,在这个了解的基础上,后续进行三种类型的具体实践来深入学习使用。通过这个整体架构图,OpenTelemetry提供一个语言无关、统一全部观测性要求、职责明确的构建,体会其中的强大。待后续具体实践,到最终在系统中构建一个完善,高可用,高性能的观测组件,服务于系统。

  历史:OpenTelemetry 是一个 CNCF 孵化级项目。这个项目是由 OpenTracing 和 OpenCensus 项目合并而诞生的
参考:https://blog.csdn.net/qq_43058348/article/details/134166293,https://blog.csdn.net/o__cc/article/details/132179649,https://opentelemetry.io/zh/
posted @   tuqunfu  阅读(155)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
点击右上角即可分享
微信分享提示