文章目錄
- 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數據源，可以查詢到鏈路信息了
