OpenTelemetry 兴趣日益增长

在过去三年中，对 OpenTelemetry 的认知、兴趣和采纳速度增长迅速。这体现在广泛的指标中。例如，在过去 12 个月里，OpenTelemetry 的每月网络搜索量翻了一番。OpenTelemetry Collector 作为用于接收、处理和导出数据的组件，在与 OpenTelemetry 相关的八大热门搜索词中占比 45%，“instrumentation”（用于基础设施和应用程序埋点的 API）占比 17%。

OpenTelemetry 相关热门搜索词

Bar chart showing top search terms for OpenTelemetry — *来源：Google Trends*

网络搜索量同比增长 100%

Line graph showing increase in web searches for OpenTelemetry — *来源：Google Trends*

探索 OpenTelemetry 的前 3 大搜索词

1. Collector

设置 Collector 并对应用程序代码和基础设施进行埋点是实现最佳可观测性的两个关键先决条件。例如，OpenTelemetry 提供了用于对 SQL 数据库（如 PostgreSQL、MySQL 和 Microsoft SQL Server）进行埋点的库，以收集遥测数据。要对数据库进行埋点，您需要使用 OpenTelemetry 提供的 API 连接到数据库。为了简化开发人员的操作，OpenTelemetry 提供了用于自动化埋点和手动埋点的库。虽然自动化埋点不需要修改代码，但它不能像手动埋点那样对遥测数据输出提供细粒度的控制。例如，用于数据库查询的自动化埋点库可以捕获查询类型、持续时间和基本错误信息，而手动埋点可以提供实际的 SQL 语句、变量、受影响的行以及大量自定义指标，例如缓存命中次数或查询不同部分的执行时间。下面的技术亮点表提供了十个示例，说明自动化提取的数据与开发人员添加埋点代码提取的遥测数据之间可能存在的差异。

OpenTelemetry Collector 网络搜索

主题	描述
1. OpenTelemetry 接收器	集成包括配置接收器以从各种源收集遥测数据，确保与不同云环境和数据格式的兼容性。
2. OpenTelemetry 导出器	侧重于设置导出器，将收集到的数据发送到各种后端或分析工具，适应不同的输出要求。
3. 容器运行时	需要确保 OpenTelemetry 能够有效地从容器中收集数据，同时考虑到特定运行时环境的细微之处。
4. Kubernetes 容器编排	涉及与 Kubernetes 集成，以有效地监控和追踪容器化应用程序和编排过程。
5. 不同编程语言	需要确保 OpenTelemetry SDK 在云环境中使用的各种编程语言中具有兼容性和效率。
6. 面向 Kubernetes 的 Prometheus 指标	集成需要与 Prometheus 兼容，以便收集和导出指标，尤其是在 Kubernetes 环境中。
7. Grafana 仪表盘	涉及配置 OpenTelemetry 以导出可有效在 Grafana 仪表盘中可视化的数据格式。
8. 公有云基础设施	需要调整 OpenTelemetry 以与公有云提供商提供的服务和功能无缝协作。
9. 代码仓库	涉及确保从代码仓库中有效捕获遥测数据并将其集成到监控系统中。
10. 传统可观测性	需要将 OpenTelemetry 与现有可观测性平台集成，确保无缝的数据收集和分析。
11. Service Mesh	涉及配置 OpenTelemetry，以监控和追踪 Service Mesh 架构内的服务间通信。
12. Kafka 消息总线	需要设置 OpenTelemetry，以有效地监控和追踪流经 Kafka 消息总线的消息流。

2. 埋点

OpenTelemetry 埋点网络搜索

主题	描述
1. 开发语言	埋点必须兼容所有主流开发语言，以确保无论使用何种编程语言，都可以捕获遥测数据。这包括 Java、Python、Go、JavaScript/Node.js 和 .NET 等语言。
2. 数据库技术	埋点必须涵盖各种数据库技术，以便对 SQL 和 NoSQL 数据库（如 PostgreSQL、MongoDB、Cassandra 等）进行监控并收集指标和查询。
3. Kubernetes	埋点应能与 Kubernetes 容器调度器集成，以在容器和编排层收集指标和日志，提供对部署、Pod 和服务的可见性。
4. GitHub	埋点应能跟踪 GitHub 源代码仓库内的更改和事件，从而实现对代码提交、拉取请求和其他仓库相关活动的分析。
5. AWS SDK	埋点需要支持 AWS SDK，以便从利用 AWS 服务的应用程序中收集遥测数据，从而增强对云资源和交互的监控。
6. 消息总线	埋点还必须涵盖消息总线技术，例如 Kafka、RabbitMQ 和 ActiveMQ，以监控和收集消息吞吐量、延迟和处理等数据，这对于理解系统通信和性能至关重要。

