OpenTelemetry是如何做到：只需检测应用程序一次，将数据发送到任何后端

OpenTelemetry是如何做到：只需检测应用程序一次，将数据发送到任何后端

OpenTelemetry（也称为 OTel）是一个开源可观测能力框架，由一系列工具、API 和 SDK 组成，使 IT 团队能够检测、生成、收集和导出远程监测数据以进行分析和了解软件性能和行为。

比较流行的有Spring Cloud全家桶自带的Zipkin，点评的CAT, 华为的skywalking，Uber的Jaeger, naver的Pinpoint。opentelemetry项目迄今为止已获得了Zipkin, Jaeger, skywalking, Prometheus等众多知名中间件的支持。

OpenTelemetry 的承诺是，它可以帮助您避免供应商锁定，允许您对应用程序进行一次检测，然后将该数据发送到您选择的任何后端。这篇文章向您展示了如何使用代码示例来完成此操作，这些示例配置您的应用程序以将遥测数据发送到 Honeycomb 和 New Relic。

供应商锁定是什么？

随着应用程序架构变得越来越复杂，我们用来管理和维护它们的工具也需要发展。传统的监控解决方案在外部探测您的应用程序，非常适合在出现问题时提醒您，但您从那里开始呢？在大型复杂系统中，这些工具无法提供足够的上下文来实际跟踪和解决问题。

应用程序工具是 APM 工具的支柱。为了提供比传统监控工具更丰富的诊断数据，应用程序维护人员会在他们的项目中添加特定于供应商的代理或库。虽然每个供应商都提供了一些预配置的基线，但维护人员仍需要手动添加他们自己的工具，以确保报告给供应商仪表板的洞察力与其特定用例相关。该工具将添加到该供应商的特定用语中，使其不可转移到其他实现。结果是在开始时节省了前期时间，但如果您决定更换工具供应商，那么这些时间将不可避免地以累积利息的数量级收回。

当另一家供应商提供一些引人注目的差异化或杀手级功能需要调查时会发生什么？那是痛苦开始的时候。

您首先必须从代码库中删除所有旧工具，然后使用一组全新的代码和依赖项重新工具。如果事实证明新工具不合格？然后，是时候回滚所有内容并重新开始了。

组织被困在使用他们碰巧首先遇到的工具！在完成重新调整和可能丢失历史数据的坑之后，你更有可能放弃并学会接受现状。

这就是供应商锁定的陷阱。

OpenTelemetry 解锁供应商锁定

如果您曾经发现自己使用的工具无法为您服务，但实施（甚至评估）替代方案的成本太高而无法考虑切换，那么您就会明白为什么供应商锁定问题是不可接受的。OpenTelemetry 旨在通过提供标准化的仪器框架来打破这个问题。

出于对专有遥测事务状态的共同挫败感，标准开始以两个并行开源项目的形式出现：OpenCensus 和 OpenTracing。最终，社区将这两个标准合并到 OpenTelemetry 项目中。虽然它仍然是一个相对较新的项目，但 OpenTelemetry（或 OTel）正在快速成长，最近被接受为 ​​CNCF 孵化项目​​。

OpenTelemetry 为跨任意数量的后端系统生成、收集和导出应用程序遥测数据提供了一个开放标准。它是一个开源和供应商中立的检测框架，可以让您摆脱使用专有库来了解代码行为方式的陷阱。现在，您只需检测您的应用程序一次，然后将该检测带到您选择的任何其他后端系统。

供应商应该根据他们如何取悦你和解决你的问题来争夺你的青睐，而不是基于摆脱它们有多困难。有了 OTel，这终于成为可能。

让我们来看看在实践中使用 OTel 切换供应商的情况。

如何使用 OpenTelemetry 切换供应商

我们将从一个简单的 Node.js Express 应用程序开始。我们只有一条路线，我们会获取一个待办事项以保持事情的趣味性。

// app.jsconst express = require("express");const = require("app = express();app.get("/", async(req, res) = >{ (incoming) = >{ incoming.on("data", (data) = >{ console.log(JSON.parse(data)) }); incoming.on("end", () = >{ res.send("OK") }); });});app.listen(3000, () = >{ console.log(`Listening for requests on //localhost:3000`);});

现在让我们在上面撒一些 OTel。我们将添加一些依赖项并引入一个用于初始化 OTel SDK 的 tracking.js 文件。

