#故障排查

Jaeger backend 本身是一个分布式系统，由不同组件组成，这些组件可能运行在许多主机上。某个组件可能未正常工作，导致 spans 无法被处理或存储。当出现问题时，请务必检查此处列出的项目。

如果你在 pipeline 中使用 OpenTelemetry Collector，请务必检查其自己的 故障排查指南。

#验证采样策略

首先，请务必确认当前使用的是哪种采样策略。对于开发场景或低流量场景，对每个 trace 进行采样是有用的。在生产环境中，你可能希望使用更低的采样率。在诊断为什么 spans 没有被 backend 接收到时，请确保将 SDK 配置为 对每个 trace 进行采样。通常，可以通过环境变量设置采样策略。

#OpenTelemetry SDKs

如果你使用的是 OpenTelemetry SDKs，它们默认应使用 parentbased_always_on sampler，这实际上等同于 100% 采样。可以通过 OTEL_TRACES_SAMPLER 环境变量进行更改（请参阅文档）。

#使用 debug Exporter

可以为 OpenTelemetry SDKs 配置一个 debug exporter，将记录的 spans 打印到控制台日志中。启用它后，你可以验证 spans 是否确实已被记录。

#绕过中间收集器

如果你的应用没有直接向 Jaeger 发送数据，而是发送到中间层，例如作为主机智能体运行的 OpenTelemetry Collector，那么可以尝试将 SDK 配置为直接向 Jaeger 发送数据，以缩小问题排查范围。

#网络连通性

如果你的 Jaeger backend 仍然无法接收 spans（请参阅以下有关如何检查日志和 metrics 的部分），那么问题很可能出在你的网络命名空间配置上。当将 Jaeger backend 组件作为容器运行时，常见错误包括：

• 未在容器外暴露相应端口。例如，collector 可能在容器网络命名空间内监听 :4317，但该端口从外部无法访问。
• 将 localhost 作为服务端点的主机名。在裸金属环境中使用 localhost 没问题，但在容器中建议改为监听 0.0.0.0。
• 没有让应用网络命名空间中可见 Jaeger 的主机名。例如，如果你将应用和 Jaeger backend 分别运行在由 containerd 管理的不同容器中，那么它们要么需要位于同一个网络命名空间中，要么需要使用 nerdctl network connect 将应用容器连接到与 Jaeger backend 相同的网络。

#提高日志详细程度

当日志级别设置为 debug 时，Jaeger 会提供有用的调试信息。

apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
spec:
  service:
    telemetry:
      logs:
        level: debug

#检查 /metrics 端点

对于不方便或不希望提高日志详细程度的情况，可以使用 /metrics 端点来检查 trace 数据是如何被 Jaeger 接收和处理的。有关如何配置 metrics 生成的更多详情，请参阅 配置 Jaeger Metrics。下面是一个用于获取 metrics 的 curl 示例：

curl -s http://jaeger-collector:8888/metrics

如果 Jaeger 能够接收 traces，计数器 otelcol_receiver_accepted_spans 应该会持续增长。如果它能够成功将 traces 写入存储，计数器 otelcol_exporter_sent_spans 也应以相同速率增长。

#Service Mesh：缺失 spans

当将应用作为 Istio 之类的 service mesh 的一部分进行部署时，组件数量会显著增加，这可能会影响 spans 的上报方式以及上报哪些 spans。如果你预期会看到由 service mesh 生成的 spans，但它们在 Jaeger UI 中不可见，请检查你所使用的 service mesh 的故障排查指南。例如，查看 Istio 网站。