Question

Difficulty: MediumMonitoring and Analyzing Logs with Amazon CloudWatch

An application running on Amazon EC2 writes log events to a local file in a space-delimited text format. The CloudWatch agent is configured to send these logs to an Amazon CloudWatch Logs log group. A typical log event looks like this:

`2026-07-14 WARN req-8812 450 502`

The positions of the values represent `[timestamp, log_level, request_id, latency_ms, status_code]`.

A developer wants to create a metric filter to capture the latency of requests that result in either a `WARN` or `ERROR` log level. The metric filter must extract the `latency_ms` value to publish a custom metric. The developer's initial attempt at configuring the metric filter pattern is `{ .loglevel=="WARN".log_level == "WARN" || .log_level == "ERROR" }` with a metric value of `$.latency_ms`. This configuration does not match any log events and fails to publish the metric.

Which of the following changes must the developer make to the metric filter configuration to correctly parse the logs and extract the latency metric? (Select TWO.)

  1. Define the filter pattern using square brackets to name the fields, such as: `[timestamp, log_level = "WARN" || log_level = "ERROR", request_id, latency_ms, status_code]`Answer
  2. Specify the metric value as `$latency_ms` to reference the extracted field.Answer
  3. C
    Define the filter pattern using curly braces to parse the fields, such as: `{ .loglevel="WARN".log_level = "WARN" || .log_level = "ERROR" }`
  4. D
    Specify the metric value as `$.latency_ms` in the metric value field to match the JSON path syntax.
  5. E
    Reference the metric value as `latency_ms` without any prefix, as CloudWatch automatically maps the variable name from the pattern.

Answer

The filter pattern must be defined using square brackets to map the fields of the space-delimited log, and the metric value must reference the extracted variable using a dollar sign prefix.
To create a metric filter for space-delimited text logs (non-JSON), the filter pattern must use square brackets `[]` to define the positions of the fields, rather than curly braces `{}` which are reserved for JSON log formats. Additionally, when extracting a value to publish as a custom metric, the metric value field must reference the defined field name using a dollar sign prefix (e.g., `latencyms)insteadofJSONpathdotnotation(e.g.,latency_ms`) instead of JSON path dot notation (e.g., `.latency_ms`).

Step-by-Step Solution

1
Identify the format of the application logs.
The log event is space-delimited, not JSON.
Understanding the log format determines whether to use JSON syntax (curly braces) or space-delimited syntax (square brackets).
2
Formulate the correct filter pattern syntax.
The filter pattern must use square brackets and single equal signs, resulting in `[timestamp, log_level = "WARN" || log_level = "ERROR", request_id, latency_ms, status_code]`.
Square brackets instruct CloudWatch to parse the log line as space-delimited tokens, and a single equals sign is used for comparison.
3
Determine the correct metric value reference syntax.
The metric value must be specified as `$latency_ms`.
For space-delimited logs, CloudWatch Logs requires variable references to be prefixed with a dollar sign to distinguish them from literal strings.

Key Concept

CloudWatch Logs Metric Filter pattern syntax differences between JSON and space-delimited log formats
Estimated Time:2m 0s
Rate this question