文档

Grafana Tempo

故障排除

查询

无法找到 traces

开源

无法找到 traces

找不到 traces 的两个主要原因如下：

数据采集到 Tempo 时出现问题。Span 可能没有正确发送到 Tempo，或者没有被采样。
查询 Tempo 已接收的 traces 时出现问题。

第一节：诊断并解决采集问题

第一步是检查应用 span 是否实际到达 Tempo。

将以下标志添加到 distributor 容器 - distributor.log_received_spans.enabled。

此标志启用 distributor 接收到的所有 traces 的调试日志记录。这些日志有助于检查 Tempo 是否接收到任何 traces。

您还可以检查以下指标：

tempo_distributor_spans_received_total
tempo_ingester_traces_created_total

在应用启动后几分钟内，这两个指标的值应大于 0。您可以通过以下任一方式检查这两个指标：

Tempo 暴露的指标页面，地址为 http://<tempo-address>:<tempo-http-port>/metrics，或
如果在 Prometheus 中抓取指标，则在 Prometheus 中查看。

情况 1 - `tempo_distributor_spans_received_total` 为 0

如果 tempo_distributor_spans_received_total 的值为 0，可能的原因包括：

在应用中初始化 tracer 时使用了错误的协议/端口组合。
内部采样器未选取 tracing 记录发送到 Tempo。
应用在 Docker 内部运行，并且将 traces 发送到错误的端点。

还可以使用 tempo_receiver_accepted_spans 获取接收器特定的流量信息，该指标带有接收器标签（用于采集的协议。例如：jaeger-thrift）。

解决方案

有三种可能的解决方案：协议或端口问题、采样问题或端点错误。

解决协议或端口问题

找出应用用于发出 traces 的通信协议。每个客户端 SDK 都不同。例如：Jaeger Golang Client 默认使用 Thrift Compact over UDP。
检查支持的协议及其端口列表，确保使用正确的组合。

解决采样问题

这些问题可能很难确定，因为大多数 SDK 默认使用概率采样器。这可能导致每 1000 条记录中只选取一条。
检查应用中初始化的 tracer 的采样配置，确保它具有较高的采样率。
有些客户端还提供应用报告的 span 数量指标，例如 jaeger_tracer_reporter_spans_total。如果可用，请检查该指标的值，确保其大于零。
诊断此问题的另一种方法是生成大量 traces，看看是否有记录到达 Tempo。

解决端点错误问题

如果应用也在 Docker 内部运行，请确保应用将 traces 发送到正确的端点 (tempo:<receiver-port>)。

情况 2 - tempo_ingester_traces_created_total 为 0

如果 tempo_ingester_traces_created_total 的值为 0，这可能表明 distributor 和 ingester 之间存在网络问题。

检查 ingester 暴露的指标 tempo_request_duration_seconds_count{route='/tempopb.Pusher/Push'}，该指标表明它正在接收来自 distributor 的采集请求。

解决方案

检查 distributor 的日志，查找类似 msg="pusher failed to consume trace data" err="DoBatch: IngesterCount <= 0" 的消息。这很可能是因为没有 ingester 加入 gossip ring，请确保 distributor 和 ingester 使用相同的 gossip ring 地址。

诊断并解决采样和限制问题

如果您能在 Tempo 中查询到一些 traces，但无法查询到另一些，那么您来对了部分。

这可能由多种原因引起，其中一些原因在本博客文章中详细介绍：我的 span 都去哪了？Jaeger 分布式 tracing 中丢弃 span 的诊断指南。如果您使用 Jaeger Agent，这会很有帮助。

如果您使用 Grafana Alloy，请继续阅读下一节以了解要监控的指标。

诊断问题

检查流水线是否丢弃 span。Grafana Alloy 上的以下指标有助于确定这一点：

exporter_send_failed_spans_ratio_total。该指标的值应为 0。
receiver_refused_spans_ratio_total。该指标的值应为 0。

如果流水线没有报告任何丢弃的 span，请检查 Tempo 是否丢弃了应用 span。以下指标有助于确定这一点：

tempo_receiver_refused_spans。tempo_receiver_refused_spans 的值应为 0。
如果 tempo_receiver_refused_spans 的值大于 0，则可能的原因是应用 span 由于速率限制而被丢弃。

解决方案

如果流水线 (Grafana Alloy) 丢弃 span，则可能需要扩展部署。
也可能存在与 Tempo 后端连接的问题，请检查 Alloy 日志，并确保 Tempo 端点和凭据配置正确。
如果 Tempo 丢弃 span，这可能是由于速率限制。速率限制可能是适当的，因此不是问题。该指标仅说明了 span 丢失的原因。
如果您需要更高的采集量，可以通过调整配置的覆盖限制中的 max_traces_per_user 属性来增加速率限制配置。

注意
有关限制的更多信息，请查阅采集限制页面。

第三节：诊断并解决查询 traces 的问题

如果 Tempo 正确地采集了 trace span，那么是时候调查查询数据时可能出现的问题了。

检查 query-frontend 的日志。query-frontend pod 运行着两个容器：query-frontend 和 query。使用以下命令查看 query-frontend 日志：

kubectl logs -f pod/query-frontend-xxxxx -c query-frontend

日志中出现以下错误可能解释了查询 traces 时的问题：

level=info ts=XXXXXXX caller=frontend.go:63 method=GET traceID=XXXXXXXXX url=/api/traces/XXXXXXXXX duration=5m41.729449877s status=500
no org id
could not dial 10.X.X.X:3200 connection refused
tenant-id not found

这些错误的可能原因包括：

querier 未连接到 query-frontend。检查 query-frontend 暴露的指标 cortex_query_frontend_connected_clients 的值。它应该 > 0，表明 querier 已连接到 query-frontend。
Grafana Tempo 数据源未配置为在 Authorization 头部传递 tenant-id（仅限多租户部署）。
未正确连接到 Tempo Querier。
权限不足。

解决方案

解决连接问题

如果 querier 未连接到 query-frontend，请检查 querier 配置中的以下部分并验证 query-frontend 地址。
yaml
```
querier:
  frontend_worker:
    frontend_address: query-frontend-discovery.default.svc.cluster.local:9095
```
验证 Grafana 数据源配置并调试 Grafana 和 Tempo 之间的网络问题。

解决权限不足问题