OpenTelemetry 有很多种组合和实现方案,我们分别来了解一下 OpenTelemetry 在三种不同技术架构下的使用方式。
作为经典的对各种遥测数据的处理架构,开源工具可将不同类型的数据存储在不同的平台,比如日志存放在 ELK,追踪存放在 Jaeger 这类的 APM 工具,而指标保存在 Prometheus 并通过 Grafana 进行视图展示。组件的整体配置如下图所示:
我们以一个 SpringBoot 应用为例,解读一下数据采集和传输的过程:
日志有下面两种收集方式。
方式一,通过 OTLP 上报日志:应用服务端和客户端将日志通过 Exporter 推送到 Collector,再通过 Collector 输出到 Elasticsearch。 但由于 OpenTelemetry 在 log 方面还不稳定,所以推荐单独处理日志,不走 Collector。
方式二,通过 Logback 上报日志:应用服务端和客户端将日志通过 Logback 推送到 Logstash(需要使用 Logstash-Logback 组件,是 Logstash 的 Logback 实现)。这是一种更加推荐的方式。
随着这两年可观测的流行,Grafana 也开始进军可观测行业。使用 Grafana 对接 OpenTelemetry 的架构如下图所示,这里面主要用到 Grafana Tempo 和 Loki 两个组件。
执行流程主要包括以下 4 步。
“ Grafana Tempo + Loki” 这个组合能够让我们直观地看到日志链路情况,但 Loki 的特性也决定了它并不能高效分析和处理大型生产系统的日志。日志链路只是可观测的一部分,仅仅通过日志链路查询并不能解决大部分问题,特别是在微服务云原生架构时代,多种多样的问题需要我们结合各方面进行分析。
观测云允许包括开发、测试、运维在内的所有团队成员在一套统一的可观测数据体系下客观分析与定位故障,便于高效地协作。观测云能够采集指标、链路、日志以及所有的可观测数据,并将它们进行关联和整合分析,实现系统完整的可观测性。
观测云的数据采集 Agent 是 DataKit ,它能够支持主机和容器的环境。
由于 DataKit 是接收 OTLP 协议的,所以我们可以把 OpenTelemetry Collector 的 Exporter 设置为 OTLP(指向 DataKit),也可以直接将数据打给 DataKit。因此这里有两种方案。
方案一:
方案二:
此文章为3月Day7 学习笔记,内容来源于极客时间《深入浅出可观测性》,推荐该课程。