在 Elastic 上通过 OpenTelemetry 实现独立

对更快捷、更可扩展服务的追求一直在上升。我们的日常生活离不开各种应用，从能够将您最喜爱的美食送到家的外卖应用，到管理您的账户的银行应用，甚至到预约看病的应用。这些应用不仅要从功能的角度实现增长，还要在用户容量方面实现增长。由于需要触达规模宏大的全球客户，这些高需求的云端应用程序越来越复杂。

为了能够满足需求，大部分这些在线应用和服务（例如手机应用程序、网页、SaaS）都正在转移至基于微服务的分布式架构和 Kubernetes。将您的应用迁移至云端后，您如何管理和监测服务的生产情况、规模以及可用性呢？对于插桩和为 Kubernetes 应用程序收集应用程序遥测数据，OpenTelemetry 正在快速成为事实上的标准。

OpenTelemetry (OTel) 是一个提供一系列工具、API 和 SDK 的开源项目，这些工具、API 和 SDK 可用来生成、收集和导出遥测数据（指标、日志和跟踪记录）以理解软件性能和行为。OpenTelemetry 最近成为了一个 CNCF 孵化项目，而且拥有巨大且仍在不断增长的社区和供应商支持。

虽然 OTel 提供了一种标准方式来使用标准遥测数据格式对应用程序进行插桩，但它并不提供任何后端或分析组件。所以如果在应用程序、基础架构和用户体验监测方面使用 OTel 库，则用户可以灵活选择合适且喜欢的可观测性工具。对于应用程序性能监测 (APM)，不会再出现供应商锁定的情况。

Elastic 可观测性为 OpenTelemetry 及其 OpenTelemetry 协议 (OTLP) 提供原生支持，以采集跟踪记录、指标和日志。Elastic 可观测性的所有 APM 功能都适用于 OTel 数据。所以可针对 OTel 数据使用下列功能（及更多）：

• 服务地图
• 服务详情（延迟、吞吐量、失败事务）
• 服务之间的依赖关系
• 事务（跟踪记录）
• ML 关联性（专门针对延迟）
• 服务日志

除了使用 Elastic 的 APM 和遥测数据统一视图，您现在还能够使用 Elastic 强大的 Machine Learning 功能来减少分析工作和告警数量，进而降低 MTTR。

鉴于 Elastic 的开源传统，Elastic 还支持其他 CNCF 型项目，例如 Prometheus、Fluentd、Fluent Bit、Istio、Kubernetes (K8S)，不一而足。  

本篇博文将会展示：

• 如何通过几个简单步骤配置通过 OTel 插桩的热门演示应用 (HipsterShop) 以将数据采集到 Elastic Cloud 中
• 重点讲解与 OTel 数据有关的一些 Elastic APM 功能和特性，以及将数据采集到 Elastic 中之后，您可以对数据进行哪些操作

在随后的跟进博文中，我们将会详细讲解如何针对 OTel 遥测数据使用 Elastic Machine Learning，如何针对特定语言对 OTel 应用程序指标进行插桩，我们如何通过 OTel 收集器支持 Prometheus 采集，等等。敬请关注！

准备工作和配置

如果您计划跟着本博文照做，下面是我们设置配置时所用的一些组件和详细信息：

• 确保您在 Elastic Cloud 上有一个账号，而且已部署一个堆栈（在此处查看说明）。
• 我们使用的是超级热门的 HipsterShop 演示应用程序的一个变体。HipsterShop 最初由 Google 编写，以展示 Kubernetes 和大量可用变体，例如 OpenTelemetry 演示应用。要使用此应用，请访问此处并按照说明进行部署。
• 此外，我们使用的是此应用程序的手动 OTel 插桩版本。在本篇博文的配置中，并未使用 OTel 自动插桩。
• 我们集群的位置。虽然我们使用的是 Google Kubernetes Engine (GKE)，但您可以使用自己喜欢的任何 Kubernetes 平台。 
• 尽管 Elastic 可以直接从已通过 OTel 插桩的服务采集遥测数据，但我们将关注更加传统的部署，即使用 OpenTelemetry 收集器的部署。
• 这里并没有使用传统上用来拉取所有 Kubernetes 数据的 Prometheus 和 FluentD/Fluent Bit，而是使用 Kubernetes 代理。跟进博文将会演示这一点。

下面是我们将在此篇博文中设置的配置：

将一切都设置完毕

在接下来的几个步骤，我将会演示：

• 在 Elastic Cloud 上获取账号
• 启动一个 GKE 集群
• 启动应用程序
• 配置 Kubernetes OTel 收集器 configmap，以指向 Elastic Cloud
• 针对 OTel 数据使用 Elastic 可观测性 APM 以改善可见性

第 0 步：在 Elastic Cloud 上创建账号

遵照说明以开始体验 Elastic Cloud。

第 1 步：启动一个 K8S 集群

虽然我们使用的是 Google Kubernetes Engine (GKE)，但您可以使用自己喜欢的任何 Kubernetes 平台。

对于从 Kubernetes 集群收集 OpenTelemetry 数据，Elastic 并没有特殊要求。GKE、EKS 或 AKS 上的任何正常 Kubernetes 集群或者符合 Kubernetes 规范的集群（自部署型和托管型）都可以。

第 2 步：将 HipsterShop 应用程序加载到集群上

将您的应用程序加载到您的自选云服务或者本地 Kubernetes 平台中的 Kubernetes 集群上。我使用的应用程序可从此处获得。

您的应用程序加载到 Kubernetes 上之后，您在 default 命名空间上将运行下列 pod（或一些变体）。

