In the world of building client/server applications logs are important.  They are helpful when trying to see what is going on in your application.  I have always held the belief  that your logs need to be detailed enough to allow you to determine the WHAT and WHERE without even looking at the code.

But lets be honest, in most cases when building client/server applications logs are an afterthought.  Often this is because you can pretty easily (in most cases) debug your application and step through the code.

When building a serverless applications with technologies like AWS Lambda functions (holds true for Azure Functions as well) your logging game really needs to step up.

The reason for this is that you cannot really debug your Lambda in the wild (you can to some degree locally with AWS SAM or the Serverless framework).  Because of this you need produce detailed enough logs to allow you to easily determine the WHAT and WHERE.

When I build my serverless functions I have a few guidelines I follow

1. Info Log calls to methods, output argument data (make sure no PII/PHI)
2. Error Log any failures (in try/catch or .catch for promises)
3. Debug Log any critical decision points
4. Info Log exit calls at top level methods

I also like to setup a simple and consistent format for my logs.  The example I follow for my Lambda logs is as seen below

timestamp: [logLevel] : [Class.Method] - message {data points} 

I have found that if I follow these general guidelines the pain of determine failure points in serverless environments is heavily reduced.

Till next time,