最终用户问答系列：在Uplight使用OTel
借助Honeycomb的Rynn Mancuso和New Relic的Reese Lee的贡献。
2023年3月2日星期四，OpenTelemetry（OTel）最终用户工作组主办了2023年的第二 最终用户问答会议。本系列活动是一个每月举行的轻松讨论，目标是与一个正在生产中使用OpenTelemetry的团队了解他们的环境、成功和面临的挑战，并与社区分享，以便我们共同推动OpenTelemetry的发展！
在本月的活动中，我与Uplight的首席架构师Doug Ramirez进行了交谈。
概述
Doug热爱可观察性，因此也热爱OpenTelemetry，因为通过它可以获得对自己编写的代码的反馈。
在本次活动中，Doug分享了：
- 他的组织在使用OpenTelemetry的过程中的经历
- 他如何在Uplight推广OpenTelemetry
- Uplight在使用OpenTelemetry过程中遇到的挑战以及几点改进建议。
问答
请介绍一下你的角色？
Uplight是一个由多家公司通过合并和收购组成的。现在，所有这些公司以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之后，开发人员的态度开始改变：
- 看到结构化日志，能够关联跟踪和日志，并发出指标。
- 体验到上下文传播的好处，即跨不同操作的跨度和跟踪相互交互，以提供对服务调用的端到端视图。
你如何在整个组织中推广OpenTelemetry？
关于OpenTelemetry是否足够成熟以引起采纳的问题在内部进行了很多讨论。因此，Doug花了很多时间来向大家普及OpenTelemetry，以表明OpenTelemetry不是很激进的技术（它已经存在一段时间了），并且它得到了主要可观察性供应商的支持。事实上，这些供应商都在他们的博客上谈论它。这些努力帮助获得了Uplight的领导层和工程师的支持。
Uplight在Doug的主要架构目标中包括可观察性、可部署性和安全性。可观察性叙事的一部分包括谈论OpenTelemetry并向大家展示它的工作原理。为了做到这一点，Doug制作了一些短小的内部loom视频，灵感来自微软的Channel 9。Loom视频非常有效地在组织中快速传播有关OpenTelemetry的信息（包括理论和代码片段）。它们非常受欢迎。视频的主题包括结构化日志、指标、跟踪以及与Webhook平台集成的分布式跟踪。
内部举办的黑客马拉松活动也被证明是推广OpenTelemetry和让人们使用它的一个非常有效的方法。
开发人员如何评价将OTel SDK集成到应用程序代码中的体验？
Doug在使用OpenTelemetry时的一个目标是为实现语言SDK的实施提供愉快的开发人员体验。关于是否使用共享库来降低实施OTel SDK的门槛，在内部进行了很多讨论。最终决定允许团队选择自己的道路：有些团队正在实施Uplight共享库，有些团队正在使用Doug创建的参考架构提供的代码片段，还有些团队直接使用SDK。
Doug的主要观点是让人们立即开始使用OpenTelemetry，了解它，并不要担心创建共享库。
手动还是自动仪表化？
Uplight的人员使用了手动和自动仪表化的组合。Doug的主要建议是只做最少量的工作，使仪表化开始运行，仅做最少需要的工作以实现跟踪和日志的发出和关联，然后根据需要进行改进。
SDK会提供所需的一切。您决定在此基础上进行多少优化是您的选择。Doug的建议是从最少量的工作开始。
您如何部署OTel Collectors？
Uplight目前有几种不同的Collector配置：
Doug的最终目标是让任何环境中的任何部署都能够轻松地将遥测数据发送到一个OTel Collector网关。
在Uplight，Collectors通常由基础设施团队运行和维护，除非个别团队决定拥有自己的Collectors。迄今为止，那些拥有自己Collectors的团队一直都有积极的体验。Uplight可能会在以后重新考虑开发团队是否应该拥有自己的Collectors，但现在，让开发人员快速创建Collector并且通过Collectors进行进一步的OpenTelemetry采用对于推动更进一步的OpenTelemetry采用更重要。
反馈
社区参与
Doug迄今为止对OpenTelemetry的体验非常积极。他很高兴看到OTel社区在CNCF社区Slack上非常活跃，并建议任何新手只需加入一些OTel频道（例如#otel-collector，#otel-logs和#otel-python）就可以了解人们在谈论什么。各个频道上的对话有助于指导他在Uplight的决策。
贡献
Doug对Python SDK做出了一些贡献，但是要了解如何参与贡献的技术细节花了一点时间。最初，他不确定应该在Slack上和谁交流，以及如何催促他人审查他的PR。任何能够使人们贡献变得简单明了的方法都将非常有帮助。
沟通
Doug发现很难确定应该在哪里进行某些类型的对话。应该在GitHub的问题中进行，还是在Slack中？如果你是一个新人想要做出贡献，你应该去哪里？如果你初次接触OTel并正在遇到问题，你应该去哪里？如何确保对话没有重复？
简单的参考实现
Doug希望看到一些非常简单的参考实现，以帮助那些从零开始使用OTel的人。例如，他们正在运行一个简单的“Hello World”程序以将数据发送到Collector，但什么也没有显示出来，他们需要一些关于此的指导。我们如何帮助那些对Docker不太熟悉、对OpenTelemetry不太熟悉的人们？我们能够提供一些非常简单的参考实现，以便引导他们开始学习OpenTelemetry，而不是为Docker网络和其他分散注意力的事情而劳累。
我向Doug分享了我们的OTel演示应用程序（以及Slack上的#otel-community-demo频道），该应用程序提供了OTel示例的完整实现。我还分享了Slack上的#otel-config-file频道，该频道旨在简化OTel启动。
Doug希望看到更有针对性的、针对特定语言的示例实现。例如，一个FastAPI示例，其中有两个Python服务相互通信，以演示上下文传播，经过Collector发送跟踪到Jaeger。
下一步是什么？
如果您想完整地了解我与Doug的谈话，您可以在这里观看视频。
如果任何人想与Doug继续交流，请在Slack上的#otel-user-research频道与他联系！
另外，一定要参加本月OTel实践系列讨论会议，3月27日，09:00 PT/11:00 ET。
最后的思考
OpenTelemetry全力依靠社区发展，没有贡献者、维护者和用户，我们不可能取得今天的成就。听到OpenTelemetry在实际生活中的应用故事只是一方面。我们重视用户反馈，并鼓励所有用户与我们分享您的经验，以便我们可以不断改进OpenTelemetry。❣️
如果您想分享您的组织如何使用OpenTelemetry的故事，我们非常乐意收到您的分享！分享方式：
- 加入CNCF社区Slack的#otel-endusers频道
- 参加我们的最终用户讨论组电话会议
- 参加我们的OTel实践会议
- 注册参加我们的每月采访/反馈会议
- 加入LinkedIn上的OpenTelemetry小组
- 在OpenTelemetry的博客上分享您的故事
记得在Mastodon和Twitter上关注OpenTelemetry，并使用**#OpenTelemetry**标签分享您的故事！