OpenTelemetry、DevOps 和平台工程


柱状图可视化了 CNCF Slack 中最受欢迎的专注于 OpenTelemetry 主题的频道,按消息频率(表示为“Token”)排名。

Bar chart of top OTel topics on CNCF Slack channels
来源:CNCF Slack

以下是数据显示的感兴趣主题:

1. OTel Collector 焦点

“otel-collector”频道最活跃,表明围绕 OpenTelemetry Collector 的讨论尤为普遍。这可能包括设置、配置和故障排除。

2. 特定语言频道

有几个特定语言的频道,如“otel-ruby”、“otel-python”、“otel-java”、“otel-dotnet”和“otel-js”,表明这是一个充满活力、以语言为中心的 OpenTelemetry 社区。这反映了在这些不同编程生态系统中如何实现和使用 OpenTelemetry 的积极参与。

3. 社区和演示

“otel-community-demo”频道的活跃程度表明人们对 OpenTelemetry 的使用演示和实际示例很感兴趣,这对于社区教育和采用至关重要。

4. Operator 和基础设施

“otel-operator”和“otel-go”等频道的存在表明人们正在讨论 OpenTelemetry 在 Go 环境中的操作方面和具体实现。

5. 插桩和自动插桩。

“otel-java-instrumentation”和“otel-dotnet-auto-instrument”等频道表明重点关注 OpenTelemetry 的插桩方面,包括捕获遥测数据的自动化解决方案。

6. 多样化主题

各种频道,包括专注于“otel-logs”、“otel-metrics”以及供应商特定频道(如“otel-newrelic”)的频道,展示了从日志和指标到 OpenTelemetry 如何与第三方监控服务集成等广泛讨论。

7. 专题讨论

“otel-specification”、“otel-maintainers”和“otel-semantic-conventions-wg”等频道的存在表明存在专题讨论,可能涉及 OpenTelemetry 规范及其语义约定的开发和治理。

该图表表明 OpenTelemetry 社区在 Slack 上活跃于广泛的主题,从通用使用和实现到深入的技术规范和特定语言的问题。这表明这是一个多样化且积极参与的社区,专注于在各种用例和技术堆栈中充分利用 OpenTelemetry。

面向 DevOps 和平台工程的关键 OpenTelemetry 主题

下图是基于 OpenTelemetry 相关 Slack 帖子讨论的主题网络可视化图。

Topic map for OTel topics on CNCF Slack
来源:CNCF Slack

我们可以从中推断出以下内容:

1. 关键组件

标有“collector”、“exporter”、“trace”、“telemetry”和“instrumentation”的突出节点表明这些是 OpenTelemetry 讨论中的核心主题。这表明遥测数据(包括追踪)的收集和导出以及插桩过程是社区关注和挑战的核心。

2. 集成与支持

图中有各种技术和协议的节点,如“grpc”、“http”、“otlp”和“prometheus”,这表明将 OpenTelemetry 与这些协议和工具集成是一个重要的讨论点。

3. 实现细节

“config”、“agent”、“processor”、“metric”、“span”和“log”等术语的存在表明对 OpenTelemetry 的实现细节进行了深入讨论,从配置到数据处理和日志记录。

4. 开发工作流程

提到“github”、“pull request (pr)”、“issue”、“commit”、“merge”和“build”表明 OpenTelemetry 社区积极参与开发工作流程,包括代码管理、构建过程和问题跟踪。

5. 挑战与解决方案

“problem”、“failed”、“error”和“fix”等词汇表明用户面临的常见挑战,以及社区为解决这些问题所做的努力。

6. 语言和框架

该网络包含对编程语言和框架(如“java”、“python”和“.net”)的引用,表明对 OpenTelemetry 在各种开发生态系统中的使用进行了讨论。

7. 社区互动

“@u01”和“@u02”等用户句柄表明数据可能包含直接互动或提及特定社区成员,这指向一个积极参与且协作的社区。

8. 数据传输与结构

“endpoint”、“request”、“header”和“attribute”等术语指向关于遥测数据如何构建和传输的技术讨论。

