Best Practices for AWS Lambda & Logging

Sharing is Caring

Virtualization, cloud computing, and serverless computing has really changed software development and technology departments everywhere. With AWS Lambda the developers only need to worry about their code and don’t need to worry about scaling up or down the system as needed. And, companies only have to pay for what they need instead of keeping capacity always available.

Having your application / system produce the right amount and quality of logs is just as important as having the system process the needed data because it helps make debugging easier and allows us to better optimize data. Incorrect logging opens up the system to potential data safety and security issues.

Logging in lambda is pretty easy regardless of the language being used. Anything printed to the standard output will end up being logged and accessible in CloudWatch. For example, with JavaScript / Node.js anything printed to the console (ie console.log, console.error) will end up being logged and accessible in CloudWatch.

Connecting To CloudWatch from AWS Lambda

CloudWatch is a logging and monitoring service from AWS. I’ve written a little bit about CloudWatch in my post Introduction to AWS CloudWatch. CloudWatch integrates seamlessly into Lambda functions; in fact, the development team basically has to do nothing to get it to work.

If a lambda should have permissions to create and update logs it will need an IAM policy that allows the following permissions:

  • logs:CreateLogGroup
  • logs:CreateLogStream
  • logs:PutLogEvents

The very first time a new function is run it will create a log group for that function. The group naming convention is /aws/lambda/{your-function-name}. For example a function called “add-user” would have a log group named “/aws/lambda/add-user”.

When a lambda first loads in a container it will create a new log stream for use by that container. The log steam will have a name that follows this pattern: date/{your-version-number}/uuid.

The version will be different if you do a deployment and an old container is still being used.

Best Practices for Logging in AWS Lambda

When setting up CloudWatch, it’s a good practice to automatically monitor and report a number of metrics. For example, the error rate for each function, the minimum and maximum duration for each function, and the memory usage.

Use a Logging Library or Abstraction

Before doing any logging, I recommend building or using a library or abstraction that will allow you to potentially turn off certain logging levels. You may have log lines that you want to run in the development environment or in staging, but don’t want to run in the production environment.

One easy spot to turn this off will make your life a lot easier in the future especially if it can be done in an env file or in a secrets file.

Include identifying information in log events

When logging errors or specific events occurring, it’s really important to log identifying details about the requests and ideally the data that caused the problem.

Having this information allows the team to potentially understand the problem and be able to resolve it. Debugging is so much easier when you have a lot of context into whatever causes the problem.

If your function needs to directly call another function, you should make sure that you pass an identifier to the new function so that you can track between the functions.

With many parallel containers running the same functions, but with different contexts 🙂 , it becomes really important that you consistently log and differentiate the containers.

The search log groups button is usually your best friend when finding details about a certain event.

Log Errors / Exceptions

Logging Errors and Exceptions is really important, it almost never makes sense to simply swallow or not log details. When logging exceptions it’s really important to log the entire stack trace and at least some of the data so you can potentially reproduce the problem when you try to solve it later.

Be consistent When Logging

By using a consistent and standardized format for logging, it becomes easier to filter and query the logs. Consistency makes it much easier for computers and people to read through the logs when searching for a particular problem.

For the most part, it’s usually a really good idea to use one library that will strip out anything that shouldn’t or can’t be logged. For example, you shouldn’t log personally identifying information (PII) because of GDPR and PIPEDA, and shouldn’t log passwords.

Visualization and CloudWatch Alarms is almost impossible with inconsistent logs. Cloudwatch Logs Insights can be a great way to search and analyze logs with the sql like query language.

Take the Time to Really Understand CloudWatch & Logging

CloudWatch can be really powerful and useful if you’re willing to take the time to understand it and how the various other parts of the service can work together.

For example, AWS X-Ray is a niffy little service that can be used to help debug issues across microservices especially when trying to do root cause analysis of performance or errors.

Setup CloudWatch Alarms

CloudWatch has this functionality that allows you to do additional processing like sending a text message or email when certain events happen or when a certain batch of events happens in a time period. For example, it can be really helpful to know when you are getting a lot of 500 errors in a certain period of time.

Alarms can be done at the function level, for example, nobody wants a broken sign up so you might want an alarm when a single 500 error happens regardless of a forgot password endpoint or something else.

Wrapping it up

CloudWatch doesn’t really get the credit that it deserves, it’s really a pretty good service once you understand how to use it. Understanding how it works and how the search works can really make you a better and more efficient debugger.

Sharing is Caring

Brian is a programmer and technology leader living in Niagara Falls with more than ten years of development experience. He is passionate about automation, business process re-engineering, and building a better tomorrow.

Brian is a proud father of four: two boys, and two girls and has been happily married to Crystal for more than ten years. From time to time, Brian may post about his faith, his family, and definitely about technology.

Leave Comment

Your email address will not be published. Required fields are marked *