终端用户问答系列：在 Uplight 使用 OTel

作者：Adriana Villela (Lightstep) |

博客文章在发布后不会更新。这篇文章已经发布一年多了，其内容可能已过时，部分链接可能无效。在依赖任何信息之前，请务必核实。

由 Rynn Mancuso (Honeycomb) 和 Reese Lee (New Relic) 贡献。

2023 年 3 月 2 日，星期四，OpenTelemetry (OTel) 终端用户工作组举办了 2023 年第二次终端用户问答会议。本系列是每月一次与在生产环境中\使用 OpenTelemetry 的团队进行的非正式讨论。目的是更多地了解他们的环境、他们的成功以及他们面临的挑战，并与社区分享，以便我们共同努力，让 OpenTelemetry 变得更棒！

本月，我采访了 Doug Ramirez，他是 Uplight 的首席架构师。

概述

Doug 热爱可观察性，也因此热爱 OpenTelemetry，因为他从获得对他编写的代码的反馈中感到兴奋。

在本次会议中，Doug 分享了：

  • 他的组织在 OpenTelemetry 方面的历程
  • 他是如何像福音传道者一样在 Uplight 推广 OpenTelemetry 的
  • 他在 Uplight 的 OpenTelemetry 历程中遇到的挑战，以及一些改进建议。

问答

请介绍一下您的角色？

Uplight 由多家公司组成，这些公司通过合并和收购聚集在一起，现在都归于 Uplight 品牌之下。它的使命是通过帮助公用事业公司运营其电网以最大限度地减少资源消耗和抵消二氧化碳排放来拯救地球。该组织有一个主要的数据平台，用于集中存储公用事业公司的海量数据集。随着 Uplight 的发展，其数据平台已成为一个极其重要的组成部分，它支持最终为客户提供价值的应用程序。

Doug 作为该平台首席架构师的角色是，帮助以满足业务需求的方式设计和构建平台，同时允许开发人员轻松地利用该平台。为了实现这一点，他已将可观察性作为一项架构特性进行了优化，在过去一年中花费了大量时间讨论和思考可观察性，并将其融入到一切工作中。

您认为可观察性将帮助您解决哪些问题？

由于 Uplight 是一个公司联合体，这意味着存在不同的技术栈、不同的设计模式和解决相同问题的不同方法。

尽管拥有所有这些具有不同技术栈的系统，Doug 认为观察它们作为一个整体协同工作的能力至关重要。他希望为公司内的开发人员创造相同的代码观察体验，无论他们使用何种技术栈——即，一种通往可观察性的通用路径。这正在通过依赖 OpenTelemetry 作为实现这一目标的标准和工具来实现。

您的架构是怎样的？

Uplight 使用“一切”，包括大量的 Ruby、Java、Python，一些 .NET，因此很难描述其技术栈。有很多遗留代码。有许多单体应用。新的开发工作使用 Python 编写，并且他们正在利用 FastAPI 进行微服务工作。

由于使用了如此多的不同语言和框架，问题是如何将可观察性和 OTel 注入或嵌入到这些不同的平台中？

最终目标是让人们理解 OpenTelemetry 和围绕可观察性的长期愿景。大多数开发人员都熟悉并习惯于日志——他们只是想写一个日志并看看会发生什么。因此，Doug 从让开发人员将 OpenTelemetry (结构化)日志添加到他们各种平台的所有服务中开始。为了利用 OTel 日志，开发人员必须将 OpenTelemetry 特定语言的 SDK 添加到他们的代码中。一旦他们越过了最初的障碍并将 SDK 添加到代码中，开发人员就可以更容易地将 其他信号 (例如 指标和 跟踪) 添加到代码中，因为 OTel 的脚手架已经到位了！

