Aws-cdk: [aws-cloudwatch] Missing ThresholdMetricId

[alextriaca]

When creating Cloudwatch Alarm that makes use of anomaly detection the following error is raised at deploy time:

ComparisonOperators for ranges require ThresholdMetricId to be set (Service: AmazonCloudWatch; Status Code: 400; Error Code: ValidationError; Request ID: xxx; Proxy: null)

Reproduction Steps

aws_cloudwatch.Alarm(
     self,
    "my_alarm",
    evaluation_periods=1,
    metric=sqs_queue.metric_number_of_messages_sent(),
    threshold=2,
    statistic="Average",
    comparison_operator=aws_cloudwatch.ComparisonOperator.LESS_THAN_LOWER_OR_GREATER_THAN_UPPER_THRESHOLD,
)

The Alarm construct works great for any of the other ComparisonOperators that do not rely on anomaly detection i.e. GreaterThanThreshold.

Environment

• CLI Version : 1.62.0
• Framework Version: 1.64.0
• Node.js Version: v12.14.1
• OS : MacOS Catalina
• Language (Version): Python 3.7

---

This is :bug: Bug Report

[rrhodes]

Hello, I'm working on a fix for this now, a PR should be open shortly.

[alextriaca]

Absolute legend! Thanks @rrhodes 😄

[rrhodes]

This will be my first contribution to CDK, so bear with me, I suspect regular contributors will have valuable feedback for me. :)

[NetaNir]

In the meantime, If you really need this feature you can configure it using escape hatch:

const anomalyDetectionExp = new cloudwatch.MathExpression({
  expression: 'ANOMALY_DETECTION_BAND(m1,2)',
  usingMetrics: {
    m1: metricA,
  },
  label: 'Anomaly detection',
  period: cdk.Duration.minutes(1),
});

const alarm = anomalyDetectionExp.createAlarm(this, 'MyAlarm', {
  evaluationPeriods: 1, 
  threshold: 5, // dummy value will be removed below 
  comparisonOperator: ComparisonOperator.LESS_THAN_LOWER_OR_GREATER_THAN_UPPER_THRESHOLD,
});

const cfnAlarm = alarm.node.defaultChild as CfnAlarm;
cfnAlarm.addPropertyDeletionOverride('Threshold');
(alarm.node.defaultChild as CfnAlarm).thresholdMetricId = 'expr_1'; // The id will always be 'expr_1' if there is one expression

[rrhodes]

An L2 solution for this problem remains outstanding. Initial work to embed support for threshold metric IDs into the existing Alarm and Metric functionality left the code in a less than desirable state for maintenance going forward, notably because any metric using thresholdMetricId cannot possess a threshold property. The PR for that approach is now closed but remains available for future reference.

@NetaNir suggested the following, which I agree would be the best approach at this time:

Since there are several such subtleties in the anomaly detection alarm (e.g the allowed operators, annotation, returnData), it probably makes more sense to implement a createAnomalyDetectionAlarm.