Grafana 和 Gitlab 引入无服务器 CI/CD 可观察性集成

作者 | Craig Risi

译者 | 王强

为了简化开发工作流，GrafanaLabs 的 Daniel Fritzgerald 发布了一个新的开源解决方案，该方案通过无服务器架构将 GitLab CI/CD 事件链接到 Grafana 的可观测性堆栈中。这种集成使得团队能够将 GitLab 的 webhooks（如推送、合并请求和流水线完成）直接导入 Grafana Cloud Logs（基于 Grafana Loki 构建）中，以实现部署事件和性能指标之间的实时可见性和关联。

该方案解决的核心挑战是源代码控制、CI/CD 工具和可观测性系统之间的碎片化。许多团队在互不连通的各种仪表板中挣扎：开发人员可能在 GitLab 上检查流水线状态；运维人员在 Grafana 中查看日志；这两种视图都与底层指标或部署没有直接联系，导致事故响应变慢和手动关联的麻烦。GitLab-Grafana 集成将结构化的 CI/CD 事件导入统一的日志流中，从而填补了这一空白，使团队能够监控流水线健康状况、部署频率，并与系统指标关联变更。

从技术角度来看，该解决方案依赖于一个轻量级的无服务器函数（如 AWS Lambda），该函数通过 API 网关端点接收 GitLab webhooks，将负载格式化为结构化日志，并将其发送到 Grafana Cloud Logs 中。用户随后可以使用 LogQL 查询按项目分析 CI/CD 活动、部署成功率或构建时间。此外，这些日志可以与 Grafana 仪表板中的应用程序性能数据结合使用，例如，将错误率与特定的部署或代码更改一起绘制。

这种无服务器可观测性流水线的引入很好地使 CI/CD 遥测成为监控平台中的一等公民。团队现在可以根据部署趋势（例如，构建失败、流水线时间过长、部署频率降低）创建警报，可视化开发人员生产力和发布速度，并推动变更失败率和部署恢复时间的合规性或审计报告。Grafana 指出，这种集成风格反映了向统一可见性的更广泛转变，其中代码更改、指标、日志和跟踪成为单一工作流的一部分。

对于寻求采用这种模型的组织，兼容的设置通常遵循四个步骤：使用 Grafana Cloud 凭据部署 Lambda 函数，为 GitLab webhooks 创建 API 端点，配置 GitLab 将事件发送到该端点，并开始在 Grafana 中构建仪表板。根据博客文章，团队可以用极少的代码（大约 69 行 Python）在不到 30 分钟内设置集成。

对这种可观测性方法感兴趣的人来说，这里有一些额外的模板，可以帮助实现类似的效果，并用于展示 CI/CD 可观测性，特别是与 GitLab + Prometheus 一起使用：

GitLab CI Pipelines 仪表板（ID: 10620）：此仪表板使用 Prometheus 作为数据源，可视化 GitLab CI 流水线的指标。它包括流水线持续时间、成功 / 失败计数、作业指标等面板。

来自 GitLab CI Pipelines Exporter 的 仪表板 JSON：gitlab-ci-pipelines-exporter 项目提供了一个示例仪表板 JSON，你可以导入或自定义它。

GitLab 自托管 Grafana 仪表板 仓库：GitLab 维护一个包含样本仪表板（用于 GitLab 指标）的仓库，包括性能、CI 指标等。

GitLab Runner 仪表板（ID: 21662）：此仪表板专注于运行器指标，可以显示运行器基础设施的健康状况、并发性和性能，是流水线仪表板的补充。

一位 Reddit 用户描述了他们如何消费 CI/CD 流水线事件或部署 webhooks 并将它们输入到 Grafana Logs 面板中。例如，他们发布了一个 webhook 服务，使用了一个 Grafana 数据源插件，并在 Grafana 日志中显示了 GitLab 流水线事件。

总体而言，这种集成标志着将开发工作流与可观测性工具链接起来的一次进步。通过将 CI/CD 事件视为结构化日志，并使它们与指标和跟踪一起可查询，团队获得了对其软件交付生命周期的更全面视图——减少了发现问题的时间，提高了事故响应，并使开发人员行动与运营结果保持一致。

Grafana and GitLab Introduce Serverless CI/CD Observability Integration(https://www.infoq.com/news/2025/11/grafana-gitlab-serverless-cicd/)

声明：本文为 InfoQ 翻译，未经许可禁止转载。