CI/CD流水线可观测性工具：如何选择合适的方案

当 CI/CD 流水线失败时，其仪表盘通常可以告诉你出了什么问题。流水线可观测性工具应该帮助你理解原因，无论是偶发测试失败、构建代理过载，还是交付过程中其他地方的问题。

随着流水线变得越来越复杂，这变得更加困难。一条流水线涉及许多独立的系统：版本控制、构建代理、容器、测试框架、制品仓库、安全扫描器和部署工具。每个系统都会生成自己的数据，在调查期间将所有数据汇集在一起并不容易。

JetBrains 开发者生态系统调查 2026 显示了这些挑战有多普遍。当我们询问 20,416 名受访者在使用云基础设施时面临的三大挑战时，44% 的人选择了云环境中的调试和故障排除问题。

安全与访问控制被 36% 的人选择，成本可见性和优化也是如此。可观测性被 16% 的人提及，而 12% 的人指出有太多独立的工具、控制台或仪表盘。 [LOADING...] JetBrains 开发者生态系统报告 2026

本文解释了 CI/CD 流水线可观测性的含义、哪些指标值得追踪，以及最常见的可观测性工具如何比较。它还提供了一个框架，用于为你的团队选择合适的 CI/CD 可观测性工具。

什么是 CI/CD 流水线可观测性？

CI/CD 流水线可观测性是指能够从交付流水线产生的数据中理解其状态和行为的能力，这些数据包括构建结果、指标、日志、事件和追踪。

实际上，一个可观测的流水线应该帮助你回答以下问题：

• 为什么构建比上个月花费的时间更长？
• 为什么一个代理池比另一个更频繁地失败？
• 哪个流水线阶段引入了回归？
• 是代码变更导致了失败，还是构建环境中的某些东西发生了变化？

监控和可观测性密切相关，但并不相同。流水线监控跟踪已知条件。你定义一个指标或事件，将其显示在仪表盘上，并可能在它超过阈值时创建警报。

当问题的原因不立即明确时，可观测性会有所帮助。它提供足够的关联数据来调查意外故障，而无需先添加新的跟踪并等待问题再次发生。

例如，监控可以显示构建持续时间突然增加。可观测性帮助你将这种增加追踪到特定的流水线、阶段、构建代理、提交、测试或基础设施问题。 [LOADING...] TeamCity 性能监控

在 CI/CD 流水线中应该观察什么？

流水线可观测性涵盖流水线执行的工作以及运行它的平台。

在流水线层面，这些指标分为两组：第一组包括队列时间、总持续时间和阶段持续时间，它们告诉你开发人员在哪里等待。另一组包括成功率、重试、偶发测试和缓存性能，它们告诉你流水线本身在哪里变得不太可靠。

在平台层面，团队需要了解代理或运行器、CPU 和内存消耗、磁盘和网络活动、服务器健康状况以及外部依赖的可用性。这种上下文有助于区分代码问题和基础设施问题。

最有用的指标是那些与具体调查相关的指标。

对于持续时间和队列时间指标，百分位数通常比平均值更有信息量。稳定的平均值可能掩盖最慢的 5% 或 10% 构建的糟糕体验。

仅看总体成功率可能会隐藏问题。即使某个分支、构建代理镜像或测试套件经常失败，该数字也可能看起来健康。要发现这些模式，团队需要能够按项目、分支、流水线阶段、代理池、环境和失败类型细分指标。

你的 CI/CD 系统通常是运行标识和流水线结构的最佳来源。例如，TeamCity 统计图表将构建持续时间、队列时间、成功率、测试、制品和其他统计数据连接到基础构建配置。

当 CI 数据导出到另一个可观测性系统时，这种上下文变得特别有价值。 [LOADING...] TeamCity 中的构建配置统计

团队在 2026 年如何观察 CI/CD 流水线

开发者生态系统现状调查 2026 询问了 8,323 名受访者他们使用哪些工具进行 CI/CD 流水线可观测性。受访者可以选择多个答案。 [LOADING...] JetBrains 开发者生态系统报告 2026

内置 CI/CD 仪表盘是最常见的选择，76% 的受访者使用。它们已经是 CI/CD 平台的一部分，几乎不需要设置，并在原始上下文中显示流水线运行、阶段、测试和失败。

然而，许多团队使用不止一种可观测性工具。他们可能在 CI/CD 仪表盘中调查失败的构建，使用 Prometheus 和 Grafana 监控构建基础设施，并在 Elastic 或 OpenSearch 中搜索日志。

这些工具不是直接的替代品：每种提供不同类型的信息。指标显示随时间变化的趋势和变化，日志提供发生情况的详细记录，追踪显示工作如何在流水线的不同部分之间移动。

