上线一个新的遥测系统可能是一项复杂的工作。它需要整个工程组织的支持，不能一蹴而就。不要低估这可能会产生的问题！

在大型组织中，通常有许多服务团队负责系统的不同部分。通常情况下，每个团队都需要付出一定的努力来使他们所管理的服务得到充分的工具化。而这些团队都有自己积压的工作，他们当然希望能够优先处理这些工作。

不幸的是，可观测性计划在开始提供价值和证明其价值之前就会耗尽人的耐心。但通过仔细的计划和协调，这种情况是可以避免的。

主要目标

在推广 OpenTelemetry 时，重要的是要记住，任何基于分布式追踪的可观测性系统都需要对参与事务的每个服务进行检测，以提供最大价值。如果只有部分服务被检测到，那么追踪就会被分割成小的、不相连的部分。

这种散乱的仪表的结果是不可取的。这种情况——不一致的仪表和断裂的追踪是你想要避免的主要事情。如果追踪是断开的，运维人员仍然需要在他们的头脑中把所有的东西拼凑起来，以获得他们系统的情况。更糟糕的是，自动分析工具可以使用的数据非常有限。与人类运维人员不同，他们可以运用直觉，跳出框框来思考问题，而分析工具却只能使用他们得到的数据。由于数据有限，他们提供有用的见解的机会也将是有限的。

为了避免这个陷阱，集中精力对一个工作流程进行检测，在进入下一个工作流程之前对其进行完整的追踪。大多数工作流程并不涉及大系统的每一个部分，所以这种方法将最大限度地减少分析开始和价值实现之前所需的工作量。

选择一个高价值的目标

谈到实现价值，在开始进行仪表测量工作时，重要的是要有一个有吸引力的目标！这一点很重要。

最有可能的是，有一个特别的问题促使人们去部署 OpenTelemetry。如果是这样的话，就把重点放在解决该问题所需的最小的推广上。否则，想一想那些众所周知的问题，解决它们就值得公布了。

目前有哪些痛苦的、长期的问题在困扰着运维？减少系统延迟在哪里可以直接转化为商业价值？当人们问 “为什么这么慢？” 时，他们说的是系统的哪一部分？在选择第一个工作流程时，请以这些信息为指导。

识别一个有吸引力的目标有两个好处。首先，它可以更有利于说服众人，因为有一个具体的理由来做这项工作。这使得它更容易说服有关团队优先考虑增加指导，并以协调的方式进行。

第二，速战速决给你的新的可观测性系统一个闪亮的机会。第一次通过分布式追踪的视角来分析一个软件系统时，几乎总是会产生有用的见解。证明可观测性的价值可以引起很多人的兴趣，并有助于降低采用时任何挥之不去的障碍。

如果直接进入生产是困难的，“生产支持” 系统也是一个好的开始。可以对 CI/CD 系统进行检测，以帮助了解构建和部署的性能。在这里，整个组织都会感受到性能的大幅提升，并可以为将 OpenTelemetry 转移到生产中提供良好的理由。

集中遥测管理

展开和管理遥测系统从集中化中获益良多。在一些组织中，会有一个平台或信息结构团队可以接触到每一项服务。像这样的团队是集中管理遥测的一个好地方，这可以提供巨大的帮助。遥测管道最好被认为是它自己的系统；允许一个团队操作整个遥测管道，往往比要求许多团队各自拥有系统的一部分要好。

在软件层面，将 OpenTelemetry 设置与已经广泛部署的代码管理工具——例如共享的启动脚本和应用框架整合起来，减少了每个团队需要管理的代码量。这有助于确保服务与最新的版本和配置保持同步，并使采用更加容易。

另一个关键工具是一个集中的知识库。OpenTelemetry 有文档，但它是通用的。创建特定于在你的组织内部署、管理和使用 OpenTelemetry 的文档。大多数工程师都是第一次接触 OpenTelemetry 和分布式追踪，这对他们的帮助怎么强调都不为过。

先广度后深度

还有一个关于合理分配精力的说明。当对一个工作流程进行端对端检测时，通常只需安装 OpenTelemetry 附带的仪表，加上你的组织所使用的任何内部或自创框架的仪表即可。没有必要深入检测应用程序代码，至少在开始时没有必要。OpenTelemetry 附带的标准跨度和指标足以让你识别大多数问题；必要时可以有选择地增加更深层次的检测。在添加这种细节之前，请确保你已经建立并运行了端到端的追踪。

这就是说，有一个快速的方法可以为你的追踪增加很多细节，那就是把任何现有的日志转换成追踪事件。这可以通过创建一个简单的日志附加器来实现，它可以抓取当前的跨度，并将日志作为一个事件附加到它上面。现在，当你查找追踪时，你所有的应用日志都可以得到，这比在传统的日志工具中寻找它们要容易得多。OpenTelemetry 确实为一些常见的日志系统提供了日志附加程序，但它们也很容易编写。

与管理层合作

如果你是一个工程师在读这篇文章，我有一个补充说明。推广一个新的遥测系统可能需要组织很多人。幸运的是，有些人已经在做这种组织工作了 —— 经理们！这就是我们的工作。

但是，如果你想启动其中的一个项目，说服工程或项目经理来帮助你是很好的第一步。他们将对如何完成项目有宝贵的见解，并能在你可能不参加的会议上推销该项目。有时候，组织人比组织代码更难，所以不要害怕寻求帮助！

加入社区

最后，在个人和组织层面上，考虑加入 OpenTelemetry 社区！维护者和项目负责人都很友好，非常平易近人。社区是一个很好的获取援助和专业知识的资源的地方；我们总是很乐意帮助新的用户得到指导。还有一种汗水文化：如果有你想看到的 OpenTelemetry 功能，加入一个工作组并提供帮助是使它们得到优先考虑的一个好办法。

至少，一定要给我们反馈。我们从用户那里听到的越多，我们就越能专注于最重要的问题。我们的目标是建立一个推动下一代可观测性的标准。没有你，我们做不到，我们的大门永远是敞开的。

谢谢你的阅读

我希望你喜欢这份关于 OpenTelemetry 的可观测性的未来的报告。如果你有任何问题、评论、反馈或基于你所读的内容的灵感，请随时在 Twitter 上与我联系，我是 @tedsuo。

要想获得 OpenTelemetry 的帮助，请加入云原生计算基金会（CNCF）Slack 上的 #OpenTelemetry 频道。我希望能在那里见到你！