Grafana Tempo 排查如何确认 Alloy 是否成功把 Trace 推送到了后端【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempoGrafana Alloy 是 Tempo 官方推荐的数据采集组件负责把应用产生的 trace 通过 OpenTelemetry 管道转发到 Tempo 后端。但在实际部署中经常出现Grafana 里查不到 trace却看不到明显报错的情况。本文以 alloy.md 为核心系统讲解从 Alloy 侧到 Tempo 侧的完整排障链路先用 Prometheus 指标量化 Alloy 收到与发出多少 span再用日志和自动日志功能定位 trace 在管道中的丢失点最后联动 Tempo 的分布式追踪指标把问题收敛到具体环节。排查思路先量化流量再定位断点当 trace 没有出现在 Grafana 中时问题可能出在两个环节之一trace 从未到达 Alloy或 Alloy 收到后没有成功转发到后端。Alloy 的 tracing pipeline 基于 OpenTelemetry Collector 构建由receiver接收、processor处理、exporter导出三类组件组成参见 Grafana Alloy 配置文档因此排障也应沿这条管道逐段检查receiver 是否收到 span应用 SDK 是否真的把数据发到了 Alloyexporter 是否发出 spanAlloy 是否成功连接并写入了 Tempo 后端Tempo 侧是否拒绝Tempo 的 distributor 是否因限流等原因丢弃了 span查询侧是否正常数据已入库但查询不到。第一步永远先看日志有没有网络类错误如果日志干净就借助下面的指标来量化每一段的流量。用 Alloy 指标判断收/发两端的流量Alloy 为 tracing 管道发布了一组 Prometheus 指标是判断Alloy 收到多少、转发多少的最佳起点。文档将其分为两组来自otelcol.receiver.otlp组件接收端receiver_accepted_spans_ratio_total receiver_refused_spans_ratio_total来自otelcol.exporter.otlp组件导出端exporter_sent_spans_ratio_total exporter_send_failed_spans_ratio_total四者的组合判断逻辑非常直观指标组合含义receiver_accepted_spans_ratio_total增长receiver_refused_spans_ratio_total为 0应用成功把 span 送入了 Alloy接收环节正常receiver_refused_spans_ratio_total持续增长Alloy 接收端在拒绝 span常见于数据格式或管道配置问题exporter_sent_spans_ratio_total与接收量同步增长span 已成功导出到后端问题大概率不在 Alloyexporter_send_failed_spans_ratio_total增长导出失败重点排查与 Tempo 的连通性、TLS、认证配置这组指标同样出现在 Tempo 的 Unable to find traces 排查文档 中其中exporter_send_failed_spans_ratio_total和receiver_refused_spans_ratio_total的正常值都应为0一旦大于 0 就说明管道在丢 span。本地直接访问 /metrics 端点Alloy 自带的 Prometheus 抓取端点/metrics挂在 Alloy HTTP server 上浏览器直接打开即可在本地快速验证http://localhost:12345/metrics默认端口为12345该端点暴露 Alloy 的组件与 controller 指标。这是最快捷的眼见为实方式——打开页面后按CtrlF搜索上述四个指标名即可确认其当前数值。若 Alloy 部署在远端或容器中请将localhost替换为实际地址与端口。在 Grafana Cloud 中检查 trace 用量指标如果你的后端是 Grafana Cloud可以在 Grafana 实例里通过grafanacloud-usage数据源查看指标步骤如下在 Grafana 左侧菜单中选择Explore将数据源切换为grafanacloud-usage在输入框输入要验证的指标名。以grafanacloud_traces_开头输入时自动补全功能会列出所有可用的 trace 用量指标方便浏览。这类指标归属于 Cloud Traces usage metrics反映的是有多少 trace 数据实际到达了 Grafana Cloud可以佐证 Alloy 侧指标的结论。日志层面把收到的 span 打印出来当指标和日志看起来都正常、但 Grafana Cloud 里依然找不到 trace 时可以配置 Alloy 把所有收到的 trace 输出到控制台console直接核对 span 内容是否符合预期。这属于 Tempo 的 automatic logging自动日志能力详细介绍见 Automatic logging 文档。自动日志的核心是otelcol.connector.spanlogs连接器它接收 trace 并为每个 span或 root span、process生成一行logfmt风格的日志默认包含svc服务名、spanspan 名、dur纳秒级耗时、tidtrace ID、status显式状态等键。例如spanHTTP GET dur150200000ns http.methodGET http.target/api/v1/query svcmy-service tid7bba9f33312b3dbb8b2c2c62bb7abe2d需要注意spanlogs连接器只生成日志、不转发原 trace。若用它排障必须同时把 trace 发给真正的后端否则会丢失数据。标准做法是把 receiver 的输出扇出fan-out到连接器和 exporter 两路。最小排障配置如下把日志打到 consoleotelcol.receiver.otlp default { grpc {} http {} output { traces [ otelcol.connector.spanlogs.default.input, otelcol.exporter.otlp.default.input, ] } } otelcol.connector.spanlogs default { roots true output { logs [otelcol.exporter.otlp.default.input] } }若只想记录根 span 并附上自定义属性可以在连接器上配置span_attributes例如span_attributes [http.method, http.target]。对于高吞吐系统逐 span 打日志会产生很大日志量此时建议退回到只记录 root span 或 process的粒度。深入 Alloytrace 在管道中可能被丢弃的环节即使 span 成功到达 Alloy也可能在后续管道处理中被丢弃。在 Grafana Alloy 配置文档 中可以找到几个常见风险点排障时应逐一核对采样Alloy 支持 tail-based sampling若配置了采样策略部分 trace 会被有意丢弃。排查时应先确认采样配置是否符合预期批量处理推荐使用otelcol.processor.batch合并 span 再导出它有助于压缩数据、减少连接数也能规避高频小批量请求导致的性能问题属性处理与 k8s 元数据otelcol.processor.attributes、otelcol.processor.transform、otelcol.processor.k8sattributes等处理器可能修改或丢弃携带不符合条件的 span导出重试与队列otelcol.exporter.otlp带有失败重试和队列缓冲机制若后端短暂不可达span 会滞留队列若队列积压溢出则可能直接丢弃数据。联动 Tempo 侧span 是否被 Tempo 拒绝如果 Alloy 的exporter_sent_spans_ratio_total正常增长说明 span 已经离开 Alloy此时应转向 Tempo 侧检查。Tempo 的 Unable to find traces 文档 提供了三个关键指标指标含义期望值tempo_distributor_spans_received_totaldistributor 每个租户收到的 span 总数应用启动后数分钟内 0tempo_live_store_traces_created_total写入 live-store 的 trace 数应用启动后数分钟内 0tempo_receiver_refused_spans因限流等原因被拒绝的 span 数0该指标在源码中有明确对应modules/distributor/distributor.go中注册了tempo_distributor_spans_received_total带tenant标签与tempo_distributor_bytes_received_totalafter limits。其含义可从 Help 文本确认The total number of spans received per tenant。当tempo_receiver_refused_spans大于 0 时最可能的原因是限流。Tempo 的 Distributor refusing spans 文档 指出distributor 在写入 Kafka 前会检查摄入速率限制拒绝时会出现形如RATE_LIMITED: ingestion rate limit (30000000 bytes) exceeded的日志同时tempo_discarded_spans_total指标递增。此时需要按需调整 overrides 中的max_traces_per_user等限流配置。开启 distributor 日志确认 span 是否到达 Tempo在 distributor 上启用 received/discarded span 日志可以最直接地验证 Tempo 是否收到了数据。相关配置定义在modules/distributor/config.go的LogSpansConfig中distributor: log_received_spans: enabled: true # 记录每个收到的 span include_all_attributes: false # 设为 true 会包含全部属性日志更详细 filter_by_status_error: false # 设为 true 只记录状态为 error 的 span log_discarded_spans: enabled: true include_all_attributes: false从源码看这些配置也支持命令行标志形式--distributor.log-received-spans.enabled、--distributor.log-received-spans.include-attributes、--distributor.log-received-spans.filter-by-status-error见 modules/distributor/config.go。丢弃 span 时日志形如levelinfo ts2024-08-19T16:06:25.880684385Z callerdistributor.go:767 msgdiscarded spanidc2ebe710d2e2ce7a traceidbd63605778e3dbe935b05e6afd291006完整排障路径一览综合上述手段当trace 到不了 Grafana时可以按下图路径逐层排查检查 Alloy 日志有无网络、连接、认证类报错检查 Alloy 指标/metrics端点确认receiver_accepted_spans_ratio_total是否增长判断 span 是否到达 Alloy检查 exporter 指标exporter_send_failed_spans_ratio_total是否大于 0判断 Alloy 是否成功把数据发出大于 0 时检查 Tempo endpoint 与 TLS 配置开启自动日志/console 输出验证 Alloy 实际收到的 span 内容trace ID、service name、属性是否符合预期同时确认采样策略没有丢弃目标 trace检查 Tempo 侧指标tempo_distributor_spans_received_total与tempo_live_store_traces_created_total是否增长若前者为 0问题在应用→Alloy→distributor 的连通性若后者为 0需检查 distributor→Kafka→live-store 链路检查tempo_receiver_refused_spans若大于 0按 max-trace-limit-reached.md 调整摄入限流配置最后排查查询侧若上述全部正常但 Grafana 仍查不到参考 Unable to find traces 检查 query-frontend 日志、querier 连接与数据源配置。这套从Alloy 收没收到到Tempo 收没收到再到查询链路的逐层检查法可以快速把问题收敛到唯一环节避免在错误的方向上反复调试。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考