I have recently come across possibly what is the most silly implementation of application logging, the developers actually separated logs into validation log files + business logic log files.
For a normal flow for example, the user would purchase some plans, and this goes through some kind of validation, then it gets processed (saved into database for example).
Therefore with the separated logs, it goes..
Go into business.log to look for sequence of events, following, jump into validation.log to look for validation logs pertaining to the user, then jump back to business.log to look for the continuation.
To make matters worse, there is no definite way to map between the logs other than to guess the timestamp, and perhaps the input values (name) that was passed in between.
Therefore when debugging production bugs, it becomes quite messy to toggle between these two files.
The issue is, there are many users and transactions going on at the same time. When questioning the developers over the intend of doing so, the reply was that so the logs were properly segmented. I find this reason quite ridiculous, has anyone come across some references for effective logging? Or does anyone find this way of logging quite normal in enterprises?
IMHO there are valid reasons for separating logs. Perhaps one contains sensitive information. Maybe one is written much more often and is rarely used. Maybe one can be toggled on/off for simplicity or security purposes.
Regardless of the reason, logging a transaction ID or user ID with each message would definitely help.