Fargate集群基于自定义指标自动伸缩的维度配置问题

这是CloudWatch自定义指标的核心机制导致的：和Prometheus这类会自动构建全维度索引的监控系统不同，CloudWatch的指标时间序列完全由命名空间+指标名+上报时携带的全量维度组合唯一确定，平台不会自动生成仅包含部分维度的聚合时间序列。
你每次上报指标都带了4个维度，CloudWatch只会存储这4个维度共同对应的独立序列，你查询时仅指定EVENT_TYPE单个维度，根本不存在匹配的对应序列，自然返回空结果。
另外你当前告警里的指标查询写了两个完全重复的m1/m2单维度查询，本质还是在查不存在的序列，外层写SUM(METRICS())也聚合不出有效数据。

优先用双指标并行上报方案，这是AWS官方推荐的ECS自定义指标伸缩最佳实践，稳定性最高、配置最简单，完全适配你的场景：

• 一次webhook事件触发时，同步写入两类同值的自定义指标：
  • 明细指标：携带全部4个维度（REPO_OWNER/REPO_NAME/EVENT_TYPE/ID），新任务启动时值为1，任务结束/取消时值为-1，这类指标仅用于后续问题排查、分仓库维度的统计分析，不用于告警配置。注意ID属于高基数维度（每个工作流运行值都唯一），这类维度不要加到聚合指标上，否则CloudWatch会按独立时间序列收费，量起来之后成本会飙升，这类唯一标识更适合打印到日志中做关联排查。
  • 聚合指标：仅携带静态维度EVENT_TYPE:workflow_job，值和同批次上报的明细指标完全一致，这个指标会生成你需要的单维度全局时间序列，直接用于伸缩告警配置即可。

告警配置修正示例 #

去掉冗余的重复指标查询和不必要的数学表达式，直接引用聚合指标：

const alarmPeriod = 120 as const

// 扩容告警
new CloudwatchMetricAlarm(this, `autoscale-up-alarm-${environment}`, {
  alarmName: `fargate-cluster-scale-up-alarm-${environment}`,
  alarmDescription: `Scales up the Fargate cluster based on aggregated runner request metric`,
  comparisonOperator: 'GreaterThanThreshold',
  threshold: 0,
  evaluationPeriods: 1,
  metric: {
    metricName: options.aggregatedCustomMetricName, // 替换为仅带EVENT_TYPE维度的聚合指标名
    namespace: options.customCloudWatchMetricNamespace,
    period: alarmPeriod,
    stat: 'Sum',
    unit: 'Count',
    dimensions: {
      EVENT_TYPE: 'workflow_job',
    }
  },
  alarmActions: [scaleUpPolicy.arn],
  actionsEnabled: true,
})

// 缩容告警
new CloudwatchMetricAlarm(this, `autoscale-down-alarm-${environment}`, {
  alarmName: `fargate-cluster-scale-down-alarm-${environment}`,
  alarmDescription: `Scales down the Fargate cluster based on aggregated runner request metric`,
  comparisonOperator: 'LessThanThreshold',
  threshold: 1,
  evaluationPeriods: 1,
  metric: {
    metricName: options.aggregatedCustomMetricName, // 替换为仅带EVENT_TYPE维度的聚合指标名
    namespace: options.customCloudWatchMetricNamespace,
    period: alarmPeriod,
    stat: 'Sum',
    unit: 'Count',
    dimensions: {
      EVENT_TYPE: 'workflow_job',
    }
  },
  alarmActions: [scaleDownPolicy.arn],
  actionsEnabled: true,
})

如果不想上报双指标，可以用CloudWatch指标搜索的通配匹配能力，在告警中匹配所有EVENT_TYPE=workflow_job的时间序列后做SUM聚合。但这个方案有明确的硬限制：单条告警最多支持匹配100条时间序列，如果你方工作流并发较高、ID维度值过多，很容易触发上限导致告警失效，生产环境不推荐使用。

内容的提问来源于stack exchange，提问作者GPX