为什么依赖图页面没有数据？

依赖图页面显示了 Jaeger Trace 的服务和它们之间的访问关系图。
当您使用具有内存存储的 all-in-one 二进制文件时，依赖关系是根据内存中存储的所有Trace信息按需计算的。
但是，如果您使用的是真正的分布式存储，例如 Cassandra 或 Elasticsearch，那么查询数据库中的所有数据来构建服务依赖图的成本太高了。
相反，Jaeger 项目提供了“big data”的 Job，可用于从trace信息中提取服务依赖图的相关信息：

为什么在Jaeger中看不到任何span数据？

可以参考问题定位页面。

我是否需要运行jaeger-agent呢？

jaeger-agent 并不是一个必须的组件。Jaeger Client 库可以配置为将 trace 数据直接导出到 jaeger-collector。
但是，我们还是推荐使用 jaeger-agent ，具体的原因包括：

  • 如果我们希望 Jaeger Client 库直接向 Collector 发送 trace 数据，我们必须为它们提供 HTTP 的 URL。 这意味着我们的应用程序需要包含此参数的额外配置，特别是如果我们部署了多个 Jaeger 集群（例如，在不同的可用区或区域中）并希望将数据发送到附近的 Jaeger 集群中时，问题就会变得复杂。 相比之下，当使用 Agent 时，Client 不需要额外的配置，因为 Agent 总是可以通过 localhost 访问。 它充当 sidecar 并将请求转发到适当的 Collector 。
  • Agent 可以通过配置向 span 添加额外的标签（例如当前区域等）来使用特定于基础设施的元数据来丰富 trace 数据。如果 Agent 作为主机守护程序运行，它将被所有应用程序共享在同一台主机上运行。如果Agent 作为真正的 sidecar 运行，即每个应用程序一个，它可以提供一些附加功能，例如强身份验证、多租户、pod 名称等。
  • Agent 允许对 Collector 实施流量控制。 如果我们在数据中心有数千台主机，每个主机运行许多应用程序，并且每个应用程序都直接向 Collector 发送数据，那么每个 Collector 可能需要处理太多打开的连接。Agent 可以使用较少的连接对该流量进行负载平衡。

推荐使用哪些后端存储服务？

Jaeger 团队推荐 Elasticsearch 作为 Jaeger 的存储后端，原因如下：

  • Cassandra 是一个key-value 数据库，因此通过trace ID 检索 trace 的效率更高，但它没有提供与Elasticsearch 一样强大的搜索能力。实际上，Jaeger 后端在 Client 实现了搜索功能，如果在 kv 存储之上，可能会导致查询结果出现问题。 Elasticsearch 不会遇到这些问题，从而带来更好的可用性。 Elasticsearch 也可以直接查询相关数据，例如可以直接使用 Kibana 仪表板，并提供有用的分析和聚合。
  • 根据性能测试，我们观察到 Cassandra 中的单次写入比 Elasticsearch 快得多，这可能表明它可以维持更高的写入吞吐量。但是，由于 Jaeger 后端需要在 kv 存储之上实现搜索能力，因此向 Cassandra 写入 Span 的成本会明显变大：Jaeger 除了为 Span 本身写入一条记录外，还会对服务名称和操作名称进行额外的写入 索引，以及每个标签的额外索引信息。相比之下，将 span 保存到 Elasticsearch 是一次写入，所有索引都在 ES 节点内部进行。 因此，Cassandra 的整体吞吐量与 Elasticsearch 相当。

Cassandra 后端的一个好处是它原生支持数据 TTL，所以维护成本相对更低。
在 Elasticsearch 中，数据过期是通过索引轮换来管理的，这需要额外的设置（参见 Elasticsearch Rollover）。