Doug 和他的团队意识到，结构化日志记录的问题已经被 OpenTelemetry 解决了。贡献者和维护者对日志记录和结构标准化进行了长时间深入的思考，没有必要重新发明轮子。日志规范已经存在，因此 Uplight 选择搭乘 OTel 的顺风车，以便开发人员能够更快、更轻松地实现他们的可观察性路径。再次强调，在采用 OpenTelemetry 日志的同时，采用 跟踪和 指标也成为了一个自然的下一步。

您的构建和部署流程是怎样的？

构建使用 CircleCI 和 Jenkins 进行。一切都在容器中运行，并且他们使用所有云提供商。他们正在努力标准化部署到云的工具和流程。

OTel 日志相对较新。为什么使用如此新的东西？

作为 较新的 OpenTelemetry 信号之一，日志的成熟度引起了很大担忧。还有许多人担心 OTel 本身是否会消失，或者日志是否会被从规范中删除。一旦 Uplight 的人员开始探索和使用日志关联——即，将日志链接到跟踪——所有这些不安都得到了平息。

在走向 OTel 的道路上，遇到过哪些挑战？

Uplight 内部面临的最大挑战之一是在发出有意义的遥测数据以实现可观察性的同时，抵制供应商锁定。Uplight 的一些人认为他们 APM 供应商提供的 SDK 可以胜任工作；然而，这意味着供应商锁定。

提供良好的开发人员体验至关重要。重要的是向开发人员展示他们可以使用已成为仪器化事实标准的框架轻松地仪器化他们的代码，并且该框架还具有可移植性，因此不会让他们被锁定在某个特定供应商中。

开发人员的心态开始转变，因为他们能够亲身体验 OpenTelemetry 的运行

  • 看到结构化日志，能够关联跟踪和日志，以及发出指标。
  • 体验 上下文传播的好处——即，跨不同操作的 span 和跟踪交互，以提供服务调用的端到端视图。

您是如何在组织内部推广 OpenTelemetry 的？

关于 OpenTelemetry 是否足够成熟以值得采用，内部有过很多争论。因此，Doug 花了大量时间教育人们了解 OpenTelemetry，以表明 OpenTelemetry 并非是崭新事物（它已经存在了一段时间），并且得到了主要可观察性供应商的支持。事实上，这些供应商都在他们的博客上谈论它。这些努力获得了 Uplight 领导层和工程师的认同。

Doug 在 Uplight 的主要架构目标是可观察性、可部署性和安全性。可观察性叙述的一部分包括谈论 OpenTelemetry 并向人们展示它的工作原理。为此，Doug 创建了许多短的内部 Loom 视频，灵感来自 Microsoft 的 Channel 9。Loom 视频已成为在整个组织中非常有效地快速共享 OpenTelemetry 信息（理论和代码片段）的方式。它们受到了极大的欢迎。视频主题包括结构化日志记录、指标、跟踪以及分布式跟踪与 webhook 平台的集成。

内部黑客马拉松也已被证明是推广 OpenTelemetry 并让人们使用它的非常有效的方式。

开发人员在将 OTel SDK 集成到应用程序代码中时，体验如何？

Doug 在 OpenTelemetry 方面的目标之一是围绕实现语言 SDK 创建一个愉快的开发人员体验。关于共享库是否有助于降低实现 OTel SDK 的门槛，内部有过很多争论。最终决定让团队选择自己的路径：一些团队正在实现 Uplight 共享库，另一些团队正在利用 Doug 创建的参考架构中的代码片段，还有一些团队直接使用 SDK。

Doug 的主要经验是让人们立即开始使用 OpenTelemetry，熟悉它，而不用担心创建共享库。

手动还是自动仪器化？

Uplight 的人员使用了手动和自动仪器化的结合。Doug 的主要建议是进行最少量的必要工作来启动仪器化，进行最少量的必要工作来发出和关联跟踪和日志，然后根据需要进行优化。

SDK 提供了您需要的一切。您可以决定在此基础上优化多少。Doug 的建议是进行最少量的必要工作来开始