基于 OpenTelemetry Google Trends 的主题图

Topic map for OpenTelemetry instrumentation Google Trends — *来源：Google Trends*

3. 导出器

OpenTelemetry 导出器网络搜索

主题	描述
1. 主要导出目标	Jaeger、Prometheus、Loki、Elastic、Datadog、Tempo、CloudWatch 和 Zipkin 等节点直接连接到 OpenTelemetry Exporter 节点，表明用户经常搜索如何将遥测数据导出到这些特定后端。这反映了 OpenTelemetry 与各种可观测性平台之间互操作性的需求。
2. 编程语言	Python 和 Node.js 等节点表明用户对如何在这些编程语言中实现 OpenTelemetry 导出器感兴趣。这突显了将 OpenTelemetry 集成到多样化应用堆栈中对特定语言指导的需求。
3. 导出类型	日志、指标和追踪等术语连接到中心节点，这意味着用户正在寻找有关导出这些特定类型遥测数据的信息。了解每种数据类型的细微之处对于有效的监控和分析至关重要。
4. 云服务	AWS CloudWatch 和 Azure Monitor 等节点表明用户对将遥测数据导出到云服务提供商感兴趣。这预示着云原生应用的增长趋势以及对无缝云集成的需求。
5. 配置和定制	configuration、custom 和 application 等节点的存在表明用户正在寻找配置和定制 OpenTelemetry 导出器的方法。定制导出器设置对于优化数据收集以适应特定操作要求至关重要。
6. OTLP	OTLP (OpenTelemetry Protocol) 节点连接到中心 OpenTelemetry 导出器节点，表明与用于导出遥测数据的协议相关的搜索。OTLP 是 OpenTelemetry 项目中的一个关键协议，旨在实现高性能和供应商中立的数据传输，这对于希望跨不同系统和平台标准化遥测数据导出的用户至关重要。

基于 Google Trends 的 OpenTelemetry 导出器主题图

Topic map for OpenTelemetry Exporter Google trends — *来源：Google Trends*

OpenTelemetry 焦点：自动化埋点 vs. 手动埋点

一般来说，自动化埋点库是建立基本可观测性的绝佳起点，因为它们无需开发人员参与即可提供遥测数据。然后，开发人员可以根据自身需求添加手动埋点，以便更好地了解应用程序性能、用户体验和健康状况。

主题遥测元素	自动化埋点输出	手动埋点输出
1. HTTP 请求	捕获方法、URL、状态码和持续时间	捕获方法、URL、状态码和持续时间，外加自定义请求头、载荷大小和用户特定属性
2. 数据库查询	捕获查询类型、持续时间和基本错误信息	捕获详细查询语句、绑定变量、受影响的行以及自定义指标，如缓存命中次数
3. 应用程序启动时间	捕获应用程序启动时的时间戳	捕获应用程序版本、环境详细信息和自定义初始化参数
4. 异常处理	捕获异常类型和堆栈跟踪	捕获异常上下文、用户影响、自定义错误码和已采取的补救措施
5. 用户认证	捕获认证成功或失败以及方法（例如 OAuth、SAML）	捕获用户角色、会话时长和自定义安全检查
6. 外部 API 调用	捕获端点、状态码和持续时间	捕获端点、状态码、载荷、API 版本和自定义请求头
7. 缓存访问	捕获缓存命中或未命中以及访问时间	捕获缓存命中率、淘汰次数和自定义缓存性能指标
8. 消息队列处理	捕获消息大小和处理时间	捕获消息元数据、处理逻辑路径和自定义消息处理指标
9. 批处理作业执行	捕获作业开始和结束时间以及成功或失败状态	捕获作业参数、中间状态、自定义进度指标和资源使用情况
10. 自定义业务逻辑执行	除非与埋点库或框架交互，否则可能无法捕获	捕获特定函数的执行时间、业务交易详情和自定义业务结果指标

