Although we are in the dark, not all information will be useful.

Last week I came across some log issues and it helped me to understand the importance to set good logs.

Improve traceability has been an important goal on my current days at work. There were many flows missing logs and we were blind to understand some behaviors on our applications. It important to know when you create the system you already know how it works, where are the main features, bugs and how to fix them. However, in big companies many people will have worked on the same project and the complexity might be higher than you expected.

Sometimes (read many times) the code creator wasn't be there anymore. It impact directly when you faced an issue in production. The problem understanding is the first step to solve its and logs are a greatest tool when you need to follow the and you should explore them, don't forget to be clear on log text, set the correct level, in other hand take care of your logs.

Although logs are a great weapon against bugs, set a fake log is something that might cost you some hours. These days I was testing with QA a flow and I faced a message in pod logs with a text like that: 'Error to processing the message, sending message to DLQ'. So, I looked at Rabbit and I didn't find the DLQ, I thought that it might be an environment issue, but this DQL didn't exist.

Now you might be thinking that I created this DLQ, but before that I have decided to look at code and understand what was happening. Well, big surprise we had an else with this log, a throw and just it. There was any DLQ configuration, any producer, just this log. We were losing our messages and believing that DLQ was supporting us.

In a nutshell: it is just as important to keep good logs as it is to avoid incorrect logs. Other day I'll write about you use good interfaces to debug the logs, you should think about it.