Jaeger Elasticsearch 指標遷移對照指南V1 到 V2 的 Metric 命名與標簽映射【免費下載鏈接】jaegerCNCF Jaeger, a Distributed Tracing Platform項目地址: https://gitcode.com/GitHub_Trending/ja/jaeger本文檔是 Jaeger v1 → v2 遷移系列中的 Elasticsearch 指標篇完整羅列了 Elasticsearch 存儲后端在遷移前后的指標名與標簽labels對照關系涵蓋組合指標Combined MetricsV1/V2 名稱完全一致與等價指標Equivalent Metrics名稱與標簽均發生變更兩類并給出對應源碼依據幫助監控團隊在升級過程中無痛切換告警規則與 Grafana 面板。本指南以倉庫內 cmd/jaeger/docs/migration/elasticsearch-metrics.md 為核心骨架結合 Elasticsearch 存儲實現源碼與指標生成腳本展開講解。讀者讀完可掌握哪些 ES 指標在 v2 中保持不變、哪些指標被重命名并擴展了標簽、以及如何在遷移后繼續用統一指標名構建監控面板。為什么需要指標遷移對照表Jaeger v2 基于 OpenTelemetry Collector 重寫了整體架構數據寫入、接收與構建信息的埋點方式也隨之變化寫入路徑從 v1 的internal/storage/v1演進為 v2 的internal/storage/v2但 Elasticsearch 批量寫入核心仍然復用統一的寫入指標模型接收路徑改為標準 OTLP receiver拒絕 span 的計數指標從 Jaeger 自定義命名切換為 OTel 語義約定的receiver_refused_spans構建信息改為遵循 OpenTelemetry 資源語義的target_info標簽結構也向 OTel 資源屬性靠攏。倉庫在 cmd/jaeger/docs/migration/ 下按存儲后端分別維護了遷移對照表all-in-one-metrics.md、badger-metrics.md、cassandra-metrics.md、elasticsearch-metrics.md、opensearch-metrics.md本文聚焦 ElasticsearchOpenSearch 對照表見 opensearch-metrics.md內容與 ES 完全一致。這些表格并非手寫維護而是由 scripts/utils/metrics-md.py 從指標定義中自動生成的腳本中的generate_combined_markdown_table負責產出Combined Metrics小節generate_spans_markdown_table負責產出Equivalent Metrics小節確保對照關系與源碼始終同步。組合指標Combined MetricsV1 與 V2 完全一致ES 寫入相關的 10 個指標在 v1、v2 中名稱與參數標簽完全相同均為N/A即無附加標簽只有指標名本身。這意味著基于這些指標構建的寫入監控面板、告警規則在遷移后無需任何修改即可繼續工作。V1 MetricV1 ParametersV2 MetricV2 Parametersjaeger_bulk_index_attempts_totalN/Ajaeger_bulk_index_attempts_totalN/Ajaeger_bulk_index_errors_totalN/Ajaeger_bulk_index_errors_totalN/Ajaeger_bulk_index_inserts_totalN/Ajaeger_bulk_index_inserts_totalN/Ajaeger_bulk_index_latency_errN/Ajaeger_bulk_index_latency_errN/Ajaeger_bulk_index_latency_okN/Ajaeger_bulk_index_latency_okN/Ajaeger_index_create_attempts_totalN/Ajaeger_index_create_attempts_totalN/Ajaeger_index_create_errors_totalN/Ajaeger_index_create_errors_totalN/Ajaeger_index_create_inserts_totalN/Ajaeger_index_create_inserts_totalN/Ajaeger_index_create_latency_errN/Ajaeger_index_create_latency_errN/Ajaeger_index_create_latency_okN/Ajaeger_index_create_latency_okN/A指標族的統一命名模型這 10 個指標屬于兩個命名族bulk_index批量寫入與index_create索引創建。每個族內都遵循固定的attempts / inserts / errors / latency-ok / latency-err五件套結構其底層定義位于 internal/storage/v1/api/spanstore/spanstoremetrics/write_metrics.gotype WriteMetrics struct { Attempts metrics.Counter metric:attempts Inserts metrics.Counter metric:inserts Errors metrics.Counter metric:errors LatencyOk metrics.Timer metric:latency-ok LatencyErr metrics.Timer metric:latency-err }其語義通過 Emit 方法 一次性確定func (t *WriteMetrics) Emit(err error, latency time.Duration) { t.Attempts.Inc(1) if err ! nil { t.LatencyErr.Record(latency) t.Errors.Inc(1) } else { t.LatencyOk.Record(latency) t.Inserts.Inc(1) } }即每次操作先遞增attempts成功則記錄latency-ok并遞增inserts失敗則記錄latency-err并遞增errors。因此監控時通常以errors / attempts計算失敗率用latency-ok與latency-err分別觀察正常與異常路徑的耗時分布。bulk_index批量寫入指標bulk_index族由 BulkIndexer 在寫入_bulk時埋點。在 v2 的統一 ES 客戶端實現 internal/storage/elasticsearch/esclient/bulk.go 中func NewBulkIndexer(client *Client, cfg BulkIndexerConfig, metricsFactory metrics.Factory, logger *zap.Logger) (*BulkIndexer, error) { b : BulkIndexer{ metrics: spanstoremetrics.NewWriter(metricsFactory, bulk_index), ... } }spanstoremetrics.NewWriter(metricsFactory, bulk_index)會將上述五件套指標統一放入bulk_index命名空間最終輸出為jaeger_bulk_index_attempts_total、jaeger_bulk_index_errors_total、jaeger_bulk_index_inserts_total、jaeger_bulk_index_latency_err、jaeger_bulk_index_latency_ok。同步寫入路徑 internal/storage/elasticsearch/esclient/sync_bulk.go 使用相同的bulk_index命名空間因此無論采用異步批量還是同步批量指標口徑完全一致。單元測試對指標行為做了精確斷言見 internal/storage/elasticsearch/esclient/bulk_test.go成功場景bulk_index.inserts 1、bulk_index.errors 0只出現latency-ok計時器失敗場景bulk_index.inserts 0、bulk_index.errors 1只出現latency-err計時器入隊失敗場景隊列已滿bulk_index.attempts 1、bulk_index.errors 1見 TestBulkIndexerEnqueueError。這從測試層面印證了表格中V1/V2 指標名與參數一致的結論——同一套寫入指標模型在遷移前后被完整保留。index_create索引創建指標index_create族對應 Elasticsearch 索引初始化/創建如按天/按小時滾動索引的預創建操作同樣沿用NewWriter(metricsFactory, index_create)的五件套模型。在遷移對照表中該族 5 個指標的 V1/V2 名稱與參數也保持完全一致N/A因此索引創建相關的告警如jaeger_index_create_errors_total持續增長可以直接沿用。等價指標Equivalent Metrics名稱與標簽均發生變更以下 2 個指標在 v1 與 v2 中名稱不同、標簽集合也不同遷移時必須同步更新告警表達式與面板查詢V1 MetricV1 ParametersV2 MetricV2 Parametersjaeger_collector_spans_rejected_totaldebug, format, svc, transportreceiver_refused_spansreceiver, service_instance_id, service_name, service_version, transportjaeger_build_infobuild_date, revision, versiontarget_infoservice_instance_id, service_name, service_version拒絕 span 計數jaeger_collector_spans_rejected_total → receiver_refused_spansv1 中拒絕 span 的計數由 Collector 自定義埋點jaeger_collector_spans_rejected_total上報攜帶標簽debug調試開關、format數據格式如 jaeger/otlp、svc服務名、transport傳輸協議。v2 中 Jaeger 以標準 OTel Collector 組件形態運行該指標由接收器按 OpenTelemetry 語義約定上報為receiver_refused_spans標簽集變為receiver接收器名稱如 otlp、jaeger 等service_instance_id/service_name/service_versionOTel 資源屬性標識上報實例transport傳輸協議標簽名保留含義與 v1 一致。這一命名在 Jaeger 的監控資產中已被采用例如 monitoring/jaeger-mixin/dashboard-for-grafana.json 與生成代碼 monitoring/jaeger-mixin/generate/main.go 中均使用receiver_refused_spans構建接收拒絕率的監控表達式。遷移后若需按服務維度拆分告警應改用service_name而非 v1 的svc。構建信息jaeger_build_info → target_infov1 的jaeger_build_info攜帶build_date構建日期、revisionGit 提交、version版本號三個標簽用于在 Prometheus 中標識運行中的二進制版本。v2 中該信息通過 OTel 資源屬性導出為target_info標簽僅保留服務身份三要素service_instance_id、service_name、service_version。遷移后查詢運行版本時不再直接看到version/revision標簽而需要通過service_nameservice_version組合定位實例若面板依賴jaeger_build_info{version...}做版本告警或展示需改寫為對target_info的查詢。遷移落地建議寫入與索引類指標零改動jaeger_bulk_index_*與jaeger_index_create_*共 10 個指標直接沿用現有面板與告警無需修改可結合errors/attempts比率與latency-err觀察寫入健康度。接收拒絕類指標改寫將jaeger_collector_spans_rejected_total相關查詢/告警替換為receiver_refused_spans并按需在標簽receiver、service_name、transport上做分組與過濾。版本信息類指標改寫將jaeger_build_info相關查詢替換為target_info注意標簽從version/revision變為service_version/service_name的差異。保持文檔同步若后續指標定義發生變更可通過 scripts/utils/metrics-md.py 重新生成 elasticsearch-metrics.md 對照表確保監控團隊始終拿到與源碼一致的遷移依據。小結Elasticsearch 后端的指標遷移可以概括為寫入路徑不變、接收與元信息標準化bulk_index與index_create兩個指標族的 10 個指標在 v1/v2 中名稱與標簽完全一致遷移成本為零而receiver_refused_spans、target_info兩個 OTel 標準化指標的引入則要求監控側同步更新查詢與告警。結合 bulk.go、write_metrics.go 與 bulk_test.go 中的實現與測試可以確認這套對照關系與運行時代碼保持一致可放心作為遷移核對清單使用。【免費下載鏈接】jaegerCNCF Jaeger, a Distributed Tracing Platform項目地址: https://gitcode.com/GitHub_Trending/ja/jaeger創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Jaeger Elasticsearch 指標遷移對照指南：V1 到 V2 的 Metric 命名與標簽映射
Jaeger Elasticsearch 指標遷移對照指南V1 到 V2 的 Metric 命名與標簽映射【免費下載鏈接】jaegerCNCF Jaeger, a Distributed Tracing Platform項目地址: https://gitcode.com/GitHub_Trending/ja/jaeger本文檔是 Jaeger v1 → v2 遷移系列中的 Elasticsearch 指標篇完整羅列了 Elasticsearch 存儲后端在遷移前后的指標名與標簽labels對照關系涵蓋組合指標Combined MetricsV1/V2 名稱完全一致與等價指標Equivalent Metrics名稱與標簽均發生變更兩類并給出對應源碼依據幫助監控團隊在升級過程中無痛切換告警規則與 Grafana 面板。本指南以倉庫內 cmd/jaeger/docs/migration/elasticsearch-metrics.md 為核心骨架結合 Elasticsearch 存儲實現源碼與指標生成腳本展開講解。讀者讀完可掌握哪些 ES 指標在 v2 中保持不變、哪些指標被重命名并擴展了標簽、以及如何在遷移后繼續用統一指標名構建監控面板。為什么需要指標遷移對照表Jaeger v2 基于 OpenTelemetry Collector 重寫了整體架構數據寫入、接收與構建信息的埋點方式也隨之變化寫入路徑從 v1 的internal/storage/v1演進為 v2 的internal/storage/v2但 Elasticsearch 批量寫入核心仍然復用統一的寫入指標模型接收路徑改為標準 OTLP receiver拒絕 span 的計數指標從 Jaeger 自定義命名切換為 OTel 語義約定的receiver_refused_spans構建信息改為遵循 OpenTelemetry 資源語義的target_info標簽結構也向 OTel 資源屬性靠攏。倉庫在 cmd/jaeger/docs/migration/ 下按存儲后端分別維護了遷移對照表all-in-one-metrics.md、badger-metrics.md、cassandra-metrics.md、elasticsearch-metrics.md、opensearch-metrics.md本文聚焦 ElasticsearchOpenSearch 對照表見 opensearch-metrics.md內容與 ES 完全一致。這些表格并非手寫維護而是由 scripts/utils/metrics-md.py 從指標定義中自動生成的腳本中的generate_combined_markdown_table負責產出Combined Metrics小節generate_spans_markdown_table負責產出Equivalent Metrics小節確保對照關系與源碼始終同步。組合指標Combined MetricsV1 與 V2 完全一致ES 寫入相關的 10 個指標在 v1、v2 中名稱與參數標簽完全相同均為N/A即無附加標簽只有指標名本身。這意味著基于這些指標構建的寫入監控面板、告警規則在遷移后無需任何修改即可繼續工作。V1 MetricV1 ParametersV2 MetricV2 Parametersjaeger_bulk_index_attempts_totalN/Ajaeger_bulk_index_attempts_totalN/Ajaeger_bulk_index_errors_totalN/Ajaeger_bulk_index_errors_totalN/Ajaeger_bulk_index_inserts_totalN/Ajaeger_bulk_index_inserts_totalN/Ajaeger_bulk_index_latency_errN/Ajaeger_bulk_index_latency_errN/Ajaeger_bulk_index_latency_okN/Ajaeger_bulk_index_latency_okN/Ajaeger_index_create_attempts_totalN/Ajaeger_index_create_attempts_totalN/Ajaeger_index_create_errors_totalN/Ajaeger_index_create_errors_totalN/Ajaeger_index_create_inserts_totalN/Ajaeger_index_create_inserts_totalN/Ajaeger_index_create_latency_errN/Ajaeger_index_create_latency_errN/Ajaeger_index_create_latency_okN/Ajaeger_index_create_latency_okN/A指標族的統一命名模型這 10 個指標屬于兩個命名族bulk_index批量寫入與index_create索引創建。每個族內都遵循固定的attempts / inserts / errors / latency-ok / latency-err五件套結構其底層定義位于 internal/storage/v1/api/spanstore/spanstoremetrics/write_metrics.gotype WriteMetrics struct { Attempts metrics.Counter metric:attempts Inserts metrics.Counter metric:inserts Errors metrics.Counter metric:errors LatencyOk metrics.Timer metric:latency-ok LatencyErr metrics.Timer metric:latency-err }其語義通過 Emit 方法 一次性確定func (t *WriteMetrics) Emit(err error, latency time.Duration) { t.Attempts.Inc(1) if err ! nil { t.LatencyErr.Record(latency) t.Errors.Inc(1) } else { t.LatencyOk.Record(latency) t.Inserts.Inc(1) } }即每次操作先遞增attempts成功則記錄latency-ok并遞增inserts失敗則記錄latency-err并遞增errors。因此監控時通常以errors / attempts計算失敗率用latency-ok與latency-err分別觀察正常與異常路徑的耗時分布。bulk_index批量寫入指標bulk_index族由 BulkIndexer 在寫入_bulk時埋點。在 v2 的統一 ES 客戶端實現 internal/storage/elasticsearch/esclient/bulk.go 中func NewBulkIndexer(client *Client, cfg BulkIndexerConfig, metricsFactory metrics.Factory, logger *zap.Logger) (*BulkIndexer, error) { b : BulkIndexer{ metrics: spanstoremetrics.NewWriter(metricsFactory, bulk_index), ... } }spanstoremetrics.NewWriter(metricsFactory, bulk_index)會將上述五件套指標統一放入bulk_index命名空間最終輸出為jaeger_bulk_index_attempts_total、jaeger_bulk_index_errors_total、jaeger_bulk_index_inserts_total、jaeger_bulk_index_latency_err、jaeger_bulk_index_latency_ok。同步寫入路徑 internal/storage/elasticsearch/esclient/sync_bulk.go 使用相同的bulk_index命名空間因此無論采用異步批量還是同步批量指標口徑完全一致。單元測試對指標行為做了精確斷言見 internal/storage/elasticsearch/esclient/bulk_test.go成功場景bulk_index.inserts 1、bulk_index.errors 0只出現latency-ok計時器失敗場景bulk_index.inserts 0、bulk_index.errors 1只出現latency-err計時器入隊失敗場景隊列已滿bulk_index.attempts 1、bulk_index.errors 1見 TestBulkIndexerEnqueueError。這從測試層面印證了表格中V1/V2 指標名與參數一致的結論——同一套寫入指標模型在遷移前后被完整保留。index_create索引創建指標index_create族對應 Elasticsearch 索引初始化/創建如按天/按小時滾動索引的預創建操作同樣沿用NewWriter(metricsFactory, index_create)的五件套模型。在遷移對照表中該族 5 個指標的 V1/V2 名稱與參數也保持完全一致N/A因此索引創建相關的告警如jaeger_index_create_errors_total持續增長可以直接沿用。等價指標Equivalent Metrics名稱與標簽均發生變更以下 2 個指標在 v1 與 v2 中名稱不同、標簽集合也不同遷移時必須同步更新告警表達式與面板查詢V1 MetricV1 ParametersV2 MetricV2 Parametersjaeger_collector_spans_rejected_totaldebug, format, svc, transportreceiver_refused_spansreceiver, service_instance_id, service_name, service_version, transportjaeger_build_infobuild_date, revision, versiontarget_infoservice_instance_id, service_name, service_version拒絕 span 計數jaeger_collector_spans_rejected_total → receiver_refused_spansv1 中拒絕 span 的計數由 Collector 自定義埋點jaeger_collector_spans_rejected_total上報攜帶標簽debug調試開關、format數據格式如 jaeger/otlp、svc服務名、transport傳輸協議。v2 中 Jaeger 以標準 OTel Collector 組件形態運行該指標由接收器按 OpenTelemetry 語義約定上報為receiver_refused_spans標簽集變為receiver接收器名稱如 otlp、jaeger 等service_instance_id/service_name/service_versionOTel 資源屬性標識上報實例transport傳輸協議標簽名保留含義與 v1 一致。這一命名在 Jaeger 的監控資產中已被采用例如 monitoring/jaeger-mixin/dashboard-for-grafana.json 與生成代碼 monitoring/jaeger-mixin/generate/main.go 中均使用receiver_refused_spans構建接收拒絕率的監控表達式。遷移后若需按服務維度拆分告警應改用service_name而非 v1 的svc。構建信息jaeger_build_info → target_infov1 的jaeger_build_info攜帶build_date構建日期、revisionGit 提交、version版本號三個標簽用于在 Prometheus 中標識運行中的二進制版本。v2 中該信息通過 OTel 資源屬性導出為target_info標簽僅保留服務身份三要素service_instance_id、service_name、service_version。遷移后查詢運行版本時不再直接看到version/revision標簽而需要通過service_nameservice_version組合定位實例若面板依賴jaeger_build_info{version...}做版本告警或展示需改寫為對target_info的查詢。遷移落地建議寫入與索引類指標零改動jaeger_bulk_index_*與jaeger_index_create_*共 10 個指標直接沿用現有面板與告警無需修改可結合errors/attempts比率與latency-err觀察寫入健康度。接收拒絕類指標改寫將jaeger_collector_spans_rejected_total相關查詢/告警替換為receiver_refused_spans并按需在標簽receiver、service_name、transport上做分組與過濾。版本信息類指標改寫將jaeger_build_info相關查詢替換為target_info注意標簽從version/revision變為service_version/service_name的差異。保持文檔同步若后續指標定義發生變更可通過 scripts/utils/metrics-md.py 重新生成 elasticsearch-metrics.md 對照表確保監控團隊始終拿到與源碼一致的遷移依據。小結Elasticsearch 后端的指標遷移可以概括為寫入路徑不變、接收與元信息標準化bulk_index與index_create兩個指標族的 10 個指標在 v1/v2 中名稱與標簽完全一致遷移成本為零而receiver_refused_spans、target_info兩個 OTel 標準化指標的引入則要求監控側同步更新查詢與告警。結合 bulk.go、write_metrics.go 與 bulk_test.go 中的實現與測試可以確認這套對照關系與運行時代碼保持一致可放心作為遷移核對清單使用。【免費下載鏈接】jaegerCNCF Jaeger, a Distributed Tracing Platform項目地址: https://gitcode.com/GitHub_Trending/ja/jaeger創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考