OpenTelemetry 作为云原生应用堆栈的一部分

基于对芝加哥 KubeCon 2023 大会上所有 311 场官方会议的完整分析，网络图展示了各种可观测性主题相互关联的特性，其中 OpenTelemetry 是众多关键领域的中心，如服务、指标和追踪。OpenTelemetry 与负载均衡、性能和分析等其他关键性能和部署考虑因素之间的紧密性和联系，强化了它在 Kubernetes 领域的中心地位。这种关联表明 OpenTelemetry 不仅仅是一个独立的主题，而是与一系列对于 Kubernetes 应用程序有效运行至关重要的实践和技术深度集成。

如图表所示，eBPF（Extended Berkeley Packet Filter）与 OpenTelemetry 之间的联系尤为值得关注。eBPF 在条形图中的重要性位列第三，表明其在 Kubernetes 可观测性领域具有高度的兴趣和相关性。鉴于 eBPF 在不修改内核或安装额外模块的情况下提供低级别系统追踪和网络流量监控的能力，它是可观测性的强大工具。当与 OpenTelemetry 集成时，eBPF 可以增强收集到的遥测数据，从而实现更复杂和细粒度的可观测性解决方案。这种结合使开发人员和运维人员不仅能够以极低的性能开销观察其系统，还能在 eBPF 提供的细粒度级别收集洞察信息，从而显著提高 Kubernetes 应用程序的可观测性和故障排查能力。

图表表明，社区认可 eBPF 与 OpenTelemetry 之间的协同作用是实现更深入的系统可见性和高级性能分析的宝贵组合。

芝加哥 KubeCON 2023 的十大可观测性主题

Bar chart for top observability topics and technologies at KubeCON 2023 — *来源：芝加哥 KubeCon 2023 会议目录*

跨 Subreddit 的 OpenTelemetry 十大主题：优点、缺点和不足

利用 GPT-4 大型语言模型 (LLM) 提取讨论 OpenTelemetry 的所有 221 个 Subreddit 中 1,000 篇帖子中的 10 个关键主题，我们发现“局限性和挑战”是排名第一的主题。

Bar chart of top OpenTelemetry topics on Reddit — *来源：Reddit*

讨论 OpenTelemetry 的前 25 个 Subreddit

Chart showing subreddit OpenTelemetry topics — *来源：Reddit*

这并不令人意外，因为 a) OpenTelemetry 仍然是一个新平台，目前的采纳速度很快，b) 专业人士经常在 Reddit 上发帖寻求建议，甚至发泄不满。考虑到这一点，通过分析我们分析的 1,000 篇帖子中提炼出的 10 个关键主题，我们仍然可以学到许多有趣且富有成效的经验教训。

1. 在生产环境中的采纳和利用：组织正寻求将其 OpenTelemetry 部署从实验状态转向生产环境。OpenTelemetry 的目标是成为在数据中心、云端和边缘跨基础设施和应用程序收集、处理和导出遥测数据的标准。跨团队采纳一个统一的可观测性标准，使组织能够节省成本和资源，简化监控流程，并降低管理多个可观测性工具的复杂性。这种标准化还有助于促进团队之间更好的协作和知识共享，从而提高问题解决效率，并使整个组织对系统性能有更统一的理解。此外，通过统一的方法，组织可以利用更深入的洞察和更有意义的数据关联，从而在快速发展的技术环境中改进决策制定和运营敏捷性。

2. 分布式追踪和埋点：讨论重点活跃于微服务中的分布式追踪，强调适当的埋点、与不同后端的集成以及追踪数据优化。还探讨了在 Amazon SQS 等场景中追踪传播的解决方案。这些讨论对于增强复杂分布式系统中的性能监控和调试至关重要。

3. 供应商适配和比较：OpenTelemetry 的供应商中立性是一大优势。讨论涉及不同可观测性平台如何与 OpenTelemetry 集成，为开发人员提供灵活性和多样化的选择。这种适应性使组织能够根据其特定需求定制其可观测性堆栈。

