Soru

Zorluk: ZorCloudWatch Metrics and Alarms

A SysOps Administrator is monitoring a critical processing application running on a fleet of Amazon EC2 instances. The application publishes a custom CloudWatch metric named `QueueProcessingLatency` at 5-minute intervals. The administrator configures a CloudWatch alarm for this metric with a threshold of 200200 milliseconds, a period of 11 minute, and `EvaluationPeriods` set to 33. The alarm is configured to treat missing data as `nonBreaching`.

During a peak traffic event, the latency increases to 450450 milliseconds and remains high for an hour, but the alarm never transitions to the `ALARM` state.

Which of the following is the reason for this behavior, and how should it be resolved?

  1. A
    Enable detailed monitoring on the EC2 instances hosting the application. This will force all custom metrics published from the instances to report at 1-minute intervals, allowing the alarm to evaluate complete data.
  2. B
    Configure an Amazon EventBridge rule that detects when the custom metric is published, and route the raw metric data directly to an Auto Scaling scaling policy, bypassing the CloudWatch alarm evaluation.
  3. Change the alarm period to 5 minutes to align with the metric's publication frequency, or modify the application code to publish the metric at 1-minute intervals so that there is no missing data.Cevap
  4. D
    Decrease the Auto Scaling group's cooldown period to 60 seconds to match the 1-minute alarm evaluation period, allowing the instances to report metrics faster.

Cevap

Change the alarm period to 5 minutes to align with the metric's publication frequency, or modify the application code to publish the metric at 1-minute intervals.
The correct option is to align the alarm period with the metric frequency (5 minutes) or modify the application to publish at 1-minute intervals. Because the custom metric is only published every 5 minutes, a 1-minute alarm period means at least two out of the three evaluation periods will contain no data. Since missing data is treated as non-breaching, the alarm will never see three consecutive breaching periods to trigger.

Adım Adım Çözüm

1
Analyze the custom metric's publication frequency.
The metric is published every 5 minutes.
This determines how often actual data points are available in CloudWatch.
2
Analyze the alarm's evaluation parameters.
The alarm has a period of 1 minute and evaluates 3 periods.
This means the alarm looks for 3 consecutive 1-minute windows.
3
Determine the impact of the missing data policy.
In any 3-minute window, at most 1 minute has data, and the other 2 are missing. Since missing data is treated as non-breaching, the alarm will never register 3 out of 3 breaching data points.
This explains why the alarm remains in OK/INSUFFICIENT_DATA despite high latency.
4
Identify the resolution.
Align the alarm period with the metric frequency (5 minutes) or increase the metric publication rate (1 minute).
This ensures the alarm has sufficient data points to evaluate the threshold.

Anahtar Kavram

CloudWatch Alarm Evaluation and Metric Resolution Alignment
Bu soruyu puanla