资讯动态

Grafana Tempo 内嵌 OpenTelemetry Collector Service:内部遥测指标与 Feature Gates 深度解析

发布时间:2026/9/20 1:40:49 来源:尧图企业网站定制
后端可观测性链路追踪【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址https://gitcode.com/GitHub_Trending/tempo1/tempo点击查看免费下载Grafana Tempo 是一个面向高吞吐、低依赖场景的分布式链路追踪后端其go.mod中以go.opentelemetry.io/collector/service v0.153.0见 go.mod引入了 OpenTelemetry Collector 的 service 模块。本文以 Tempo 仓库中 vendor 的 service/documentation.md 为核心系统梳理该模块对外暴露的内部遥测Internal Telemetry指标清单、稳定性级别以及四个 Feature Gates 的启用方式与版本边界并结合仓库内 vendor 源码给出实现级佐证。读完本文你将掌握如何在 Prometheus 中采集、解读otelcol_*系列指标以及如何通过--feature-gates开关控制 Collector service 的新特性行为。一、什么是 Collector Service 模块为什么它与 Tempo 相关OpenTelemetry Collector 的service包是整个 Collector 的运行时骨架它负责加载配置、构建 receiver → processor → exporter 组成的 pipeline 图、启动与关闭所有组件并为这些组件提供统一的生命周期管理和内部遥测。在 Tempo 仓库中该模块以 vendor 依赖的形式存在vendor/go.opentelemetry.io/collector/service并配套service/hostcapabilities、receiver/otlpreceiver同为 v0.153.0见 go.mod等子模块为 Tempo 的 OTLP 数据接入链路提供支撑。documentation.md由 mdatagen 工具从 metadata.yaml 自动生成文件头部标注 Code generated by mdatagen. DO NOT EDIT.因此本文所述指标与 Feature Gates 的源头实际是 metadata.yaml其内容与 documentation.md 完全一致、一一对应。二、内部遥测指标总览service 模块共暴露 12 个指标documentation.md 与 metadata.yaml 逐一对应可归为两大类管道流量指标Development 稳定性otelcol.*.consumed.items/otelcol.*.produced.items用于衡量数据在 receiver、processor、exporter、connector 之间的流转量进程级指标Alpha 稳定性otelcol_process_*用于描述 Collector 进程自身的 CPU、内存与运行时长。所有指标的底层实现由 mdatagen 生成在 internal/metadata/generated_telemetry.go 的TelemetryBuilder中它基于settings.MeterProvider.Meter(go.opentelemetry.io/collector/service)创建 Meter将每个指标映射为对应的 OpenTelemetry 计量 Instrument如metric.Int64Counter、metric.Float64ObservableCounter、metric.Int64ObservableGauge。2.1 管道流量指标Development 稳定性这 8 个指标全部为Sum类型、Int值、单调递增Monotonic单位均为{item}稳定性均为Developmentotelcol.connector.consumed.items—— 传递给 connector 的数据项数量。UnitMetric TypeValue TypeMonotonicStability{item}SumInttrueDevelopmentotelcol.connector.produced.items—— connector 发出的数据项数量。UnitMetric TypeValue TypeMonotonicStability{item}SumInttrueDevelopmentotelcol.exporter.consumed.items—— 传递给 exporter 的数据项数量。UnitMetric TypeValue TypeMonotonicStability{item}SumInttrueDevelopmentotelcol.processor.consumed.items—— 传递给 processor 的数据项数量。UnitMetric TypeValue TypeMonotonicStability{item}SumInttrueDevelopmentotelcol.processor.produced.items—— processor 发出的数据项数量。UnitMetric TypeValue TypeMonotonicStability{item}SumInttrueDevelopmentotelcol.receiver.produced.items—— receiver 发出的数据项数量。UnitMetric TypeValue TypeMonotonicStability{item}SumInttrueDevelopment说明metadata.yaml中还定义了*.consumed.size与*.produced.size四个尺寸指标基于ProtoMarshaler.Sizer估算的数据大小默认enabled: false且仅在 telemetry 级别为 detailed 时才会被 metricviews 保留因此未列入 documentation.md 的正式公开清单。从源码看这类指标由 internal/obsconsumer 包在 pipeline 图各节点之间注入观测消费者observability consumer实现计数例如 obsconsumer/traces.go 的ConsumeTraces在调用下游ConsumeTraces之前通过defer记录ItemCounter.Add(ctx, int64(itemCount), *attrs)并区分成功withSuccessAttrs、下游拒绝withRefusedAttrs与失败withFailureAttrs三类属性同包中的 logs.go、metrics.go、profiles.go 对 Logs、Metrics、Profiles 信号采用同样的模式。计数发生在数据被下游消费可能被修改之前确保数值反映的是进入节点的真实量。obsconsumer的计数器通过 internal/obsconsumer/telemetry.go 中的Settings注入ItemCounter metric.Int64Counter、SizeCounter metric.Int64Counter。2.2 进程级指标Alpha 稳定性以下 6 个指标描述 Collector 进程自身的资源占用全部为异步async指标由 internal/proctelemetry/process_telemetry.go 实现RegisterProcessMetrics通过 gopsutil 的process.NewProcessWithContext获取当前进程句柄支持用WithHostProc覆盖 Linux 的/proc路径然后注册 6 个 observable 回调。otelcol_process_cpu_seconds—— 进程 CPU 用户态与系统态时间总计秒。UnitMetric TypeValue TypeMonotonicStabilitysSumDoubletrueAlpha实现上由updateCPUSeconds回调调用proc.TimesWithContext汇总User System Idle Nice Iowait Irq Softirq Steal后Observe参见 process_telemetry.go。otelcol_process_memory_rss—— 常驻物理内存resident set size。UnitMetric TypeValue TypeStabilityByGaugeIntAlpha由updateRSSMemory回调通过proc.MemoryInfoWithContext读取mem.RSS后上报同文件 L133-L140。otelcol_process_runtime_heap_alloc_bytes—— 已分配的堆对象字节数对应go doc runtime.MemStats.HeapAlloc的Alloc字段。UnitMetric TypeValue TypeStabilityByGaugeIntAlphaotelcol_process_runtime_total_alloc_bytes—— 堆对象累计分配字节数对应runtime.MemStats.TotalAlloc。UnitMetric TypeValue TypeMonotonicStabilityBySumInttrueAlphaotelcol_process_runtime_total_sys_memory_bytes—— 从操作系统获得的内存总字节数对应runtime.MemStats.Sys。UnitMetric TypeValue TypeStabilityByGaugeIntAlphaotelcol_process_uptime—— 进程运行时长秒。UnitMetric TypeValue TypeMonotonicStabilitysSumDoubletrueAlpha由updateProcessUptime基于进程启动时间戳startTimeUnixNanoRegisterProcessMetrics创建processMetrics时以time.Now().UnixNano()记录与当前时间之差换算得到。值得注意的工程细节三个runtime.MemStats类指标共用一个readMemStatsIfNeeded缓存逻辑——runtime.ReadMemStats是相对昂贵的操作因此实现中做了 1 秒粒度去重if now.Sub(pm.lastMsRead) time.Second { return }避免每次采集都触发完整的 GC 统计快照见 process_telemetry.go。三、遥测级别与指标可见性控制otelcol.*系列指标并非在任何配置下都全量暴露。Collector 的 telemetry 配置支持normal、detailed等级别而 internal/metricviews/views.go 中的DefaultViews(level)会根据级别裁剪默认视图Views级别低于detailed时丢弃 otelhttp / otelgrpc 的埋点指标、otelcol_processor_internal_duration时长指标、otelcol.*.consumed.size/otelcol.*.produced.size等尺寸指标以及部分 exporter / receiver 的批量与错误指标如otelcol_exporter_send_failed_*会排除error.type、error.permanent两个属性维度级别低于normal时进一步丢弃 batch processor 与 otel-arrow 相关指标如arrow_batch_records、arrow_memory_inuse。这意味着若你在 Prometheus 中找不到某个otelcol_*指标应先确认 service 的telemetry.metrics.level配置是否为detailed再排查是否属于上述被裁剪的尺寸类或 HTTP/gRPC 埋点类指标。四、Feature Gates四个特性开关详解documentation.md 的第二个核心章节列出该组件注册的 4 个 Feature Gates。它们的注册代码位于 internal/metadata/generated_feature_gates.go统一通过featuregate.GlobalRegistry().MustRegister(...)注册到全局注册表并携带描述Description、引入版本From Version、移除版本To Version与参考链接等元数据。Feature GateStageDescriptionFrom VersionTo Versionservice.AllowNoPipelinesalpha允许在不启动任何 pipeline 的情况下启动 Collectorv0.122.0N/Aservice.profilesSupportalpha控制是否可以启用 profiles 支持v0.112.0N/Atelemetry.UseLocalHostAsDefaultMetricsAddressstable控制默认 Prometheus 指标服务是否以 localhost 作为端点默认主机v0.111.0v0.154.0telemetry.newPipelineTelemetryalpha在 Collector 内部指标中注入组件标识 scope 属性v0.123.0N/A4.1 service.AllowNoPipelinesalpha自 v0.122.0默认情况下Collector 配置文件中必须至少定义一个 pipeline 才能启动。该开关允许在没有任何 pipeline 的情况下启动进程适用于只运行 extensions如健康检查、pprof而暂无数据管道的边缘场景。源码佐证位于 pipelines/config.goConfig.Validate()中if !metadata.ServiceAllowNoPipelinesFeatureGate.IsEnabled() len(cfg) 0 { return errMissingServicePipelines }即未开启该开关时空 pipeline 配置会直接报出service must have at least one pipeline错误。4.2 service.profilesSupportalpha自 v0.112.0控制 Collector 是否启用 Profiling连续分析信号的支持。由于该能力处于 alpha 阶段未开启时即使配置了 profiles 信号 pipeline 也会校验失败。同样见 pipelines/config.go 的Validate()if !metadata.ServiceProfilesSupportFeatureGate.IsEnabled() { for pipelineID : range cfg { if pipelineID.Signal() xpipeline.SignalProfiles { return fmt.Errorf( pipeline %q: profiling signal support is at alpha level, gated under the %q feature gate, pipelineID.String(), metadata.ServiceProfilesSupportFeatureGate.ID(), ) } } }从该段代码可以推断profiles 信号在 pipeline 配置层面已被xpipeline.SignalProfiles建模但默认被 Feature Gate 拦截需显式开启后方可使用。4.3 telemetry.UseLocalHostAsDefaultMetricsAddressstablev0.111.0 → v0.154.0控制默认 Prometheus 指标暴露端点是否以localhost作为默认主机。该开关已处于stable阶段且带有明确的To Version: v0.154.0——意味着从 v0.154.0 起该行为被固定为默认值并移除开关。结合本仓库 vendor 的 service 版本 v0.153.0go.mod 第 89 行可以推断当前 Tempo 依赖的 Collector service 仍处于该开关生命周期末期升级到 v0.154.0 及以上版本的 Collector 时需注意默认指标地址行为的固化。4.4 telemetry.newPipelineTelemetryalpha自 v0.123.0在 Collector 内部指标中注入组件标识的 scope 属性使指标可以按组件维度如 receiver 名称、pipeline 名称进行区分与聚合对应 OpenTelemetry Collector 的组件通用遥测component-universal-telemetry方向。源码中该开关影响两处行为internal/obsconsumer 的四个信号消费者traces.go、logs.go、metrics.go、profiles.go在New*构造函数中均先判断if !metadata.TelemetryNewPipelineTelemetryFeatureGate.IsEnabled() { return cons }——未开启时直接返回原始消费者不注入任何观测逻辑internal/componentattribute/telemetry.go 的TelemetrySettingsWithAttributes在开启该开关时才会为MeterProvider包装一层带组件属性的 providermeterProviderWithAttributes而 Logger 与 TracerProvider 的包装则不受该开关限制。4.5 如何启用 Feature GatesCollector service 的 Feature Gates 通过标准启动参数--feature-gates控制。其 CLI 接线实现位于 vendor/go.opentelemetry.io/collector/featuregate/flag.goRegisterFlags向flag.FlagSet注册名为feature-gates的开关flagValue实现flag.Value接口把命令行上以逗号分隔的 gate 列表支持idvalue形式直接应用到全局 Registry。典型用法示例# 同时开启多个 alpha 特性 tempo --feature-gatesservice.AllowNoPipelines,service.profilesSupport # 显式指定取值默认 alpha gate 开启后为 true tempo --feature-gatestelemetry.newPipelineTelemetrytrue版本边界由注册时携带的WithRegisterFromVersion/WithRegisterToVersion决定见 featuregate/registry.go 中WithRegisterToVersion的实现其会对版本字符串做校验。需要注意的是Feature Gates 属于 OpenTelemetry Collector 层面的开关具体是否被 Tempo 的启动入口透传取决于 Tempo 对 Collector 依赖的封装方式生产环境使用前应先确认所在版本的 Collector service 已注册对应 gate。五、落地实践指标采集与告警结合上述指标清单在 Grafana 中监控 Tempo 所依赖的 Collector service 运行时可以重点关注数据吞吐对otelcol_receiver_produced_items、otelcol_exporter_consumed_items做rate()计算观察每秒进入/流出 pipeline 的数据项速率用于容量规划与异常突增告警资源水位otelcol_process_memory_rss常驻内存、otelcol_process_runtime_heap_alloc_bytes堆分配、otelcol_process_cpu_secondsCPU 累计时间直接反映进程健康度可设定内存增长趋势与 CPU 持续高占用告警进程状态otelcol_process_uptime的归零或骤降意味着进程重启/崩溃可作为进程存活与稳定性监控的补充信号维度区分在启用telemetry.newPipelineTelemetry的部署中管道流量指标会携带组件标识属性可将同一指标按 receiver/processor/exporter 实例拆分观察。所有指标名、单位、类型与稳定性级别的权威出处即 documentation.md 及同目录 metadata.yaml指标底层采集逻辑可继续阅读 internal/proctelemetry/process_telemetry.go 与 internal/obsconsumer 目录下的信号实现。六、小结Grafana Tempo 以 vendor 方式内嵌的 OpenTelemetry Collector service 模块v0.153.0提供了两层可观测性资产一层是otelcol.*.consumed/produced.items与otelcol_process_*共 12 个内部遥测指标其中管道类 8 个为 Development 稳定性进程类 6 个为 Alpha 稳定性另一层是 4 个 Feature Gates覆盖无 pipeline 启动service.AllowNoPipelines、profiles 信号service.profilesSupport、默认指标地址主机telemetry.UseLocalHostAsDefaultMetricsAddressstable 且将于 v0.154.0 移除与组件级指标属性注入telemetry.newPipelineTelemetry。理解这些指标的语义、稳定性级别与开关的版本边界是正确配置 Tempo 监控告警、评估 Collector 依赖升级影响的前提。延伸阅读仓库内路径本文核心依据vendor/go.opentelemetry.io/collector/service/documentation.md指标与开关的元数据源头vendor/go.opentelemetry.io/collector/service/metadata.yaml进程指标实现vendor/go.opentelemetry.io/collector/service/internal/proctelemetry/process_telemetry.go管道流量指标注入vendor/go.opentelemetry.io/collector/service/internal/obsconsumer/traces.go遥测级别视图裁剪vendor/go.opentelemetry.io/collector/service/internal/metricviews/views.goFeature Gate 注册vendor/go.opentelemetry.io/collector/service/internal/metadata/generated_feature_gates.goFeature Gate 校验逻辑vendor/go.opentelemetry.io/collector/service/pipelines/config.go依赖版本声明go.mod赞分享后端可观测性链路追踪【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址https://gitcode.com/GitHub_Trending/tempo1/tempo点击查看免费下载相关推荐OpenTelemetry Collector service 组件内部遥测指标与特性开关Feature Gates完全指南OpenTelemetry Collector service 组件内部遥测指标与特性开关Feature Gates完全指南 本指南以 OpenTelem可观测性后端运维观测Grafana Tempo 中的 receiverhelper 内部遥测指标与 Feature Gate 深度解析Grafana Tempo 中的 receiverhelper 内部遥测指标与 Feature Gate 深度解析 本文以 Grafana Tempo 仓库 v后端可观测性链路追踪OpenTelemetry Collector scraperhelper 内部抓取遥测指标Scraped/Errored与 Scraper Controller 深度解析OpenTelemetry Collector scraperhelper 内部抓取遥测指标Scraped/Errored与 Scraper Control可观测性后端运维观测创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价