Question

Difficulty: HardCloudWatch Logs and Metric Filters

A SysOps Administrator is configuring monitoring for a serverless application where AWS Lambda functions write JSON-formatted log events to an Amazon CloudWatch Logs log group. The administrator creates a metric filter with the pattern { $.level = "ERROR" } to count database connection failures. When errors occur, a custom metric named DatabaseFailures is incremented. The administrator also configures a CloudWatch alarm to alert the operations team if the count of errors is 5 or more within a 5-minute period. During normal operations, no database connection errors occur, and no log events are written to the log group at all, causing the alarm to enter the INSUFFICIENT_DATA state. Which combination of actions will prevent the alarm from entering the INSUFFICIENT_DATA state during periods of zero errors while maintaining accurate alerting behavior?

  1. A
    Enable detailed monitoring for the log group to force CloudWatch to evaluate the metric filter at 1-minute intervals, and adjust the alarm threshold to evaluate 1 period instead of 5 periods.
  2. B
    Configure an Amazon EventBridge rule that detects the INSUFFICIENT_DATA state and triggers a Systems Manager Automation document to write dummy log events to the log group.
  3. C
    Remove the log group retention limit by setting it to 'Never Expire' to ensure that historic log metrics are permanently available, and increase the alarm's evaluation periods to 24 hours.
  4. Set the default value of the metric filter's metric transformation to 0, and configure the CloudWatch alarm's missing data treatment to treat missing data as notBreaching.Answer

Answer

Set the default value of the metric filter's metric transformation to 0, and configure the CloudWatch alarm's missing data treatment to treat missing data as notBreaching.
Setting the default value of the metric filter's metric transformation to 0 ensures that if log events are ingested into the log group but do not match the error pattern, a value of 0 is reported to CloudWatch. However, if there is absolutely no traffic and no log events are sent to the log group at all, the metric filter is not evaluated, and no metric data is reported. To handle this second scenario, the CloudWatch alarm must be configured to treat missing data as notBreaching (good), which keeps the alarm in the OK state rather than INSUFFICIENT_DATA.

Step-by-Step Solution

1
Analyze the log ingestion behavior during zero-traffic periods.
No log events are sent to the CloudWatch Logs log group during these periods.
Understanding the source of the missing data is necessary to determine why the metric filter is not reporting metrics.
2
Evaluate the metric filter's default value configuration.
Setting the default value to 0 ensures that 0 is reported when log events are written but do not match the filter, but it does not report data if no logs are written at all.
A metric filter is only evaluated when log events are ingested; if there are no logs, no metric data is published.
3
Determine the necessary configuration on the CloudWatch alarm.
Configure the alarm to treat missing data as 'notBreaching' (good).
This prevents the alarm from entering the 'INSUFFICIENT_DATA' state when no metric data points are reported due to a complete lack of log ingestion.

Key Concept

Handling missing data in CloudWatch alarms generated by metric filters when log ingestion stops.
Rate this question