代码部署后，开发和运维的真正工作才开始，这提升了可观测性对应用程序性能的重要性。
译自 OTel Is the Secret to DevOps Success，作者 Clay Roach。
过去“开发人员编写代码，运维人员运行代码”的界限已经不存在了。如果你编写、设计或贡献应用程序，你对应用程序在生产中的执行负有一定的责任。在某些时候，你会被要求诊断和修复它。
在创建应用程序时，开发人员需要从一开始就树立这样的心态：真正的工作从代码部署后开始。那时，开发人员会看到他们的应用程序在现实世界中的表现，并确保它们提供积极的客户体验。
通过使用 应用程序性能管理 (APM) 工具在前期捕获有关代码和业务流程的详细信息，运维人员可以继承开发人员所做的一切出色、周到的工作。运维人员在事件响应期间可以更快地查明关键问题，从而节省时间和精力。通过访问有助于修复特定于每个应用程序的错误和延迟问题的信息，开发人员和运维人员的生活都变得更加轻松。
从本质上讲，APM 是关于 实现 DevOps 的，而那些在他们开发的应用程序中 构建更好的可观测性 的开发人员将自己置于这种实现的最前沿。
开发和运维：不同的视角
尽管开发人员和运维人员有共同点，但两者仍然从不同的角度进行操作。开发人员将职业生涯投入到创建对业务至关重要的应用程序中。对于每个编写的应用程序，开发人员都希望成为创建者、故障排除者和修复者。
开发人员还希望看到新功能投入生产后使用情况和输入之间的差异。应用程序是否按预期工作？它是否为客户提供价值？应用程序支持的业务流程是否得到改善？
与此同时，运维人员对应用程序和基础设施性能采取整体的视角。一切是否正常运行？基础设施变更是否影响应用程序性能？这个问题是否影响其他服务？我们是否满足客户期望或合同服务级别协议 (SLA)？如果是代码问题，谁需要访问此信息来修复它？
了解这一点，我们如何才能获得开发反馈循环和最佳业务指标，以实现真正的 DevOps？
OTel 的优缺点
要创建不会占用资源的高性能应用程序，关键是要通过 OpenTelemetry (OTel) 等周到的检测来了解生产中的应用程序代码。通过在创建代码时捕获有关应用程序流程和依赖项的详细信息，开发人员可以在以后需要修复问题或提高性能时节省大量时间。
OTel 支持对同一个应用程序同时使用自动和手动检测。这种检测使开发人员能够添加代码片段来捕获和发送特定于其应用程序的自定义指标。
自动检测提供预构建的库或代理，这些库或代理捕获标准指标，例如 CPU 使用率、内存使用率、请求延迟和错误率。自动检测不需要开发人员修改代码，实施起来更简单、更快，但灵活性较差。
手动和自定义检测使 DevOps 团队能够轻松访问有关发生了什么以及原因的详细信息，并以有用的格式呈现。此外，使用 OTel 可以帮助您设计和改进本地和测试环境中的监控，以便您知道在生产中会发生什么。您在不同的环境中不会拥有不同的数据集，因为工具在所有环境中都是相同的。
但是，OpenTelemetry 本身并不知道什么对业务很重要。该技术捕获 SQL 查询、HTTP/TCP 调用、消息传递调用以及硬件和网络信息。OTel 不会捕获用户 ID、非通用元数据或任何特定于您的应用程序和业务的任何内容。
这就是自定义检测发挥作用的地方。自定义检测需要工作和时间来实施，但它使开发人员能够灵活地控制捕获在生产中进行故障排除所需的信息。
现实世界中的例子
为了理解这在实践中是如何运作的，让我们来看一个在线购物车结账。一个交易可能会命中一个端点，四个端点，甚至 10 个或更多端点。这些端点可能会命中其他端点。应用程序可能有一个 Kafka 后端，一个消息总线后端，数据库或 NoSQL 数据库存储，或任何数量的自定义 API 或资源。当客户下订单时，系统会运行所有这些与订单处理、计费、营销和履行相关的特定于业务的应用程序和服务。
那么，当许多用户通过购物车结账时，您如何才能确定，当客户点击购买按钮时，它会正确地触发订单处理、采购、运输、计费以及其他任何需要的操作的完成？最重要的是，您如何知道每个人都被正确地计费？
通过自定义仪器，OTel 使您能够将所有这些不同的应用程序链接在一起，并获得对所有这些不同服务中整个业务交易的整体视图。
OTel 充当 DevOps 之间的桥梁，将开发团队关注的代码内部与您的运维团队监控的网络流量数据和来源连接起来。这种精确的可观测性使 DevOps 能够快速排查和解决问题，并确保应用程序和业务流程得到优化和准确。
自定义仪器还使应用程序能够捕获对您的 DevOps 团队确保出色用户体验至关重要的特定于业务的遥测数据。
使用 OTel 还是不使用 OTel
拥有大型 APM 部署的公司可能已经在员工中拥有高技能的开发人员，他们可以利用 OTel 和自定义仪器来提高 DevOps 效率。
如果您的开发人员没有能力进行自定义仪器，那么让他们学习可能值得。您可以在应用程序中逐步嵌入自定义 OTel 仪器，这将把时间和成本分散到整个开发周期中。
现有的 APM 用户需要考虑更多因素，首先是其 APM 部署的广度。当您监控数千个应用程序时，添加 OTel 功能无疑会更加复杂，并且费用可能会被视为过高。这些公司可以在其应用程序的子集中测试 OTel 增强型 APM 的优势，或者在开发或通用可用性环境中使用低成本的开源监控替代方案。
OpenTelemetry for DevOps：下一步
OTel 的目标是标准化遥测数据的收集和导出，以便组织能够灵活地选择其后端 APM 或可观测性解决方案。随着对分析的支持的增加，分析在运行时动态检查应用程序代码的行为和性能，OpenTelemetry 项目正在扩展功能以匹配商业产品。
持续分析提供了对代码级别资源利用率的洞察，并允许随着时间的推移以及跨不同属性存储、查询和分析分析数据。这些数据使开发人员和运营人员能够将跨服务的资源耗尽或糟糕的用户体验与受影响的特定服务或 Pod 以及导致它的函数或代码行相关联。
无论您的企业是大型还是小型，是 APM 新手还是广泛的 APM 用户，OTel 都可以帮助您以最少的额外代码或工作量来实现可观测性的承诺。