输出应该类似于以下内容：

在此版本中，我们仅启动了所有的 service 和 loadgenerator。您会发现 OpenTelemetry 收集器尚未启动。（请查看下一步。）
如果您查看单独服务的 yaml，您会发现它指向 port 4317 上的 OpenTelemetry 收集器。

Port 4317 是 OpenTelemetry 从服务聆听遥测数据的默认端口。 因此，所有服务都应指向 OTel 收集器。

第 3 步：启动指向 Elastic 的 OpenTelemetry 收集器

如您在 otelcollector.yaml 文件中所看到的，在 /deploy-with-collector-k8s 中，有两个具体变量需要在 configmap 部分进行设置。

OTEL_EXPORTER_OTLP_ENDPOINT 是 Elastic 的 APM 服务器。

OTEL_EXPORTER_OTLP_ENDPOINT 提供您的授权。

有关这些变量的更多详情。请查看有关 OTel 收集器配置的 Elastic 文档。

从哪里得到这些值？ 

在 Elastic 可观测性的 UI 中，在 APM 下，点击 +add data，将会出现下面的界面。 

来到 OpenTelemetry 下面：

您将会看到变量 OTEL_EXPORTER_OTLP_ENDPOINT 的值（您 Elastic APM 服务器的 终端），以及来自 OTEL_EXPORTER_OTLP_HEADERS 的授权。

将 OTel 收集器与 Elastic APM 服务器终端进行配置时，有两个选项：gRPC 和 http。

在 otelcollector.yaml（见此处）中，exporters 配置使用的是 http。 

如果您想使用 gRPC 端口发送至 APM 服务器，则您需要对 exporters 进行如下修改：

请注意，从 otlphttp 变成了 otlp。完成上述所需的变更后，则创建 otelcollector：

确保它已启动且运行正常。

第 4 步：打开 Kibana 并使用 APM 服务地图来查看您已通过 OTel 插桩的服务

在 Elastic 可观测性的 UI 中，在 APM 下面，选择 servicemap 即可查看您的服务。

如果您能看到上述界面，则表明 OpenTelemetry 收集器正在将数据发送到 Elastic 中：

恭喜！您已使用 OpenTelemetry 对 HipsterShop 演示应用程序服务完成插桩以进行跟踪，而且已将遥测数据成功采集到 Elastic 中！

如何配置具体的环境

Elastic APM 允许您采集多个应用程序，让您能够基于 Environment 进行筛选。因此，如果您的 dev team 1 和 dev team 2 都在使用该 UI，则您需要正确设置 environment 变量。 

为该应用程序设置 Environment 变量的过程是通过服务 yaml 中的 deployment.environment 变量来完成的。

如果想更改的话，则对于此博文，您必须在应用程序 git 中对每个服务 yaml 中的 OTEL_RESOURCE_ATTRIBUTES 进行更改。

更改前：

更改后：

要对所有服务均进行此操作，请运行下列代码：

第 5 步：Elastic 能向我显示什么？

现在 OpenTelemetry 数据已被采集到 Elastic 中，您接下来可以怎么做呢？

首先，您可以查看 APM 服务地图（如前一步中所示）——这能够为您提供涵盖全部服务的完整视图，也会显示服务之间的事务流动情况。

然后，您现在可以查看单独服务，以及所收集的事务。

如您所见，前端详情已列出。所有内容，包括： 

• 平均服务延迟
• 吞吐量
• 主要事务
• 失败事务率
• 错误
• 依赖关系

我们前往跟踪记录。在 Transaction（事务）选项卡中，您可以查看与前端服务相关的所有事务类型：

选择 /cn/cart/checkout 事务，我们可以查看完整跟踪记录以及所有跨度：

您不仅可以查看跟踪记录，而且还可以分析哪些因素与 /cn/chart/checkout 高于正常的延迟有关。

Elastic 会使用 Machine Learning 从跟踪记录中帮助发现各项服务的任何潜在延迟问题。操作十分简单，选择 Latency Correlations （延迟关联性）选项卡并运行关联性即可。

上图显示了，对于此事务，来自客户端 10.8.0.16 的事务可能有异常延迟。

然后，您可以从跟踪记录视图中直接向下钻取到日志，查看与跟踪记录相关的日志，从而帮助确定并找出潜在问题。

使用 Elastic Machine Learning (ML) 分析您的数据

OpenTelemetry 指标被采集到 Elastic 后，您可以通过 Elastic 的 ML 功能开始分析您的数据。

可在这里找到有关这些功能的出色回顾：确定 APM 遥测数据的关联性以确定事务中的根本原因。

而且在 Elastic 博客 中还有更多的视频和博文。

我们将会发表更多跟进博文，讲解如何利用 Elastic 的 Machine Learning 功能处理 OpenTelemetry 数据。

结论

希望您现在已理解 Elastic 可观测性可以如何搭配 Elastic APM 功能帮助您采集和分析 OpenTelemetry 数据。

快速回顾一下所学内容，更具体而言，我们学到了：

• 如何通过几个简单步骤配置通过 OTel 插桩的热门演示应用 (HipsterShop) 以将数据采集到 Elastic Cloud 中
• 重点讲解与 OTel 数据有关的一些 Elastic APM 功能和特性，以及将数据采集到 Elastic 中之后您可以对数据进行哪些操作

准备好开始体验了吗？注册 Elastic Cloud 并试用我在上面列出的特性和功能，以便从您的 OpenTelemetry 数据中获得最大价值和可见性。