OpenTelemetry 实践指南：汗青、架构与根本概念

配景
之前陆续写过一些和 OpenTelemetry 相关的文章：

• 实战：如何优雅的从 Skywalking 切换到 OpenTelemetry
  
• 实战：如何编写一个 OpenTelemetry Extensions
  
• 从一个 JDK21+OpenTelemetry 不兼容的问题讲起
  

这些内容的条件是最好有一些 OpenTelemetry 的配景知识，看起来就不会那么枯燥，为此这篇文章就来做一个入门科普，方便一些对 OpenTelemetry 不是那么熟的朋友快速掌握一些 OpenTelemetry 的根本概念。

---

汗青发展

早在 OpenTelemetry 诞生之前可观测性这个概念就不停存在了，我记得我最早接触到这个概念是在 16 年当时的公司所使用的一个产物：pinpoint
   现如今这个项目依然比力活泼。
  

依然还记适当时通过它可以直接看到项目调用的拓扑图，在时间坐标上框出高延迟的点就能列出这些哀求，同时还能检察此时的运行日记。
这样强大的功能对于一个刚工作一年的小白来说冲击力实属太大了一点。
后来才了解到 pinpoint 属于 APM 这类产物，类似的产物尚有：

• Apache SkyWalking
  
• 美团的 CAT 等
  

他们都是可以用于性能分析和链路追踪的产物，到后来公司的运维层面也接入过 Zabbix、open-falcon 之类的产物：

17之后全面切换到 spring boot 时，也用过社区提供的 spring-boot-admin 项目：

这就是一个简单的可以监控 spring boot 应用的产物，用于展示 JVM 指标，或者本身也可以界说一些康健指标。

---

再之后进入云原生体系后可观测性的技能栈稍有变革。

日记使用 Sidecar 署理的方式通过 Agent 将数据写入 ElasticSearch 中。 具体日记采集方式可以参考之前的文章：

• 在 kubernetes 环境下如何采集日记
  

而链路追踪则是使用的 skywalking，在 trace 这个范畴 skywalking 还是非常受大家喜爱的。
不外最近也从 skywalking 切换到了我们本文所讲到的 OpenTelemetry，具体可以看之前的文章：

• 实战：如何优雅的从 Skywalking 切换到 OpenTelemetry
  

指标采集使用的是自然也是 Prometheus 的那一套技能栈，只是 Prometheus 换为了与它完全兼容的 VictoriaMetric 目前是为了更省资源。
客户端使用则是直接使用 Prometheus 的库举行指标袒露：

1. <dependency>
2. ????<groupId>io.prometheus</groupId>
3. ????<artifactId>prometheus-metrics-core</artifactId>
4. ????<version>1.0.0</version>
5. </dependency>
6. <dependency>
7. ????<groupId>io.prometheus</groupId>
8. ????<artifactId>prometheus-metrics-instrumentation-jvm</artifactId>
9. ????<version>1.0.0</version>
10. </dependency>
11. <dependency>
12. ????<groupId>io.prometheus</groupId>
13. ????<artifactId>prometheus-metrics-exporter-httpserver</artifactId>
14. ????<version>1.0.0</version>
15. </dependency>

复制代码

终极通过配置抓取计谋，由 VictoriaMetrics 的 scrape 步伐来抓取指标终极写入到它本身的存储中：