OpenTelemetry 帮助收集和发送这些数据，但它仍然需要一个单独的系统来存储和显示它。

如何选择 CI/CD 流水线可观测性工具

大多数可观测性工具承诺相同的基础功能：仪表盘、警报和一些集成。真正区分它们的是它们收集什么数据、这些数据与你的流水线保持连接的程度，以及设置和保持运行需要多少工作。

以下五个标准可以帮助你比较选项，并为你的团队选择合适的工具。

1. 调查深度和 CI/CD 上下文

想想你希望工具帮助你调查的问题。如果流水线失败，你能快速找到受影响的阶段或测试吗？你能将失败的运行与之前成功的运行进行比较吗？

要回答这些问题，工具需要将每个指标、日志或追踪与相关的流水线运行保持连接。应该能够看到数据来自哪个仓库、分支、提交、阶段和环境。

你可能还需要有关涉及的拉取请求、构建代理、测试或制品的信息。 [LOADING...] TeamCity 的 AI 助手帮助分析失败的构建

内置 CI/CD 仪表盘很有用，因为它们已经具有这种上下文。在评估外部可观测性工具时，检查其集成是否保持这些连接，还是将流水线简化为不相关的指标和日志的集合。

2. 跨系统关联

流水线问题可能来自许多地方，包括构建运行器、容器、云服务、制品仓库、外部 API 或部署环境。

一个好的可观测性工具应该连接来自这些系统的数据，这样开发人员就不必比较时间戳并在多个仪表盘中搜索以了解发生了什么。这对于使用多个 CI/CD 平台或环境的组织尤其有用。

根据 开发者生态系统现状调查 2026，22% 的受访者认为管理多个环境具有挑战性，而 12% 的人因拥有太多独立的工具、控制台或仪表盘而苦恼。可观测性工具应该将这些信息汇集在一起，而不是增加另一个孤立的仪表盘。 [LOADING...]

3. 设置和可用性

不同的可观测性工具需要不同程度的设置。内置 CI/CD 仪表盘可能立即可用，而外部工具需要连接到流水线并配置为收集、存储和显示正确的数据。分布式追踪可能需要对流水线本身进行额外更改。

如果更复杂的设置能给团队提供所需的信息，那么可能是值得的。但是，你应该考虑引入和维护该工具需要多少工作。

该工具还应该易于开发人员使用。他们通常是第一个看到流水线失败的人。如果他们无法在没有平台团队帮助的情况下理解数据，那么该工具在日常调查中的价值将有限。

4. 安全和部署模型

从 CI/CD 流水线收集的数据可能包括仓库和提交详细信息、用户名、基础设施地址以及有关构建环境的信息。如果敏感信息没有被正确隐藏，构建日志还可能包含密码、令牌或其他机密。

这也不是一个小问题：安全、权限和访问控制在调查受访者中排名为 36% 的首要云挑战。

在选择工具之前，了解它在哪里存储你的数据、数据在传输时如何受到保护、谁可以访问它以及保留多长时间。你的组织可能还需要访问控制、活动日志、加密、数据存储区域的选择，或者在自己的基础设施上运行该工具的能力。

5. 成本、维护和可移植性

订阅或许可证价格只是总成本的一部分。收集大量详细的指标、日志和追踪会增加存储和处理成本。自托管工具可能会降低订阅费用，但你的团队仍然需要提供基础设施、安装更新、管理备份并维护系统。

你还应该考虑将数据迁移到另一个工具有多容易。10% 的调查受访者将供应商锁定和可移植性列为使用云服务的挑战。

开放标准不能使迁移变得轻松，但它们可以减少必须重建的数据收集和流水线配置的数量。

开源、托管还是组合？

我们经常将开源平台与商业平台视为二元选择。但大多数团队可以说是“脚踏两只船”。

Prometheus、Grafana、OpenSearch 和 OpenTelemetry 让你完全控制托管、数据和保留。你决定它在哪里以及保留多久。代价是你也是运行和保护它的人。

商业平台替你完成这项工作。你可以更快地获得有用的数据，但你需要支付订阅和摄取成本，并且你信任别人来存储你的数据。

大多数团队实际上并没有选择一方。典型的设置使用 OpenTelemetry 收集数据，Prometheus 用于基础设施指标，以及一个托管平台在两者之上进行存储和分析。

根据你的团队已经知道如何运行什么以及你实际需要回答什么问题来决定，而不是根据给定平台是开源还是商业来决定。## CI/CD 流水线可观测性工具对比

2026 年开发者生态系统现状调查按类型对可观测性工具进行了分组。这意味着结果显示了每种方法的采用范围，但没有显示单个产品的使用情况。

