Examkin

Soru

Zorluk: ZorCloudWatch Metrics and Alarms

An operations team is running a containerized transaction service on Amazon ECS. To monitor transaction processing delays, they publish a custom metric named ProcessingLatency to Amazon CloudWatch. They set up a CloudWatch alarm with an evaluation period of 10 seconds to alert them of latency spikes. However, they observe that the alarm remains in an INSUFFICIENT_DATA state during periods of low transaction volume, and even under normal load, it fails to trigger reliably. Which of the following explains why this alarm is failing to function as expected?

  1. A
    Detailed monitoring has not been enabled for the underlying ECS container instances, which limits all custom metric dimensions to a default 5-minute reporting interval.
  2. The custom metric is being published with standard storage resolution (1-minute interval), but the alarm is configured with an evaluation period of 10 seconds.Cevap
  3. C
    The custom metric is not associated with an Amazon EventBridge rule that is required to route sub-minute metric data points directly to CloudWatch Alarms.
  4. D
    The ECS service's auto-scaling cooldown period is set to a value shorter than 10 seconds, which causes CloudWatch to suppress metric data points during evaluation.

Cevap

The custom metric is being published with standard storage resolution (1-minute interval), but the alarm is configured with an evaluation period of 10 seconds.
The option specifying that the custom metric is published with standard storage resolution while the alarm is configured with a 10-second period is correct. By default, custom metrics are stored in CloudWatch with a standard resolution of 1 minute. If you configure a CloudWatch alarm with a high-resolution period (such as 10 seconds or 30 seconds), the alarm will look for data points in those small windows. Because standard resolution metrics only receive data points once every 60 seconds, the alarm will frequently have no data to evaluate, leading to an INSUFFICIENT_DATA state. To resolve this, the metric must be published with high-resolution storage (using the StorageResolution parameter set to 1 in the API call) or the alarm period must be adjusted to 60 seconds or longer.

Adım Adım Çözüm

1
Analyze the custom metric publishing frequency.
By default, custom metrics sent to CloudWatch have a standard storage resolution of 1 minute.
To identify if the metric frequency is sufficient to support sub-minute alarm evaluation.
2
Compare the metric frequency with the alarm evaluation period.
The alarm is configured with a 10-second period, which requires high-resolution data points (1-second resolution) to avoid missing data.
An alarm period of less than 60 seconds requires high-resolution metrics to ensure data is present in each evaluation window.
3
Determine why the alarm remains in the INSUFFICIENT_DATA state.
Since the metric is standard resolution (1-minute), most 10-second evaluation intervals contain zero data points, leading to the INSUFFICIENT_DATA status.
Without high-resolution storage enabled for the custom metric, sub-minute alarms cannot function correctly.

Anahtar Kavram

CloudWatch Custom Metric Storage Resolution and Alarm Periods
Bu soruyu puanla

Konular

CloudWatch Metrics and Alarms

Bu konudan daha fazla soru