Grafana Tempo Metrics-generator 设计解析从 Trace 到 Prometheus 指标的 Server-Side 处理管线【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo导读本篇基于 Grafana Tempo 仓库中的设计提案 docs/design-proposals/2022-01 Metrics-generator.md深入解析 Tempo 中从 Trace 生成指标的机制引入一个可选的metrics-generator组件在写入路径上与 ingester 并行消费 spans通过 service graph 与 span metrics 两类处理器将追踪数据转换为指标并经 Prometheus remote write 协议写入指标后端。读完本文你将掌握 metrics-generator 的架构定位、写入链路、处理器原理、gRPC 协议与完整配置方法并结合仓库源码理解其真实实现与默认值。仓库当前实现与设计提案相比已有明显演进如新增 host-info 处理器、Kafka 消费模式、WAL 持久化等文中将同步标注。设计提案背景该文档由 Koenraad Verheydenkvrhdn与 Mario Rodriguezmapno于 2021 年 12 月—2022 年 1 月编写最后更新于 2022-02-07。文中明确指出此功能有时被称为 server-side metrics——Grafana Agent 已具备从 Trace 生成指标的能力将这些处理器从 Agent 移入 Tempo 即服务端化。同时强调该提案描述的是初始实现部分功能被标记为 out-of-scope暂不实现不应视为完全生产就绪。一、架构设计独立组件与职责边界生成并写入指标为 Tempo 引入了全新的领域与既有功能截然不同。提案的核心决策是不把指标功能塞进任何现有组件而是新增一个专职处理指标的独立组件。这样既实现了职责的清晰划分也将指标处理器的故障半径blast radius限制在组件内部避免拖垮其他模块。设计时曾考虑过的替代方案及其被否定的原因集成进 distributor部分处理器如 service graph 处理器需要处理一个 trace 的全部 spans若放在 distributor 中要么要求 distributor 具备 trace 感知的负载均衡要么需要一个所有实例共享的外部存储。这会显著复杂化 distributor 的部署并使其偏离写入入口的核心职责。集成进 ingesteringester 本身就是非常复杂且关键的组件追加额外职责只会让它的复杂度雪上加霜。提案给出的引入 metrics-generator 之后的写入路径图│ │ Ingress │ ▼ ┌──────────────────────┐ │ │ │ Distributor │ │ │ └──────────────────────┘ 2│ │1 │ │ ┌──────────────────┘ └────────┐ │ │ ▼ ▼ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ┏━━━━━━━━━━━━━━━━━━━━━━┓ ┌──────────────────────┐ │ ┃ ┃ │ │ │ Prometheus ◀────Prometheus ────┃ Metrics-generator ┃ │ Ingester │◀───Queries──── │ Remote Write ┃ ┃ │ │ └ ─ ─ ─ ─ ─ ─ ─ ─ ┗━━━━━━━━━━━━━━━━━━━━━━┛ └──────────────────────┘ │ │ │ ▼ ┌─────────────────┐ │ │ │ Backend │ │ │ └─────────────────┘写入流经 distributor 后被分为两条一条送往 ingester负责存储与查询另一条送往 metrics-generator负责指标生成。metrics-generator 将生成的指标通过 Prometheus remote write 写入 Prometheus 兼容的数据源。与 Cortex / Loki ruler 的对比metrics-generator 在外观上与 Cortex 和 Loki 的 ruler 相似三者都是可选组件都能生成指标并 remote write。但存在一个根本性差异ruler 使用查询引擎PromQL / LogQL去查询 ingesters 和 backend再基于查询结果计算指标metrics-generator 不查询任何其他组件而是直接消费入口ingress数据流。Tempo 当时还没有查询引擎因此无法构建 Tempo ruler如果未来 Tempo 获得能力相近的查询引擎可以引入 Tempo ruler 并与 metrics-generator 集成。两者之间还有两点显著区别只能处理实时数据由于必须消费入口数据流metrics-generator 只能针对正在被写入的数据生成指标无法基于历史数据回填backfill指标。固定处理器 vs 灵活规则metrics-generator 使用固定的处理器不如用户可自定义查询的规则灵活但反过来处理器可以执行查询语言难以表达的复杂计算——例如 service graph 处理器对 trace 边的配对分析用查询语言表达会非常困难。二、组件详解Distributor 与 Metrics-generator2.1 Distributor写入入口的双写与 Best-Effort 语义Distributor 是 Tempo 写入的入口接收 span 批次并转发给 ingester启用复制时按副本策略转发。加入 metrics-generator 后distributor先写 ingester写成功后再将同一份数据推给 metrics-generator。关键语义是写入 metrics-generator 是 best-effort尽力而为——即使写 metrics-generator 失败Tempo 的写入仍然被视为成功。这是一个刻意的取舍若 ingester 写入成功而 metrics-generator 写入失败要让 distributor 回滚已写入 ingester 的数据需要一套丢弃已摄取数据的逻辑提案认为这过于复杂得不偿失。该取舍的代价是只要 metrics-generator 未能消费部分数据就会出现指标缺失或不完整。由于客户端对失败无感知它不会重发请求。因此失败的写入必须通过 distributor 上的指标暴露出来供运维告警例如distributor_metrics_generator_pushes_failures_total。在 modules/distributor/distributor.go 中可以看到 distributor 会检查MetricsGeneratorProcessors(userID)是否配置了处理器以此决定是否为该租户启用 metrics-generator 推送。2.1.1 Metrics-generator ringtrace 感知的负载均衡当集群中存在多个 metrics-generator 实例时distributor 需要跨实例负载均衡写入。负载均衡必须是 trace 感知的同一个 trace ID 的所有 spans 必须始终发往同一个实例否则 service graph 处理器无法可靠配对同一条 trace 的边。提案采用与 ingester 相同的机制基于 dskit ring由 memberlist 支撑。distributor 依据各实例持有的 token 对请求进行分片。在 modules/generator/config.go 中ring 的默认 key 为metrics-generator常量generatorRingKey metrics-generator并可通过override_ring_key覆盖。Out-of-scope超出当前范围让 metrics-generator 以复制因子 ≥2 运行。虽然 ring 本身支持但这需要额外的指标去重逻辑否则会被重复计数。初始实现仅以RF1运行——这意味着某个实例崩溃时会造成该实例负责的数据丢失。提案同时指出处理器在内存中累积的部分 trace 状态会在崩溃时丢失状态的持久化同样被列为 out-of-scope。2.1.2 gRPC 协议PushSpans与其他 Tempo 组件间通信一致distributor → metrics-generator 走 gRPCAPI 定义在 pkg/tempopb/tempo.proto 中。提案给出的服务定义如下service MetricsGenerator { rpc PushSpans(PushSpansRequest) returns (PushResponse) {}; } // Note: a PushSpansRequest should only contain spans that are relevant to the configured tenants // and processors. We can reduce the amount of data sent to the metrics-generator by trimming spans // and their metadata in the distributor. message PushSpansRequest { // Note: these are full traces. For further optimisation we should consider using a slimmer span // format containing the minimal amount of data. repeated tempopb.trace.v1.ResourceSpans batches 1; } message PushResponse { }由于 metrics-generator 直接位于写入路径上入口流量的增长会直接传导给它。为了削减从 distributor 发往 metrics-generator 的数据量distributor 只发送对已配置的处理器和租户相关的 spans例如某个处理器只依赖 spans 的子集distributor 应在发送前丢弃无关 spans这样 metrics-generator 可以以低于 ingester 的速率扩容并节省带宽与处理时间。这要求 distributor 感知 metrics-generator 中配置的租户与处理器因此这份配置必须由两个组件共享——在 modules/generator/config.go 的copyWithOverrides中可以看到处理器配置会结合 per-tenant overrides 动态生成而 distributor 侧同样依赖 overrides 判断是否推送。实现演化当前仓库中metrics-generator 已支持从Kafka消费 spansConsumeFromKafka由部署模型注入codec支持push-bytes与otlp两种解码器并支持ring_mode的partition/generator两种模式详见 modules/generator/config.go。这比提案中的纯 gRPC 直连模式更进一步。2.2 Metrics-generator 内部结构租户隔离的处理器组提案给出了 metrics-generator 的内部结构示意图Metrics-generator ┌──────────────────────────────────────────────────────────────────────────────────┐ │ │ │ 1 instance per tenant │ │ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ │ ┌──────────────┐ │ │ │ │ Metrics │ Collect metrics │ │ │ ┌────▶│ processor #1 │◀─ ─ ─ ─ ─ │ │ │ │ └──────────────┘ │ │ │ │ ┌────────┐ │ ┌──────────────┐ │ │ │ gRPC │ │ │ │ Metrics │ │ │ │ ───Spans──┼─▶│ server │─────┼────▶│ processor #2 │◀─ ─ ─ ─ ─ │ │ └────────┘ │ │ └──────────────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ └────▶ ... ◀─ ─ ─ ─ ─ │ │ │ │ │ │ │ ┌──────────────┐ ┌──────────────┐ │ ┌ ─ ─ ─ ─ ─ ─ ─ │ │ │ Metrics │ │ │ Remote write │ │ │ │ │ collector │──────▶│ client │──┼───Prometheus ────▶│ Prometheus │ │ └──────────────┘ │ └──────────────┘ │ Remote Write │ │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ └ ─ ─ ─ ─ ─ ─ ─ │ │ └──────────────────────────────────────────────────────────────────────────────────┘2.2.1 Metrics processor每租户一个处理器实例处理器运行在 metrics-generator 内部它们消费 span 批次并维护指标状态。为了租户间隔离每个租户运行独立的处理器实例并拥有各自的配置处理器应能在不重启 metrics-generator 的情况下重新配置。Out-of-scope持久化处理器状态以减少崩溃时的数据丢失。处理过程中累积的部分 trace 状态保存在内存中metrics-generator 崩溃即丢失。仓库实现与提案一一对应在 modules/generator/instance.go 中Generator内部维护instances map[string]*instance以租户 ID 为键getOrCreateInstance在收到某租户首个批次时懒创建其实例实例内的processors map[string]processor.Processor只允许同一名称的处理器同时存在一个。处理器接口定义在 modules/generator/processor/interface.gotype Processor interface { // Name returns the name of the processor. Name() string // PushSpans processes a batch of spans and updates the metrics registered in RegisterMetrics. PushSpans(ctx context.Context, req *tempopb.PushSpansRequest) // Shutdown releases any resources allocated by the processor. Shutdown(ctx context.Context) }每个实例都会启动一个watchOverrides协程每 10 秒重载一次 overrides 并 diff 处理器集合updateProcessors需要新增的处理器被 add被移除的 shutdown配置变化的被 replace见diffProcessors通过reflect.DeepEqual对比配置。这与提案运行时可重新配置的目标完全一致。租户处理器集合与配置来自MetricsGeneratorProcessorsoverrides 及copyWithOverridesmodules/generator/config.go例如metrics_generator_processor_service_graphs_histogram_buckets、metrics_generator_processor_span_metrics_dimensions等 per-tenant 覆盖项都会在此合并。实例还通过preprocessSpans做摄入时的粗过滤以metrics_ingestion_time_range_slack默认 30s见 modules/generator/config.go 的RegisterFlagsAndApplyDefaults为窗口丢弃 end time 超过该窗口或早于该窗口的 spans并分别计入tempo_metrics_generator_spans_received_total、tempo_metrics_generator_bytes_received_total与带 reason 标签的tempo_metrics_generator_spans_discarded_totalreason 包括outside_metrics_ingestion_slack、span_metrics_filtered、service_graphs_filtered、invalid_utf8。此外instance会根据LimiterTypeseries或entity选择localserieslimiter或localentitylimiter以限制单租户的活跃序列/实体数量防止高基数击穿指标后端。2.2.2 Metrics processor configuration借道 overrides 实现动态配置处理器配置必须支持运行时重载。Tempo 已经用 overrides 机制动态配置 limitsmetrics-generator 直接复用这套系统从 overrides 中读取 per-tenant 处理器配置。Out-of-scope为租户提供管理 API 让租户自行配置处理器类似 cortextool 的命令行工具。提案设想该 API 的流程如下配置写入并从 bucket 读写在实现之前必须先建立 limits 以保护 Tempo 集群与指标数据库免受过量指标或高基数冲击┌────────────┐ ┌──────────────────────┐ ┌────────────┐ │ Client │─────Manage ────▶│ Metrics-generator │────Store/fetch ────▶│ Bucket │ └────────────┘ processors └──────────────────────┘ config └────────────┘2.2.3 Metrics collector 与 Prometheus remote writemetrics collector 是 metrics-generator 内部的一个小进程按固定间隔从各处理器收集指标样本再通过 Prometheus remote write 协议写入时序数据库。其工作方式类似 Prometheus 抓取scrape某台主机因此应支持配置采集间隔与附加外部标签external labels。多租户模式下用于标识租户的X-Scope-OrgID头会被转发给 Prometheus 兼容后端对应仓库中的remote_write_add_org_id_header配置。潜在未来特性支持输出 OTLP metrics。仓库中的对应实现位于 modules/generator/registry/config.go关键默认值配置项默认值说明collection_interval15s从处理器采集指标并刷出到 remote write 的间隔stale_duration15m活跃序列超过该时长未更新则视为 stale 并从 registry 删除external_labels无附加到本实例生成的所有时序上的标签inject_tenant_id_as无将租户 ID 注入为指定标签名max_label_name_length1024超出长度的标签名被截断max_label_value_length2048超出长度的标签值被截断remote write 的落地配置见 modules/generator/storage/config.gostorage.path必须配置否则Generator.New会返回ErrUnconfigured: no metrics_generator.storage.path configured, metrics generator will be disabled、remote_writePrometheusRemoteWriteConfig列表、remote_write_flush_deadline、remote_write_add_org_id_header以及一组 Prometheus agent WAL 参数wal_segment_size、wal_compression、truncate_frequency等。值得注意的是当前实现用 Prometheus agent 风格的 WAL 在崩溃时暂存尚未远写的样本这已部分缓解了提案中处理器状态丢失的担忧——虽然处理器自身的配对状态仍是内存态但采集后的样本不再因崩溃而完全丢失。三、Metrics processors指标处理器的核心原理处理器是 metrics-generator 的核心负责把 trace 数据转换为指标。提案的初始范围描述了两个在 Grafana Agent 中已存在的处理器service graph与span metrics并要求处理器实现足够灵活便于后续追加新的处理器。3.1 Service graph服务间依赖关系的指标化服务图service graph是各服务之间相互关系的可视化表示。service graph 处理器分析 trace 数据生成描述服务间关系的指标供 Grafana 等前端绘制服务图。配对原理边处理器通过分析 trace 中的边edge构建元数据——一条边由一对具有父子关系的 spans组成其中父 span 的SpanKind为client子 span 的SpanKind为server。每条边代表一个服务对另一个服务的请求请求数量与耗时被记录为指标。由于处理器需要处理一条边的两侧它必须处理整条 trace 的所有 spans如果一条 trace 的 spans 被分散到多个实例就无法可靠配对。设计目标与 Grafana Agent 的实现保持镜像理想情况下 Tempo 导出的指标与 Agent 完全一致使 Grafana 等前端可同时兼容两者。提案定义的导出指标Metric类型标签描述traces_service_graph_request_totalCounterclient, server两个节点之间的请求总数traces_service_graph_request_failed_totalCounterclient, server两个节点之间失败的请求总数traces_service_graph_request_server_secondsHistogramclient, server从服务端视角看两节点间一次请求的耗时traces_service_graph_request_client_secondsHistogramclient, server从客户端视角看两节点间一次请求的耗时traces_service_graph_unpaired_spans_totalCounterclient, server未配对 spans 的总数traces_service_graph_dropped_spans_totalCounterclient, server被丢弃 spans 的总数可配置项success_codes被视为成功请求的状态码用于区分成功与失败请求buckets直方图使用的桶。仓库当前实现位于 modules/generator/processor/servicegraphs/servicegraphs.go指标名与提案基本一致并做了一些演进现有指标常量traces_service_graph_request_total、traces_service_graph_request_failed_total、traces_service_graph_request_server_seconds、traces_service_graph_request_client_seconds另新增traces_service_graph_request_messaging_system_seconds消息系统中间件时延直方图与traces_service_graph_connection_info相关内部指标tempo_metrics_generator_processor_service_graphs_dropped_spans、..._dropped_edges_total、..._edges唯一边总数、..._expired_edges按未匹配 span kind 标签的过期边数等边的状态管理与配对逻辑位于 modules/generator/processor/servicegraphs/storeedge.go、store.go。service graphs 的配置结构见 modules/generator/processor/servicegraphs/config.go默认值与注释如下type Config struct { Wait time.Duration yaml:wait // 等待一条边完成的时长默认 10s MaxItems int yaml:max_items // storeMap 中最多存储的边数默认 10_000 Workers int yaml:workers // 处理边的 worker 数默认 10 HistogramBuckets []float64 yaml:histogram_buckets // 时延直方图桶默认 prometheus.ExponentialBuckets(0.1, 2, 8) Dimensions []string yaml:dimensions // 附加维度标签 EnableClientServerPrefix bool yaml:enable_client_server_prefix // 维度以 client_/server_ 前缀区分 EnableMessagingSystemLatencyHistogram bool yaml:enable_messaging_system_latency_histogram PeerAttributes []string yaml:peer_attributes // 用于创建 peer 边的属性默认 [peer.service, db.name, db.system, db.system.name] SpanMultiplierKey string yaml:span_multiplier_key // 用属性值参与指标计算采样倍率 EnableTraceStateSpanMultiplier bool yaml:enable_tracestate_span_multiplier // 从 W3C tracestate (otth:...) 提取倍率 EnableVirtualNodeLabel bool yaml:enable_virtual_node_label // 为未埋点服务添加 virtual_node 标签 DatabaseNameAttributes []string yaml:database_name_attributes // 识别数据库名的属性列表 FilterPolicies []filterconfig.FilterPolicy yaml:filter_policies // 包含/排除 spans 的过滤策略 Subprocessors map[Subprocessor]bool yaml:- }其中默认HistogramBuckets prometheus.ExponentialBuckets(0.1, 2, 8)即从 0.1s 起、公比 2 的 8 个桶。Subprocessor 默认启用Request与Latency向后兼容裸service-graphs名称ConnectionInfo默认关闭、按需通过service-graphs-connection-info子名称开启。3.2 Span metricsRED 指标的聚合span metrics 处理器从 span 数据聚合RED 指标请求率 request、错误率 error、时延 duration。聚合原理对于维度的每一种唯一组合计算 spans 的总数与耗时。维度可以是服务名、操作名、span kind、状态码以及 span 中存在的任意 tag 或属性。启用的维度越多生成指标的高基数cardinality风险越高。设计目标与 OpenTelemetry Collector 的实现保持镜像。提案定义的导出指标Metric类型标签描述traces_spanmetrics_duration_secondsHistogramDimensionsspan 的耗时traces_spanmetrics_calls_totalCounterDimensionsspan 的总数可配置项dimensions生成指标中包含的标签每个维度必须与 span 的某个属性匹配buckets直方图使用的桶include/exclude过滤哪些 spans 参与 span metrics 生成例如可以只对部分服务的 spans 生成指标。仓库当前实现位于 modules/generator/processor/spanmetrics/spanmetrics.go。指标名与提案略有出入请以当前实现为准const ( metricCallsTotal traces_spanmetrics_calls_total metricDurationSeconds traces_spanmetrics_latency // 提案中的 duration_seconds 现为 latency metricSizeTotal traces_spanmetrics_size_total targetInfo traces_target_info )即当前实际导出traces_spanmetrics_calls_total、traces_spanmetrics_latency、traces_spanmetrics_size_total新增长度类指标以及traces_target_infoenable_target_info开启时将 resource 属性发布为 info 型指标。时延计算中负时延的 span 按 0 处理start end才计算差值。span metrics 的配置结构见 modules/generator/processor/spanmetrics/config.gotype Config struct { HistogramBuckets []float64 yaml:histogram_buckets // 默认 prometheus.ExponentialBuckets(0.002, 2, 14) IntrinsicDimensions IntrinsicDimensions yaml:intrinsic_dimensions // 内置维度开关 Dimensions []string yaml:dimensions // 从 span 属性生成的附加维度 DimensionMappings []sharedconfig.DimensionMappings yaml:dimension_mappings // 多属性拼接并重命名标签 EnableTargetInfo bool yaml:enable_target_info // 是否输出 traces_target_info SpanMultiplierKey string yaml:span_multiplier_key EnableTraceStateSpanMultiplier bool yaml:enable_tracestate_span_multiplier Subprocessors map[Subprocessor]bool yaml:- FilterPolicies []filterconfig.FilterPolicy yaml:filter_policies TargetInfoExcludedDimensions []string yaml:target_info_excluded_dimensions EnableInstanceLabel bool yaml:enable_instance_label // 默认 true } type IntrinsicDimensions struct { Service bool yaml:service // 默认 true SpanName bool yaml:span_name // 默认 true SpanKind bool yaml:span_kind // 默认 true StatusCode bool yaml:status_code // 默认 true StatusMessage bool yaml:status_message,omitempty // 默认 false需显式开启 }默认值要点HistogramBuckets prometheus.ExponentialBuckets(0.002, 2, 14)从 0.002s 起、公比 2 的 14 个桶内置维度service、span_name、span_kind、status_code默认开启status_message需显式开启Subprocessor 默认启用Latency、Count、Size三类EnableInstanceLabel默认 true在启用了 target_info 的前提下向所有 span metrics 序列附加 instance 标签。维度在注册为指标标签前会经过 Prometheus 标签名净化sanitize并处理与内置维度的碰撞如deployment.environment与deployment_environment都会净化为deployment_environment。相关校验逻辑见 modules/generator/validation/fields.goValidateDimensions会检测维度/映射之间净化后的标签碰撞ValidateProcessor校验处理器名称ValidateCollectionInterval要求collection_interval在 15s5m 之间ValidateIngestionTimeRangeSlack要求 slack 在 012h 之间ValidateHistogramBuckets要求桶严格递增ValidateHistogramMode校验generate_native_histograms的取值为classic/native/both。处理器家族的扩展提案仅描述了两个处理器当前仓库的SupportedProcessorsmodules/generator/validation/fields.go已扩展为 9 个名称service-graphs、service-graphs-request、service-graphs-latency、service-graphs-connection-info、span-metrics、span-metrics-count、span-metrics-latency、span-metrics-size、host-info。子名称subprocessor允许只启用某个大类下的部分指标例如service-graphs-latency只产出时延直方图host-info处理器modules/generator/processor/hostinfo用于从 resource 属性提取主机标识并输出相关指标。processor 名称常量定义在 modules/generator/processor/processor_names.go。四、配置示例从提案到当前实现提案末尾给出了 distributor、metrics-generator 与 overrides 的配置示意并注明仅是提案最终配置以文档为准。下面先完整保留提案示例再给出基于当前仓库字段核对后的更完整配置。4.1 提案中的配置示例distributor: # Toggle to enable or disable the metrics-generator ring. If disabled, the distributor should # not initialize the metrics-generator ring and does not send data to the metrics-generator. enable_metrics_generator_ring: true # Similar to the ingester_client, configure the client used by the distributor metrics_generator_client: # Same settings as ingester_client metrics_generator: collection_interval: 15s external_labels: some_static_label: foo # Global settings for the metrics processors processor: service_graphs: histogram_buckets: [0.1, 0.2, 0.5, 1, 2, 5, 10] span_metrics: dimensions: - http.method - http.target # Configure remote write target remote_write: enabled: true client: # prometheus.RemoteWriteConfig url: http://prometheus:9090/prometheus/api/v1/write4.2 提案中的 overrides 示例overrides: 1: metrics_generator_processors: - service-graphs - span-metrics 2: metrics_generator_processors: - service-graphs4.3 对照当前仓库字段的完整配置说明结合 modules/generator/config.go、modules/generator/registry/config.go、modules/generator/storage/config.go 与各处理器 config当前可用的 metrics_generator 配置段含默认值标注大致如下metrics_generator: # 处理器配置全局默认值可被 per-tenant overrides 覆盖 processor: service_graphs: wait: 10s # 等待一条边完成的时长默认 10s max_items: 10000 # 内存中最多缓存的边数默认 10000 workers: 10 # 处理边的 worker 数默认 10 histogram_buckets: [0.1, 0.2, 0.5, 1, 2, 5, 10] # 默认 ExponentialBuckets(0.1, 2, 8) dimensions: [] # 附加维度 enable_client_server_prefix: false enable_messaging_system_latency_histogram: false peer_attributes: [peer.service, db.name, db.system, db.system.name] enable_virtual_node_label: false filter_policies: [] # 包含/排除 spans 的策略 span_metrics: histogram_buckets: [0.002, 0.004, 0.008, 0.016, 0.032, 0.064, 0.128, 0.256, 0.512, 1.024, 2.048, 4.096, 8.192, 16.384] intrinsic_dimensions: service: true span_name: true span_kind: true status_code: true status_message: false # 默认关闭 dimensions: [http.method, http.target] dimension_mappings: [] enable_target_info: false enable_instance_label: true target_info_excluded_dimensions: [] filter_policies: [] host_info: host_identifiers: [] # 至少配置一个例如 [host.name] metric_name: traces_host_info # 指标采集与远写 registry: collection_interval: 15s # 默认 15s合法范围 15s5m stale_duration: 15m # 默认 15m external_labels: some_static_label: foo max_label_name_length: 1024 max_label_value_length: 2048 storage: path: /var/tempo/metrics-generator # 必填不配置则 generator 被禁用 remote_write: - url: http://prometheus:9090/prometheus/api/v1/write # 其余字段为 Prometheus RemoteWriteConfig remote_write_add_org_id_header: true # 多租户时转发 X-Scope-OrgID metrics_ingestion_time_range_slack: 30s # 默认 30s合法范围 012h limiter_type: series # series 或 entity ring_mode: partition # partition 或 generator codec: push-bytes # push-bytes 或 otlp ingest_concurrency: 16 instance_id: hostname # 默认取主机名注意collection_interval的有效范围被校验为 15s5mmodules/generator/validation/fields.go 的ValidateCollectionInterval小于 15s 的配置会被拒绝metrics_ingestion_time_range_slack的有效范围是 012h。storage.path是硬性前提——modules/generator/generator.go 的New中若cfg.Storage.Path 直接返回ErrUnconfiguredmetrics-generator 将被禁用。4.4 运行与验证提示从仓库根目录运行单元测试可快速验证两个处理器的行为例如go test ./modules/generator/...重点测试文件包括 modules/generator/processor/servicegraphs/servicegraphs_test.go、modules/generator/processor/spanmetrics/spanmetrics_test.go 与 modules/generator/instance_test.goservice graphs 处理器使用 modules/generator/processor/servicegraphs/testdata 下的 JSON trace 作为配对、过期边、虚拟节点、失败请求等场景的测试输入可作为理解边配对逻辑的样例集成测试中与 metrics-generator 相关的配置样例可参考 integration/metrics-generator/config-remote-write.yaml 等文件指标生成完成后可在 Prometheus 中通过traces_service_graph_request_total、traces_spanmetrics_calls_total、traces_spanmetrics_latency等指标验证结果并在 Grafana 中绘制服务图service graph与 RED 面板。五、总结与设计边界metrics-generator 的设计提案确立了几条贯穿至今的原则独立组件、职责分离不并入 distributor 或 ingester将指标领域的爆炸半径隔离在独立组件内直连写入路径不查询任何其他组件直接消费入口流因此只能生成实时指标的无法回填best-effort 双写distributor 先写 ingester 再尽力推给 metrics-generator失败不影响 Trace 写入成功语义但需通过distributor_metrics_generator_pushes_failures_total等指标监控数据缺口trace 感知分片基于 dskit ring 实现同 trace 同实例的一致性路由初始 RF1多副本与去重留待后续固定处理器 动态配置处理器为固定集合service graph / span metrics / host-info通过 overrides 实现 per-tenant、运行时热重载的配置。从仓库实现看提案中的两个处理器均已落地并扩展出子处理器与 host-info指标名大体沿用提案span metrics 的时延指标名从traces_spanmetrics_duration_seconds演化为traces_spanmetrics_latency并新增 size 与 target_info 指标存储侧通过 Prometheus agent 风格 WAL 增加了崩溃场景下已采集样本的持久化保障并新增了 Kafka 消费与 ring 的 partition/generator 双模式这些都是在原设计骨架之上的自然演进。对于需要从 Trace 得到可观测指标的部署场景可按本文第四节的配置段启用 metrics-generator并通过 overrides 按租户精细化控制处理器组合进而在 Grafana 中同时获得服务图与 RED 面板两类视图。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考