部署的完整路徑)
如何用Jaeger 5步跑通分布式追蹤從零到生產(chǎn)部署的完整路徑【免費(fèi)下載鏈接】jaegerCNCF Jaeger, a Distributed Tracing Platform項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ja/jaeger用戶在群里投訴下單變慢了你翻了三小時(shí)各服務(wù)日志只看到一堆上游超時(shí)的半句話。直到你在 Jaeger——CNCF 畢業(yè)的分布式追蹤平臺(tái)——里打開那條跨了 7 個(gè)服務(wù)的調(diào)用鏈9 秒的總耗時(shí)里有 8.2 秒卡在一句沒走索引的 SQL 上。這就是鏈路追蹤和日志的本質(zhì)區(qū)別日志告訴你誰報(bào)了錯(cuò)追蹤告訴你時(shí)間到底花在哪。Jaeger到底是什么 / 解決什么問題可以把 Jaeger 理解成快遞的物流跟蹤系統(tǒng)一個(gè)請(qǐng)求在微服務(wù)之間流轉(zhuǎn)時(shí)每一站的時(shí)間戳和狀態(tài)都被記錄成span串起來就是一條trace調(diào)用鏈。它由 Uber 開發(fā)并捐贈(zèng)給 CNCF現(xiàn)在基于 OpenTelemetry Collector 構(gòu)建原生接收OTLP 協(xié)議gRPC 4317 / HTTP 4318。和傳統(tǒng)日志方案比對(duì)比項(xiàng)分散日志Jaeger 分布式追蹤定位慢在哪逐服務(wù) grep 后人工拼時(shí)間線瀑布圖直接看每個(gè) span 耗時(shí)跨服務(wù)關(guān)聯(lián)依賴 traceId 手工串聯(lián)自動(dòng)聚合為一條完整鏈路服務(wù)依賴關(guān)系看不出來依賴圖直接展示核心能力調(diào)用鏈查詢與瀑布圖按服務(wù)、操作、標(biāo)簽、時(shí)間窗過濾逐 span 查看耗時(shí)服務(wù)性能監(jiān)控SPM從 trace 數(shù)據(jù)直接算出 RED 指標(biāo)請(qǐng)求率、錯(cuò)誤率、延遲分位數(shù)多種存儲(chǔ)后端memory、Badger、Elasticsearch、OpenSearch、Cassandra、ClickHouse靈活采樣策略概率采樣、自適應(yīng)采樣、尾部采樣控制高流量下的數(shù)據(jù)量從零跑起來最小可用環(huán)境準(zhǔn)備一臺(tái)裝了 Docker 的機(jī)器就夠了確認(rèn)端口空閑16686UI 和查詢 API、4317OTLP gRPC、4318OTLP HTTP。啟動(dòng)一鍵拉起 Jaeger All-in-one一條命令啟動(dòng)包含 UI、Collector、Query、內(nèi)存存儲(chǔ)的 all-in-one 容器docker run --rm --name jaeger \ -p 16686:16686 \ -p 4317:4317 \ -p 4318:4318 \ jaegertracing/jaeger:latest接入應(yīng)用OTLP 是唯一的入口v2 版本統(tǒng)一走 OTLP。以 Go 應(yīng)用為例最小接入代碼exporter, _ : otlptracegrpc.New(ctx, otlptracegrpc.WithEndpoint(localhost:4317), otlptracegrpc.WithInsecure(), // 本地開發(fā)用明文生產(chǎn)記得換 TLS ) otel.SetTracerProvider(sdktrace.NewTracerProvider( sdktrace.WithBatcher(exporter), // 批量導(dǎo)出減少網(wǎng)絡(luò)往返 ))Java、Python、Node.js 用各自的 OpenTelemetry SDK配置方式相同把 exporter endpoint 指向localhost:4317gRPC或4318HTTP。不想改業(yè)務(wù)代碼用官方自帶的 tracegen 生成模擬流量--network host讓它訪問宿主機(jī)的 4318 端口docker run --rm --network host \ -e OTEL_EXPORTER_OTLP_TRACES_ENDPOINThttp://localhost:4318/v1/traces \ jaegertracing/jaeger-tracegen:latest \ -trace-exporter otlp-http -traces 100驗(yàn)證先確認(rèn)數(shù)據(jù)進(jìn)來了再看界面# 返回的服務(wù)列表里應(yīng)該出現(xiàn) tracegen說明數(shù)據(jù)已入庫(kù) curl -s http://localhost:16686/services出現(xiàn)結(jié)果即代表整條鏈路跑通了。瀏覽器打開http://localhost:16686進(jìn)入 UI。想要帶指標(biāo)監(jiān)控的完整演示環(huán)境microsim 微服務(wù)模擬器 OTel Collector Prometheus Grafana可以直接用倉(cāng)庫(kù)里現(xiàn)成的 docker-compose/monitor/cd docker-compose/monitor docker compose up架構(gòu)圖見下圖數(shù)據(jù)流應(yīng)用 SDK → Collector → Jaeger → 存儲(chǔ)UI 同時(shí)查 trace 和指標(biāo)Jaeger 監(jiān)控環(huán)境架構(gòu)OTel SDK 發(fā)出的 trace 經(jīng) Collector 分流trace 進(jìn) Jaeger 存儲(chǔ)聚合出的 RED 指標(biāo)進(jìn) Prometheus最終統(tǒng)一在 UI 呈現(xiàn)看懂你的第一條追蹤數(shù)據(jù)打開http://localhost:16686默認(rèn)進(jìn)入查詢頁。頁面分三塊頂部是搜索表單service、operation、tags、時(shí)間窗、是否只看錯(cuò)誤中間是 trace 列表每條顯示總耗時(shí)、span 數(shù)、服務(wù)名、時(shí)間點(diǎn)進(jìn)單條后是瀑布圖詳情。Jaeger UI 的 trace 查詢界面上方按服務(wù)/操作/標(biāo)簽/時(shí)間篩選列表區(qū)展示每條 trace 的總時(shí)長(zhǎng)與 span 數(shù)量點(diǎn)擊某條進(jìn)入瀑布圖以圖中tracegen服務(wù)為例幾個(gè)關(guān)鍵讀法總時(shí)長(zhǎng)Duration這條鏈路從第一個(gè) span 開始到最后一個(gè) span 結(jié)束的墻鐘時(shí)間比單個(gè) span 耗時(shí)更接近用戶真實(shí)感受單個(gè) span 的耗時(shí)占比瀑布圖里最長(zhǎng)的色塊就是關(guān)鍵路徑。如果 9 秒的 trace 里某 span 占了 8 秒排查就從它開始o(jì)peration 名span 的操作名如Get、POST /api/checkout同名 operation 的延遲突變往往就是回歸點(diǎn)錯(cuò)誤標(biāo)記帶 ? 的 span 表示狀態(tài)碼為錯(cuò)誤搜索表單里可以勾選只看錯(cuò)誤 trace核心能力詳解日常監(jiān)控看什么Monitor 標(biāo)簽頁的 RED 三件套v2 內(nèi)置 SPMService Performance Monitoring功能jaeger-query 直接從 trace 數(shù)據(jù)算出調(diào)用率call rate、錯(cuò)誤率error rate、延遲分位數(shù)P50/P95/P99在 UI 的 Monitor 標(biāo)簽頁以曲線展示。Monitor 標(biāo)簽頁展示的 RED 指標(biāo)請(qǐng)求率、錯(cuò)誤率和 P95 延遲按時(shí)間分布可按服務(wù)/操作下鉆三個(gè)數(shù)字高了分別說明什么P95 延遲上升大部分請(qǐng)求還正常但尾部變慢了——通常是某個(gè)下游變慢或 GC 抖動(dòng)去瀑布圖里找變長(zhǎng)的 span錯(cuò)誤率上升配合只看錯(cuò)誤 trace過濾定位是哪個(gè) operation 開始報(bào)錯(cuò)請(qǐng)求率與延遲同步跳變大概率是流量峰值打爆了容量進(jìn)入容量規(guī)劃場(chǎng)景指標(biāo)也可以通過 API 直接取方便接入自己的腳本# 查詢 tracegen 服務(wù)最近 1 小時(shí)的 P95 延遲 curl -s http://localhost:16686/api/metrics/latencies?servicetracegenquantile0.95排障時(shí)查什么多維過濾 依賴圖排障的標(biāo)準(zhǔn)動(dòng)作是縮小范圍先按service 時(shí)間窗圈定再加operation和tag如http.status_code500收斂最后打開具體 trace 看瀑布圖。UI 的 Services 頁還能看到依賴圖直觀回答誰在調(diào)我、我調(diào)了誰。容量規(guī)劃看什么采樣策略與存儲(chǔ)選型高流量下全量記錄既不現(xiàn)實(shí)也沒必要Jaeger 提供三類采樣方案適合場(chǎng)景注意事項(xiàng)概率采樣probabilistic開發(fā)/低流量全量或固定比例無法保證錯(cuò)誤 trace 一條不漏自適應(yīng)采樣adaptive中流量v2 默認(rèn)方向按服務(wù)/operation 動(dòng)態(tài)調(diào)概率依賴 trace 反饋尾部采樣tail_sampling高流量只留有用的 trace需等待決策窗口如 5s占內(nèi)存SPM 指標(biāo)的存儲(chǔ)也有兩種路線完整演示見 docker-compose/monitor/ 下的多個(gè) compose 文件方案適合場(chǎng)景注意事項(xiàng)Prometheus 后端已有 Prometheus 生態(tài)、要接告警多一個(gè)組件指標(biāo)有約 60s 聚合延遲直接查 trace 存儲(chǔ)ES/OS已經(jīng)在用 ES/OS 存 trace不引新組件但查詢打到 trace 庫(kù)ClickHouse 同時(shí)存 trace 和指標(biāo)數(shù)據(jù)量大、查詢并發(fā)高需建表支持create_schema: true自動(dòng)建生產(chǎn)環(huán)境怎么配才穩(wěn)推薦路徑先 all-in-one 驗(yàn)證 → 數(shù)據(jù)量上來后換存儲(chǔ)、拆組件 → 接入自身監(jiān)控告警。階段一all-in-one 明確數(shù)據(jù)上限內(nèi)存存儲(chǔ)重啟即丟但開發(fā)驗(yàn)證夠用。關(guān)鍵是顯式設(shè)上限參考倉(cāng)庫(kù) cmd/jaeger/config.yamljaeger_storage: backends: some_store: memory: max_traces: 100000 # 只保留最近 10 萬條 trace超了丟最老的避免內(nèi)存無界增長(zhǎng)階段二數(shù)據(jù)量上來后換持久化存儲(chǔ)換成 Badger單機(jī)時(shí)務(wù)必設(shè)置 TTL否則磁盤會(huì)無限增長(zhǎng)參考 cmd/jaeger/config-badger.yamlbadger: directories: keys: /data/jaeger/ values: /data/jaeger/ ttl: spans: 48h # 只留 48 小時(shí)按排障習(xí)慣定老數(shù)據(jù)靠歸檔而非無限保留換 Elasticsearch/OpenSearch 時(shí)按天滾動(dòng)索引方便按時(shí)間清理完整配置見 cmd/jaeger/config-elasticsearch.yamlelasticsearch: server_urls: [http://localhost:9200] indices: index_prefix: jaeger-main spans: rollover_frequency: day # 每天一個(gè)索引清理就是刪舊索引 shards: 5 replicas: 1階段三把 Jaeger 自己也監(jiān)控起來v2 默認(rèn)在8888端口以 Prometheus 格式暴露自身指標(biāo)見config.yaml中 telemetry 段。至少盯這 4 個(gè)otelcol_receiver_accepted_spans接收到的 span 數(shù)突降說明上游斷流otelcol_exporter_sent_spans成功寫入存儲(chǔ)的 span 數(shù)與接收數(shù)持續(xù)差值變大說明存儲(chǔ)端在丟traces_span_metrics_calls_total/traces_span_metrics_errors_totalSPM 算出的調(diào)用量與錯(cuò)誤量可配業(yè)務(wù)告警Jaeger 進(jìn)程的內(nèi)存與 CPU容器docker stats或 node exporter踩過的坑與診斷路徑數(shù)據(jù)明明發(fā)出去了UI 里看不到可能原因采樣策略把流量過濾掉了endpoint 指錯(cuò)4317 是 gRPC、4318 是 HTTP混用會(huì)連不上服務(wù)名和你搜索的不一致。# 1. 先確認(rèn)后端到底收到了哪些服務(wù) curl -s http://localhost:16686/services # 2. 看 Collector 有沒有報(bào)錯(cuò)如 schema/索引問題 docker logs --tail 200 jaeger | grep -iE error|fail調(diào)整建議臨時(shí)把采樣調(diào)成全量驗(yàn)證鏈路確認(rèn)應(yīng)用端OTEL_EXPORTER_OTLP_TRACES_ENDPOINT的協(xié)議和端口匹配搜索時(shí)用/services返回的原樣服務(wù)名。查詢?cè)絹碓铰赡茉驎r(shí)間窗開得太寬默認(rèn) 1h 起步有人直接選全部trace 庫(kù)索引膨脹沒清理單條 trace 的 span 數(shù)過多。# ES 后端看索引數(shù)量和大小確認(rèn)滾動(dòng)索引是否生效、舊索引是否已清 curl -s localhost:9200/_cat/indices/jaeger*?sstore.size:desc調(diào)整建議養(yǎng)成先窄時(shí)間窗、再放寬的查詢習(xí)慣給舊索引設(shè)保留策略熱點(diǎn)查詢加 service operation 條件而不是裸查。內(nèi)存 / 磁盤持續(xù)增長(zhǎng)可能原因all-in-one 內(nèi)存存儲(chǔ)接近max_traces上限Badger/ES 沒設(shè) TTL 或滾動(dòng)隊(duì)列積壓消費(fèi)速度 接收速度。# 看容器內(nèi)存水位 docker stats --no-stream # 對(duì)比收發(fā)差值sent 明顯低于 accepted 說明存儲(chǔ)端寫入跟不上 curl -s http://localhost:8888/metrics | grep -E otelcol_(receiver_accepted|exporter_sent)_spans調(diào)整建議給 memory 后端設(shè)小一點(diǎn)max_traces給持久化后端設(shè)ttl/ 索引保留天數(shù)用tail_sampling或降低概率采樣率把入口流量砍下來。從Demo到生產(chǎn)進(jìn)階玩法如果你需要只留慢的和錯(cuò)的其他全丟上尾部采樣。在 pipeline 里掛tail_samplingprocessor按屬性或延遲過濾倉(cāng)庫(kù)里有現(xiàn)成示例cmd/jaeger/config-tail-sampling-service-name-policy.yamlprocessors: tail_sampling: decision_wait: 5s # 等 5 秒攢齊一條 trace 再?zèng)Q策 policies: - name: keep-tracegen type: string_attribute string_attribute: { key: service.name, values: [tracegen-00] }如果你需要按業(yè)務(wù)維度下鉆在應(yīng)用里給 span 加自定義屬性如business.tierpremiumUI 搜索表單的 tags 里就能直接按business.tierpremium過濾——這是把追蹤從技術(shù)視角擴(kuò)展到業(yè)務(wù)視角的關(guān)鍵一步。如果你需要回答這次發(fā)布動(dòng)了哪些依賴對(duì)比發(fā)布前后的 Services 依賴圖和 Monitor 頁 RED 曲線比翻變更日志快得多。收尾你的行動(dòng)清單docker run拉起 all-in-onecurl http://localhost:16686/services返回tracegen用 OTLP 把一個(gè)真實(shí)應(yīng)用接進(jìn)來gRPC 4317 或 HTTP 4318在 UI 看到第一條自己的 trace按流量規(guī)模選定采樣策略概率 / 自適應(yīng) / 尾部采樣寫進(jìn)配置存儲(chǔ)從 memory 換到 Badger 或 ES/ClickHouse并顯式設(shè)置 TTL / 索引保留把8888端口的自身指標(biāo)接入 Prometheus至少對(duì) span 接收/寫出差值配一條告警從 Demo 到生產(chǎn)不是一次切換而是數(shù)據(jù)量倒逼的漸進(jìn)過程先保證鏈路可見再談留存和告警。核心關(guān)鍵詞Jaeger分布式追蹤, 分布式追蹤平臺(tái), 微服務(wù)性能監(jiān)控, OpenTelemetry OTLP接入, Jaeger生產(chǎn)部署 長(zhǎng)尾關(guān)鍵詞Jaeger all-in-one一鍵啟動(dòng), Jaeger采樣策略配置, Jaeger存儲(chǔ)后端選擇, Jaeger SPM服務(wù)性能監(jiān)控, Jaeger故障診斷排查指南【免費(fèi)下載鏈接】jaegerCNCF Jaeger, a Distributed Tracing Platform項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ja/jaeger創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 如何用Jaeger 5步跑通分布式追蹤：從零到生產(chǎn)部署的完整路徑
如何用Jaeger 5步跑通分布式追蹤從零到生產(chǎn)部署的完整路徑【免費(fèi)下載鏈接】jaegerCNCF Jaeger, a Distributed Tracing Platform項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ja/jaeger用戶在群里投訴下單變慢了你翻了三小時(shí)各服務(wù)日志只看到一堆上游超時(shí)的半句話。直到你在 Jaeger——CNCF 畢業(yè)的分布式追蹤平臺(tái)——里打開那條跨了 7 個(gè)服務(wù)的調(diào)用鏈9 秒的總耗時(shí)里有 8.2 秒卡在一句沒走索引的 SQL 上。這就是鏈路追蹤和日志的本質(zhì)區(qū)別日志告訴你誰報(bào)了錯(cuò)追蹤告訴你時(shí)間到底花在哪。Jaeger到底是什么 / 解決什么問題可以把 Jaeger 理解成快遞的物流跟蹤系統(tǒng)一個(gè)請(qǐng)求在微服務(wù)之間流轉(zhuǎn)時(shí)每一站的時(shí)間戳和狀態(tài)都被記錄成span串起來就是一條trace調(diào)用鏈。它由 Uber 開發(fā)并捐贈(zèng)給 CNCF現(xiàn)在基于 OpenTelemetry Collector 構(gòu)建原生接收OTLP 協(xié)議gRPC 4317 / HTTP 4318。和傳統(tǒng)日志方案比對(duì)比項(xiàng)分散日志Jaeger 分布式追蹤定位慢在哪逐服務(wù) grep 后人工拼時(shí)間線瀑布圖直接看每個(gè) span 耗時(shí)跨服務(wù)關(guān)聯(lián)依賴 traceId 手工串聯(lián)自動(dòng)聚合為一條完整鏈路服務(wù)依賴關(guān)系看不出來依賴圖直接展示核心能力調(diào)用鏈查詢與瀑布圖按服務(wù)、操作、標(biāo)簽、時(shí)間窗過濾逐 span 查看耗時(shí)服務(wù)性能監(jiān)控SPM從 trace 數(shù)據(jù)直接算出 RED 指標(biāo)請(qǐng)求率、錯(cuò)誤率、延遲分位數(shù)多種存儲(chǔ)后端memory、Badger、Elasticsearch、OpenSearch、Cassandra、ClickHouse靈活采樣策略概率采樣、自適應(yīng)采樣、尾部采樣控制高流量下的數(shù)據(jù)量從零跑起來最小可用環(huán)境準(zhǔn)備一臺(tái)裝了 Docker 的機(jī)器就夠了確認(rèn)端口空閑16686UI 和查詢 API、4317OTLP gRPC、4318OTLP HTTP。啟動(dòng)一鍵拉起 Jaeger All-in-one一條命令啟動(dòng)包含 UI、Collector、Query、內(nèi)存存儲(chǔ)的 all-in-one 容器docker run --rm --name jaeger \ -p 16686:16686 \ -p 4317:4317 \ -p 4318:4318 \ jaegertracing/jaeger:latest接入應(yīng)用OTLP 是唯一的入口v2 版本統(tǒng)一走 OTLP。以 Go 應(yīng)用為例最小接入代碼exporter, _ : otlptracegrpc.New(ctx, otlptracegrpc.WithEndpoint(localhost:4317), otlptracegrpc.WithInsecure(), // 本地開發(fā)用明文生產(chǎn)記得換 TLS ) otel.SetTracerProvider(sdktrace.NewTracerProvider( sdktrace.WithBatcher(exporter), // 批量導(dǎo)出減少網(wǎng)絡(luò)往返 ))Java、Python、Node.js 用各自的 OpenTelemetry SDK配置方式相同把 exporter endpoint 指向localhost:4317gRPC或4318HTTP。不想改業(yè)務(wù)代碼用官方自帶的 tracegen 生成模擬流量--network host讓它訪問宿主機(jī)的 4318 端口docker run --rm --network host \ -e OTEL_EXPORTER_OTLP_TRACES_ENDPOINThttp://localhost:4318/v1/traces \ jaegertracing/jaeger-tracegen:latest \ -trace-exporter otlp-http -traces 100驗(yàn)證先確認(rèn)數(shù)據(jù)進(jìn)來了再看界面# 返回的服務(wù)列表里應(yīng)該出現(xiàn) tracegen說明數(shù)據(jù)已入庫(kù) curl -s http://localhost:16686/services出現(xiàn)結(jié)果即代表整條鏈路跑通了。瀏覽器打開http://localhost:16686進(jìn)入 UI。想要帶指標(biāo)監(jiān)控的完整演示環(huán)境microsim 微服務(wù)模擬器 OTel Collector Prometheus Grafana可以直接用倉(cāng)庫(kù)里現(xiàn)成的 docker-compose/monitor/cd docker-compose/monitor docker compose up架構(gòu)圖見下圖數(shù)據(jù)流應(yīng)用 SDK → Collector → Jaeger → 存儲(chǔ)UI 同時(shí)查 trace 和指標(biāo)Jaeger 監(jiān)控環(huán)境架構(gòu)OTel SDK 發(fā)出的 trace 經(jīng) Collector 分流trace 進(jìn) Jaeger 存儲(chǔ)聚合出的 RED 指標(biāo)進(jìn) Prometheus最終統(tǒng)一在 UI 呈現(xiàn)看懂你的第一條追蹤數(shù)據(jù)打開http://localhost:16686默認(rèn)進(jìn)入查詢頁。頁面分三塊頂部是搜索表單service、operation、tags、時(shí)間窗、是否只看錯(cuò)誤中間是 trace 列表每條顯示總耗時(shí)、span 數(shù)、服務(wù)名、時(shí)間點(diǎn)進(jìn)單條后是瀑布圖詳情。Jaeger UI 的 trace 查詢界面上方按服務(wù)/操作/標(biāo)簽/時(shí)間篩選列表區(qū)展示每條 trace 的總時(shí)長(zhǎng)與 span 數(shù)量點(diǎn)擊某條進(jìn)入瀑布圖以圖中tracegen服務(wù)為例幾個(gè)關(guān)鍵讀法總時(shí)長(zhǎng)Duration這條鏈路從第一個(gè) span 開始到最后一個(gè) span 結(jié)束的墻鐘時(shí)間比單個(gè) span 耗時(shí)更接近用戶真實(shí)感受單個(gè) span 的耗時(shí)占比瀑布圖里最長(zhǎng)的色塊就是關(guān)鍵路徑。如果 9 秒的 trace 里某 span 占了 8 秒排查就從它開始o(jì)peration 名span 的操作名如Get、POST /api/checkout同名 operation 的延遲突變往往就是回歸點(diǎn)錯(cuò)誤標(biāo)記帶 ? 的 span 表示狀態(tài)碼為錯(cuò)誤搜索表單里可以勾選只看錯(cuò)誤 trace核心能力詳解日常監(jiān)控看什么Monitor 標(biāo)簽頁的 RED 三件套v2 內(nèi)置 SPMService Performance Monitoring功能jaeger-query 直接從 trace 數(shù)據(jù)算出調(diào)用率call rate、錯(cuò)誤率error rate、延遲分位數(shù)P50/P95/P99在 UI 的 Monitor 標(biāo)簽頁以曲線展示。Monitor 標(biāo)簽頁展示的 RED 指標(biāo)請(qǐng)求率、錯(cuò)誤率和 P95 延遲按時(shí)間分布可按服務(wù)/操作下鉆三個(gè)數(shù)字高了分別說明什么P95 延遲上升大部分請(qǐng)求還正常但尾部變慢了——通常是某個(gè)下游變慢或 GC 抖動(dòng)去瀑布圖里找變長(zhǎng)的 span錯(cuò)誤率上升配合只看錯(cuò)誤 trace過濾定位是哪個(gè) operation 開始報(bào)錯(cuò)請(qǐng)求率與延遲同步跳變大概率是流量峰值打爆了容量進(jìn)入容量規(guī)劃場(chǎng)景指標(biāo)也可以通過 API 直接取方便接入自己的腳本# 查詢 tracegen 服務(wù)最近 1 小時(shí)的 P95 延遲 curl -s http://localhost:16686/api/metrics/latencies?servicetracegenquantile0.95排障時(shí)查什么多維過濾 依賴圖排障的標(biāo)準(zhǔn)動(dòng)作是縮小范圍先按service 時(shí)間窗圈定再加operation和tag如http.status_code500收斂最后打開具體 trace 看瀑布圖。UI 的 Services 頁還能看到依賴圖直觀回答誰在調(diào)我、我調(diào)了誰。容量規(guī)劃看什么采樣策略與存儲(chǔ)選型高流量下全量記錄既不現(xiàn)實(shí)也沒必要Jaeger 提供三類采樣方案適合場(chǎng)景注意事項(xiàng)概率采樣probabilistic開發(fā)/低流量全量或固定比例無法保證錯(cuò)誤 trace 一條不漏自適應(yīng)采樣adaptive中流量v2 默認(rèn)方向按服務(wù)/operation 動(dòng)態(tài)調(diào)概率依賴 trace 反饋尾部采樣tail_sampling高流量只留有用的 trace需等待決策窗口如 5s占內(nèi)存SPM 指標(biāo)的存儲(chǔ)也有兩種路線完整演示見 docker-compose/monitor/ 下的多個(gè) compose 文件方案適合場(chǎng)景注意事項(xiàng)Prometheus 后端已有 Prometheus 生態(tài)、要接告警多一個(gè)組件指標(biāo)有約 60s 聚合延遲直接查 trace 存儲(chǔ)ES/OS已經(jīng)在用 ES/OS 存 trace不引新組件但查詢打到 trace 庫(kù)ClickHouse 同時(shí)存 trace 和指標(biāo)數(shù)據(jù)量大、查詢并發(fā)高需建表支持create_schema: true自動(dòng)建生產(chǎn)環(huán)境怎么配才穩(wěn)推薦路徑先 all-in-one 驗(yàn)證 → 數(shù)據(jù)量上來后換存儲(chǔ)、拆組件 → 接入自身監(jiān)控告警。階段一all-in-one 明確數(shù)據(jù)上限內(nèi)存存儲(chǔ)重啟即丟但開發(fā)驗(yàn)證夠用。關(guān)鍵是顯式設(shè)上限參考倉(cāng)庫(kù) cmd/jaeger/config.yamljaeger_storage: backends: some_store: memory: max_traces: 100000 # 只保留最近 10 萬條 trace超了丟最老的避免內(nèi)存無界增長(zhǎng)階段二數(shù)據(jù)量上來后換持久化存儲(chǔ)換成 Badger單機(jī)時(shí)務(wù)必設(shè)置 TTL否則磁盤會(huì)無限增長(zhǎng)參考 cmd/jaeger/config-badger.yamlbadger: directories: keys: /data/jaeger/ values: /data/jaeger/ ttl: spans: 48h # 只留 48 小時(shí)按排障習(xí)慣定老數(shù)據(jù)靠歸檔而非無限保留換 Elasticsearch/OpenSearch 時(shí)按天滾動(dòng)索引方便按時(shí)間清理完整配置見 cmd/jaeger/config-elasticsearch.yamlelasticsearch: server_urls: [http://localhost:9200] indices: index_prefix: jaeger-main spans: rollover_frequency: day # 每天一個(gè)索引清理就是刪舊索引 shards: 5 replicas: 1階段三把 Jaeger 自己也監(jiān)控起來v2 默認(rèn)在8888端口以 Prometheus 格式暴露自身指標(biāo)見config.yaml中 telemetry 段。至少盯這 4 個(gè)otelcol_receiver_accepted_spans接收到的 span 數(shù)突降說明上游斷流otelcol_exporter_sent_spans成功寫入存儲(chǔ)的 span 數(shù)與接收數(shù)持續(xù)差值變大說明存儲(chǔ)端在丟traces_span_metrics_calls_total/traces_span_metrics_errors_totalSPM 算出的調(diào)用量與錯(cuò)誤量可配業(yè)務(wù)告警Jaeger 進(jìn)程的內(nèi)存與 CPU容器docker stats或 node exporter踩過的坑與診斷路徑數(shù)據(jù)明明發(fā)出去了UI 里看不到可能原因采樣策略把流量過濾掉了endpoint 指錯(cuò)4317 是 gRPC、4318 是 HTTP混用會(huì)連不上服務(wù)名和你搜索的不一致。# 1. 先確認(rèn)后端到底收到了哪些服務(wù) curl -s http://localhost:16686/services # 2. 看 Collector 有沒有報(bào)錯(cuò)如 schema/索引問題 docker logs --tail 200 jaeger | grep -iE error|fail調(diào)整建議臨時(shí)把采樣調(diào)成全量驗(yàn)證鏈路確認(rèn)應(yīng)用端OTEL_EXPORTER_OTLP_TRACES_ENDPOINT的協(xié)議和端口匹配搜索時(shí)用/services返回的原樣服務(wù)名。查詢?cè)絹碓铰赡茉驎r(shí)間窗開得太寬默認(rèn) 1h 起步有人直接選全部trace 庫(kù)索引膨脹沒清理單條 trace 的 span 數(shù)過多。# ES 后端看索引數(shù)量和大小確認(rèn)滾動(dòng)索引是否生效、舊索引是否已清 curl -s localhost:9200/_cat/indices/jaeger*?sstore.size:desc調(diào)整建議養(yǎng)成先窄時(shí)間窗、再放寬的查詢習(xí)慣給舊索引設(shè)保留策略熱點(diǎn)查詢加 service operation 條件而不是裸查。內(nèi)存 / 磁盤持續(xù)增長(zhǎng)可能原因all-in-one 內(nèi)存存儲(chǔ)接近max_traces上限Badger/ES 沒設(shè) TTL 或滾動(dòng)隊(duì)列積壓消費(fèi)速度 接收速度。# 看容器內(nèi)存水位 docker stats --no-stream # 對(duì)比收發(fā)差值sent 明顯低于 accepted 說明存儲(chǔ)端寫入跟不上 curl -s http://localhost:8888/metrics | grep -E otelcol_(receiver_accepted|exporter_sent)_spans調(diào)整建議給 memory 后端設(shè)小一點(diǎn)max_traces給持久化后端設(shè)ttl/ 索引保留天數(shù)用tail_sampling或降低概率采樣率把入口流量砍下來。從Demo到生產(chǎn)進(jìn)階玩法如果你需要只留慢的和錯(cuò)的其他全丟上尾部采樣。在 pipeline 里掛tail_samplingprocessor按屬性或延遲過濾倉(cāng)庫(kù)里有現(xiàn)成示例cmd/jaeger/config-tail-sampling-service-name-policy.yamlprocessors: tail_sampling: decision_wait: 5s # 等 5 秒攢齊一條 trace 再?zèng)Q策 policies: - name: keep-tracegen type: string_attribute string_attribute: { key: service.name, values: [tracegen-00] }如果你需要按業(yè)務(wù)維度下鉆在應(yīng)用里給 span 加自定義屬性如business.tierpremiumUI 搜索表單的 tags 里就能直接按business.tierpremium過濾——這是把追蹤從技術(shù)視角擴(kuò)展到業(yè)務(wù)視角的關(guān)鍵一步。如果你需要回答這次發(fā)布動(dòng)了哪些依賴對(duì)比發(fā)布前后的 Services 依賴圖和 Monitor 頁 RED 曲線比翻變更日志快得多。收尾你的行動(dòng)清單docker run拉起 all-in-onecurl http://localhost:16686/services返回tracegen用 OTLP 把一個(gè)真實(shí)應(yīng)用接進(jìn)來gRPC 4317 或 HTTP 4318在 UI 看到第一條自己的 trace按流量規(guī)模選定采樣策略概率 / 自適應(yīng) / 尾部采樣寫進(jìn)配置存儲(chǔ)從 memory 換到 Badger 或 ES/ClickHouse并顯式設(shè)置 TTL / 索引保留把8888端口的自身指標(biāo)接入 Prometheus至少對(duì) span 接收/寫出差值配一條告警從 Demo 到生產(chǎn)不是一次切換而是數(shù)據(jù)量倒逼的漸進(jìn)過程先保證鏈路可見再談留存和告警。核心關(guān)鍵詞Jaeger分布式追蹤, 分布式追蹤平臺(tái), 微服務(wù)性能監(jiān)控, OpenTelemetry OTLP接入, Jaeger生產(chǎn)部署 長(zhǎng)尾關(guān)鍵詞Jaeger all-in-one一鍵啟動(dòng), Jaeger采樣策略配置, Jaeger存儲(chǔ)后端選擇, Jaeger SPM服務(wù)性能監(jiān)控, Jaeger故障診斷排查指南【免費(fèi)下載鏈接】jaegerCNCF Jaeger, a Distributed Tracing Platform項(xiàng)目地址: https://gitcode.com/GitHub_Trending/ja/jaeger創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考