A logging solution must be designed to make it as easy as possible to find the source of issues, while at the same time providing the depth needed to isolate and track hard to find bugs.
Logging to a single file makes it fairly easy to get an understanding of the entire system, but can easily be overwhelmed with too much detail. Modularized logging reduces the amount of noise, as you can investigate each module independently, but makes it harder to get an understanding of the complete system. These are two trades offs.
In addition the level of your logging has an effect as well. If you are only logging at the WARNING, ERROR or FATAL level a single log is much easier to understand, while if you are logging at DEBUG level, modularized logging may make more sense as the amount of detail a DEBUG level log can generate can be overwhelming.
To me though it sounds like you may have run into the limits of file based logging, perhaps you would be better of logging to a database. You don't mention what logging framework you are using (log4j, log4net), but many frameworks allow you to go beyond file based logging. The benefit of logging to a database is that you are able to use SQL queries to isolate the information in a much more granular way then by looking in individual files.
Additionally you may wish to look at logging visualization tools for your particular framework. Rather then simply opening up a file in notepad, some tools can allow you to easily filter and get a better understanding of any issues.
As for best practices I think its clear, for small amounts of logging start of with a single file. As that file becomes overwhelming move to a modularized system, and when that is no longer sufficient move to a database sink.