OpenTelemetry 正在扩展至 CI/CD 的可观测性 | CNCF
这最初于2024年11月4日发布在 CNCF博客 。
SIG 发帖由 Dotan Horovits 和 Adriel Perkins 发布的一个帖子,OpenTelemetry 特殊兴趣小组 (SIG) CI/CD 可观测性的项目负责人和
我们多年来一直在讨论需要一种共同的“语言”来报告和观察CI/CD管道,终于看到了这种“语言”的首批“词汇”进入了可观测性的“词典”——即OpenTelemetry开放标准。随着最近发布的OpenTelemetry v1.27.0语义约定,您可以在指定的属性中报告CI/CD流水线。
这是由CI/CD可观察性SIG在OpenTelemetry中的工作所取得的成果之一。在我们完成第一阶段的核心里程碑后,我们认为现在是时候与全世界分享这个好消息了。
CI/CD可观测性 对确保软件高效且可靠地发布到生产环境至关重要。运行良好的 CI/CD 管道直接影响业务成果,通过缩短更改前置时间(DORA 指标),并实现对故障或不稳定的过程进行快速识别和解决。通过将可观测性集成到 CI/CD 流程中,团队可以实时监控管道的健康和性能,获得瓶颈和需要改进的地方的洞察。
利用相同的成熟工具,组织可以扩展其可观测性能力,涵盖发布流程,促进软件交付的全面方法。不论是开源还是专有工具,在为CI/CD管道选择可观测性工具集时,不必重复造轮子。
然而,CI/CD工具的多样化带来了实现一致的端到端可观测性的挑战。每个工具都有自己独特的报告流水线执行状态的方式、格式和语义约定,这使得工具链内部碎片化,从而妨碍了无缝监控。在工具间迁移变得痛苦,这需要重新实现现有的仪表板、报告和警报。
事情变得更复杂,特别是在需要统一监控多个涉及发布管道的工具时。这时,开放标准和规范就显得非常重要。它们创造了一种通用的语言,这种语言与工具和供应商无关,具有中立性,让不同工具间实现协同可观测性成为可能,从而让团队能够清晰全面地了解其CI/CD管道的性能。
创建上述提到的语义约定需要标准化,这种标准化是为了报告管道中发生的事件的语言。标准化也是必要的,用于传播这些报告的方法,例如在管道执行过程中启动进程时。这促使我们推广使用环境变量在进程之间传播上下文和元数据,最近这一重要的里程碑已被批准并合并。
](https://www.linkedin.com/feed/update/urn:li:share:7254577377660334081)
这一认识驱使我们寻找正确的方式来制定规范。OpenTelemetry 成为了 telemetry 生成和收集的标准规范。OpenTelemetry 规范的任务正是解决这个问题:创建一个通用的、中立于供应商的 telemetry 规范。在云原生计算基金会(CNCF)的支持下,可以确保其保持开放和中立。作为 OpenTelemetry 的长期支持者,扩展 OpenTelemetry 至该重要的 DevOps 场景自然是合情合理的。
几年前,我们提出了一个 OpenTelemetry 扩展提案 (OTEP #223),提议将 OpenTelemetry 扩展到涵盖 CI/CD 可观测性用例。同时,我们在 CNCF 的 Slack 上启动了一个 Slack 频道,聚集了对这一想法感兴趣的同行,并开始讨论这一想法应该是什么样子。Slack 频道逐渐壮大,我们很快发现,这个问题在很多组织中都很普遍。
根据技术监督委员会和其他 CNCF 内部成员的反馈,我们请求成立一个专注于此主题的专门工作组,即 OpenTelemetry 的语义约定 SIG(SIG SemConv 简称)。在获得他们的同意后,我们正式成立了 CI/CD 可观测性 SIG,以正式化我们之前在 Slack 群组中讨论过的议题和目标,这个 SIG 的正式名称可以在 这里 找到。
。访问领英上的更新以获取更多详细信息。
自2023年11月以来,SIG一直积极与多家公司和开源项目的专家合作,致力于开发CI/CD可观测性语义标准。从一开始就决定把2024年的重点放在几个关键领域。
最初,我们的SIG在每周一的Semantic Conventions工作组会议期间举行。这为我们提供了很好的机会,使我们能够在研究和讨论如何达成路线图上的目标时找到方向。这使我们有机会结识OpenTelemetry社区中的许多成员,征求我们设计的反馈,并得到了关于如何继续前进的指导。OpenTelemetry Semantic Convention工作组对我们的CI/CD倡议给予了极大的支持。
在完成并发布首个里程碑(见下文)之后,我们的SIG获得了自己在OpenTelemetry日历上的专属会议时间档,即每个星期四上午0600美国太平洋时间。小组成员会在此聚集,讨论当前和未来的任务,然后参加每周一的更大规模的语义约定会议。我们非常期待社区继续给予支持和参与我们的会议,共同推进这一关键领域的标准化进程。
这里是一个链接到领英上的分享页面。
经过数月的迭代和反馈,第一套语义约定被合并 到 v1.27.0 版本中。这一变化带来了 CI/CD 下 CICD、工件(Artifacts)、VCS、测试和部署命名空间中的一套初步的基础语义。这标志着 CI/CD 可观察性 SIG 和整个行业的一个重要里程碑,从而使得我们其他目标的实现有了基础。
但这到底是什么意思?它有什么用处?让我们用两个实际的例子来考虑这两个命名空间(namespace)。
版本控制系统(VCS)属性涵盖了版本控制系统中常见的多个领域,如引用和变更(拉取/合并请求)。版本控制系统(VCS)属性 覆盖了多个领域,如引用和变更(拉取/合并请求)。vcs.repository.ref.revision
属性是元数据的关键组成部分。当像 GitHub 和 GitLab 这样的版本控制系统发布事件时,它们现在可以具备这个语义上兼容的属性。这意味着在集成代码、发布代码并将其部署到环境中时,系统可以包含此属性,并更容易地追踪代码修订跨界的轨迹。如果部署失败,你可以快速查看代码的修订版本并追溯到有问题的发布版本。此属性也是DORA 指标中的关键元数据,当你计算变更前置时间和失败部署恢复时间时。
The artifact 属性命名空间 在它的第一次实现中包含了多个属性。这个一组关键的属性涵盖了与SLSA 模型紧密相关的证明。这是首次在可观测性和软件供应链安全之间建立直接联系。请看SLSA定义的以下供应链威胁模型:
这些新属性可以帮助我们实时观察上述图中所展示的事件流程。实际上,现有的惯例和未来将添加的惯例通过可观测性语义来实现这些核心软件交付能力(例如安全性和平台工程)之间的互操作性。
我们前面提到的第一个重要里程碑是将扩展语义规范的 OTEP 与新属性合并,现在这已成为 OpenTelemetry 最新的语义规范的一部分。
另一个重要的里程碑是刚刚被批准并合并的OTEP #258,它定义了环境变量上下文传播的规范。这为编写相关规范奠定了基础。
查看LinkedIn上的更新,了解更多详细信息。
自从我们在初始里程碑方面取得了进展,我们更新了CI/CD Observability SIG 2024年剩余时间的里程碑。我们的目标是在年底前尽可能完成尽可能多的里程碑。特别值得关注的是,比如特定的功能或改进。
以上提到的内容只是个开头!我们在CICD项目看板上有许多定义好的任务,还有许多正在进行的任务。我们将继续在2024年内逐步推进已设定的里程碑。这里有几个需要注意的地方。
还有很多呢!
点击链接查看帖子
哇哦,这可真是好多事情要处理!毫无疑问,这个SIG肯定会持续到2025年。制定标准虽然难,但却是必不可少的。而且,我们有很多很棒的人加入到了这个SIG,并且在制定这些标准方面贡献良多!你可能会想问,他们是谁?
首先,我们特别感谢OpenTelemetry领导委员会中的关键成员,在我们迄今为止的工作中起到了关键作用,并将继续发挥关键作用。
从 OpenTelemetry 技术委员会中有两位核心赞助商:来自 Lightstep 的 Carlos Alberto 和来自 Google 的 Josh Suereth。Carlos 和 Josh 都非常支持我们的 CI/CD 工作,一直在帮助我们顺利进行流程和细节,确保我们的成功。
来自 OpenTelemetry 管理委员会,微软的 Trask Stalnaker 为我们提供了大力的支持,还有 Skyscanner 的 Daniel Blanco,他现在是我们联络员。他们在支持 SIG 和帮助我们在 OpenTelemetry 社区建立自己的会议方面起了重要作用。
除了这些人之外,我们还得到了以下关键人士的重要反馈和支持:
起这么多名字可真够费劲的!我们非常感谢所有支持这项倡议并帮助将其变为现实的人!构建行业标准需要相当的思考能力和时间。难题确实难,但这些人迎难而上,让可观测性和CICD系统的领域变得更美好、更互通。
想了解更多并参与CI/CD可观测性的构建吗?
我们邀请开发者和实践者参与讨论,提出建议,并帮助塑造CI/CD可观察性的未来以及OpenTelemetry语义规范。讨论在CNCF Slack工作空间的#cicd-o11y通道中进行,您也可以在GitHub上发表意见,每周四上午0600 PT还可以在CICD SIG的每周电话会议中加入讨论。