DevOps 和 SRE 团队正在改变软件开发流程。DevOps 工程师专注于高效的软件应用程序和服务交付,而 SRE 团队则是确保可靠性、可扩展性和性能的关键。这些团队必须依靠完整的可观测性解决方案来管理和监控系统,并确保在问题影响业务之前解决问题。
现代分布式应用程序整个堆栈的可观测性需要数据收集、处理和关联,通常以仪表盘的形式呈现。摄取所有系统数据需要在各个堆栈、框架和提供商中安装代理,对于必须处理版本更改、兼容性问题以及无法随着系统更改而扩展的专有代码的团队来说,这是一个具有挑战性和耗时的过程。
感谢 OpenTelemetry (OTel),DevOps 和 SRE 团队现在有了一种标准的方式来收集和发送数据,这种方式不依赖于专有代码,并且拥有庞大的支持社区,从而减少了供应商锁定。
在之前的博文中,我们还回顾了如何使用 OpenTelemetry 演示 并将其连接到 Elastic®,以及 Elastic 在 OpenTelemetry 和 Kubernetes 中的一些功能。
在本博文中,我们将展示如何将 OpenTelemetry 的自动监控 与我们 名为 Elastiflix 的应用程序 的 Node.js 服务一起使用,这有助于以简单的方式突出显示自动监控。
这样做的好处是:**无需 otel-collector**!此设置使您能够根据最适合您业务的时间线,缓慢且轻松地将应用程序迁移到使用 Elastic 的 OTel。
应用程序、先决条件和配置
我们用于本博文的应用程序称为 Elastiflix,一个流媒体电影应用程序。它由用 .NET、NodeJS、Go 和 Python 编写的多个微服务组成。
在我们监控示例应用程序之前,我们首先需要了解 Elastic 如何接收遥测数据。
Elastic 可观测性提供的所有 APM 功能都可用于 OTel 数据。其中一些包括
- 服务映射
- 服务详细信息(延迟、吞吐量、失败的事务)
- 服务之间的依赖关系、分布式跟踪
- 事务(跟踪)
- 机器学习 (ML) 关联
- 日志关联
除了 Elastic 的 APM 和统一的遥测数据视图之外,您还可以使用 Elastic 强大的机器学习功能来减少分析,并使用警报帮助减少 MTTR。
先决条件
- 一个 Elastic Cloud 帐户 — 立即注册
- Elastiflix 演示应用程序 的克隆,或您自己的 **Node.js** 应用程序
- 对 Docker 的基本了解 — 可能需要安装 Docker Desktop
- 对 Node.js 的基本了解
查看示例源代码
完整的源代码(包括本博文中使用的 Dockerfile)可以在 GitHub 上找到。该存储库还包含 没有监控的相同应用程序。这使您可以比较每个文件并查看差异。
以下步骤将向您展示如何监控此应用程序并在命令行或 Docker 中运行它。如果您有兴趣了解更完整的 OTel 示例,请查看 此处的 docker-compose 文件,它将启动整个项目。
分步指南
步骤 0. 登录您的 Elastic Cloud 帐户
本博文假设您拥有 Elastic Cloud 帐户 — 如果没有,请按照 说明开始使用 Elastic Cloud。
步骤 1. 为 Node.js 服务配置自动监控
我们将使用来自 Elastiflix 演示应用程序 的 Node.js 服务的自动监控。
我们将使用 Elastiflix 中的以下服务
Elastiflix/node-server-otel-manual
根据 OpenTelemetry JavaScript 文档 和 @open-telemetry/auto-instrumentions-node 文档,您只需使用 npm 安装相应的节点包。
npm install --save @opentelemetry/api
npm install --save @opentelemetry/auto-instrumentations-node
如果您在命令行上运行 Node.js 服务,则以下是如何使用 Node.js 运行自动监控的方法。
node --require '@opentelemetry/auto-instrumentations-node/register' app.js
对于我们的应用程序,我们在 Dockerfile 中执行此操作。
Dockerfile
FROM node:14
WORKDIR /app
COPY ["package.json", "./"]
RUN ls
RUN npm install --production
COPY . .
RUN npm install --save @opentelemetry/api
RUN npm install --save @opentelemetry/auto-instrumentations-node
EXPOSE 3001
CMD ["node", "--require", "@opentelemetry/auto-instrumentations-node/register", "index.js"]
步骤 2. 使用环境变量运行 Docker 镜像
如 OTEL 文档 中所述,我们将使用环境变量并传入配置值以使其能够连接到 Elastic 可观测性的 APM 服务器。
由于 Elastic 本机接受 OTLP,因此我们只需提供 OTEL Exporter 需要发送数据的端点和身份验证,以及其他一些环境变量。
获取 Elastic Cloud 变量
您可以从 Kibana® 的路径 /app/home#/tutorial/apm 中复制端点和令牌。
您需要复制以下环境变量
OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_HEADERS
构建镜像
docker build -t node-otel-auto-image .
运行镜像
docker run \
-e OTEL_EXPORTER_OTLP_ENDPOINT="<REPLACE WITH OTEL_EXPORTER_OTLP_ENDPOINT>" \
-e OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <REPLACE WITH TOKEN>" \
-e OTEL_RESOURCE_ATTRIBUTES="service.version=1.0,deployment.environment=production" \
-e OTEL_SERVICE_NAME="node-server-otel-auto" \
-p 3001:3001 \
node-server-otel-auto
您现在可以发出一些请求以生成跟踪数据。请注意,预计这些请求将返回错误,因为此服务依赖于您机器上可能未运行的一些下游服务。
curl localhost:3001/api/login
curl localhost:3001/api/favorites
# or alternatively issue a request every second
while true; do curl "localhost:3001/api/favorites"; sleep 1; done;
步骤 3:在 Elastic APM 中探索跟踪、指标和日志
在 Elastic APM 中浏览“服务”部分,您将看到显示的 Node 服务。
单击 node-server-otel-auto 服务,您可以看到它正在使用 OpenTelemetry 摄取遥测数据。
总结
在本博文中,我们讨论了以下内容
- 如何使用 OpenTelemetry 自动监控 Node.js
- 通过在 Dockerfile 中使用标准命令,可以高效地完成自动监控,而无需在多个位置添加代码,从而提高了可管理性
由于 Elastic 支持多种数据摄取方法,无论是使用开源 OpenTelemetry 的自动检测还是使用其原生 APM 代理的手动检测,您都可以先专注于几个应用程序的迁移到 OTel,然后在日后以最适合您业务需求的方式在所有应用程序中使用 OpenTelemetry。
开发者资源
- Elastiflix 应用程序,使用 OpenTelemetry 检测不同语言的指南
- Python:自动检测,手动检测
- Java:自动检测,手动检测
- Node.js:自动检测,手动检测
- .NET:自动检测,手动检测
- Go:手动检测
- OpenTelemetry 检测最佳实践
通用配置和用例资源
- 在 Elastic 上使用 OpenTelemetry 的独立性
- 使用 Elastic 和 OpenTelemetry 实现现代可观察性和 Kubernetes 安全性
- 使用 OpenTelemetry 和 Elastic 进行日志记录的 3 种模型
- 将免费且开源的 Elastic APM 作为 Elastic 可观察性部署的一部分添加
- 通过 OpenTelemetry API 在代码中捕获自定义指标(使用 Elastic)
- 使用 OpenTelemetry 和 Elastic 为您的可观察性平台奠定未来基础
- Elastic 可观察性:专为 Kubernetes、OpenTelemetry、Prometheus、Istio 等开放技术而构建
还没有 Elastic Cloud 账户?注册 Elastic Cloud 并试用我上面讨论的自动检测功能。我很乐意了解您使用 Elastic 提高应用程序堆栈可见性的体验反馈。
本文中描述的任何功能或功能的发布和时间安排完全由 Elastic 自行决定。任何当前不可用的功能或功能可能无法按时或根本无法交付。