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".Cevap
- 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 }.Cevap
- 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.
Cevap
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.
Adım Adım Çözüm
Anahtar Kavram
Distinguishing between plain-text and structured JSON log streams when configuring Amazon CloudWatch metric filters.
Tahmini Süre:2m 0s