Soru

Zorluk: ZorMonitoring and Analyzing Logs with Amazon CloudWatch

A developer is implementing real-time processing of application logs generated by a payment service. The application writes JSON-formatted logs to an Amazon CloudWatch Logs log group. The developer sets up a CloudWatch Logs subscription filter to stream logs where the transaction status is "failed" and the error code is 504 to an AWS Lambda function for alerting.

During load testing, the developer observes that several alerts are missed, and the Lambda function's CloudWatch logs show multiple "Task timed out after 3.00 seconds" errors. The database connection initialization is currently located inside the Lambda handler function.

Which of the following represents the correct subscription filter pattern to extract these failed transactions, along with the appropriate troubleshooting step to resolve the Lambda timeout errors?

  1. Filter pattern: `{ .status = "failed" && .errorCode = 504 }`
    Resolution: Increase the Lambda function's execution timeout and move the database connection initialization outside the handler function to leverage execution context reuse.
    Cevap
  2. B
    Filter pattern: `[status = "failed", errorCode = 504]`
    Resolution: Increase the Lambda function's execution timeout and move the database connection initialization outside the handler function to leverage execution context reuse.
  3. C
    Filter pattern: `{ .status = "failed" && .errorCode = 504 }`
    Resolution: Increase the Lambda function's execution timeout and ensure that the database connection is initialized inside the handler function on every invocation to prevent concurrent connection leaks.
  4. D
    Filter pattern: `fields @message | filter status = "failed" and errorCode = 504`
    Resolution: Reconfigure the Lambda function to run in a private VPC subnet without a NAT Gateway or VPC endpoint to isolate traffic and reduce network hops.

Cevap

Filter pattern: `{ .status = "failed" && .errorCode = 504 }` and Resolution: Increase the Lambda function's execution timeout and move the database connection initialization outside the handler function to leverage execution context reuse.
The subscription filter pattern for JSON logs requires curly braces `{}` and prefixing JSON keys with `.` to properly parse and match values (e.g., `{ .status = "failed" && $.errorCode = 504 }`). To address the Lambda timeouts, moving the database connection initialization outside the handler function enables connection reuse across multiple invocations (execution context reuse). This avoids the heavy overhead of creating a new database connection on every function invocation, which is a major contributor to latency and timeouts.

Adım Adım Çözüm

1
Analyze the log format and identify the correct CloudWatch Subscription Filter pattern syntax.
Since the logs are JSON-formatted, the filter pattern must use curly braces `{}` and reference fields using the `.` prefix (e.g., `{ .status = "failed" && $.errorCode = 504 }`).
Bracket-based syntax `[...]` is used for space-delimited text logs, whereas CloudWatch Logs requires JSON property paths for structured logs.
2
Examine the Lambda execution logs showing timeouts and identify the source of latency.
Initializing database connections inside the handler function leads to high connection establishment latency on every invocation.
During load spikes, establishing a new connection on every invocation leads to container resource exhaustion and execution timeouts.
3
Determine the correct mitigation to resolve the Lambda function's timeouts.
Move the database connection initialization code outside the handler to utilize execution context reuse, and increase the timeout.
Declaring the database client globally allows AWS Lambda to reuse the active connection pool across sequential warm invocations, dramatically reducing invocation latency.

Anahtar Kavram

CloudWatch Logs JSON Metric and Subscription Filter syntax combined with Lambda execution context reuse optimization.
Tahmini Süre:2m 0s
Bu soruyu puanla