文章目录
- 1、最终效果
- 2、前提准备
- 2、环境信息
- 3、服务集成（Opentelemetry ->Tempo）
- 3.1 上报链路数据
- 3.1.1 下载opentelemetry-agent
- 3.1.2 启动配置业务app
- 3.1.3 配置opentelemetry输入输出
- 3.1.4 配置grafana datasource
- 3.1.4.1 配置tempo
- 3.1.4.2 配置loki
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
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: 5slimit_percentage: 80spike_limit_percentage: 25
#声明使用的输入
receivers:jaeger:protocols:grpc:endpoint: 0.0.0.0:14250thrift_compact:endpoint: 0.0.0.0:6831thrift_http:endpoint: 0.0.0.0:14268otlp:protocols:grpc:endpoint: 0.0.0.0:4317http:endpoint: 0.0.0.0:4318prometheus:config:scrape_configs:- job_name: opentelemetry-collectorscrape_interval: 10sstatic_configs:- targets:- 0.0.0.0:8888zipkin:endpoint: 0.0.0.0:9411
#真正要使用的输入输出
service:extensions:- health_checkpipelines:logs:exporters:- debug- loggingprocessors:- memory_limiter- batchreceivers:- otlpmetrics:exporters:- debugprocessors:- memory_limiter- batchreceivers:- otlp- prometheustraces:exporters:- debug- otlpprocessors:- memory_limiter- batchreceivers:- otlp- jaeger- zipkintelemetry:metrics:address: 0.0.0.0:8888
重新启动opentelemetry
3.1.4 配置grafana datasource
3.1.4.1 配置tempo
URL：http://tempo-gateway.trace.svc
3.1.4.2 配置loki
URL：http://loki-distributed-gateway.logs.svc.cluster.local
Name：trace_id
Regex：trace_id=(\w+)
Query（先打开下面的Internal link）：${__value.raw}
最后，我们在grafana的explore中选择Tempo数据源，可以查询到链路信息了
