A developer is troubleshooting a serverless application deployed on AWS Lambda. The application logs events in a structured JSON format to Amazon CloudWatch Logs. The developer needs to configure CloudWatch metric filters to monitor two separate issues:
1. Lambda function execution timeouts, which generate service-level log lines containing the string: `Task timed out after`
2. Application API failures, where the log events are JSON objects containing a key `statusCode` with a value of 500 or greater.
Which two configurations should the developer implement to achieve this? (Select TWO.)
- Create a metric filter for the execution timeouts using the filter pattern "Task timed out after".Answer
- BCreate a metric filter for the execution timeouts using the JSON filter pattern { $.errorMessage = "Task timed out after*" }.
- Create a metric filter for the API failures using the JSON filter pattern { $.statusCode >= 500 }.Answer
- DCreate a metric filter for the API failures using the space-delimited filter pattern [..., status_code >= 500, ...].
- ECatch the timeout exception in the application code and publish a custom metric using the PutMetricData API call before the function terminates.
Answer
The correct configurations are to create a metric filter for the execution timeouts using the filter pattern "Task timed out after" and to create a metric filter for the API failures using the JSON filter pattern { $.statusCode >= 500 }.
The correct options involve setting up a literal string filter pattern to match plain-text Lambda runtime log entries and a JSON path filter pattern to match structured JSON application log entries. Since Lambda service timeouts are logged as raw text lines, a literal string match is required. Since the application writes logs in JSON, the JSON path filter syntax allows matching numeric conditions on specific properties.
Step-by-Step Solution
Key Concept
Distinguishing between plain-text and structured JSON log streams when configuring Amazon CloudWatch metric filters.
Estimated Time:2m 0s