不动 CI 配置：OpenTelemetry 采集 GitHub Actions 追踪数据
OpenTelemetry Collector 的 githubreceiver 组件可以接住组织级 GitHub webhook，把 workflow_run 与 workflow_job 事件转成 OTLP 链路，工作流、任务与步骤分别对应外层和子级 span，团队无需改动任何仓库的 YAML 就能获得跨组织视图；组件仍处 alpha 阶段，文档给出了部署前检查与容量估算方法。
作者：核流编辑 · 栏目：资源
组织里的 GitHub Actions 用量往往悄悄上涨，可见性却停在单仓级别：哪个工作流慢、哪些任务抖动、排队时间多长，要一个个仓库去翻。一个开源采集方案能在不动任何工作流文件的前提下补齐这块：把 OpenTelemetry Collector 挂在组织级 webhook 后面，用它的 githubreceiver 组件接事件。 关键认识是 GitHub 本来就会持续发出 workflow_run 与 workflow_job 事件，组织级只需监听一次。Collector 把事件直接转成 OTLP span：一个工作流是一条外层 span，内部任务和步骤逐层挂子 span，方便下钻排查。该组件仍处于 alpha 阶段，配置可能变化，建议固定 Collector 版本再升级。部署前要提前决定的事包括：Collector 需要公网可达，建议按 GitHub webhook 源地址段限制访问或用 GitHub App 代替静态共享口令；配置组织级 webhook 需要管理员权限。 容量估算与开始使用 容量别按仓库总数估算：先统计一周内真正有工作流活动的活跃仓库，再乘平均运行次数与平均步骤数，得到 span 量级，通常远小于应用链路追踪的体积。想动手试，githubreceiver 的仓库里有完整配置示例（见参考资料），导出端走 OTLP，接 Tempo、Jaeger 或 Datadog 都可以；组织级 webhook 配置一次即可覆盖所有仓库，包括之后新建的仓库。它不替代 Runner 侧的队列指标，两者解决的是不同层面的问题。 参考资料 CNCF Blog：Distributed tracing for CI pipelines without touching a single workflow file OpenTelemetry Collector Contrib：githubreceiver（opentelemetry-collector-contrib）