Grafana Tempo 監(jiān)控 MIXIN 完全指南從 jsonnet 構(gòu)建到儀表盤、告警與 Runbook 實戰(zhàn)【免費下載鏈接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.項目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo本文以倉庫operations/tempo-mixin目錄為骨架系統(tǒng)講解 Grafana Tempo 官方監(jiān)控方案的組成、構(gòu)建流程、可調(diào)參數(shù)與運維實踐。讀完你將掌握如何用make all一鍵生成 Grafana 儀表盤與 Prometheus 告警/記錄規(guī)則理解config.libsonnet中每一項閾值與選擇器的含義并學(xué)會對照 Runbook 對分布式追蹤集群進行故障排查。一、tempo-mixin 是什么tempo-mixin是 Grafana Tempo 官方的Jsonnet 監(jiān)控混入mixin集合。它用 Jsonnet 語言描述監(jiān)控一個 Tempo 集群需要的一切——即 Grafana 儀表盤dashboards、Prometheus 告警規(guī)則alerts和記錄規(guī)則rules并通過 jsonnet-bundler 引入 grafana-builder 與 mixin-utils 等公共庫完成渲染。構(gòu)建后的產(chǎn)物統(tǒng)一放在operations/tempo-mixin-compiled目錄可以直接導(dǎo)入 Prometheus 和 Grafana 使用。倉庫為此提供兩種用法直接使用編譯產(chǎn)物從tempo-mixin-compiled/dashboards/、alerts.yaml、rules.yaml原樣導(dǎo)入自行構(gòu)建按需修改 mixin 源碼如調(diào)整閾值、Job 名、命名空間再重新生成產(chǎn)物以便融入自己的變更。整個 mixin 的裝配入口是operations/tempo-mixin/mixin.libsonnet它把配置、儀表盤、告警、規(guī)則四部分疊加在一起(import config.libsonnet) (import dashboards.libsonnet) (import alerts.libsonnet) (import rules.libsonnet)而dashboards.jsonnet、alerts.jsonnet、rules.jsonnet三個入口文件分別負責把上述內(nèi)容渲染成 JSON 儀表盤文件與 YAML 規(guī)則文件。二、構(gòu)建環(huán)境準備根據(jù)operations/tempo-mixin/README.md構(gòu)建需要兩個工具jsonnetJsonnet 語言解釋器jsonnet-bundlerjbJsonnet 包管理工具用于拉取依賴庫。在 macOS 上安裝方式如下原文檔原文brew install jsonnet brew install jsonnet-bundler go install github.com/jsonnet-bundler/jsonnet-bundler/cmd/jbv0.6.0在 Linux 環(huán)境下可從發(fā)行版軟件源安裝jsonnetjb同樣可通過go install安裝。依賴聲明見operations/tempo-mixin/jsonnetfile.json當前 mixin 依賴grafana/jsonnet-libs倉庫中的grafana-builder與mixin-utils兩個子目錄版本均為master分支jsonnetfile.lock.json鎖定了具體的提交。三、構(gòu)建流程make all 到底做了什么在operations/tempo-mixin目錄下執(zhí)行make all即可重新生成全部儀表盤、告警和規(guī)則。原文檔給出了完整的執(zhí)行輸出? make all jb install jsonnet -J vendor -S dashboards.jsonnet -m ../tempo-mixin-compiled/dashboards/ ../tempo-mixin-compiled/dashboards/tempo-backendwork.json ../tempo-mixin-compiled/dashboards/tempo-block-builder.json ../tempo-mixin-compiled/dashboards/tempo-operational.json ../tempo-mixin-compiled/dashboards/tempo-reads.json ../tempo-mixin-compiled/dashboards/tempo-resources.json ../tempo-mixin-compiled/dashboards/tempo-rollout-progress.json ../tempo-mixin-compiled/dashboards/tempo-tenants.json ../tempo-mixin-compiled/dashboards/tempo-writes.json jsonnet -J vendor -S alerts.jsonnet ../tempo-mixin-compiled/alerts.yaml jsonnet -J vendor -S rules.jsonnet ../tempo-mixin-compiled/rules.yaml對照operations/tempo-mixin/Makefilemake all實際依次執(zhí)行四個目標目標命令作用installjb install按jsonnetfile.json拉取依賴到vendor/目錄dashboardsjsonnet -J vendor -S dashboards.jsonnet -m ../tempo-mixin-compiled/dashboards/渲染全部儀表盤 JSON 到tempo-mixin-compiled/dashboards/alertsjsonnet -J vendor -S alerts.jsonnet ../tempo-mixin-compiled/alerts.yaml渲染告警規(guī)則到alerts.yamlrulesjsonnet -J vendor -S rules.jsonnet ../tempo-mixin-compiled/rules.yaml渲染記錄規(guī)則到rules.yaml命令參數(shù)說明-J vendor在vendor目錄中查找 jsonnet 庫導(dǎo)入路徑-S以字符串方式輸出string output使 YAML/JSON 內(nèi)容保持純文本避免被轉(zhuǎn)義-m 目錄多文件輸出模式按字典鍵名生成多個文件。Makefile 還提供兩個輔助目標check重新構(gòu)建后執(zhí)行g(shù)it diff --exit-code -- ../tempo-mixin-compiled/若產(chǎn)物與倉庫中已提交的編譯結(jié)果不一致則構(gòu)建失敗——適合 CI 中校驗源碼與產(chǎn)物同步fmt對目錄下所有*.libsonnet與*.jsonnet文件運行jsonnetfmt -i統(tǒng)一代碼格式。四、核心配置 config.libsonnet 逐項解讀operations/tempo-mixin/config.libsonnet是 mixin 的全部可調(diào)參數(shù)所在分為三組組件 Job 名映射、告警閾值、標簽選擇器與聚合配置。4.1 組件 Job 名映射jobsTempo 的每個組件在 Kubernetes 部署中的 Prometheusjob標簽?zāi)J值如下配置鍵默認值對應(yīng)組件gatewaycortex-gw(-internal)?網(wǎng)關(guān)正則query_frontendquery-frontend查詢前端querierquerier查詢器metrics_generatormetrics-generator指標生成器distributordistributor分發(fā)器compactorcompactor壓縮器block_builderblock-builder數(shù)據(jù)塊構(gòu)建器Kafka 消費backend_schedulerbackend-scheduler后端調(diào)度器backend_workerbackend-worker后端工作器memcachedmemcachedMemcached 緩存層live_storelive-store實時存儲live_store_zoneslive-store.*實時存儲按可用區(qū)正則若你的部署使用了不同的job標簽例如通過 Helm 自定義只需覆蓋這些鍵即可讓全部告警和儀表盤自動適配。4.2 告警閾值alerts原文檔未展開、但源碼中完整定義的所有閾值如下可直接在_config.alerts中覆蓋配置鍵默認值用途compactions_per_hour_failed2每小時壓縮失敗次數(shù)告警閾值flushes_per_hour_failed2每小時刷新失敗次數(shù)閾值polls_per_hour_failed2每小時 blocklist 輪詢失敗次數(shù)閾值user_configurable_overrides_polls_per_hour_failed5每小時用戶可配置 Overrides 重載失敗閾值max_tenant_index_age_seconds600tenant index 最大允許年齡秒p99_request_threshold_seconds3P99 請求延遲告警閾值秒p99_request_exclude_regexmetrics\|/frontend.Frontend/Process\|debug_pprofP99 統(tǒng)計中排除的路由正則outstanding_blocks_warning100待壓縮數(shù)據(jù)塊數(shù)告警warningoutstanding_blocks_critical250待壓縮數(shù)據(jù)塊數(shù)告警criticalpartition_lag_critical_seconds90015 分鐘指標生成器 Kafka 分區(qū)滯后 critical 閾值block_builder_partition_lag_warning_seconds200約 3.3 分鐘block-builder 分區(qū)滯后 warning 閾值block_builder_partition_lag_critical_seconds3005 分鐘block-builder 分區(qū)滯后 critical 閾值backend_scheduler_jobs_failure_rate0.05調(diào)度器任務(wù)失敗率閾值5%backend_scheduler_jobs_retry_count_per_minute20每分鐘任務(wù)重試次數(shù)閾值backend_scheduler_compaction_tenant_empty_job_count_per_minute10每分鐘空任務(wù)數(shù)閾值backend_scheduler_bad_jobs_count_per_minute0壞任務(wù)數(shù)閾值有任何壞任務(wù)即告警backend_worker_call_retries_count_per_minute5工作器每分鐘調(diào)用調(diào)度器重試次數(shù)閾值vulture_error_rate_threshold0.1vulture 校驗錯誤率閾值10%distributor_kafka_produce_failure_ratio0.001分發(fā)器寫 Kafka 失敗率閾值0.1%作為快速前導(dǎo)信號live_store_partition_lag_warning_seconds200live-store 分區(qū)滯后 warning 閾值live_store_partition_lag_critical_seconds120020 分鐘live-store 單成員滯后 critical 閾值live_store_all_members_lag_seconds3005 分鐘live-store 全體成員同時滯后閾值對應(yīng)讀路徑部分中斷4.3 標簽選擇器與聚合selectors / group_bymixin 支持多集群、多命名空間、多租戶的監(jiān)控隔離通過一組標簽列表控制per_cluster_label: cluster、namespace_selector_separator: /cluster_selectors[cluster, namespace]用于按集群聚合的告警job_selectors[cluster, namespace, job]用于按組件聚合tenant_selectors[cluster, namespace, tenant]用于按租戶聚合對應(yīng)的group_prefix_*下劃線連接與group_by_*逗號連接分別用于 PromQL 表達式中的by (...)子句。此外http_api_prefix默認空字符串用于適配網(wǎng)關(guān)在反代后追加的 API 路徑前綴namespace默認.*即默認匹配所有命名空間可通過覆蓋該鍵將監(jiān)控范圍限定到特定命名空間如tempo-prod。4.4 記錄規(guī)則時間窗recording_rules_range_interval: 1m控制直方圖記錄規(guī)則的聚合區(qū)間。源碼注釋明確提醒該值至少應(yīng)為抓取間隔scrape interval的兩倍建議設(shè)為抓取間隔的四倍否則記錄規(guī)則可能輸出空數(shù)據(jù)——這是調(diào)節(jié) scrape 頻率后最容易踩的坑。五、構(gòu)建產(chǎn)物與使用方式5.1 儀表盤dashboardsmake all后在operations/tempo-mixin-compiled/dashboards/下生成 10 個 Grafana 儀表盤文件名關(guān)注內(nèi)容tempo-backendwork.json后端調(diào)度器/工作器任務(wù)執(zhí)行情況tempo-block-builder.jsonblock-builder 消費與構(gòu)建tempo-livestore.jsonlive-store 實時存儲分區(qū)與滯后tempo-operational.json運維總覽壓縮、輪詢等tempo-reads.json讀路徑網(wǎng)關(guān)/查詢前端/查詢器/live-store 的 QPS、延遲tempo-resources.json資源使用CPU、內(nèi)存等tempo-rollout-progress.json滾動發(fā)布進度tempo-service-graph.jsonService Graph服務(wù)間調(diào)用拓撲tempo-tenants.json按租戶維度的使用與限流情況tempo-writes.json寫路徑接收、Kafka、壓縮寫入儀表盤的結(jié)構(gòu)定義在operations/tempo-mixin/dashboards.libsonnet與dashboards/下的各.libsonnet文件。以dashboards/tempo-reads.libsonnet為例可以看到Gateway → Query Frontend → Querier → Livestore分行的面板編排每行包含 QPS 與 Latency 面板且查詢語句按組件 Job 名與路由前綴route~api_.*過濾例如 querier 行的延遲面板為tempo_request_duration_seconds{job~querier,route~querier_api_.*}livestore 行還會展示tempo_live_store_complete_queue_length待完成隊列長度、tempo_live_store_blocks_completed_total已完成數(shù)據(jù)塊速率以及按分區(qū)/消費組拆分的 Kafka 滯后面板。這些.json文件可直接在 Grafana 中通過Import dashboard上傳或在配置了 provisioning 時放入儀表盤目錄。5.2 告警規(guī)則alerts.yaml構(gòu)建出的operations/tempo-mixin-compiled/alerts.yaml是標準的 Prometheus 規(guī)則文件告警組名為tempo_alerts。原文檔指出告警清單見對應(yīng)文件——編譯產(chǎn)物展開后的 32 條告警及其觸發(fā)條件、嚴重級別與for時長如下表達式均已把cluster/namespace等占位符替換為實際選擇器一組件健康類| 告警 | 嚴重級別 | for | 觸發(fā)條件要點 | | --- | --- | --- | --- | |TempoDistributorUnhealthy| warning | 15m |tempo_ring_members{stateUnhealthy,namedistributor}大于 0 | |TempoLiveStoreUnhealthy| critical | 15m | ring 中 live-store 有不健康成員 | |TempoMetricsGeneratorUnhealthy| critical | 15m | ring 中 metrics-generator 有不健康成員 | |TempoMemcachedErrorsElevated| warning | 10m | memcached 5xx 占比超過 20% |二存儲/blocklist 類| 告警 | 嚴重級別 | for | 觸發(fā)條件要點 | | --- | --- | --- | --- | |TempoCompactionsFailing| critical | 1h | 1 小時內(nèi)壓縮失敗 2 且最近 5 分鐘仍有失敗 | |TempoPollsFailing| critical | — | 1 小時內(nèi) blocklist 輪詢失敗 2 且 5 分鐘內(nèi)仍失敗 | |TempoTenantIndexFailures| critical | — | 1 小時內(nèi) tenant index 錯誤 2 且 5 分鐘內(nèi)仍錯誤 | |TempoNoTenantIndexBuilders| critical | 5m | 某租戶無 index 構(gòu)建者且 blocklist 非空 | |TempoTenantIndexTooOld| critical | 5m | tenant index 年齡超過 600 秒 | |TempoCompactionTooManyOutstandingBlocks| warning/critical | 6h/24h | 每后端工作器待壓縮塊數(shù) 100/250 | |TempoBadOverrides| critical | 15m |tempo_runtime_config_last_reload_successful 0| |TempoUserConfigurableOverridesReloadFailing| critical | 15m | 1 小時重載失敗 5 且 5 分鐘內(nèi)仍失敗 |三Kafka 分區(qū)滯后類| 告警 | 嚴重級別 | for | 觸發(fā)條件要點 | | --- | --- | --- | --- | |TempoMetricsGeneratorPartitionLagCritical| critical | 5m | metrics-generator 分區(qū)滯后 900s | |TempoBlockBuilderPartitionLagWarning| warning | 5m | block-builder 6 分鐘平均滯后 200s | |TempoBlockBuilderPartitionLagCritical| critical | 5m | block-builder 6 分鐘平均滯后 300s | |TempoLiveStorePartitionLagWarning| warning | 5m | live-store 分區(qū)滯后 200s | |TempoLiveStoreSingleMemberLagHigh| critical | 5m | 單個 live-store 成員滯后 1200s | |TempoLiveStoreAllMembersLagging| critical | 2m | 某分區(qū)全部 live-store 成員滯后 300s讀路徑部分中斷 | |TempoBlockBuildersPartitionsMismatch| critical | 10m | 超過一個分區(qū)無 block-builder 認領(lǐng) | |TempoLiveStoresPartitionsUnowned| critical | 10m | 存在無 live-store 認領(lǐng)的活躍/非活躍分區(qū) | |TempoLiveStoreZoneSeverelyDegraded| critical | 10m | 某可用區(qū)持有分區(qū)數(shù)比其他區(qū)少 60% 以上 |四調(diào)度器/工作器類| 告警 | 嚴重級別 | for | 觸發(fā)條件要點 | | --- | --- | --- | --- | |TempoBackendSchedulerJobsFailureRateHigh| critical | 10m | 任務(wù)失敗率 5% | |TempoBackendSchedulerRetryRateHigh| warning | 10m | 每分鐘重試任務(wù) 20 | |TempoBackendSchedulerCompactionEmptyJobRateHigh| warning | 10m | 每分鐘空任務(wù) 10 | |TempoBackendWorkerBadJobsRateHigh| warning | 10m | 每分鐘壞任務(wù) 0 | |TempoBackendWorkerCallRetriesHigh| warning | 10m | 每分鐘調(diào)用調(diào)度器重試 5 |五寫路徑/指標生成器/vulture 類| 告警 | 嚴重級別 | for | 觸發(fā)條件要點 | | --- | --- | --- | --- | |TempoDistributorKafkaProduceFailing| critical | 5m | 分發(fā)器寫 Kafka 失敗率 0.1%排除cancelled-before-producing原因并要求產(chǎn)生速率非零 | |TempoDistributorUsageTrackerErrors| critical | 30m | 租戶用量追蹤報錯 | |TempoMetricsGeneratorProcessorUpdatesFailing| critical | 15m | 處理器動態(tài)更新失敗 | |TempoMetricsGeneratorServiceGraphsDroppingSpans| warning | 15m | service graph 丟棄 span 占比 0.5% | |TempoMetricsGeneratorCollectionsFailing| critical | 5m | 指標收集失敗次數(shù) 2 | |TempoVultureHighErrorRate| critical | 5m | vulture 校驗錯誤率 10% |一個值得注意的實現(xiàn)細節(jié)是TempoDistributorKafkaProduceFailing它被設(shè)計為寫路徑問題的快速前導(dǎo)指標。由于失敗率可能很小但持續(xù)存在等到錯誤傳播到cortex-gw觸發(fā) SLO burn-rate 告警可能要數(shù)小時而從生產(chǎn)者側(cè)度量幾分鐘內(nèi)就能發(fā)現(xiàn)。表達式末尾的... and sum by (...) (rate(tempo_distributor_produce_records_total[5m])) 0守衛(wèi)是為了避免分母為零時 PromQL 求值為Inf導(dǎo)致無意義告警。tempo_distributor_produce_failures_total攜帶的reason標簽由pkg/ingest/writer_client.go中的produceErrReason設(shè)置取值包括timeout、buffer-full、record-too-large、canceled、other其中cancelled-before-producing屬于調(diào)用方取消、被顯式排除在告警表達式之外。5.3 記錄規(guī)則rules.yamloperations/tempo-mixin-compiled/rules.yaml對應(yīng)tempo_rules組由operations/tempo-mixin/rules.libsonnet通過 mixin-utils 的histogramRules自動生成。它針對tempo_request_duration_seconds直方圖預(yù)聚合了 6 條記錄規(guī)則按(cluster, namespace, job, route)維度聚合record: cluster_namespace_job_route:tempo_request_duration_seconds:99quantile record: cluster_namespace_job_route:tempo_request_duration_seconds:50quantile record: cluster_namespace_job_route:tempo_request_duration_seconds:avg record: cluster_namespace_job_route:tempo_request_duration_seconds_bucket:sum_rate record: cluster_namespace_job_route:tempo_request_duration_seconds_sum:sum_rate record: cluster_namespace_job_route:tempo_request_duration_seconds_count:sum_rate例如 99 分位規(guī)則的具體表達式為histogram_quantile(0.99, sum(rate(tempo_request_duration_seconds_bucket[1m])) by (le, cluster, namespace, job, route))預(yù)聚合的價值在于儀表盤直接引用這些低基數(shù)序列避免每個面板都重復(fù)執(zhí)行高開銷的直方圖分位數(shù)計算同時保證多個面板對P99 延遲的統(tǒng)計口徑完全一致。六、Runbook告警觸發(fā)后怎么處理operations/tempo-mixin/runbook.md是每條告警配套的排障手冊與告警文件一一對應(yīng)告警注解中的runbook_url即指向該文件的錨點。以下提煉其中最關(guān)鍵的幾類問題。6.1 查詢追蹤失敗Trace Lookup Failures當查詢報錯queue doesnt have room for xyz jobs時說明數(shù)據(jù)塊數(shù)量超過了查詢器并行檢查的能力。判斷公式為(blocklist 長度 / 查詢器數(shù)量) 查詢器隊列深度 queue_depthqueue_depth 在查詢器配置中設(shè)置默認 10000storage: trace: pool: queue_depth: xyz # 默認 10000處置方向增加查詢器數(shù)量調(diào)大隊列深度調(diào)整壓縮策略減少數(shù)據(jù)塊總數(shù)。快速檢查指標tempodb_blocklist_length、count(tempo_build_info{containerquerier})日志{containerquerier} | queue doesnt have room for6.2 組件不健康Distributor / LiveStore / MetricsGenerator Unhealthy這些告警通常由非優(yōu)雅終止如 Pod 被 OOM-Kill留下的殘留 ring 成員觸發(fā)。分發(fā)器會在2 * distributor.ring.heartbeat-timeout后自動遺忘不健康條目默認 5 分鐘超時對應(yīng) 10 分鐘自動清理小于告警 15 分鐘的for窗口因此通常無需人工干預(yù)。若需立即處理可訪問對應(yīng) ring 頁面如/distributor/ring點擊 Forget 按鈕移除。相關(guān)的快速檢查指標為tempo_ring_members{stateUnhealthy, name組件}。6.3 壓縮失敗TempoCompactionsFailing最常見原因是壓縮超大 trace 導(dǎo)致 OOM。處置思路將內(nèi)存上限提升到足以越過該 trace且需一直保持到該 trace 超出保留期被刪除否則可能反復(fù) OOM同時復(fù)查并調(diào)低攝取限制無法解決的壞塊可手動刪除。在當前 backend-scheduler/backend-worker 架構(gòu)下調(diào)度器暴露積壓指標tempodb_compaction_outstanding_blocks工作器負責實際壓縮排查時應(yīng)結(jié)合調(diào)度器的隊列深度指標與工作器的資源/日志。6.4 輪詢問題Polling Issues 系列輪詢失敗意味著組件對后端的認知逐漸過期查詢器會開始對已存在的數(shù)據(jù)返回 404后端工作器會嘗試壓縮不存在的塊。間歇性失敗無需關(guān)注持續(xù)性失敗必須處理若后端不可用導(dǎo)致輪詢無法修復(fù)讀路徑將開始失敗而寫路徑正常需提前告知用戶。關(guān)鍵認知是tenant index 是按租戶獨立構(gòu)建的問題可能只影響個別租戶。tempodb_blocklist_tenant_index_builder、tempodb_blocklist_tenant_index_age_seconds、tempodb_blocklist_tenant_index_errors_total都是按租戶打標的指標。最省事的杠桿是刪除過期的 tenant index 文件位于對象存儲的/tenant/index.json.gz所有組件會自動回退到桶掃描bucket listing。兩種日志的含義不同failed to pull bucket index for tenant. falling back to polling系統(tǒng)已回退處于穩(wěn)定態(tài)只需查日志定位根因failed to write tenant indexindex 未在更新需要更直接的干預(yù)。對TempoNoTenantIndexBuilders優(yōu)先手段是提高構(gòu)建者數(shù)量storage: trace: blocklist_poll_tenant_index_builders: 2 # 增大此值或刪除未更新的 index 文件強制回退掃描。6.5 待壓縮塊積壓TempoCompactionTooManyOutstandingBlocks壓縮瓶頸通常是 CPU因此增加后端工作器是最有效的措施。擴容后觀察tempodb_compaction_outstanding_blocks是否開始下降由于塊數(shù)量升高還需復(fù)查隊列相關(guān)配置避免觸發(fā)前文的查詢失敗。6.6 Kafka 分區(qū)滯后TempoPartitionLag 系列指標生成器滯后給消費組增加實例block-builder 滯后擴實例對齊 live-store 分區(qū)或縮短 cycle timelive-store 單成員滯后若 Pod 剛重啟可能是重放中節(jié)點過載會拖慢重放屬部分自愈若未重啟則可能真的卡住可重啟該 Pod或檢查單分區(qū) leader 切換等 Kafka 側(cè)問題live-store 全體成員滯后意味著沒有任何可用區(qū)能服務(wù)該分區(qū)屬于讀路徑部分中斷需檢查是否發(fā)生同步滾動重啟、節(jié)點過度調(diào)度或 Kafka broker 問題。6.7 寫路徑快速前導(dǎo)信號TempoDistributorKafkaProduceFailing按reason標簽拆分失敗率定位故障模式timeout指向 Kafka broker 健康buffer-full指向客戶端緩沖打滿通常是下游變慢record-too-large指向異常租戶發(fā)送超大批次canceled按源碼注釋不應(yīng)發(fā)生需立即調(diào)查。同時用tempo_distributor_buffered_produce_bytes / tempo_distributor_buffered_produce_bytes_limit觀察緩沖占用。七、自定義與維護建議改閾值覆蓋config.libsonnet的_config.alerts對應(yīng)鍵例如把outstanding_blocks_warning調(diào)到 150改組件名覆蓋_config.jobs中的正則適配非默認的job標簽限定范圍覆蓋_config.namespace如tempo-prod縮小告警與儀表盤的作用域格式化與 CI提交前運行make fmt統(tǒng)一格式在 CI 中執(zhí)行make check校驗編譯產(chǎn)物與源碼一致避免改了源碼忘更新產(chǎn)物產(chǎn)物再分發(fā)operations/tempo-mixin-compiled/下的alerts.yaml、rules.yaml可直接由 Prometheus Operator 的PrometheusRuleCRD 引用或作為靜態(tài)規(guī)則文件掛載10 個儀表盤 JSON 可通過 Grafana provisioning 批量導(dǎo)入。八、總結(jié)tempo-mixin將 Grafana Tempo 的監(jiān)控最佳實踐沉淀為可版本化、可參數(shù)化的 Jsonnet 代碼config.libsonnet集中管理全部閾值與選擇器alerts.libsonnet定義了覆蓋環(huán)成員、blocklist/索引、Kafka 滯后、調(diào)度器、寫路徑與指標生成器的 32 條告警rules.libsonnet提供延遲直方圖預(yù)聚合dashboards.libsonnet按讀/寫/資源/租戶等維度組織 10 個儀表盤而runbook.md為每條告警配套了從公式判斷到快速檢查命令的完整排障路徑。無論是直接使用tempo-mixin-compiled產(chǎn)物快速接入監(jiān)控還是 fork 后定制自己的閾值與組件映射這份 mixin 都是運維 Tempo 集群最值得依賴的起點?！久赓M下載鏈接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.項目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考