总而言之,该图表描绘了一个活跃且相互关联的社区,专注于开发、实施和优化 OpenTelemetry,讨论从设置和配置到错误处理以及与其他工具和系统的集成等广泛技术方面。

面向 DevOps 的六大 OpenTelemetry 挑战

DevOps 工程师、开发者、平台工程师和运维人员使用 Slack 获取技术支持和建议。为了了解他们当前的痛点和优先事项,我们分析了 CNCF Slack 工作区中与 #OpenTelemetry 相关的 10,000 条连续帖子。

基于 CNCF Slack 的主要 DevOps 挑战

Bar chart of devops challenges based on CNCF Slack
来源:CNCF Slack

在云原生应用和可观测性领域,Stack Overflow 上的讨论揭示了开发者和运维人员在 OpenTelemetry 生态系统各个组件中面临的一系列挑战。这些挑战涵盖从 OpenTelemetry Collector 的基础设置到 gRPC 通信的细微复杂性,每个挑战都在追求无缝可观测性和监控的过程中提出了独特的障碍。

OpenTelemetry Collector 对于数据收集和导出至关重要,但经常遇到配置复杂性、高可用性问题和存储管理问题。例如,在 Kubernetes 中配置 Collector 以实现高可用性可能非常棘手,因为需要持久化存储解决方案和网络配置来确保数据完整性和和可用性。

2. 插桩问题

插桩对于生成遥测数据至关重要,但也带来了学习曲线陡峭和难以实现高可用性等挑战。一个常见的场景是为 .NET 应用进行追踪插桩,开发者必须在不同的库和标准之间进行选择,以确保全面的数据收集。

3. OpenTelemetry 追踪问题

追踪是可观测性的一个关键方面,但充满了语言支持差异和可视化挑战等问题。一个例子是将 OpenTelemetry 追踪与支持有限或库少的语言集成,这使得实现端到端追踪可见性的过程变得复杂。

4. OpenTelemetry Exporter 问题

Exporter 负责将遥测数据发送到各种后端,它们面临着设置和数据导出挑战。一个实际例子是在微服务架构中配置 Jaeger Exporter,确保追踪数据正确路由并在 Jaeger 的 UI 中可视化需要精确的配置和对 Jaeger 数据模型的理解。

5. OTLP 问题

OpenTelemetry Protocol (OTLP) 旨在统一遥测数据导出,但有时会遇到设置和连接问题。例如,如果网络配置和安全策略未正确对齐,使用 OTLP 连接跨不同环境的服务可能导致超时或数据丢失。

6. SDK 问题

OpenTelemetry SDK 提供了用于生成和导出遥测数据的 API 和库,但使用和配置可能具有挑战性。开发者在尝试创建自定义 Span 或指标时经常寻求更清晰的文档和示例,这反映了需要更容易获取的 SDK 资源。

这些讨论强调了在现代软件系统中实现和管理可观测性的复杂性。开发者和运维人员一直在寻找能够简化配置、改进与现有工具集成并为 OpenTelemetry 生态系统中遇到的各种挑战提供强大支持的解决方案。

OpenTelemetry 和特定语言的挑战

从战略业务层面来看,在各种技术堆栈中集成 OpenTelemetry 带来了一系列运营挑战,对于组织解决这些挑战以实现高效的系统监控和可观测性至关重要。

采用 .NET 技术的企业正在应对围绕核心应用框架、数据库交互和云服务监控的复杂性,并重点关注确保在容器化环境(如 Docker)和编排系统(如 Kubernetes)中的无缝功能。同样,利用 Go 的组织正在集中精力优化关键 Web 框架内的性能监控,并确保可靠的消息传递和云交互,这对于实时数据处理和分析至关重要。

以 Java 为中心的企业正通过更好地与现有框架集成来提升应用性能,并积极致力于简化分布式系统中的遥测数据收集。对于 JavaScript 环境,重点在于增强后端服务和云通信,以确保 Web 应用的健壮性和可伸缩性。

