【APM】在Kubernetes中搭建OpenTelemetry+Loki+Tempo+Grafana链路追踪（一）-EW帮帮网

文章目录

1、最终效果
2、前提准备
2、环境信息
3、服务集成（Opentelemetry ->Tempo）
- 3.1 上报链路数据

1、最终效果

Loki与Tempo关联后，在Loki收集的日志，可以查看tempo的链路
在这里插入图片描述

2、前提准备

1、已安装Kubernetes
2、安装Grafana （安装文档）
3、安装Promtail （安装文档）
4、安装Loki （安装文档）
5、安装Tempo （安装文档）
6、安装OpenTelemetry （安装文档）

2、环境信息

服务	版本	安装方式	Github
Kubernetes	1.25	我这里使用的是华为云CCE（暂时不推荐使用）	-
OpenTelemetry	0.97.0	Helm安装	https://github.com/open-telemetry
Loki	2.9.6	Helm安装	https://github.com/grafana/loki
Tempo	2.4.1	Helm安装	https://github.com/grafana/tempo
Grafana	9.5.1	Helm安装	https://github.com/grafana/grafana

3、服务集成（Opentelemetry ->Tempo）

在这里插入图片描述
如图所示，绿色和蓝色这里就不说了，网上教程很多，大家自行完成

主要来说下橘色部分之前，我们来说下为什么要使用Opentelemetry，而不是直接让app->tempo。这样的设计有几个关键原因：
标准化: OpenTelemetry 是一个开放标准的可观测性框架，它提供了一套统一的API和SDK，用于收集 Metrics、Traces 和 Logs。这意味着开发者只需要学习一套接口，就可以在不同的服务和语言中实现一致的可观测性实践。这样，服务无需直接适配每个跟踪后端（如 Tempo），提高了代码的可移植性和维护性。

解耦: 通过 OpenTelemetry，服务与追踪后端（如 Tempo）之间的耦合度大大降低。服务只需生成追踪数据，而不需要知道数据最终如何被收集、处理或存储。这使得追踪系统的升级或替换变得更加容易，比如从一个追踪后端切换到另一个，而无需改动服务代码。

灵活性和扩展性: OpenTelemetry 支持多种出口（exporters），可以轻松地将数据发送到不同的后端，如 Tempo、Jaeger、Prometheus 等。这为用户提供了一个灵活的架构，可以根据需要选择最适合自己的追踪解决方案，或者根据环境（如开发、测试、生产）的不同配置不同的后端。

丰富的生态支持: OpenTelemetry 社区活跃，提供了多种语言的实现和支持，几乎涵盖了所有主流的编程语言。这意味着不论你的服务是用什么语言编写的，都能找到相应的 OpenTelemetry SDK 或者自动化的集成工具。

高级功能: OpenTelemetry SDK 提供了丰富的特性，如自动追踪上下文传播、手动追踪跨度的创建与关联、标签和事件的添加等，使得追踪数据更加丰富和有用。此外，它还支持动态采样策略，可以在不影响性能的前提下，智能地调整追踪数据的收集量。

所以通过 OpenTelemetry 作为中介，可以让服务的开发和维护更加集中于业务逻辑本身，同时享受标准化、灵活性和扩展性的优势，而不必关心具体的追踪数据处理细节

3.1 上报链路数据

3.1.1 下载opentelemetry-agent

这里已java为例
下载地址：https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases

通过修改Java启动的VM参数上报链路数据。

-javaagent:/path/to/opentelemetry-javaagent.jar //修改为文件下载的实际路径。
-Dotel.resource.attributes=service.name=appName //appName 为应用名。
-Dotel.exporter.otlp.endpoint=endpoint //opentelemetry 服务端地址。
-Dotel.metrics.exporter=none

3.1.2 启动配置业务app

配置env

目前OpenTelemetry指标仅支持通过HTTP上报，暂不支持使用gRPC

JAVA_TOOL_OPTIONS = -javaagent:/tmp/aps-tools/opentelemetry-javaagent.jar -Dotel.resource.attributes=service.name=dev-dysk  -Dotel.exporter.otlp.endpoint=http://otel-opentelemetry-collector.otel.svc.cluster.local:4318  -Dotel.metrics.exporter=none

JAVA_TOOL_OPTIONS 是一个环境变量，它允许你在不直接修改启动 Java 应用程序的命令行参数的情况下，向 Java 虚拟机 (JVM) 传递额外的配置选项。这对于那些不能直接控制 JVM 启动参数的应用特别有用，比如通过 JNI (Java Native Interface) 调用 JVM 的应用、脚本中嵌入的 JVM 应用，或者一些服务管理工具自动启动的服务。

联系开发修改服务日志字段，新增trance_id

启动会发现日志中并没有trace_id字段，这是因为并没有做日志字段对应，属于正常情况。虽不会影响opentelemetry输入输出，但是会影响接下来的loki和tempo集成，他们需要trace_id字段做为相同数据媒介来快速查询。

在这里插入图片描述

3.1.3 配置opentelemetry输入输出

#声明使用的输出
exporters:
  debug: {}
  logging:
  otlp:
    endpoint: "tempo-distributor-discovery.trace.svc.cluster.local:4317" #修改为tempo地址
    tls:
      insecure: true
extensions:
  health_check:
    endpoint: 0.0.0.0:13133
processors:
  batch: {}
  memory_limiter:
    check_interval: 5s
    limit_percentage: 80
    spike_limit_percentage: 25
#声明使用的输入
receivers:
  jaeger:
    protocols:
      grpc:
        endpoint: 0.0.0.0:14250
      thrift_compact:
        endpoint: 0.0.0.0:6831
      thrift_http:
        endpoint: 0.0.0.0:14268
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  prometheus:
    config:
      scrape_configs:
      - job_name: opentelemetry-collector
        scrape_interval: 10s
        static_configs:
        - targets:
          - 0.0.0.0:8888
  zipkin:
    endpoint: 0.0.0.0:9411
#真正要使用的输入输出
service:
  extensions:
  - health_check
  pipelines:
    logs:
      exporters:
      - debug
      - logging
      processors:
      - memory_limiter
      - batch
      receivers:
      - otlp
    metrics:
      exporters:
      - debug
      processors:
      - memory_limiter
      - batch
      receivers:
      - otlp
      - prometheus
    traces:
      exporters:
      - debug
      - otlp
      processors:
      - memory_limiter
      - batch
      receivers:
      - otlp
      - jaeger
      - zipkin
  telemetry:
    metrics:
      address: 0.0.0.0:8888