Examkin

Soru

Zorluk: ZorCloudWatch Metrics and Alarms

A SysOps Administrator is managing a microservices application running on a fleet of Amazon EC2 instances. The fleet size fluctuates dynamically based on demand via an Auto Scaling group. Each instance publishes a custom CloudWatch metric named `RequestLatency` in the namespace `CustomApp` using two dimensions: `InstanceId` and `ServiceName`. The administrator needs to configure a single CloudWatch alarm to alert when the average `RequestLatency` for the service named `InventoryService` exceeds 500500 milliseconds across the entire fleet. Which two configurations or actions should the administrator perform to achieve this? (Select TWO.)

  1. Modify the application code to publish the RequestLatency metric a second time using only the ServiceName dimension, and configure the CloudWatch alarm to monitor this new metric.Cevap
  2. Configure the CloudWatch alarm using a Metric Insights query: SELECT AVG(RequestLatency) FROM SCHEMA("CustomApp", ServiceName) WHERE ServiceName = 'InventoryService'.Cevap
  3. C
    Configure the CloudWatch alarm to monitor RequestLatency in the CustomApp namespace, specifying the ServiceName dimension as InventoryService and leaving the InstanceId dimension blank.
  4. D
    Configure a CloudWatch Metric Math expression using the SUM function to automatically aggregate RequestLatency across all dynamic InstanceId values.
  5. E
    Enable detailed monitoring on all EC2 instances in the Auto Scaling group so that CloudWatch automatically aggregates custom namespace metrics at 1-minute intervals.

Cevap

To monitor the aggregate latency of a custom metric across a dynamic fleet of instances, the administrator should either configure the CloudWatch alarm using a Metric Insights query to aggregate the metrics, or modify the application code to publish the metric a second time without the instance ID dimension.
To alarm on the average latency of a service across a dynamic fleet of instances, the SysOps Administrator must overcome the limitation that CloudWatch does not automatically aggregate custom metrics across dimensions. Modifying the application code to publish the metric with only the ServiceName dimension creates an aggregated metric stream that can be directly alarmed on. Alternatively, using a CloudWatch Metric Insights SQL query allows real-time aggregation over the dynamic InstanceId dimension, outputting a single aggregated time series suitable for an alarm.

Adım Adım Çözüm

1
Identify how CloudWatch handles custom metrics with multiple dimensions.
Recognize that CloudWatch treats every unique combination of dimensions as a separate metric stream, meaning it does not automatically aggregate custom metrics across dimensions.
This explains why querying the metric by omitting the InstanceId dimension in a standard alarm configuration results in missing data.
2
Evaluate application-side changes to support aggregate monitoring.
Understand that publishing the metric twice—once with both dimensions and once with only the ServiceName dimension—creates an aggregated stream.
This allows the SysOps Administrator to configure a standard CloudWatch alarm directly on the single-dimension metric stream representing the whole fleet.
3
Evaluate query-side aggregation using CloudWatch Metric Insights.
Construct a SQL query that aggregates the metric across the dynamic InstanceId dimension and filters by ServiceName.
CloudWatch Metric Insights enables real-time query aggregation, and CloudWatch alarms can be created directly on queries that return a single time series.

Anahtar Kavram

CloudWatch Custom Metric Dimensions and Aggregation
Bu soruyu puanla

Konular

CloudWatch Metrics and Alarms

Bu konudan daha fazla soru