在所有平台上,在管理资源限制的同时保持高可观测性标准的必要性促使企业寻找更精简、更有效的追踪和指标收集解决方案,从而增强了对复杂且用户友好的可观测性工具的需求。

Topic map of language-related challenges for OTel
来源:CNCF Slack

从业务角度来看,组织在集成 OpenTelemetry 用于日志、指标和追踪时面临多方面挑战。十大问题反映了技术复杂性、成本影响以及全面战略的结合。

Topics map for challenges related to metrics, logs, traces, events in OTel.
来源:Reddit

指标:企业必须解决指标中高基数带来的财务影响,这会增加存储成本。此外,还需要理解和利用指标仪表来增强数据收集,同时应对 OpenTelemetry 指标组件的新兴特性。实施 OpenTelemetry 不是一个小改动;它需要大量的组织承诺和资源。配置 OpenTelemetry 的复杂性可能会增加,需要精密的管理才能在大规模部署中保持效率。后端解决方案在存储、分析和可视化方面存在差距,需要与第三方工具集成。数据噪声仍然是一个挑战,使提取可操作的洞察变得复杂。标准化遥测数据的生成和收集至关重要,有效跟踪请求和事务以加快问题解决的能力也同样重要。

日志:与现有日志库的无缝集成对于一致的可观测性至关重要,同时还需要收集上下文相关的日志数据。在过渡到 OpenTelemetry 的同时支持遗留日志系统需要仔细规划以及对遗留和第三方日志机制的支持。与指标一样,日志组件的成熟度仍在发展中。

追踪:理解追踪组件的复杂性至关重要,特别是在不同格式之间管理上下文传播。分布式追踪管理是一项复杂的任务,可以跟踪通过服务的请求和事务,这对于识别瓶颈和优化性能至关重要。

事件:挑战包括在没有明确操作 Span 的情况下表示事件,以及将 OpenTelemetry 与现有事件库集成。收集带有上下文的事件数据对于全面的可观测性战略至关重要。

总之,组织必须应对 OpenTelemetry 不断发展的复杂环境,需要付出专门的努力来管理相关的复杂性,并将 OpenTelemetry 有效地集成到现有的技术堆栈中。大规模倡议的需求,加上实施和管理的复杂性,需要采取积极主动的方法来确保 OpenTelemetry 的成功采用,这对于现代应用的可观测性和运营弹性至关重要。

Reddit 上的 OpenTelemetry

在 DevOps 框架内实施 OpenTelemetry 给企业带来了复杂的挑战,包括建立强大的基础设施来处理遥测数据收集和可观测性工具托管的密集资源需求。与各种技术堆栈的无缝集成、确保数据安全和隐私、自动化安全部署、维护不同生产和预生产环境之间的一致性以及管理生成的大量数据,所有这些都需要战略规划和资源优化。解决这些挑战对于组织充分发挥 OpenTelemetry 的潜力至关重要,这需要结合强大的基础设施基础、细致的资源管理和严格的安全协议。

1. 基础设施和托管挑战

OpenTelemetry 需要强大的基础设施来收集、处理和导出遥测数据。这可能是一个挑战,特别是在资源可能有限的自行托管环境中。例如,您可能需要自行托管 Kibana、Zipkin、Prometheus 和 Grafana 实例以实现可观测性。这可能消耗大量资源,并需要显著的计算能力和存储容量。

2. 集成和兼容性问题

OpenTelemetry 需要与您的技术堆栈的各个部分集成,包括您的服务网格(如 Istio)、CI/CD 流水线和容器注册表。确保兼容性和无缝集成可能是一项复杂的任务,特别是在微服务架构中,其中存在大量独立的微服务。

3. 数据安全和隐私问题

OpenTelemetry 收集大量数据,其中一些可能包含敏感信息。确保这些数据的安全至关重要。例如,如果您使用 Terraform 进行基础设施管理,您需要使用 git-crypt 等工具加密 Terraform 文件中的秘密。

4. 自动化部署和测试

