OpenTelemetry 和开源社区发展
OpenTelemetry 社区在过去两年中经历了显著而持续的受欢迎度和贡献增长。这在 GitHub 的关键指标中得到了体现。
GitHub 星标：排名前 10 位的 OpenTelemetry 存储库的 GitHub 星标同比增长 63%，两年增长 136%，这表明开发者社区对该项目越来越感兴趣并给予肯定。GitHub 星标通常被用来衡量项目的受欢迎程度，因为它表明有多少用户收藏该项目以供参考或表达他们对该项目的喜爱。
代码提交：代码提交量同比增长 45%，两年增长 95%，表明项目参与度非常高。图表显示代码提交在各个仓库之间分布异常均匀。这是因为编码人员需要针对每种开发语言实现一套相似的插桩代码。
贡献的编码人员和公司：贡献的编码人员两年增长 25%，表明该项目吸引了更多个人贡献者并获得了更多公司支持。这可能是由于该项目在行业中被认为具有价值，导致更多公司投入资源参与其开发。
贡献者和贡献组织
这些数字共同表明 OpenTelemetry 正在开发者社区和整个行业中获得关注。过去两年贡献和兴趣的持续增长表明该项目可能会继续增长和发展，有可能成为云原生领域可观测性的标准工具。
OpenTelemetry 相关的 GitHub 仓库
Grafana（仪表盘）、Prometheus（Kubernetes 指标）和 Apache Skywalking（微服务应用性能监控）是与 OpenTelemetry 相关的三个最突出的 GitHub 存储库，紧随其后的是 Grafana 的 Loki（日志管理）、Elastic Kibana 和 Jaeger。
Grafana 仪表盘与 OpenTelemetry
Grafana 和 OpenTelemetry 具有共生关系，这对于现代可观测性实践至关重要。Grafana 是一个流行的开源监控和可观测性平台，允许用户为其数据创建仪表盘和可视化。另一方面，OpenTelemetry 是一套 API、SDK、工具和集成，旨在为云原生软件创建和管理遥测数据（指标、日志和追踪）。
两者之间的关系围绕着使用 OpenTelemetry 从各种来源收集遥测数据以及 Grafana 可视化这些数据的能力展开。OpenTelemetry 提供了一种统一的方式来收集跨不同服务和平台的遥测数据，然后可以将这些数据导出到包括 Grafana 在内的各种后端进行分析和可视化。这种集成使开发者和运维人员能够深入了解其系统，排除故障，并确保其应用程序以最佳状态运行。
此外，这种集成很重要，因为它支持广泛的可观测性用例。例如，Grafana 可以显示 OpenTelemetry 收集的指标，允许用户监控其应用程序的性能。它还可以可视化追踪，这有助于理解请求在系统中的流向并识别瓶颈。此外，Grafana 可以用于探索 OpenTelemetry 收集的日志，从而更容易将日志与指标和追踪关联起来，以全面了解系统健康状况。
总而言之，Grafana 和 OpenTelemetry 之间的关系非常重要，因为它能够实现强大且灵活的可观测性技术栈，可适应云原生环境复杂动态的特性。Grafana 的可视化能力与 OpenTelemetry 全面的数据采集框架相结合，为监控、故障排除和优化现代软件系统提供了强大的解决方案。
OpenTelemetry 开发优先级：6 个关键主题
对过去 12 个月创建的 1,369 个 GitHub 问题进行聚类分析，我们发现六个关键主题
- 追踪
- Prometheus
- SDK
- Kafka
- 元数据
- Kubernetes
GitHub 上 OpenTelemetry 的 6 大开发优先级
接下来，我们将对所有相关 GitHub 问题的标题和文本进行完整分析，深入探讨每个主题领域，以确定其重点关注领域。
OpenTelemetry 追踪：开发优先级
配置与集成
许多问题围绕着追踪与各种系统和协议的配置和集成展开。这包括处理特定的 HTTP 错误、正确设置 exporters 和 receivers，以及确保与不同版本的 OpenTelemetry 协议兼容。最终，OpenTelemetry 开发者致力于使追踪在不同平台和服务之间无缝工作。
数据传播与上下文管理
此类问题侧重于追踪上下文在微服务之间的传播、SpanID 和 TraceID 的处理，以及确保在系统的不同部分正确维护追踪上下文。这还包括关于在日志中正确处理追踪上下文以及确保追踪信息正确填充和传播的问题。
采样与过滤
存在与追踪数据的采样和过滤相关的挑战，例如实施高效的采样策略、区分健康检查与其他追踪的处理方式，以及通过选择性采样管理追踪数据量。开发者正在寻求解决方案，以便在不压垮底层系统的情况下捕获最相关的追踪数据。
Exporter 和 receiver 功能
Exporter 和 receiver 功能问题包括特定 exporter 未正确发送追踪数据、处理大量追踪数据以及确保追踪数据格式正确和传输的问题。同时也在努力提高 exporter 和 receiver 的稳定性和可靠性，尤其是在高吞吐量环境中。
性能与资源管理
性能相关的问题包括内存泄漏、处理大型追踪负载，以及在处理和导出追踪数据时高效利用资源。开发者正在寻找优化方案，以减少追踪在其系统上的开销，并提高其监控设置的整体性能。
错误处理与稳定性
本主题包括在追踪系统不同组件中报告的各种错误和崩溃，通常与特定配置或边缘情况相关。开发者正在努力改进错误处理、提供更清晰的错误消息，并增强稳定性，以防止追踪数据丢失并确保可靠运行。
插桩与 API 使用
与插桩和 API 使用相关的问题包括手动插桩的挑战、在存在定时器时上下文和追踪的行为，以及可能不直观或文档不完善的 API 方法的使用。开发者正在努力改进 API，使插桩更加直接且不易出错。
追踪数据质量与准确性
对追踪数据质量和准确性的关注包括确保追踪数据反映系统中操作的正确时间、关系和状态。这包括处理追踪 ID 和 span ID、准确记录异常和堆栈追踪，以及确保追踪数据完整且信息丰富。
这些主题代表了在将追踪与 OpenTelemetry 集成时遇到的广泛技术挑战和功能请求。解决这些问题对于开发一个强大、高效且用户友好的追踪系统至关重要，该系统能够在各种环境中有效运行。
OpenTelemetry 与 Prometheus：开发优先级
兼容性与规范
此类问题主要集中于确保 Prometheus exporter 与 OpenTelemetry 规范和兼容性指南保持一致。这包括与指标名称、标签、类型以及 Prometheus 兼容性规范的整体稳定性和清晰度相关的挑战。目标是实现 Prometheus 和 OpenTelemetry 之间的无缝集成和互操作性，遵循既定的标准和实践。
配置与自定义
配置和自定义问题围绕着设置和自定义 Prometheus receivers 或 exporters 时遇到的困难。用户寻求在配置选项方面更大的灵活性，例如功能开关、批量大小、头部信息以及处理同一环境中的多个实例。增强可配置性将更好地适应特定用例和操作要求。
Exporter 和 receiver 功能
本主题涵盖了 Prometheus exporters 和 receivers 功能方面的问题，包括指标类型支持、exemplar 支持和数据模型转换。此外，Prometheus remote write exporter 也存在问题，例如处理大型请求、重试逻辑和错误处理。改进这些方面对于高效可靠地收集和转发指标至关重要。
性能与资源管理
性能和资源管理问题的特点是内存使用率高、潜在的内存泄漏以及在指标转换过程中内存使用效率低下。解决这些问题对于优化 OpenTelemetry 生态系统中 Prometheus 集成的性能和可伸缩性至关重要，特别是在资源受限的环境中。
数据准确性与完整性
关于数据准确性和完整性的问题包括指标时间性和聚合处理不当，导致指标数据不准确。还存在指标标签和命名约定问题，以及抓取过程中的问题，例如处理没有 bucket 的直方图或没有 quantiles 的 summary 指标。确保指标数据的准确性和完整性是可靠监控和分析的基础。
可观测性与调试
为了更好地追踪和理解 Prometheus 组件的行为，需要增强日志记录和调试能力。这包括 exemplar 数据可见性问题以及 Prometheus exporter 对 exemplar 提供更好支持的需求。改进的可观测性和调试工具将有助于更高效地诊断和解决问题。
部署与运维
部署和运维挑战包括在特定环境（例如 Kubernetes 或无服务器平台）中设置和运行 Prometheus receivers。还存在与服务发现和动态抓取配置相关的问题。简化部署和运维流程将有助于在各种基础设施中更顺畅地集成和管理 Prometheus。
错误处理与稳定性
本主题涵盖了在 Prometheus exporter 和 receiver 不同组件中报告的各种错误和崩溃，通常与特定的软件版本或配置相关。还存在对 Prometheus 相关组件稳定性和可靠性的担忧，呼吁提供更好的错误处理和回退机制。增强错误处理和稳定性对于构建健壮可靠的监控解决方案至关重要。
这些主题共同代表了在将 Prometheus 与 OpenTelemetry 集成时遇到的各种技术挑战和功能请求。解决这些问题是推进 Prometheus 在 OpenTelemetry 生态系统中的兼容性、性能和可用性的关键，适用于广泛的部署场景。
OpenTelemetry 与 SDK：开发优先级
Metric SDK 规范合规性
本主题中的问题与验证 metric SDK 的实现是否符合 OpenTelemetry 规范有关。这包括确保各种组件，例如 MetricExporter、MetricProducer、MetricReader，以及它们的 Collect、RegisterProducer 和 Shutdown 等操作得到正确实现。
SDK 配置与扩展
本主题涵盖了与 SDK 配置和扩展相关的问题。它包括配置 MetricExporters 的能力、增加对日志的支持、处理环境变量，以及通过 HostDetector 或用于指标的自定义过滤器等附加功能扩展 SDK。
SDK 插桩与 exporters
这里的问题涉及 SDK 的插桩和 exporter 组件。这包括升级各种 exporters 的依赖、处理元数据以及确保与不同版本 SDK 的兼容性。它还涵盖了 SDK 与其他服务（如 AWS、阿里云和 Azure）的集成。
SDK 错误与兼容性
本主题包括由 SDK 更新引起的破坏现有功能的问题，例如 @opentelemetry/sdk-node 0.35.1 版本中的 http 插桩问题。它还涵盖了与其他 OpenTelemetry 实现的兼容性问题以及 SDK 内错误的异常处理。
SDK 性能与资源管理
此问题集群处理 SDK 的性能问题，包括基准测试、SDK 内部状态指标处理以及资源管理，例如 shutdown 方法处理和压力测试。
SDK 日志与追踪
本主题包括与 SDK 的日志记录和追踪功能相关的问题，例如在日志中包含追踪上下文、日志记录处理器处理以及 LoggerProvider 和 TracerProvider 配置。
SDK 指标与视图
与指标数据模型、NaN 值处理以及视图和聚合配置相关的问题属于本主题。它还包括指标 instrument 处理和基数限制的实施。
SDK 稳定性与生命周期
本主题涵盖了与 SDK 稳定性与生命周期相关的问题，包括 SDK 2.0 规划、常规发布节奏以及 SDK 配置整合。它还包括关键日志处理以及移除依赖项以使 SDK 更加模块化。
跨领域问题与最佳实践
涵盖 SDK 多个领域的问题，例如环境变量处理以与其他 OpenTelemetry SDK 保持一致、采用 W3C Trace Context Level 2 规范以及考虑内部状态指标的设计改进，均包含在此主题中。
集群与多进程支持
本主题包括与在集群环境或多进程中使用 SDK 相关的问题，例如 Node.js 集群模式下指标收集和导出面临的挑战。
每个主题都代表了 OpenTelemetry SDK 开发和维护的重点领域，反映了该项目提供全面可观测性框架目标的复杂性和广度。
Kafka 与 OpenTelemetry：开发优先级
Kafka Exporter 面临的挑战
OpenTelemetry 的 Kafka exporter 组件面临一系列问题。这些问题涵盖从系统设置（配置）、用户和系统验证（身份验证）到数据处理（消息处理）等各个方面。它们还包括支持各种通信协议和数据格式（协议和编码）的需求。
Kafka Receiver 面临的困难
负责接收和解释数据的 Kafka receiver 组件有其自身的挑战。这包括处理和理解数据（消息消费）、处理附加信息（元数据支持）、管理非活动会话（会话超时配置），以及支持各种数据格式（日志格式和编码）。
身份验证与安全问题
安全是任何系统的关键方面，OpenTelemetry 中的 Kafka 也不例外。存在与用户和系统验证（SASL 配置）、处理敏感数据（加密的 TLS 密钥）以及管理受信任实体（keystore 和 truststore 身份验证）相关的问题。
配置与优化问题
优化 OpenTelemetry 中 Kafka 的性能是一个挑战。这包括过滤不必要的数据（消息过滤）、提高数据处理速度（消费速度），以及管理唯一标识符和数据分布（客户端 ID 和分区键）。
总而言之，这些主题提供了公司在将 Kafka 与 OpenTelemetry 集成时面临的各种挑战的高层视图。它们突出了需要关注的领域，以改善用户和开发者体验。
OpenTelemetry 元数据：开发优先级
工具与 CI/CD 集成
此类包括与支持 OpenTelemetry 中元数据处理的开发工具和持续集成/持续部署 (CI/CD) 过程相关的问题。此类问题着重于通过更好的工具和与 CI/CD 管道的集成来增强开发者体验并确保元数据相关功能的可靠性。
元数据 schema 与文档
此类包括处理元数据 schema 定义、文档和增强的问题，以及改进关于如何在 OpenTelemetry 组件中使用元数据的文档。这些问题旨在澄清和标准化元数据在 OpenTelemetry 中的定义和使用方式，使开发者更容易一致地实现和利用元数据。
exporters 与 receivers 中的元数据
此类涵盖了 OpenTelemetry 生态系统中各种 exporters 和 receivers 中元数据处理和利用相关的问题。此类问题着重于改进在导出和接收遥测数据情境下元数据的捕获、传输和利用，增强应用程序的可观测性和可追溯性。
Kubernetes 与容器元数据
此类包括与在 Kubernetes 环境和容器化应用中提取和利用元数据相关的问题。这些问题旨在改进 OpenTelemetry 与 Kubernetes 和容器技术的集成，通过丰富的元数据实现对容器化应用的更好可观测性和监控。
元数据处理
此类涵盖了 OpenTelemetry 框架内元数据的一般处理、处理和增强相关的问题。此类问题着重于 OpenTelemetry 中支持元数据处理的机制和功能，旨在提高元数据管理的灵活性、效率和能力。
总而言之，OpenTelemetry 正积极致力于改善其生态系统中的元数据处理，重点放在增强开发者工具、标准化元数据 schema、改进数据捕获和传输、与 Kubernetes 和容器技术集成以及完善元数据处理能力。
Kubernetes 与 OpenTelemetry：开发优先级
OpenTelemetry 是一个用于监控 Kubernetes 环境的强大框架，目前正积极开发，以解决各种挑战并增强其功能。以下是重点关注领域的概要总结：
测试与兼容性
正在努力确保 OpenTelemetry 与不同 Kubernetes 版本兼容。这包括在各种版本上运行测试，以确保无缝集成和性能。
Receiver 功能
OpenTelemetry receivers 负责从 Kubernetes 收集数据，正在更新以支持 Kubernetes 的新特性和版本。这确保 OpenTelemetry 能够有效收集和处理来自最新 Kubernetes 环境的数据。
领导者选举支持
为了防止数据重复，OpenTelemetry 正在努力支持 Kubernetes 领导者选举。此功能将有助于简化数据收集并提高效率。
功能增强
OpenTelemetry 不断发展，不断有新的功能请求以改进其对 Kubernetes 的支持。这些增强旨在扩大 OpenTelemetry 监控能力的范围和有效性。
配置与身份验证
OpenTelemetry 正在改进其在 Kubernetes 环境中的配置和身份验证过程。这包括利用 Kubernetes service account JWT 进行身份验证，这可以增强安全性和易用性。
日志收集
OpenTelemetry 正在专注于改进从 Kubernetes 收集日志的体验。这将为监控和故障排除提供更详细和有用的信息。
不稳定测试
OpenTelemetry 正在解决测试结果不一致的问题，以确保其特性和功能的可靠性。
总而言之，OpenTelemetry 正积极解决一系列问题，以增强其对 Kubernetes 的支持。这些改进旨在为 Kubernetes 环境提供更强大、高效且用户友好的监控，从而帮助技术娴熟的个人更好地理解和管理其 Kubernetes 部署。
GitHub 上 OpenTelemetry 优先级：总结
OpenTelemetry 项目正在战略性地增强其可观测性框架，以解决 Kubernetes、元数据管理、Kafka 集成、SDK 开发、Prometheus 兼容性以及追踪能力等关键领域的问题。这种整体方法旨在完善互操作性、扩展功能，并提高 OpenTelemetry 生态系统的可靠性和可用性。通过专注于跨 Kubernetes 版本的测试和兼容性、丰富元数据处理以及解决与 Kafka 相关的挑战，OpenTelemetry 旨在确保无缝高效的可观测性体验。这些努力强调了强大的测试框架、高级功能集以及改进的配置和身份验证机制的重要性，以支持现代云原生应用的动态需求。
同时，该项目致力于通过确保符合规范、增强配置选项以及改进性能和资源管理来推进其 SDK。此外，还通过解决兼容性问题、优化性能和确保数据准确性来加强 Prometheus 集成。此外，增强追踪功能的举措重点在于改进数据传播、采样策略和 exporter 性能。总而言之，这些优先级表明 OpenTelemetry 致力于提供一个全面、可伸缩且用户友好的可观测性框架。通过解决这些多样化但相互关联的挑战，OpenTelemetry 将自己定位为开发者和组织在其软件环境中实现更高可见性、可靠性和操作效率的关键工具。