4. 社区支持和资源共享：社区积极分享教程、博客文章和文档，同时进行社区电话会议和 Meetup，营造协作学习环境。这种分享文化不仅加速了 OpenTelemetry 的采纳，还丰富了集体知识库。

5. 测试策略：探讨 OpenTelemetry 和埋点系统的测试方法，包括黑盒和基于追踪的方法，以确保发布可靠性和可维护性。这些策略对于在软件发布和持续部署流程中维持高质量标准至关重要。

6. 局限性和挑战：沟通在指标导出配置、日志集成和追踪数据管理等领域的局限性及改进需求。解决这些挑战是增强 OpenTelemetry 在大型环境中的可伸缩性和可靠性的关键。

7. OpenTelemetry 的能力和增长：概述 OpenTelemetry 在收集追踪、日志和指标方面的能力，并指出其增长和行业认可。其不断演变的特性和行业采纳使其成为未来云原生可观测性的基石技术。

8. 集成和可用性：强调 OpenTelemetry 作为一个全面的开源框架，可跨语言标准化遥测并支持各种后端服务，从而增强可观测性和监控。这种集成能力对于确保跨多语言应用环境实现无缝可观测性至关重要。

9. 实际应用和部署：展示在生产环境中的实际用例，有效集成 Kubernetes 和 Istio 等工具，展示其在技术运营中的实际价值。这些实际案例突显了 OpenTelemetry 在简化现代基础设施中复杂可观测性挑战方面的作用。

10. 教育资源和社区参与：强调对教育内容和社区参与的需求，以应对 OpenTelemetry 的复杂性，并为其发展和完善做出贡献。社区的积极参与对于推动 OpenTelemetry 的持续演进和可用性至关重要。

Reddit 上 OpenTelemetry 的十大主题

OpenTelemetry topic map from Reddit — *来源：Reddit*

对 Reddit 上十大 OpenTelemetry 讨论的分析表明，企业正积极探索集成这一新软件平台的复杂性。尽管热情高涨，但由于生产经验有限和文档不足，转型过程充满挑战。此外，代码库某些部分的新颖性增加了难度。OpenTelemetry 的全部潜力只有在与现有企业系统深度集成时才能实现，这是一个微妙的过程，目前组织正在努力掌握。

商业视角

从 Hacker News 论坛（1,350 篇帖子）关于 OpenTelemetry 的讨论中提取的词云（见下文）提供了对 Hacker News 参与者（包括技术人员、创业者和投资者）兴趣和重点的洞察。追踪和指标等词汇的突出表明了他们对监控和管理云原生应用程序技术方面的浓厚兴趣。这种关注对于希望了解软件系统的运行状况和性能的投资者和技术领导者尤为重要，因为这些是技术投资风险评估和决策的关键因素。

Word cloud for OpenTelemetry topics on Hacker News — *来源：Hacker News*

Bar chart of OpenTelemetry topics on Hacker News — *来源：Hacker News*

词云中包含 Kubernetes、Datadog、Java、Python 和 AWS 等特定技术，表明讨论是基于实际应用和集成。这表明 Hacker News 社区不仅对 OpenTelemetry 的理论方面感兴趣，还对其在各种平台和语言中的实际实现感兴趣。对于更高层次的技术人员和投资者来说，这转化为关于如何利用 OpenTelemetry 增强其正在使用或考虑投资的技术堆栈的可观测性的丰富信息来源。

Line graph showing increase in discussions about OpenTelemetry on Hacker News — *来源：Hacker News*

最后，开源、社区、支持和集成等词汇的存在突显了 OpenTelemetry 项目及其生态系统的协作性质。这强调了社区驱动创新的价值以及技术长期可持续性和支持的潜力。Collector 一词指向关于 OpenTelemetry Collector 的具体讨论，对希望了解项目技术基础和能力的那些人来说很有意义。总的来说，词云表明 Hacker News 论坛是关于 OpenTelemetry 的高级讨论中心，提供了对社区中技术和投资导向成员都有价值的见解。

下一篇：OpenTelemetry 和开源社区增长