您如何部署您的 OTel Collector？

Uplight 目前有几种不同的 Collector 配置

Doug 的最终目标是让任何环境中的任何部署都能轻松地将遥测数据发送到 OTel Collector 网关。

Collector 在 Uplight 通常由基础设施团队运行和维护，除非各个团队决定拥有自己的 Collector。那些拥有自己 Collector 的团队迄今为止取得了积极的经验。Uplight 可能会在稍后重新考虑开发团队是否应该拥有自己的 Collector，但目前，让开发人员快速启动 Collector 更重要，以进一步推广 OpenTelemetry。

反馈

社区参与

Doug 到目前为止在 OpenTelemetry 方面获得了非常积极的体验。他很高兴看到 OTel 社区在 CNCF Community Slack 上非常活跃，并建议任何刚接触 OpenTelemetry 的人加入一些 OTel 频道（例如 #otel-collector、#otel-logs、#otel-python）并看看人们在谈论什么。各个频道中的对话有助于指导他在 Uplight 的决策。

贡献

Doug 对 Python SDK 做出了一些贡献；然而，理解贡献的流程花了一些时间。他最初不确定如何参与，在 Slack 上找谁，以及如何催促人们审核他的 PR。任何能让人们超级容易和明确地做出贡献的事情都会非常有帮助。

沟通

Doug 发现很难确定在哪里进行某些类型的对话。是 GitHub 问题，还是 Slack？对于想做出贡献的新人来说，应该去哪里？如果有人是 OTel 的新手并且遇到了问题，应该去哪里？如何确保对话不重复？

简单的参考实现

Doug 希望看到非常简单的参考实现，以帮助那些从头开始学习 OTel 的人。例如，他们运行一个简单的“Hello World”程序将数据发送到 Collector，但没有任何显示，需要一些指导。我们如何帮助那些不熟悉 Docker 也不熟悉 OpenTelemetry 的人？我们能否提供一些非常简单的参考实现来指导他们入门？例如，对于 Ruby 开发人员，克隆 X 仓库，运行 docker compose up1，一切都会启动并运行。这样，他们就可以专注于学习 OpenTelemetry，而不是纠缠于 Docker 网络和其他分散注意力的东西。

我与 Doug 分享了我们有 OTel Demo App（以及 Slack 上的 #otel-community-demo 频道），它提供了一个“一站式”OTel 示例。我还分享了 #otel-config-file Slack 频道，该频道旨在简化 OTel 的引导过程。

Doug 希望看到更具针对性的、特定语言的“一站式”示例。例如，一个 FastAPI 示例，包含 2 个相互通信的 Python 服务，以演示上下文传播，通过 Collector，然后将跟踪发送到 Jaeger。

下一步？

如果您想完整地了解我与 Doug 的对话，有一个 视频。

如果您想继续与 Doug 交流，请在 #otel-user-research Slack 频道联系他！

另外，请务必查看本月 OTel 实践系列（3 月 27 日，太平洋时间上午 9 点/东部时间上午 11 点）中 Doug 的更多 OTel 冒险故事。

最后的想法

OpenTelemetry 关乎社区，没有我们的贡献者、维护者和用户，我们就不会有今天的成就。听到 OpenTelemetry 如何在现实生活中实现的案例只是图景的一部分。我们重视用户反馈，并鼓励所有用户与我们分享您的经验，以便我们能够继续改进 OpenTelemetry。❣️

如果您有关于您如何在组织中使用 OpenTelemetry 的故事要分享，我们很乐意倾听！分享方式

请务必在 Mastodon 和 Twitter 上关注 OpenTelemetry，并使用 #OpenTelemetry 标签分享您的故事！

  1. docker-compose 已弃用。有关详细信息，请参阅迁移到 Compose V2。 ↩︎

最后修改日期：2025 年 5 月 27 日：[chore] Accessible links 5 (#6053) (860f5141)