什么是 OpenTelemetry？

踪迹

跟踪记录操作期间发生的事件，例如处理单个请求。 踪迹被划分为一系列跨度，每个跨度代表一个工作单元。

例如，Web 请求的跟踪可能包括三个跨度：

• 接受请求
• 查询数据库
• 发送回复

跟踪将可能包含多个服务的数据流分割成一系列按时间顺序排列的块，以帮助您轻松理解：

• 每个块中发生的所有步骤
• 块执行的顺序
• 每一步持续多长时间
• 每个步骤的元数据

一旦 OTel 生成了跟踪，下一步就是将其导出到跟踪后端或工具中进行分析。 OTel 为Jaeger 、 Zipkin和AWS X‑Ray等流行后端提供了一组导出器。 这些服务提供了用于分析和可视化跟踪数据的工具。

指标

在 OTel 中，指标是对操作系统行为的特定方面的测量，并随着时间的推移以键值对（称为指标标签）的形式收集。 键值对提供了有关随时间推移的测量的背景信息。 例如，Web 服务响应时间的指标可能包括 HTTP 状态代码、端点和 HTTP 方法的标签。 所有指标都带有时间戳，以便按时间顺序排列。

日志

日志是了解特定服务运行情况的最古老和最常用的方法。 它们通常以文本形式生成，必须进行解析才能产生见解。 OTel 对日志的支持仍处于试验阶段。

要了解我们的解决方案架构师在将 OTel 中的可观察性功能集与其他可观察性工具进行比较时发现的内容，请参阅我们博客上的将 OpenTelemetry 集成到现代应用程序参考架构中 - 进度报告。

OTel 与许多流行的编程语言、库和框架集成。 对某些语言的支持比其他语言更全面。 例如， JavaScript 检测库具有自描述的用于跟踪和指标的“稳定”实现以及一些最稳定的日志支持。 它们还提供自动检测选项，让您可以开始接收跟踪，而无需在服务逻辑中添加任何特定于检测的代码。 另一方面，像Go这样的语言对指标和日志的支持不太成熟，并且缺乏自动检测功能。

在设置遥测仪器时，最好从一组更明确的仪器目标开始，而不是“发送所有内容并希望获得见解”。 虽然在查看数据之前您无法了解全部可能性，但设置一些最低要求有助于确保您的服务顺利运行和维护。

这些可能是技术问题，例如：

• 我想知道我的服务何时面临压力并需要扩展。
• 我想知道我的服务是否经常重启。

但它们也可能是与产品和用户体验相关的问题，例如：

• 我希望用户能在五秒内看到系统中的新消息。
• 我希望在消息发送后一分钟内发出通知。

以我们的教程《如何使用 OpenTelemetry 跟踪来了解您的微服务》为例，您可以将以下内容定义为关键目标：

• 了解请求完成新消息流所采取的所有步骤。
• 检查用户流程是否成功完成。
• 确信用户流程从端到端的执行速度快于五秒（在“正常”情况下）。
• 了解通知服务是否及时处理事件（由信使服务分派）。 

OTel 为开发人员提供了一套应用编程接口 (API)、软件开发工具包 (SDK) 和检测库，开发人员可以使用它们以一致、标准化的方式对其应用s进行检测。

由于 OTel 生成的数据格式被视为行业标准，因此多种遥测聚合和可视化解决方案都接受它。 您可以选择本地解决方案，例如 Jaeger（正如我们在本教程中所做的那样），或者选择软件即服务 (SaaS) 解决方案，例如SumoLogic或SigNoz 。

要管理所有三种类型的遥测，OTel 的唯一替代方案是多种工具的组合。 这在运行微服务架构和基础设施固有的复杂性之上增加了更多的复杂性。

API 定义了软件组件相互交互所使用的方法、功能和协议。 OTel API定义了一组标准方法和协议，开发人员可以使用它们来检测他们的applications并收集遥测数据。