Solving Serverless Observability with Lambda Powertools
Set up distributed tracing with logging integration for your serverless apps on AWS.
Do you have 5 minutes?
I’ll help you set up distributed tracing with logging integration for your serverless apps on AWS.
I’m not even kidding. Getting up and running is that simple and it will be useful right away. Especially, if you’re not leveraging traces yet.
Background
If you’re not very familiar with observability let me give you a brief introduction.
Observability
Observability encompasses all techniques used to observe and introspect your running workloads. It allows you to derive the state of your system and from there you can take action like remediating issues or improving the parts that don’t perform well enough.
The three main techniques within observability are Monitoring, Logging and Tracing.
Monitoring
Monitoring means measuring metrics.
Metrics allow you to derive the state of your system and its components. If you apply thresholds to those metrics, you can configure alerts that notify you when there are certain error states in your system.
Logging
Logging means creating records of things that happened in a system.
Each log represents a message, time stamp and potentially other metadata (e.g. name of app / service or trace id). Logs are used to analyse what happened in a system at a given time.
Tracing
Tracing means tracking and correlating the requests in your system.
A trace will tell you where a request entered your system, which different parts it touched, how long each of those steps took as well as the response of each of the steps and the response of the request as a whole.
Now that everyone is up to speed, let’s take a look at how the Powertools for AWS Lambda can help us implement Observability for serverless applications.
Powertools
Powertools for AWS Lambda (Python) is a developer toolkit to implement Serverless best practices and increase developer velocity.
- https://docs.powertools.aws.dev
What are powertools?
As mentioned in the quote, Powertools is a toolkit that you can use to implement observability according to AWS best practices. There is more that you can do with them but for this post we will focus on observability.
What languages are supported?
Powertools are available in Python, Typescript, Java, and .NET. In this blog post, I will show the Python version.
What’s the difference between Powertools and the AWS SDK?
It builds upon the AWS SDK but makes some smart and sensible choices for configuration and orchestration in order to make the necessary AWS capabilities (like CloudWatch, X-Ray, etc.) usable in a very simple and straightforward way.
How to set up Powertools
There are two ways to set up Powertools. The first one is to use the respective package managers of the language you’re using.
The second one is to add them as a lambda layer. The Powertools team maintains lamba layers for the aws regions that you can reference in your lambda configuration.
Once you’ve set up Powertools, you can start using them in your code.
Let’s see some code
Let’s start by using Powertools to set up logging and tracing. This can be done as follows.
Let me explain what’s happening in the code. By using the tracing decorator and pointing it to API Gateway as the event source, we’re telling the tracer to check the HTTP trace header for a trace id to be used. If the tracer can’t find one in the specified location, it will generate a new trace id.
All subsequent HTTP calls to AWS and non-AWS services will have that trace id set in the HTTP trace header which allows the AWS Xray service to correlate all HTTP calls with the same trace id to one trace.
The log decorator appends the trace id to all the log statements in your function which in turn allows AWS Xray to display all logs associated with each trace and span.
Before creating custom metrics, please be sure to verify that the metric you’re trying to capture isn’t already captured by AWS. Generic metrics like error rates, invocations, and execution duration are already captured.
Also when you’ve created a custom metric you might want to add that metric to a dashboard or create an alert to make it meaningful.
Setting up dashboards and alerts is not in scope for code that you would run in a lambda function and therefore not in scope for the Powertools. You can configure them like you would any of your other resources e.g. via the console, CLI, or infrastructure as code.
What else can Powertools do?
Other than observability Powertools offer various other features for various use cases:
- Streaming
- Batch processing
- Feature flags
- Idempotency
- Types
If you take a look at their GitHub repo, you can also see that there are more features in the pipeline. But for this blog post let’s stick to observability and end here. Check out their documentation for more info:
As you can see getting started with observability using Powertools for Lambda is straightforward and can be achieved quickly.
Using annotations might be new or confusing to some developers, however, it’s a neat way to differentiate code that is part of our function logic from code that is used for configuration or instrumentation.
Go and give Powertools a try!
