Jaeger 元件實作各種 API，以儲存或擷取追蹤資料。

下列標籤用於描述 API 相容性保證。

• 穩定 - API 保證回溯相容性。如果未來進行破壞性變更，將會產生新的 API 版本，例如 /api/v2 URL 首碼或 IDL 中的不同命名空間。
• 內部 - API 旨在 Jaeger 元件之間的內部通訊，不建議外部元件使用。
• 已棄用 - 僅因舊版原因而維護的 API，未來將會逐步淘汰。

自 Jaeger v1.32 起，提供 gRPC 端點的 jaeger-collector 和 jaeger-query 服務埠會啟用 gRPC 反射  。 不幸的是，內部使用的 gogo/protobuf 與官方的 golang/protobuf 有相容性問題  ，因此目前只有 list 反射命令運作正常。

跨度報告 API

jaeger-agent 和 jaeger-collector 是 Jaeger 後端的兩個元件，可以接收跨度。目前，它們支援兩組不重疊的 API。

OpenTelemetry 通訊協定 (穩定)

自 v1.35 起，Jaeger 後端可以接收來自 OpenTelemetry SDK 的原生 OpenTelemetry 通訊協定 (OTLP)  追蹤資料。不再需要使用 Jaeger 匯出工具設定 OpenTelemetry SDK，也不需要在 OpenTelemetry SDK 和 Jaeger 後端之間部署 OpenTelemetry Collector。

OTLP 資料可以接受下列格式：(1) 二進位 gRPC，(2) HTTP 上的 Protobuf，(3) HTTP 上的 JSON。如需 OTLP 接收器的詳細資訊，請參閱官方文件 。請注意，並非所有組態選項都受 jaeger-collector 支援 (請參閱 --collector.otlp.* CLI 標誌)，而且只接受追蹤資料，因為 Jaeger 不會儲存其他遙測類型。

UDP 上的 Thrift (穩定)

jaeger-agent 只能接收 Thrift 格式的 UDP 跨度。主要 API 是 UDP 封包，其中包含在 jaeger.thrift  IDL 檔案中定義的 Thrift 編碼 Batch 結構，位於 jaeger-idl  儲存庫中。大多數 Jaeger 用戶端使用 Thrift 的 compact 編碼，但某些用戶端程式庫不支援此編碼 (尤其是 Node.js)，並使用 Thrift 的 binary 編碼 (傳送到不同的 UDP 連接埠)。jaeger-agent 的 API 由 agent.thrift  IDL 檔案定義。

由於舊版原因，jaeger-agent 也接受 Zipkin 格式的 UDP 跨度，但是只有非常舊版的 Jaeger 用戶端才能以該格式傳送資料，且已正式棄用。

透過 gRPC 的 Protobuf (穩定)

在典型的 Jaeger 部署中，jaeger-agent 會從用戶端接收 span，並將它們轉發到 jaeger-collector。自 Jaeger v1.11 起，jaeger-agent 和 jaeger-collector 之間官方且推薦的協定是 jaeger.api_v2.CollectorService gRPC 端點，定義於 collector.proto  IDL 檔案中。相同的端點可以用於將追蹤資料直接從 SDK 提交到 jaeger-collector。

透過 HTTP 的 Thrift (穩定)

在某些情況下，將 jaeger-agent 部署在應用程式旁邊是不可行的，例如，當應用程式程式碼以無伺服器函式執行時。在這些情況下，可以將 SDK 設定為透過 HTTP/HTTPS 直接將 span 提交到 jaeger-collector。

相同的 jaeger.thrift  payload 可以透過 HTTP POST 請求提交到 /api/traces 端點，例如 https://jaeger-collector:14268/api/traces。 Batch 結構需要使用 Thrift 的 binary 編碼進行編碼，並且 HTTP 請求應指定內容類型標頭

Content-Type: application/vnd.apache.thrift.binary

透過 HTTP 的 JSON (不適用)

沒有官方的 Jaeger JSON 格式可以被 jaeger-collector 接受。Jaeger 確實透過 JSON 接受 OpenTelemetry 協定 (請參閱上方)。

Zipkin 格式 (穩定)

jaeger-collector 也可以接受幾種 Zipkin 資料格式的 span，即 JSON v1/v2 和 Thrift。 需要設定 jaeger-collector 以啟用 Zipkin HTTP 伺服器，例如在 Zipkin 收集器使用的 9411 埠上。 伺服器啟用兩個預期 POST 請求的端點

• /api/v1/spans 用於提交 Zipkin JSON v1 或 Zipkin Thrift 格式的 span。
• /api/v2/spans 用於提交 Zipkin JSON v2 中的 span。

追蹤檢索 API

儲存中保存的追蹤可以透過呼叫 jaeger-query 服務來檢索。

gRPC/Protobuf (穩定)

程式化檢索追蹤和其他資料的推薦方式是透過 jaeger.api_v2.QueryService gRPC 端點，該端點定義於 query.proto  IDL 檔案中。在預設設定中，此端點可從 jaeger-query:16685 存取。

HTTP JSON (內部)

Jaeger UI 透過 JSON API 與 jaeger-query 服務通訊。例如，可以透過向 https://jaeger-query:16686/api/traces/{trace-id-hex-string} 發出 GET 請求來檢索追蹤。此 JSON API 是故意不公開的，並且可能會變更。

遠端儲存 API (穩定)

當使用 grpc 儲存類型（又名遠端儲存）時，只要這些後端實作了 gRPC 遠端儲存 API  ，Jaeger 元件可以使用自訂儲存後端。

遠端取樣設定 (穩定)

此 API 支援 Jaeger 的 遠端取樣協定，該協定定義於 sampling.proto  IDL 檔案中。

jaeger-agent 和 jaeger-collector 都實作了 API。 有關如何使用取樣策略配置 Collector 的詳細資訊，請參閱遠端取樣。 jaeger-agent 僅作為 jaeger-collector 的代理。

下表列出了可用於查詢取樣策略的不同端點和格式。 官方的 HTTP/JSON 端點使用標準的 Protobuf 到 JSON 對應  。

範例

在一個終端機中執行 all-in-one

$ go run ./cmd/all-in-one \
  --sampling.strategies-file=cmd/all-in-one/sampling_strategies.json

在另一個終端機中查詢不同的端點

# Collector
$ curl "https://127.0.0.1:14268/api/sampling?service=foo"
{"strategyType":"PROBABILISTIC","probabilisticSampling":{"samplingRate":1}}

# Agent
$ curl "https://127.0.0.1:5778/sampling?service=foo"
{"strategyType":"PROBABILISTIC","probabilisticSampling":{"samplingRate":1}}

# Agent, legacy endpoint / (not recommended)
$ curl "https://127.0.0.1:5778/?service=foo"
{"strategyType":0,"probabilisticSampling":{"samplingRate":1}}

服務相依性圖 (內部)

可以從 jaeger-query 服務的 /api/dependencies 端點檢索。GET 請求需要兩個參數

• endTs (自 epoch 以來的毫秒數) - 時間間隔的結束
• lookback (以毫秒為單位) - 時間間隔的長度 (即開始時間 + lookback = 結束時間)。

返回的 JSON 是一個邊緣清單，表示為元組 (caller, callee, count)。

為了以程式化方式存取服務圖，建議使用的 API 是上面描述的 gRPC/Protobuf。

服務效能監控 (內部)

請參閱SPM 文件