Question

Difficulty: HardCloudWatch Logs and Metric Filters

A SysOps Administrator is configuring a monitoring and remediation solution for a backend service running on Amazon EC2. The service outputs space-delimited logs to an Amazon CloudWatch Logs log group. A typical log entry is formatted as follows:

`api-srv-01 srv-core WARN 500 1200`

The fields, from left to right, represent: `Source`, `Service`, `LogLevel`, `StatusCode`, and `ResponseTimeMs`.

The administrator wants to:
1. Extract `ResponseTimeMs` as a custom metric named `TransactionLatency` in the `BackendApp` namespace.
2. Only count logs where the `LogLevel` is either `WARN` or `ERROR`, and the `StatusCode` is not equal to 200200.
3. Automatically restart the EC2 instance using the Systems Manager Automation document `AWS-RestartEC2Instance` if the average `TransactionLatency` exceeds 500500 ms over three consecutive 11-minute periods.

Which two steps must the SysOps Administrator take to meet these requirements? (Select TWO.)

  1. Create a CloudWatch Logs metric filter with the pattern `[source, service, level = WARN || level = ERROR, status != 200, latency]` and map the metric value to `$latency`.Answer
  2. B
    Create a CloudWatch Logs metric filter with the JSON pattern `{ .LogLevel="WARN".LogLevel = "WARN" || .LogLevel = "ERROR" && .StatusCode != 200 }` and map the metric value to `.ResponseTimeMs`.
  3. Create a CloudWatch alarm for the `TransactionLatency` metric that evaluates the average value over three consecutive 11-minute periods, and configure an Amazon EventBridge rule that triggers the `AWS-RestartEC2Instance` Systems Manager Automation document when the alarm transitions to the `ALARM` state.Answer
  4. D
    Create a CloudWatch alarm for the `TransactionLatency` metric that evaluates the average value over three consecutive 11-minute periods, and configure the alarm's action to directly execute the `AWS-RestartEC2Instance` Systems Manager Automation document when the alarm transitions to the `ALARM` state.
  5. E
    Enable detailed monitoring on the Amazon EC2 instances to decrease the metric filter evaluation and ingestion interval from 55 minutes to 11 minute.
  6. F
    Modify the log group retention period to 33 days to force CloudWatch Logs to aggregate the custom metric data points at 11-minute intervals.

Answer

Create a CloudWatch Logs metric filter with the pattern `[source, service, level = WARN || level = ERROR, status != 200, latency]` mapping the metric value to `$latency`, and configure an Amazon EventBridge rule to trigger the Systems Manager Automation document when the CloudWatch alarm transitions to the `ALARM` state.
The correct options are the ones stating that a positional metric filter pattern `[source, service, level = WARN || level = ERROR, status != 200, latency]` must be used, and that an EventBridge rule must be created to trigger the Systems Manager Automation document. The log entries are space-delimited, which necessitates positional bracket matching to map the fields. Because CloudWatch alarms do not natively support direct targets like Systems Manager Automation, the state transition of the alarm must be captured as an event in Amazon EventBridge, which then targets the Systems Manager Automation document to perform the EC2 restart.

Step-by-Step Solution

1
Define a CloudWatch Logs metric filter pattern suitable for space-delimited text logs.
The metric filter pattern `[source, service, level = WARN || level = ERROR, status != 200, latency]` matches the position of each space-delimited log field, filters the events, and maps the fifth field to the variable `$latency`.
This extracts only log messages with warning or error levels and non-200 statuses, enabling the retrieval of the response time values.
2
Create the custom metric transformation under the custom namespace and metric name.
A custom metric named `TransactionLatency` is published in the `BackendApp` namespace, with its value derived from the extracted `$latency` variable.
This establishes the numeric metric timeline necessary to configure threshold alarms.
3
Configure the CloudWatch alarm threshold and evaluation period.
A CloudWatch alarm is set up to evaluate the average of `TransactionLatency` over three 11-minute periods, triggering when the average is greater than 500500.
This defines the threshold condition under which remediation must occur.
4
Set up the remediation trigger using Amazon EventBridge.
An EventBridge rule matches the state change event of the CloudWatch alarm to `ALARM` and executes the target `AWS-RestartEC2Instance` Systems Manager Automation document.
This bridges the monitoring alarm with the automated operational remediation because CloudWatch alarms cannot directly call Systems Manager Automation.

Key Concept

CloudWatch Logs metric filters extract numeric metrics from space-delimited log events using positional bracket notation, and automated remediation requires routing CloudWatch alarm state change events through Amazon EventBridge to Systems Manager Automation.
Rate this question