我开始了解 opentracing，甚至正在与 Jaeger 和 Spring 合作开发 POC。我们在生产中拥有大约 25 多个微服务。我已经阅读过它，但对于如何真正使用它有点困惑。
我正在考虑将其用作故障排除工具来确定应用程序故障的根本原因。为此，我们可以在 JaegerUI 中搜索 httpStatus 代码、自定义标签、traceIds 和应用程序日志。此外，我们可以通过监控跟踪找到瓶颈/缓慢的区域。
其他用途是什么？
Jaeger 有一个请求采样器，我认为我们不应该对 Prod 中的每个请求进行采样，因为它可能会产生不利影响。这是真的？
如果是，那么为什么会对应用程序产生什么影响？我想在这种情况下它不能真正用于故障排除，因为我们不会有每个请求的数据。
建议对 Prod 使用什么采样配置？
此外，像 Jaeger 这样的工具与 APM 工具有何不同，它适用于何处？我的意思是你也可以用 APM 工具做类似的事情。例如，可以钻取服务的事务并跳转到 AppDynamics 中对其他服务的相应请求。可以对缓慢的交易发出警报。还可以捕获请求标头/正文，以便对其进行搜索等。
这里有很多不同的问题，如果没有有关您的特定设置的更多信息，其中一些问题没有答案，但我会尽力为您提供一个很好的概述。
为什么要追踪？
您已经直觉到“APM”和“跟踪”之间有很多相似之处 - 差异非常小。分布式跟踪是作为 APM（应用程序性能监控）和 RUM（真实用户监控）销售的功能的超集，因为它允许您捕获有关服务中正在完成的工作的性能信息，以处理单个逻辑请求-服务级别，以及从客户端到数据库并返回的整个请求（或事务）级别。
与其他形式的遥测数据一样，跟踪数据可以以不同的方式进行聚合和分析——例如，未采样的跟踪数据可用于为给定的 API 端点或函数调用生成 RED（速率、错误、持续时间）指标。传统上，跟踪数据使用有关请求或处理请求的底层基础架构的属性进行注释（标记）（例如客户标识符，或处理请求的服务器的主机名，或为给定查询访问的数据库分区）允许在 Jaeger 或商业跟踪工具等工具中进行强大的探索性查询。
采样
生成跟踪的整体性能影响各不相同。通常，跟踪库被设计为相当轻量级的——尽管有很多因素会影响这种开销，例如跨度上的属性数量、附加到它的日志事件以及服务的请求率。像谷歌这样的公司会因为其规模而积极采样，但老实说，从长期存储的角度考虑采样比从前期开销的角度考虑更有益。
虽然创建跨度并将其传输到跟踪后端的每个请求的额外开销可能很小，但随着时间的推移存储跟踪数据的成本很快就会变得令人望而却步。此外，来自大多数系统的大多数跟踪都不是很有趣。这就是为什么动态和基于尾部的采样方法变得越来越流行的原因。这些系统将采样决策从单个服务层转移到一些外部过程，例如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、可观察性和其他主题的更多信息，我编写了一个较长的系列，您可以在此处找到（查找其他“OpenTelemetry 101”帖子）。