Soru

Zorluk: Çok zorCloudWatch Metrics and Alarms

An application deployed on Amazon EC2 instances publishes a custom metric named `TransactionLatency` at 1010-second intervals using the AWS SDK. The metric is sent with three dimensions: `ClusterName`, `Service`, and `Region`. A SysOps Administrator needs to configure an Amazon CloudWatch alarm to trigger if the average latency across all services in the `prod-cluster` cluster exceeds 150 ms150\text{ ms} for 33 consecutive 11-minute evaluation periods. The administrator creates a CloudWatch alarm for `TransactionLatency` specifying a single dimension of `ClusterName=prod-cluster` and a period of 1 minute1\text{ minute}. However, the alarm remains in the `INSUFFICIENT_DATA` state even though the services are actively publishing metrics. Which of the following describes the root cause of this issue and the correct resolution?

  1. A
    The Auto Scaling group's scaling cooldown period (set to 300300-seconds) is longer than the alarm evaluation window of 3 minutes3\text{ minutes} (3×1 minute3 \times 1\text{ minute}), which suppresses custom metric data retrieval until the cooldown period expires.
  2. B
    Detailed monitoring must be enabled for the EC2 instances. Custom metrics published at high-resolution require detailed monitoring to be active on the host instances in order to aggregate data at 11-minute intervals.
  3. CloudWatch does not support automatic aggregation across dimensions. The administrator must use a CloudWatch Metric Math `SEARCH` expression to aggregate the metrics across the omitted dimensions, or publish the metric with only the `ClusterName` dimension.Cevap
  4. D
    The custom metric must be routed through an Amazon EventBridge rule to an AWS Systems Manager Automation runbook. High-resolution metrics evaluated over standard periods cannot be processed directly by CloudWatch Alarms without this intermediate automation step.

Cevap

CloudWatch does not support automatic aggregation across dimensions. The administrator must use a CloudWatch Metric Math SEARCH expression to aggregate the metrics across the omitted dimensions, or publish the metric with only the ClusterName dimension.
The correct answer states that CloudWatch does not support automatic aggregation across dimensions. Each unique set of dimensions uniquely identifies a metric in CloudWatch. If a metric is published with multiple dimensions (ClusterName, Service, and Region), querying that metric using only a subset (ClusterName) will look for a metric published with only that single dimension. Since no such metric exists, the query returns no data, causing the alarm to remain in the INSUFFICIENT_DATA state. The resolution is to either modify the application to publish the metric with the desired aggregated dimension set, or use Metric Math SEARCH expressions to aggregate the metrics.

Adım Adım Çözüm

1
Analyze how Amazon CloudWatch stores and identifies metrics based on dimensions.
Identify that CloudWatch treats each unique dimension combination as a distinct metric identity, and does not automatically roll up or aggregate metrics by subset dimensions.
This explains why querying a metric with a subset of the published dimensions (e.g., querying only ClusterName when ClusterName, Service, and Region are published) returns no data.
2
Evaluate the proposed solutions for aggregating multi-dimensional metrics.
Determine that the administrator can either publish the metric with fewer dimensions or use CloudWatch Metric Math with a SEARCH function to dynamically aggregate the metrics in real time.
This identifies the necessary remediation steps to make the aggregate metrics visible to the alarm configuration.
3
Validate the correct configuration for the CloudWatch alarm.
Ensure that the alarm targets either the exact dimension combination or uses the metric math expression to resolve the INSUFFICIENT_DATA state.
This completes the troubleshooting and resolution process.

Anahtar Kavram

CloudWatch Metric Dimensions and Aggregation
Tahmini Süre:3m 0s
Bu soruyu puanla