Examkin

Soru

Zorluk: ZorCloudWatch Logs and Metric Filters

An application logs HTTP requests to an Amazon CloudWatch Log Group in a space-delimited format:

`timestamp request_id client_ip api_endpoint status_code latency_ms`

Example log event:
`1783987200 req-98765 203.0.113.55 /checkout 503 1240`

A SysOps Administrator must monitor checkout transaction failures. The requirements are:
- A CloudWatch alarm must trigger if there are more than 5 failures (where `status_code` is 500 or greater) on the `/checkout` endpoint within a 5-minute period.
- The custom metric must record a value of 0 when checkout transactions are processed but do not result in a 5XX error, preventing the alarm from entering an `INSUFFICIENT_DATA` state.
- If there is no traffic to the `/checkout` endpoint at all (no logs written), the alarm must remain in an `OK` state.
- Log data must not be stored indefinitely to control AWS costs, with a maximum retention of 30 days.

Which configuration strategy should the SysOps Administrator implement to meet these requirements?

  1. Configure the CloudWatch Log Group retention period to 30 days. Create a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, setting the metric value to 1 and the default value to 0. Create a CloudWatch alarm based on this metric with a threshold of 5, and set its TreatMissingData behavior to notBreaching.Cevap
  2. B
    Create a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, setting the metric value to 1 and the default value to 0. Leave the CloudWatch Log Group retention period at its default setting. Create a CloudWatch alarm on this metric with a threshold of 5, and configure its TreatMissingData behavior to missing.
  3. C
    Enable detailed monitoring on the EC2 instances hosting the application to support log-based custom metric publication. Create a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, setting the metric value to 1 and leaving the default value empty. Set the log group retention to 30 days. Create a CloudWatch alarm with a threshold of 5, and set its TreatMissingData behavior to notBreaching.
  4. D
    Create an Amazon EventBridge rule that triggers whenever any log event is written to the log group. Use an EventBridge input transformer to parse the log line for "/checkout" and status codes >= 500, then publish a custom metric to CloudWatch with a value of 1. Set the log group retention to 30 days. Create a CloudWatch alarm with a threshold of 5, and configure its TreatMissingData behavior to ignore.

Cevap

Configure the CloudWatch Log Group retention period to 30 days. Create a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, setting the metric value to 1 and the default value to 0. Create a CloudWatch alarm based on this metric with a threshold of 5, and set its TreatMissingData behavior to notBreaching.
The correct strategy involves setting the log group retention to 30 days to optimize storage costs, setting up a metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]` to filter space-delimited log messages, setting the default value to 0 to keep the metric active with 0 values for healthy checkout requests (or non-matching logs), and configuring the alarm to treat missing data as notBreaching to handle zero-traffic periods safely.

Adım Adım Çözüm

1
Set the log group retention period to 30 days.
Limits log storage duration, preventing indefinite retention costs in compliance with the cost requirement.
By default, log groups have an infinite retention period ('Never Expire'), which incurs ongoing storage charges unless explicitly configured.
2
Define the metric filter pattern for space-delimited logs and specify the metric transformation parameters.
A metric filter with the pattern `[timestamp, request_id, client_ip, api_endpoint = "/checkout", status_code >= 500, latency_ms]`, a metric value of 1, and a default value of 0 is created.
The pattern extracts status codes of 500 or greater for the '/checkout' endpoint. Setting the default value to 0 ensures that whenever any log event is written to the log group but does not match this failure pattern (i.e., healthy checkout requests or other endpoint requests), CloudWatch publishes a 0, keeping the metric populated and preventing false alarms.
3
Configure the CloudWatch alarm based on the custom metric.
An alarm is created with a threshold of 5 and TreatMissingData set to notBreaching.
If there is zero traffic and no logs are written at all, the metric filter is not executed, resulting in no data points. Setting TreatMissingData to notBreaching ensures the alarm remains in the OK state rather than transitioning to INSUFFICIENT_DATA or triggering falsely.

Anahtar Kavram

Configuring CloudWatch Logs metric filters for space-delimited log formats, utilizing metric default values to maintain continuous reporting, and setting alarm missing data behaviors to handle periods of zero traffic.
Bu soruyu puanla

Konular

CloudWatch Logs and Metric Filters

Bu konudan daha fazla soru