自动化将更改部署到预生产环境并运行集成测试可能具有挑战性。如果您使用 GitOps 工作流程,您需要确保只能在受保护的分支上进行部署,以防止未经授权的更改。

5. 管理差异化环境

如果您为生产和预生产环境分别设置了 Kubernetes 集群,保持这些环境同步可能是一个挑战。一个环境中的更改可能会影响另一个环境,导致不一致和潜在问题。

6. 资源管理

OpenTelemetry 可以生成大量数据,这可能会给您的资源带来压力。有效管理这些资源,尤其是在自行托管环境中,可能是一个重大挑战。为了克服这些挑战,拥有周密的实施计划、强大的基础设施和有效的资源管理策略至关重要。此外,使用自动化工具和遵循数据安全最佳实践可以帮助缓解其中一些问题。

Topic map of subreddit topics related to OpenTelemetry
来源:Reddit

1. 社区交集:OpenTelemetry Subreddit 的活跃用户与专注于相关 DevOps 工具和实践(如 Kubernetes、Grafana、Elasticsearch 和编程)的 Subreddits 用户之间存在显著重叠。这表明这些社区之间存在共同的兴趣或用户群。

2. 可观测性的相关性:Grafana、Elasticsearch、Kibana、New Relic 和 Datadog 等特定可观测性工具的 Subreddits 与 OpenTelemetry Subreddit 相关联,突显了 OpenTelemetry 在可观测性领域的重要性。

3. 更广泛的 DevOps 生态系统:与“devops”、“microservice”、“kubernetes”和“programming”等更广泛类别的连接表明,围绕 OpenTelemetry 的讨论是关于 DevOps 实践、微服务架构、容器编排和软件开发等更大范围对话的一部分。

4. 特定工具集成:该图显示用户可能正在讨论 OpenTelemetry 如何与其他流行的 DevOps 和可观测性工具集成,这由与特定工具 Subreddit 的连接得到证实。

5. OpenTelemetry 在监控和站点可靠性中的作用:与“SRE”(Site Reliability Engineering)的连接表明 OpenTelemetry 是围绕站点可靠性和系统监控讨论中的一个热门话题。

6. 供应商存在:与 OpenTelemetry 相关联的供应商特定 Subreddits(如“datadog”和“newrelic”)的可见性表明用户可能正在比较或将 OpenTelemetry 与这些商业监控解决方案集成。

OpenTelemetry、DevOps 和平台工程:主要要点

1. 活跃且不断壮大的社区

OpenTelemetry 拥有一个充满活力且不断壮大的开发者社区,每年独特的贡献者数量和总提交次数不断增加证明了这一点。这种积极参与反映了该项目在可观测性领域的重要性和价值。

2. 集成和跨语言适用性

OpenTelemetry 旨在与各种技术、编程语言和云平台无缝集成。它支持与 Docker、Kubernetes、Prometheus 和可观测性堆栈等流行工具集成。这种跨语言适用性使其与全栈开发相关。

3. 专注于插桩和数据流

OpenTelemetry 社区高度重视插桩,以确保准确捕获数据从而实现有效的可观测性。此外,还高度关注优化可观测性工具内的数据流、增强组件和扩展,并确保跨不同平台的无缝集成。

4. 社区讨论和挑战

OpenTelemetry 社区积极讨论和解决在不同环境中集成 OpenTelemetry、使其适应各种云服务、配置复杂系统、优化性能和实施高级插桩技术相关的挑战。这些讨论反映了社区对持续改进和知识共享的承诺。

5. 在可观测性领域的关联性

OpenTelemetry 在可观测性领域发挥着至关重要的作用,通过指标、追踪和日志提供关键可见性。它已被广大开发者社区广泛采用和认可,其在 GitHub 和 Stack Overflow 等平台上的受欢迎程度就证明了这一点。OpenTelemetry 的影响力超越了其直接社区,影响着整个软件开发领域。

这些主要发现突显了 OpenTelemetry 作为强大的可观测性框架的重要性、其不断壮大的社区以及在不同技术生态系统中的关联性。

下一篇:OpenTelemetry:业务视角