Agree with the unique log. While filename/line number seems good at first, its more mental overhead to find the file and then go to the line number. I tend to

Agree with the unique log. While filename/line number seems good at first, its more mental overhead to find the file and then go to the line number. I tend to add a unique id based which is usually just the first 7 characters from any hash function. Something like date | md5sum | cut 1-7 which gives you something unique for each log message making it really easy to identify where it happened in any codebase using your search tool of choice. You have to embed the value into the code itself for the benefit, but its really useful in the short/long term. I was debugging a lot of lambda functions and this really ended up saving a lot of time as at runtime that was about the only information you could get. One other thing I found useful was to use JSON format for logs. I know there are many against this, but I found being able to add additional params without breaking existing tooling was a massive win, plus it formatted nicely in cloud-trail. Later on I realised most of our logs were processed by humans second and computers first, so having a machine readable format was really a benefit. Additional we were using Scalyr at the the time, so each new value in the JSON became an additional filter which was a very nice outcome.