?️URL: https://grafana.com/blog/2020/11/17/tracing-with-the-grafana-cloud-agent-and-grafana-tempo/
✍Author: Robert Fratto • 17 Nov 2020
?Description:
Here's your starter guide to configuring the Grafana Agent to collect traces and ship them to Tempo, our new distributed tracing system.
編者注：程式碼片段已於 2021-06-23 更新。
早在 3 月份，我們 介紹 了 Grafana Agent，這是 Prometheus 的一個子集，為託管指標而建。它使用了很多與 Prometheus 相同的經過實戰檢驗的程式碼，可以節省 40%的記憶體使用。
自推出以來，我們一直在為 Agent 新增功能。現在，新增功能有：叢集機制，額外的 Prometheus exporters，以及對 Loki 的支援。
我們的最新功能。Grafana Tempo! 這是一個易於操作、規模大、成本低的分散式追蹤系統。
在這篇文章中，我們將探討如何配置 Agent 來收集跟蹤，並將其傳送到 Tempo。
配置 Tempo 支援
在你現有的 Agent 配置檔案中新增 trace 支援很簡單。你所需要做的就是新增一個tempo 塊。熟悉 OpenTelemetry Collector 的人可能會認出以下程式碼塊中的一些設定。
# other Agent settings
tempo:
configs:
- name: default
receivers:
jaeger:
protocols:
thrift_compact:
attributes:
actions:
- action: upsert
key: env
value: prod
remote_write:
- endpoint: tempo-us-central1.grafana.net:443
basic_auth:
username: 12345
# Replace <Grafana API Key> below with an API key that
# has the "Metrics Publisher" role
password: <Grafana API Key>
接收器允許 Grafana Agent 接受來自眾多系統的追蹤資料。我們目前支援從 Jaeger、Kafka、OpenCensus、OTLP 和 Zipkin 接收跨度。
雖然 OpenTelemetry Collector 允許你配置指標和日誌接收器，但我們目前只公開了與追蹤有關的接收器。我們相信 Agent 內現有的 Prometheus 和 Loki 支援將滿足其他支柱觀察能力的需要。
如果你願意，你可以將代理配置為接受每一個接收器的資料。
tempo:
# 鍵，配置啟用一個接收器或其協議。
# 把它設定為空值可以啟用該接收器或協議的預設配置。
receivers:
# 支援 grpc14250 埠的 spans，
# 6832 埠的 thrift_binary，
# 6831 埠的 thrift_compact，
# 以及 14268 埠的 thrift_http。
# 具體的埠號可以 特定的埠號可以在協議的配置中自定義。
jaeger:
protocols:
grpc:
thrift_binary:
thrift_compact:
thrift_http:
# 配置 opencensus 支援。span 可以透過埠 55678 傳送，
# 這是預設的。
opencensus:
# 配置 otlp 支援。Spans 可以被髮送到 55680 埠，
# 這是預設的。
otlp:
protocols:
grpc:
http:
# 配置 zipkin 支援。Spans 可以被髮送到 9411 埠，
# 這是預設的。
zipkin:
另一方面，屬性使操作者能夠操作傳送到 Grafana Agent 的傳入 span 上的標籤。當你想新增一組固定的後設資料時，這真的很有用，比如備註一個環境。
attributes:
actions:
- action: upsert
key: env
value: prod
上面的配置例子為所有收到的 span 設定了一個 env標籤，其值為prod。upsert動作意味著具有現有 env標籤的span將被覆蓋。這對於保證你知道哪個 Agent 收到了 span 以及它在哪個環境下執行是很有用的。
屬性 (Attributes ) 真的很強大，並且支援超出這裡的例子的使用情況。請檢視 OpenTelemetry 關於它們的文件 以瞭解更多資訊。
但在 Grafana Labs，我們並沒有僅僅使用 OpenTelemetry Collector 的一個子集就了事；我們增加了對 Prometheus 風格的scrape_configs的支援，可以用來根據發現目標的後設資料自動標記傳入的 span。
用 Prometheus 服務發現附加後設資料
Promtail 是一個日誌客戶端，用於收集日誌並將其傳送到 Loki。它最強大的功能之一是支援使用 Prometheus 的服務發現機制。這些服務發現機制使你能夠將相同的後設資料附加到你的日誌和你的指標上。
當你的指標和日誌有相同的後設資料時，你就可以降低在系統之間切換的認知開銷，並且讓有一種你的所有資料都儲存在一個系統中的 "感覺"。我們希望這種能力也能擴充套件到追蹤方面。
Joe Elliott 在 Agent 的追蹤子系統中增加了相同的 Prometheus 服務發現機制。它的工作原理是將傳送 span 的系統的 IP 地址與發現的服務發現目標的地址相匹配。
對於 Kubernetes 使用者來說，這意味著你可以動態地附加傳送 span 的容器的名稱空間、pod 和 container 名稱的後設資料。
tempo:
configs:
- name: default
receivers:
jaeger:
protocols:
thrift_compact:
scrape_configs:
- bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
job_name: kubernetes-pods
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_namespace]
target_label: namespace
- source_labels: [__meta_kubernetes_pod_name]
target_label: pod
- source_labels: [__meta_kubernetes_pod_container_name]
target_label: container
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
insecure_skip_verify: false
# remote_write, etc
不過，這個功能不僅僅對 Kubernetes 使用者有用。這裡支援 Prometheus 的所有 各種服務發現機制。這意味著你可以在你的度量、日誌和追蹤之間使用相同的scrape_configs來獲得相同的標籤集，當從你的度量、日誌和追蹤中切換時，可以輕鬆地在你的可觀察性資料之間轉換。
配置 Span 的推送方式
當然，僅僅收集 span 並不十分有用！配置 Tempo 支援的最後部分是透過remote_write部分。remote_write描述了一個類似於 Prometheus 的配置塊，用來控制收集的 span 被髮送到哪裡。
對於好奇的人來說，這是對 OpenTelemetry Collector 的 OTLP exporter 的一個封裝。由於 Agent 匯出 OTLP 格式的 span，這意味著你可以將 span 傳送到任何支援 OTLP 資料的系統。我們今天的重點是 Tempo，但你甚至可以讓 Agent 傳送跨度到另一個 OpenTelemetry 採集器。
除了端點和認證，remote_write允許你控制 span 的排隊和重試功能。批處理 (Batching)是在remote_write之外管理的，可以更好地壓縮 span，減少用於向 Tempo 傳輸資料的出站連線數。和前面一樣，OpenTelemetry 在這方面有一些 相當好的文件。
tempo:
configs:
- name: default
# span 的批處理設定。在收集 10,000 個跨度後
# 或 10s 後（以先到者為準）完成一個批次。
batch:
send_batch_size: 10000
timeout: 10s
# remote_write, etc
在 remote_write方面，queues和retries允許你配置在記憶體中保留多少個批次，以及如果一個批次碰巧失敗了，你將重試多長時間。這些設定與 OpenTelemetry's OTLP exporter 的retry_on_failure和sending_queue設定相同。
tempo:
configs:
- name: default
remote_write:
- endpoint: tempo-us-central1.grafana.net:443
basic_auth:
username: 12345
password: api_key
# 將預設的佇列大小增加一倍，以便在記憶體中保留更多的批次，
# 但在 5 秒後放棄重試失敗的 span。
sending_queue:
queue_size: 10000
retry_on_failure:
max_elapsed_time: 5s
雖然把最大重試時間設定得很高很誘人，但它很快就會變得很危險。重試會增加從 Agent 到 Tempo 的網路流量總量，與其不斷重試，不如放棄 span 。另一個風險是記憶體的使用。如果你的後端發生故障，高重試時間將迅速填滿 span 佇列，並可能以 Out Of Memory 錯誤使 Agent 當機。
因為對於一個有大量 span 吞吐量的系統來說，100%的 span 被儲存是不現實的，控制批處理、佇列和重試邏輯以滿足你的特定網路使用，對於有效追蹤是至關重要的。
下回見
我們已經談到了如何手動配置 Grafana Agent 以獲得 tracing 支援，但要想了解一個實際的例子，請檢視 production-ready tracing Kubernetes manifest。這個清單附帶的配置涉及到這裡的所有內容，包括服務發現機制，以自動將 Kubernetes 後設資料附加到傳入的 span 上。
我非常感謝 Joe 從他繁忙的 Tempo 工作中抽出時間，在 Agent 中新增跟蹤支援。我很高興 Grafana Agent 現在支援大部分的 Grafana 堆疊，而且我對接下來的產品更感興趣
原文內建：
開始使用 Tempo 的最簡單方法是在 Grafana Cloud。我們有免費的（包括 50GB 的痕跡）和付費的 Grafana Cloud 計劃，以滿足各種使用情況 - 現在註冊免費。
詞彙表
| 英文 | 中文 | 備註 |
|---|---|---|
| Receivers | 接收器 | Grafana Agent 元件 |
| Trace | 追蹤 | |
| span | 跨度 | Tracing 專有名詞 |
Grafana 系列文章
三人行, 必有我師; 知識共享, 天下為公. 本文由東風微鳴技術部落格 EWhisper.cn 編寫.