Actions Runner Controller中高基数指标导致的内存泄漏问题分析

在GitHub Actions生态系统中，Actions Runner Controller是一个重要的自托管运行器管理工具。近期在0.9.2版本中，用户报告了一个关键的性能问题：ghalistener组件在处理工作流任务时会产生高基数(high cardinality)的监控指标，导致系统资源持续消耗并最终影响服务稳定性。

问题本质

该问题的核心在于ghalistener生成的Prometheus指标中包含了两个高度动态变化的标签：

• runner_id：每个运行器的唯一标识符
• runner_name：运行器的名称

这些标签会为每个工作流任务创建全新的指标时间序列，例如：

gha_completed_jobs_total{...,runner_id="71363",runner_name="self-hosted-linux-x64-zfhfn-runner-k752n"} 1
gha_completed_jobs_total{...,runner_id="71369",runner_name="self-hosted-linux-x64-zfhfn-runner-pr56c"} 1

问题影响

1. 指标爆炸：每个工作流任务都会创建新的时间序列，导致指标数量呈线性增长
2. 资源泄漏：ghalistener需要维护这些永不更新的指标，内存和CPU使用率会持续上升
3. 监控失效：当指标数量超过Prometheus处理能力时，监控系统可能崩溃

从用户提供的监控图表可以明显看到，随着时间推移，ghalistener的内存使用呈现稳定上升趋势，最终需要强制重启才能恢复正常运行。

技术背景

在监控系统设计中，高基数指标是一个常见陷阱。Prometheus等监控系统对每个唯一标签组合都会创建独立的时间序列。当标签值高度动态变化时（如包含随机生成的ID），会导致时间序列数量爆炸式增长。

解决方案

该问题已在githubrunnerscalesetlistener组件中通过PR #3003修复，主要方法是：

1. 移除导致高基数的标签（runner_id和runner_name）
2. 同时移除了job_workflow_ref标签，这也是另一个高基数来源

最佳实践

在设计监控指标时，应该：

1. 避免使用高度动态的值作为标签
2. 保持标签值的有限集合
3. 对于运行器这类临时资源，考虑使用聚合指标而非实例级指标
4. 定期审查指标基数，防止意外增长

结论

高基数指标问题在分布式系统中尤为常见，开发者需要特别注意监控指标的设计。Actions Runner Controller的这个问题提醒我们，即使是成熟的开源项目，也需要持续优化其监控策略。对于使用该组件的用户，建议升级到包含修复的版本，以避免潜在的系统稳定性问题。