1. apiVersion:?operator.victoriametrics.com/v1beta1??
2. kind:?VMPodScrape??
3. metadata:??
4. ??name:?kubernetes-pod-scrape??
5. ??namespace:?monitoring??
6. spec:??
7. ??podMetricsEndpoints:??
8. ????-?scheme:?http??
9. ??????scrape_interval:?"30s"??
10. ??????path:?/metrics??
11. ??????relabelConfigs:??
12. ????????-?source_labels:?[__meta_kubernetes_pod_annotation_prometheus_io_scrape]??
13. ??????????separator:?;??
14. ??????????regex:?"true"??
15. ??????????replacement:?$1??
16. ??????????action:?keep??
17. ????????#?端口相同??
18. ????????-?action:?keep_if_equal??
19. ??????????source_labels:?[?__meta_kubernetes_pod_annotation_prometheus_io_port,?__meta_kubernetes_pod_container_port_number?]??
20. ????????#?过滤INIT容器??
21. ????????-?action:?drop??
22. ??????????source_labels:?[?__meta_kubernetes_pod_container_init?]??
23. ??????????regex:?"true"??
24. ????????-?source_labels:?[__meta_kubernetes_pod_annotation_prometheus_io_path]??
25. ??????????separator:?;??
26. ??????????regex:?(.+)??
27. ??????????target_label:?__metrics_path__??
28. ??????????replacement:?$1??
29. ??????????action:?replace??
30. ????????-?source_labels:?[__address__,?__meta_kubernetes_pod_annotation_prometheus_io_port]??
31. ??????????separator:?;??
32. ??????????regex:?([^:]+)(?::d+)?;(d+)??
33. ??????????target_label:?__address__??
34. ??????????replacement:?$1:$2??
35. ??????????action:?replace??
36. ????????-?separator:?;??
37. ??????????regex:?__meta_kubernetes_pod_label_(.+)??
38. ??????????replacement:?$1??
39. ??????????action:?labelmap??
40. ????????-?source_labels:?[__meta_kubernetes_namespace]??
41. ??????????separator:?;??
42. ??????????regex:?(.*)??
43. ??????????target_label:?kubernetes_namespace??
44. ??????????replacement:?$1??
45. ??????????action:?replace??
46. ????????-?source_labels:?[__meta_kubernetes_pod_name]??
47. ??????????separator:?;??
48. ??????????regex:?(.*)??
49. ??????????target_label:?kubernetes_pod_name??
50. ??????????replacement:?$1??
51. ??????????action:?replace??
52. ??????vm_scrape_params:??
53. ????????stream_parse:?true??
54. ??namespaceSelector:??
55. ????any:?true

复制代码

  以上是 VM 提供的 CRD
  OpenTelemetry 诞生

到此铺垫完成，不知道有没有发现在可观测性中关键的三个部分：日记、指标、trace 都是使用不同的开源产物，从而会导致技能栈较多，维护起来自然也是比力麻烦的。
这么一个软件范畴的焦点能力自然必要提供一个完整方案的，将以上的不同技能栈都整合在一起，更加的方便开发者使用。
在这之前也有两个社区想要做类似的事情：

• OpenTracing
  
• OpenCensus
  

不外他们并没有统一整个可观测范畴，直到 2019 年 CNCF 社区宣布创建 OpenTelemetry，并且将上述两个社区举行合并共同开发 OpenTelemetry。
   背靠 CNCF 云原生社区加上许多着名厂商的支持（Google、Amazon、Redhat 等），现在已经正式成为 CNCF 的顶级项目了。
  OpenTelemetry 架构介绍

但我们打开 OpenTelemetry 社区的 GitHub 首页时，会看到有许多项目；第一反应应该是比力蒙的，下面我会着重介绍一些比力重要的项目。
在开始之前还是先简单介绍下 OpenTelemetry 的一些基础组件和概念：

整个 OpenTelemetry 系统其实可以简单分为三个部分：

• 客户端
  
• OTel collector
  
• 数据存储
  

第一个客户端很好明白，也就是我们的业务应用；如果是 Java 应用只必要挂载一个 agent 就可以主动采集系统的指标、链路信息、日记等上传到 Collector 中。
也就是上图的左边部分。
之后就是非常关键的组件 collector，它可以通过 OTLP 协议接收刚才提到的客户端上传的数据，然后再内部举行处理，终极输出到后续的存储系统中。
Collector

   上图是 collector 的架构图
  由于 OpenTelemetry 计划之初就是要做到厂商无关，所以它就得做出更高层级的计划。
关键点就是这里的 Receiver 和 Exporter 都是模块化的计划，第三方开发者可以基于它的标准开发不同组件从而兼容不同的产物。
Receiver：用于接收客户端上报的数据，不止是本身 agent 上报的数据，也可能会来自不同的厂商，比如 kubernetes、Kafka 等。
Exporter：同理，可以将 receiver 收到的数据举行处理之后输出到不同的组件中；比如 Kafka/Pulsar/Promethus/Jaeger 等。
比如我们可以使用 Nginx Receiver接收来着 Nginx 上报的数据。
使用 MySQL Receiver接收来自 MySQL 的数据。
当然通常我们使用最多的还是 OTLP Receiver，这是官方的 OTLP 协议的接收器，可以接受官方的一些指标，比如我们只使用了 Java Agent 举行数据上报时。

https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver
在这里是可以看到目前支持的全部第三方的 Receiver。

---

OpenTelemetry 所支持的 Exporter 也许多，比如一些常见的存储：

• clickhouse exporter
  
• elasticsearch exporter
  
• pulsar exporter
  
• prometheus exporter
  
• otlp http exporter
  