"dependencies": { "@grpc/grpc-js": "1.3.7", "@opentelemetry/api": "1.0.3", "@opentelemetry/auto-instrumentations-node": "0.25.0", "@opentelemetry/exporter-collector-grpc": "0.25.0", "@opentelemetry/sdk-node": "0.25.0", "express": "~4.16.1"}``````js// tracing.jsconst opentelemetry = require('@opentelemetry/sdk-node');const { getNodeAutoInstrumentations} = require('@opentelemetry/auto-instrumentations-node');const { CollectorTraceExporter} = require("@opentelemetry/exporter-collector-grpc");const { credentials} = require("@grpc/grpc-js");const traceExporter = new CollectorTraceExporter({ credentials: credentials.createSsl(),});let sdk = new opentelemetry.NodeSDK({ traceExporter, instrumentations: [getNodeAutoInstrumentations()]});sdk.start()

我们将通过环境变量配置 OTel 管道的其余部分。首先，让我们将其指向 Honeycomb。

export OTEL_EXPORTER_OTLP_ENDPOINT=“OTEL_EXPORTER_OTLP_HEADERS=“x-honeycomb-team=MY_HNY_KEY,x-honeycomb-dataset=otel-node”export OTEL_SERVICE_NAME=“express-backend”

node -r tracing.js app.js

当然不止于此。我们想知道我们获取了什么样的待办事项。让我们添加一个以 todo 标题作为属性的 span。

// app.jsconst otel = require("@opentelemetry/api");let tracer = otel.trace.getTracer("my-tracer");app.get("/", async(req, res) = >{ (incoming) = >{ let span = tracer.startSpan("reading-todo"); incoming.on("data", (data) = >{ span.setAttribute("title", JSON.parse(data).title) }); incoming.on("end", () = >{ span.end(); res.send("OK") }); });});

哦，嘿，我们的跟踪中有另一个跨度，它显示了待办事项的标题！

现在，假设您想将数据发送到 Honeycomb 以外的其他地方。简单——只需换掉你的端点和标头。让我们以 New Relic 为例。

export OTEL_EXPORTER_OTLP_ENDPOINT=“OTEL_EXPORTER_OTLP_HEADERS=“api-key=MY_NR_KEY”

但是，如果您还没有完全准备好进行转换并且想在多个供应商处购买您的数据怎么办？OpenTelemetry ​​Collector​​是一个 OTel 组件，允许您通过配置数据管道来摄取、处理和导出遥测数据。它不是必需的组件，但在这种情况下，我们可以利用它将跟踪发送到 Honeycomb 和 New Relic。我们首先在 Docker 容器中本地运行收集器。

docker run -p 4317:4317 -v /collector-config.yaml:/etc/collector-config.yaml otel/opentelemetry-collector —config=/etc/collector-config.yaml

这是我们导出到两个供应商的 collector-config.yaml 文件。

receivers:otlp:protocols:grpc:exporters:otlp/hny:endpoint: api-dogfood.honeycomb.io:443headers:"x-honeycomb-team": "MY_HNY_KEY""x-honeycomb-dataset": "otel-node"otlp/nr:endpoint: otlp.nr-data.net:4317headers:"api-key": "MY_NR_KEY"service:pipelines:traces:receivers: [otlp]exporters: [otlp/hny,otlp/nr]

因为现在我们的 Node.js 应用程序将向本地主机上的收集器发送数据，所以我们需要更新我们的 gRPC 凭据以使其不安全。

// tracing.jsconst traceExporter = new CollectorTraceExporter({ credentials: credentials.createInsecure(),});

最后，我们将端点交换为收集器地址。

export OTEL_EXPORTER_OTLP_ENDPOINT=localhost:4317

摆脱供应商锁定的循环

本博客中的示例是一个微不足道的示例，但想想数十个，或数百个微服务端点和代码路径，这些端点和代码路径可能完全不知道您的跟踪后端。使用 OpenTelemetry，无需将特定于供应商的逻辑硬编码到您的应用程序中。

OpenTelemetry 使您能够对遥测数据拥有更多代理权，并在选择供应商，或多个供应商时成为可能。

可以在 ​​OpenTelemetry 官网​​ 上了解有关该项目的更多信息。

翻译自

原文：​​https://thenewstack.io/opentelemetry-otel-is-key-to-avoiding-vendor-lock-in/​​

关注

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。