Metrics and Monitoring - Serverless Architectures with AWS Lambda

Metrics and Monitoring

Lambda, just like other AWS services, provides a number of CloudWatch metrics out of the box. These include metrics related to the number of invocations a function has received, the execution duration of a function, and others. It’s best practice to create alarm thresholds (high and low) for each of your Lambda functions on all of the provided metrics through CloudWatch. A major change in how your function is invoked or how long it takes to execute could be your first indication of a problem in your architecture.

For any additional metrics that your application needs to gather (for example, application error codes, dependency-specific latency, etc.) you have two options to get those custom metrics stored in CloudWatch or your monitoring solution of choice:

  • Create a custom metric and integrate directly with the API required from your Lambda function as it’s executing. This has the fewest dependencies and will record the metric as fast as possible. However, it does require you to spend Lambda execution time and resources integrating with another service dependency. If you follow this path, ensure that your code for capturing metrics is modularized and reusable across your Lambda functions instead of tightly coupled to a specific Lambda function.

  • Capture the metric within your Lambda function code and log it using the provided logging mechanisms in Lambda. Then, create a CloudWatch Logs metric filter on the function streams to extract the metric and make it available in CloudWatch. Alternatively, create another Lambda function as a subscription filter on the CloudWatch Logs stream to push filtered log statements to another metrics solution. This path introduces more complexity and is not as near real-time as the previous solution for capturing metrics. However, it allows your function to more quickly create metrics through logging rather than making an external service request.