使用 Jaeger 等 Opentracing 工具

Question

我开始了解 opentracing，甚至正在与 Jaeger 和 Spring 合作开发 POC。我们在生产中拥有大约 25 多个微服务。我已经读过它，但对它如何真正使用有点困惑。

我正在考虑将其用作故障排除工具，以确定应用程序故障的根本原因。为此，我们可以在 JaegerUI 中搜索 httpStatus 代码、自定义标签、traceIds 和应用程序日志。此外，我们可以通过跟踪跟踪找到瓶颈/缓慢的区域。

还有什么其他用途？

Jaeger 有一个请求采样器，我认为我们不应该对 Prod 中的每个请求进行采样，因为它可能会产生不利影响。这是真的吗？

如果是，那么为什么会对应用程序产生什么影响？我想在这种情况下它不能真正用于故障排除，因为我们不会有每个请求的数据。

建议 Prod 采用什么采样配置？

另外，像 Jaeger 这样的工具与 APM 工具有何不同，它适用于哪些方面？我的意思是你也可以用 APM 工具做类似的事情。例如，可以钻取服务的事务并跳转到 AppDynamics 中对其他服务的相应请求。可以对缓慢的交易发出警报。还可以捕获请求标头/正文，以便对其进行搜索等。

Answer 1

这里有很多不同的问题，如果没有关于您的具体设置的更多信息，其中一些问题没有答案，但我会尽力为您提供一个很好的概述。

为什么要跟踪？

您已经直觉到“APM”和“跟踪”之间有很多相似之处 - 差异非常小。分布式跟踪是作为 APM（应用程序性能监控）和 RUM（真实用户监控）销售的功能的超集，因为它允许您捕获有关服务中正在完成的工作的性能信息，以处理单个逻辑请求-服务级别，以及从客户端到数据库并返回的整个请求（或事务）级别。

跟踪数据与其他形式的遥测数据一样，可以通过不同方式进行汇总和分析 - 例如，未采样的跟踪数据可用于为给定的 API 端点或函数调用生成 RED（速率、错误、持续时间）指标。传统上，跟踪数据使用有关请求或处理请求的底层基础架构的属性进行注释（标记）（例如客户标识符，或处理请求的服务器的主机名，或为给定查询访问的数据库分区）允许在 Jaeger 或商业追踪工具等工具中进行强大的探索性查询。

抽样

生成跟踪对整体性能的影响各不相同。通常，跟踪库​​被设计为相当轻量级的——尽管有很多因素会影响这种开销，例如跨度上的属性数量、附加到它的日志事件以及服务的请求率。像 Google 这样的公司会因为其规模而大举采样，但老实说，从长期存储的角度考虑采样比从前期开销的角度考虑更有利。

虽然创建跨度并将其传输到跟踪后端的每个请求的额外开销可能很小，但随着时间的推移存储跟踪数据的成本很快就会变得令人望而却步。此外，来自大多数系统的大多数跟踪都不是很有趣。这就是为什么动态和基于尾部的采样方法变得越来越流行的原因。这些系统将采样决策从单个服务层转移到某个外部流程，例如OpenTelemetry Collector，它可以分析整个跟踪并根据用户定义的标准确定是否应该对其进行采样。例如，您可以确保对发生错误的任何迹线进行采样，而“基线”迹线以 1% 的速率进行采样，以便保留重要的错误信息，同时让您了解稳态性能。

专有 APM 与 OSS

AppDynamics 或 New Relic 等工具与 Jaeger 等工具之间的一个重要区别是，Jaeger 不依赖专有仪器代理来生成跟踪数据。 Jaeger 支持 OpenTelemetry，允许您使用诸如 OpenTelemetry Java Automatic Instrumentation 库之类的开源工具，它将自动为许多流行的 Java 框架和库（例如 Spring）生成跨度。此外，由于 OpenTelemetry 以多种语言提供，具有共享数据格式和跟踪上下文格式，因此您可以保证您的跟踪将在多语言环境中正常工作（因此，如果您除了 Java 之外还有 Node.JS 或 Golang 服务服务，您可以为每种语言使用 OpenTelemetry，并且跟踪上下文传播将在所有语言之间无缝地工作）。

不过，更有利的是，您的仪器与特定供应商或工具分离。您可以使用 OpenTelemetry 检测您的服务，然后将数据发送到一个或多个商业和开源分析工具。这使您摆脱了供应商的束缚，并允许您选择最适合工作的工具。

如果您想了解有关 OpenTelemetry、可观察性和其他主题的更多信息，我写了一个更长的系列，您可以找到 here（查找其他“OpenTelemetry 101”帖子）。