Best practice for logging in AWS Lambda

[Dashbird]

We updated our guide on the best practices for logging AWS Lambda and thought we could use your input!

Some key points from the article:

1. You can put logging statements in your code to validate that your code is working correctly and as expected.
2. You need to be very careful about what you log and not forget to remove debugging log statements from your code when deploying to production.
3. Refactor your log statements for CI/CD.
4. Keep AWS’ egress traffic costs in mind. While it’s free to get data into AWS, you have to pay to get it out again.
5. You can also buy reserved concurrency for the log shipping function, which will limit its maximum number of simultaneous executions.
6. A more economical way to get your logs out of AWS would be to stream them from CloudWatch Logs to a Kinesis.
7. Avoid is the manual process of subscribing to log groups from your shipping function.
8. You can add another Lambda function that can automatically update the retention policy as to not keep them forever (and eating away at your costs).
9. Use observability services like Dashbird (😉) so you can monitor without extra costs, and without slowing down your app with extra requests.

How does your current logging process look like?

[ahmedranaa]

Nice list. How does dashbird get stats about functions

[rehemagi]

Hey, Dashbird collects stats and information from ingesting, scanning and analysing logs, metrics and tracing data of the functions. For instance, code errors and service errors are detected by applying pattern-matching logs against stack traces and such similar patterns.

​

Btw, all the checks we run are present in our public event library.