feat(cloudwatch): construct for alarms based on anomaly detection (#10540)

[vgolemis]

feat(cloudwatch): construct for alarms based on anomaly detection (#10540)

Issue # (if applicable)

Closes #10540.

Reason for this change

Introduce new construct AnomalyDetectionAlarm that covers the gap of creating an Alarm based on anomaly detection.

Description of changes

• Documentation for the API of AnomalyDetectionAlarm
• New class AnomalyDetectionAlarm that creates an alarm that utilizes [CloudWatch anomaly detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html
  • The underlying resource is a AWS::CloudWatch::Alarm
  • It can create the Alarm either directly if the metric property has an ANOMALY_DETECTION_BAND metric expression or can generate it. The user can provide the generateAnomalyDetectionExpression property to define this behavior.
  • Validates the the ComparisonOperator provided applies to the anomaly detection scenario.
  • The thresholdMetricId was not exposed to the user because the IMetric interface does not provide a property to define the id of the metric. This is done when defining the MetricDataQueryProperty; decided to not force the user to provide the array of MetricDataQueryProperty.
  • The threshold property is mandatory by the CreateAlarmOptions. It was repurposed to define the anomaly detection threshold if the function generates the ANOMALY_DETECTION_BAND metric expression.
  • The implementation of the renderMetric() verifies the expressions provided are correct and forces the appropriate reference ids to be in place.
• The static methods fromAlarmName() and fromAlarmArn() were the same for Alarm and CompositeAlarm so moved the to the AlarmBase so all of the classes can access them.

Description of how you validated changes

Integration test and Unit tests and have been added for the AnomalyDetectionAlarm. Verified the existing tests for the Alarm and CompositeAlarm are not impacted.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 0a30d8f
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[comcalvi]

Why is there no CfnAnomalyDetector in this construct? Can you help me understand how this works? I thought the AnomalyDetectorAlarm required a reference to the metric of an AnomalyDetector

[comcalvi]

could we move these from methods out of the Base class? These methods should always be named fromXyzArn or fromXyzName, where Xyz is the name of the construct; Alarm, for example, but also fromAnomalyDetectionAlarm

[comcalvi]

The AnomalyDetectionAlarmProps extend the AlarmProps, but the AnomalyDetectionAlarm does not extend Alarm.

Why is the AnomalyDetectionAlarm a separate construct? It looks like it's a strict superset of the Alarm we have already, which suggests that instead of making a new construct we could add a prop to Alarm.

To make this decision we have to understand what the differences between an AnomalyDetectionAlarm and an Alarm are. Are there any properties unique to the AnomalyDetectionAlarm which conflict with the props of a regular Alarm? (Props 'A' and 'B' are said to conflict if I can (or should) specify 'A' or 'B', but not both).

[aws-cdk-automation]

This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

[aws-cdk-automation]

This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error.