Exporter 的使用场景许多：如果是指标相关的数据可以直接写入 Prometheus，如果是日记数据也可以直接写入 ElasticSearch。
如果尚有其他的特殊需求（删减属性等）则可以写入消息队列，自行处理完之后再发往 collector 举行后续的处理。
可能你已经发现了，由于 collector 非常的灵活，所以我们可以像搭积木一样组装我们的 receiver 和 exporter，它会以我们配置的流水线的方式举行调用，这样我们就可以实现恣意可定制的处理逻辑。
而这些流水线的组装对于客户端来说都是透明的，也就是说 collector 的更改完全不会影响到业务；业务只必要按照 OTLP 的格式上报数据即可。
在之前的从 Skywalking 切换到 OpenTelemetry 的文章中有人问为什么要切换到 OpenTelemetry？
从这里也能看得出来，OpenTelemetry 的灵活度非常高，借助于 Exporter 可以恣意的更换后端存储，或者增加/删减一些不必要的指标数据等。

---

当然我们也可以统一的在这里举行搜索，可以列出全部的第三方集成的组件： https://opentelemetry.io/ecosystem/registry/

OpenTelemetry 项目介绍

opentelemetry-java

介绍完根本的概念后，我们可以看看 OTel 社区的一些主要开源项目。

这里我们还是以刚才的那个架构图从作往右讲起，也就是主要分为客户端和 collector 端。

目前官方支持的客户端语言已经非常齐备了，大部分的版本都已经是 Stable 稳定版，意味着可以进入生产环境。
这里我们以 Java 客户端为例：

此中我们重点关注下 opentelemetry-java 和 opentelemetry-java-instrumentation 这两个项目。
我们用的最多的会是 opentelemetry-java-instrumentation，它会给我们提供一个 java agent 的 JAR 包：

1. java?-javaagent:path/to/opentelemetry-javaagent.jar?

复制代码

???-jar?myapp.jar
我们只必要在 Java 应用中加上该 agent 就可以实现日记、指标、trace 的主动上报。
而且它还实现了不同框架、库的指标采集与 trace。
在这里可以查到支持的库与框架列表：

https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries–frameworks
   总之几乎就是你能想到和不能想到的都支持了。
  而 opentelemetry-java 我们直接使用的几率会小一些，opentelemetry-java-instrumentation 本身也是基于它创建的，可以明白为是 Java 版本的焦点基础库，一些社区支持的组件就可以移动到 instrumentation 这个库中。
比如我在上篇文章：从一个 JDK21+OpenTelemetry 不兼容的问题讲起中涉及到的 HostResourceProvider 资源加载就是从 opentelemetry-java 中移动到了 opentelemetry-java-instrumentation。
具体可以参考：https://github.com/open-telemetry/opentelemetry-java/issues/4701
collector

之后就是 collector 的组件了，它同样的也有两个库：OpenTelemetry Collector 和 OpenTelemetry Collector Contrib
其实通过他们的名字也可以看得出来，他们的作用与刚才的 Java 库类似：

• opentelemetry-collector：由官方社区维护，提供了一些焦点能力；比如只包含了最根本的 otlp 的 receiver 和 exporter。
  
• opentelemetry-collector-contrib：包含了官方的 collector，同时更多的维护了社区提供的各种 receiver 和 exporter；就如上文提到的，一些社区组件（pulsar、MySQL、Kafka）等都维护在这个堆栈。
  

而我们生产使用时通常也是直接使用 opentelemetry-collector-contrib，究竟它所支持的社区组件更多。
总结

因为 OpenTelemetry 想要解决的是整个可观测范畴的全部需求，所以堆栈非常多，社区也很开放，感兴趣的朋友可以直接参与贡献，这么多 repo 总有一个得当你的。
后续会继续讲解如何安装以及配置我们的 OpenTelemetry。
参考链接：

• https://github.com/pinpoint-apm/pinpoint
  
• https://github.com/codecentric/spring-boot-admin
  
• https://github.com/open-telemetry/opentelemetry-java
  
• https://github.com/open-telemetry/opentelemetry-java-instrumentation
  
• https://github.com/open-telemetry/opentelemetry-java/issues/4701
  

往期推荐
OpenTelemetry agent 对 Spring Boot 应用的影响：一次 SPI 失效的调查
主动化测试在 Kubernetes Operator 开发中的应用：以 OpenTelemetry
深入剖析：如何使用Pulsar和Arthas高效排查消息队列延迟问题
日记架构演进：从集中式到分布式的Kubernetes日记计谋
实战：如何编写一个 OpenTelemetry Extensions

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。