Question

Difficulty: Very hardMonitoring and Analyzing Logs with Amazon CloudWatch

A developer has deployed a microservice as an Amazon ECS task. The application writes JSON-formatted logs to an Amazon CloudWatch Logs group named `/aws/ecs/payment-service`. A sample log event is shown below:

{
"level": "error",
"responseCode": 504,
"latency": 1500,
"context": {
"api": "charge"
}
}

The developer needs to:
1. Create a CloudWatch metric filter to increment a custom metric named `PaymentTimeoutCount` whenever `responseCode` is 504504 and `latency` is greater than 10001000. Currently, the developer's metric filter pattern `[level = "error", responseCode = 504, latency > 1000]` is matching zero events.
2. Stream these matching log events in real time to an Amazon Kinesis Data Firehose delivery stream for archiving in Amazon S3. The developer has created a CloudWatch subscription filter pointing to Kinesis Data Firehose, but logs are not arriving in the S3 bucket, and CloudWatch Logs reports delivery errors.

Which two actions must the developer perform to resolve these issues? (Select two.)

  1. Update the metric filter pattern to use JSON object syntax: `{ .responseCode = 504 && .latency > 1000 }`.Answer
  2. B
    Change the metric filter pattern to use a SQL-like query structure: `SELECT * WHERE responseCode = 504 AND latency > 1000`.
  3. Update the IAM role associated with the subscription filter to trust the `logs.amazonaws.com` service principal to perform the `sts:AssumeRole` action.Answer
  4. D
    Modify the Kinesis Data Firehose delivery stream's IAM role to grant the `logs:PutSubscriptionFilter` permission to the CloudWatch Logs service.
  5. E
    Update the ECS task execution role to permit the `firehose:PutRecord` action on the destination delivery stream.

Answer

To resolve the issues, the developer must update the metric filter pattern to use the JSON object syntax `{ .responseCode = 504 && .latency > 1000 }` and update the subscription filter's IAM role trust policy to trust the `logs.amazonaws.com` service principal to perform the `sts:AssumeRole` action.
For JSON-structured logs in CloudWatch Logs, metric filter patterns must follow the JSON object syntax enclosed in curly braces with the `.` path prefix for fields. The correct pattern is `{ .responseCode = 504 && $.latency > 1000 }`. Additionally, to write logs to Kinesis Data Firehose via a subscription filter, CloudWatch Logs must assume an IAM role. The role's trust policy must allow `logs.amazonaws.com` to assume the role, and the policy must permit `firehose:PutRecord` operations on the target delivery stream.

Step-by-Step Solution

1
Diagnose the metric filter matching failure.
The metric filter is currently using space-delimited syntax (`[...]`), which expects space-separated values. Since the logs are JSON-formatted, CloudWatch Logs does not match the fields properly, resulting in zero matched events.
Structured JSON log groups require JSON path query notation to query inner fields.
2
Correct the metric filter pattern.
Convert the pattern to `{ .responseCode = 504 && .latency > 1000 }`.
This JSON syntax properly addresses the target fields and logical operators in CloudWatch Logs metric filters.
3
Diagnose the subscription filter delivery issue.
Determine that CloudWatch Logs requires permission to write to Kinesis Data Firehose via an IAM role. The delivery error indicates CloudWatch Logs cannot assume the configured role.
Subscription filters execute asynchronously at the CloudWatch service level, necessitating a trust relationship with the `logs.amazonaws.com` service principal.
4
Update the IAM role trust policy.
Add `logs.amazonaws.com` under the `Principal` block with the `sts:AssumeRole` action.
This authorizes CloudWatch Logs to temporarily assume the role and execute `firehose:PutRecord` batch calls to the delivery stream.

Key Concept

CloudWatch Logs Metric Filters JSON syntax and Subscription Filter IAM permissions
Estimated Time:3m 0s
Rate this question