You need to use structured logging with AWS Lambda

This is a lesson that I wished I learnt when I first started , it would have made my life simpler right from the start. using AWS Lambda in anger But, we did get there before long, and it allowed us to in our log messages (which are then which would also include other useful information such as: track and include correlation IDs pushed to an ELK stack) age of the function execution whether invocation was a cold start log level etc. Looking back, I fell into the common trap of forgetting the practices that had served us well in a different paradigm of developing software, at least until I figured out how to adopt these old practices for the new serverless paradigm. In this case, we know and , and also . But like many others, we started with because it was simple and it worked (to a limited degree). structured logs are important why we need them how to do it well console.log But, this approach has a really low ceiling: you can’t add contextual information with the log message, at least not in a way that’s (you may change the message you log, but the contextual information should always be there, e.g. user-id, request-id, etc.) and for an process consistent easy to extract automated as a result, it’s also hard to filter the log messages by specific attributes — e.g. “show me all the log messages related to this request ID” it’s hard to control what level to log at (i.e. debug, info, warning, …) based on configuration — e.g. log at debug level for non-production environments, but log at info/warning level for production Which is why, if you’re just starting your Serverless journey, then learn from my mistakes and write your logs as structured JSON . Also, you should use whatever log client that you were using before — log4j, nlog, loggly, log4net, whatever it is — and configure the client to format log messages as JSON and . from the start attach as much contextual information as you can As I mentioned in the post on how to , it’s also a good idea to enable debug logging on the entire call chain for a small % of requests in production. It helps you catch pervasive bugs in your logic (that are easy to catch, but ONLY if you have the right info from the logs) that would otherwise require you to redeploy all the functions on the entire call chain to turn on debug logging… capture and forward collection IDs So there, a simple and effective thing to do to massively upgrade your serverless architecture. Check out my mini-series on logging for AWS Lambda which covers , , and some such as why and how to send custom metrics asynchronously. log aggregation tracking correlation IDs tips and tricks