例如，14% 的受访者使用商业可观测性平台，但调查没有显示这一比例在 Datadog、New Relic 和 Dynatrace 之间如何分配。

因此，下面的对比使用与调查相同的工具类别，并根据我们的选型框架对每一类进行评估。

内置 CI/CD 仪表板

模式： 随云端或自托管的 CI/CD 平台提供。

信号与 CI 上下文： 流水线运行、阶段、构建日志、测试、变更、排队时间以及代理或运行器信息。

配置： 通常默认可用，具体取决于平台，还提供额外的图表、报告、API 或指标导出。

内置仪表板通常是流水线可观测性的最佳第一层。失败的测试、缓慢的预发布、排队的构建和触发提交，会作为同一次运行的相关部分呈现，而不是独立的遥测记录。

• 最适合： 当大多数团队使用同一个 CI/CD 平台时进行日常排查。
• 突出能力： 强大的原生 CI 上下文、较低的设置工作量，以及可从构建结果直接访问。
• 局限： 跨系统可见性通常有限。仪表板可能显示某个阶段变慢，却无法说明原因是基础设施、存储、网络还是外部服务。

评估内置仪表板时，应关注历史趋势、测试历史、队列分析和代理工作负载，而不是只关注最近一次运行。

TeamCity 提供构建和项目统计、测试历史、日志、代理工作负载信息和流水线可视化。我们关于使用 TeamCity 仪表板排查构建问题的文章，展示了在排查过程中如何组合这些来源。

Prometheus 和 Grafana

模式： 开源且通常自管理，也提供托管的 Grafana 服务。

信号与 CI 上下文： 时间序列指标、标签、仪表板和告警；CI 上下文取决于导出的指标。

配置： Prometheus 抓取配置和告警规则，通常为 YAML；Grafana 仪表板和数据源。

[LOADING...] JetBrains IntelliJ 基础设施团队的 Grafana 仪表板

Prometheus 收集并查询时间序列数据，而 Grafana 提供仪表板和可视化。两者结合是调查中最常见的基于指标的方法，29% 的受访者选择了它。

• 最适合： 监控 CI 基础设施、容量、利用率和性能趋势。
• 突出能力： 灵活的查询和仪表板、强大的基础设施关联能力，以及对数据存储的控制。
• 局限： 指标可以显示行为在何处、何时发生变化，但可能没有足够细节来解释确切原因。团队还必须运维这套技术栈并控制指标基数。

结果质量在很大程度上取决于指标标签。流水线、阶段、结果、项目和代理池上下文使聚合变得有用。单个构建 ID 和提交哈希应谨慎处理，以避免不必要的高基数。

TeamCity 以 Prometheus 格式暴露服务器指标。我们关于使用 Prometheus 和 Grafana 监控 TeamCity 服务器健康的指南，涵盖了构建队列、代理、服务器负载、JVM 健康状况和数据库连接。

Elastic Stack 和 OpenSearch

模式： 开源或开放核心软件，提供自管理和托管部署选项。

信号与 CI 上下文： 主要是日志和可搜索事件，并根据技术栈支持指标和追踪。

配置： 收集器、解析和摄取管道、模式、索引、仪表板和保留策略

Elastic Stack 和 OpenSearch 代表日志聚合类别，18% 的调查受访者使用它们。当排查依赖于流水线阶段、代理、基础设施或外部服务的详细输出时，它们很有用。

• 最适合： 需要大量日志排查的组织，或已有集中式日志平台的组织。
• 突出能力： 跨大量流水线和基础设施事件进行搜索。
• 局限： 集中日志并不会自动保留流水线结构。摄取和存储量也可能变得昂贵。

收集更多日志还不够。每条日志条目都应显示它属于哪次流水线运行、哪个阶段、哪个仓库和哪个构建代理。构建输出中的敏感信息也应在日志存储之前隐藏。

Elastic 记录了一种基于 OpenTelemetry 的 CI/CD 可观测性架构，而 OpenSearch 支持对日志、指标和追踪的探索。流水线上下文的深度仍取决于 CI/CD 系统的插桩方式。

OpenTelemetry

模式： 开源、厂商中立的插桩标准；需要单独的后端。

信号与 CI 上下文： 指标、日志和追踪，并带有 CI/CD 遥测的语义约定。

配置： 插桩或 CI 集成、OTLP 导出器，通常还需要 OpenTelemetry Collector。

17% 的受访者使用 OpenTelemetry。它并不是一个自带存储和仪表板的完整可观测性工具。相反，它提供了一种标准方式来收集流水线数据并将其发送到另一个可观测性系统。

