文章目录
- 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: 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
重新启动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
数据源,可以查询到链路信息了