不触碰任何工作流文件的CI管道分布式追踪
内容提要
文章介绍如何通过GitHub Webhook和OpenTelemetry Collector的githubreceiver组件，零侵入地收集组织级CI工作流追踪数据。它无需修改各仓库工作流文件，自动覆盖所有现有及未来仓库，将工作流、任务和步骤映射为OTLP追踪跨度，并集成到现有追踪后端。文章还讨论了部署注意事项、数据量估算方法及获取团队支持的建议。
延伸解读
零侵入的代价：alpha 组件与配置陷阱
githubreceiver 是 OpenTelemetry Collector 的 contrib 组件，仍处于 alpha 阶段，配置可能变化。文章建议固定 collector 版本并留意更新日志。此外，即使只使用 webhook 追踪，scrapers 配置块也必须存在（可填 dummy 条目），否则校验失败。这些细节提醒我们，零侵入方案并非零配置，部署前需仔细阅读文档并测试。
数据量估算：别被仓库总数误导
文章强调，估算 CI 追踪数据量时，不应以仓库总数为基准，因为其中包含大量休眠或归档仓库。正确方法是统计一周内有实际工作流活动的仓库数，再乘以平均运行次数和步骤数，得出预期 span 量。将结果与现有应用追踪量对比，通常 CI 数据只是“零头”。这种基于实际活动的估算，比拍脑袋更可靠，也更容易说服预算持有者。
与 Actions Runner Controller 互补而非替代
如果你使用 ARC 管理自托管 runner，需明确此方案不替代 ARC。ARC 提供 runner 队列深度、自动扩缩容等指标，关注基础设施；而此方案通过追踪工作流运行，回答“某个 run 为何慢”“哪些工作流不稳定”等问题。两者从不同视角看同一问题，建议同时运行，以获得完整视图。
Q&A
如何在不修改任何工作流文件的情况下收集GitHub Actions的CI追踪数据？
通过设置一个组织级的GitHub Webhook，并使用OpenTelemetry Collector的githubreceiver组件，将workflow_run和workflow_job事件转换为OTLP追踪跨度。这样无需修改各仓库的工作流文件，即可自动覆盖所有现有及未来仓库。
githubreceiver组件将GitHub事件映射为追踪跨度时，workflow、job和step是如何对应的？
一个workflow对应一个外层跨度，每个job作为其子跨度，每个step作为job的子跨度，形成层级结构，便于深入分析。
githubreceiver生成的span和trace ID是如何确定的？有什么好处？
span和trace ID是确定性地从workflow的run ID和job的check run ID哈希生成的。好处是，如果用户想从步骤内部发出自己的遥测数据，可以使用工具计算匹配的ID，直接附加到同一追踪，无需与收集器协调。
部署githubreceiver时，为什么需要配置scrapers块？
scrapers块虽然属于该接收器提供的GraphQL/REST指标功能，与追踪无关，但配置验证要求至少有一个虚拟条目，否则即使只需要webhook端，配置也会失败。
在部署githubreceiver之前，需要考虑哪些安全性和权限问题？
需要确保收集器有公开可达的端点，并配置IP白名单或WAF限制为GitHub的webhook源范围，不能仅依赖共享密钥。也可以选择GitHub App来管理密钥。此外，设置组织级webhook需要组织管理员权限，并需验证GitHub Enterprise Server的webhook行为。
如何估算CI追踪数据量，以避免产生意外成本？
首先扫描组织中活跃的仓库数（有真实工作流活动的），而不是总仓库数。然后乘以平均每次运行的步骤数得到预期跨度数，再乘以典型负载大小得到每日数据量。最后与现有应用追踪量对比，通常CI追踪量相对较小。
githubreceiver与Actions Runner Controller (ARC) 的指标有何不同？
ARC的指标关注runner舰队，如pod数量、自动扩缩容和队列深度；而githubreceiver关注工作流本身，如特定运行为何慢、哪些工作流不稳定。两者互补，应同时运行。