例如，OpenTelemetry 可以将流水线记录为作业、阶段、测试、制品传输和外部服务调用组成的一条连接序列。然后可以使用开源或商业平台存储和分析这些数据。

• 最适合： 跨多个工具或服务的复杂流水线，尤其是在可移植性很重要时。
• 突出能力： 跨系统追踪，以及厂商中立地收集指标、日志和追踪。
• 局限： OpenTelemetry 不提供存储、仪表板或完整的排查体验。插桩可能需要大量工作。

OpenTelemetry 的 CI/CD 语义约定涵盖 span、指标和日志。OpenTelemetry Collector 可以处理这些信号并将其路由到一个或多个后端。

评估这种方法时，请检查流水线的哪些部分是自动插桩的。仅包含流水线和作业名称的追踪，除了原生 CI/CD 界面之外可能几乎没有附加价值。当它将流水线活动与进程、代理、网络调用或部署系统连接起来时，其价值就会增长。

商业可观测性平台

模式： 主要是托管 SaaS，数据收集和托管选项因供应商而异。

信号与 CI 上下文： 指标、日志、追踪、事件、测试和流水线数据，具体取决于集成。

配置： 原生集成、代理、插件、API 或 OpenTelemetry 收集器。

14% 的受访者选择了商业可观测性平台。调查将 Datadog、New Relic 和 Dynatrace 归为一组，因此这一数字不应被解释为其中任何一家的单独采用数据。

• 最适合： 已经使用商业可观测性平台并希望将 CI/CD 数据添加到同一环境的组织。
• 突出能力： 托管存储和分析、跨系统关联、供应商支持以及现成集成。
• 局限： 订阅、摄取和保留成本可能会随着冗长日志和测试数据的增加而增长。CI/CD 集成深度、可移植性和数据驻留因供应商而异。

评估应关注具体的 CI/CD 集成，而不是平台的一般功能列表。测试用户是否能够从流水线回归问题转到相关阶段、测试、日志、代理指标和提交，而无需手动重建该上下文。

例如，Datadog Pipeline Visibility 为支持的 CI 提供商提供流水线级数据，而 New Relic 可以通过集成和变更跟踪接收 CI/CD 信息。

当 Datadog 已是其可观测性技术栈的一部分时，TeamCity 用户还可以将构建数据连接到 Datadog CI Visibility。

自定义内部可观测性

模式： 通常为自托管并在内部开发。

信号与 CI 上下文： 由组织定义，从规范化的流水线事件到自定义成本和基础设施数据。

配置： 自定义收集器、API、模式、存储、仪表板和访问控制。

12% 的受访者使用自定义解决方案。当组织运行多个 CI/CD 系统、专有基础设施、特殊硬件，或通用工具无法很好建模的交付流程时，这种方法更为常见。

• 最适合： 需求无法通过现有集成满足的大型或专业化组织。
• 突出能力： 完全控制数据模型、托管、CI 上下文和组织特定的分析。
• 局限： 组织拥有整个生命周期，包括插桩、安全、升级、文档和用户体验。

团队通常不需要从头构建整个可观测性系统。他们可以使用现有工具收集和存储流水线数据，然后只构建组织所需的自定义报告和功能。

如何评估流水线可观测性的选项

大多数团队不需要单一工具来处理流水线可观测性的每个部分。

从 CI/CD 平台内置的仪表板开始。如果你需要更多关于构建队列、可用代理或服务器健康状况的信息，请添加指标工具。如果你需要搜索来自多个系统的详细信息，请将相关日志收集到一个地方。当你需要跟踪复杂流水线和外部服务内部发生的事情时，追踪最有用。

比较工具时，请使用团队实际遇到过的问题来测试它们，例如构建缓慢、不稳定测试或构建代理过载。检查开发者能多快找到受影响的流水线运行、理解问题发生的位置，并收集足够的证据来解释它。

还要考虑设置和维护每个工具所需的工作量，以及它将存储的数据量。使用典型月份的流水线活动而不是小型测试项目来估算成本。

选择一个能帮助团队快速理解和解决流水线问题，而不会增加不必要复杂性的工具。

结语

有效的流水线可观测性设置将使交付过程不同部分的信息保持连接。这使团队能够看到哪个提交触发了构建、哪个代理运行了某个阶段，以及变慢是否与可用基础设施有关。

从当前设置无法回答的问题开始。使用本文中的框架来确定缺少哪些能力，然后使用真实的流水线问题和典型数据量来测试潜在工具。

正确的设置应帮助团队理解发生了什么，并更快地找到原因。

封面照片：由 David Billings 发布在 Unsplash 上