> Oh and to Java devs everywhere, writing everything including the kitchen sink to Log4J output files in not the answer to reliable systems
Log4xyz is a good thing™. Certainly beats the hell out of something went wrong somewhere and we have no logs or some half arsed attempt to write to a text file using code lifted from stack overflow which isn't threadsafe, isn't buffered and works by loading the whole file into memory, appending a line then rewriting the file. Oh and by a file, I mean hundreds of files in various folders with no cleanup mechanism.
Other than sensible defaults, it's usually not a developer's role to configure log4xyz (internal or custom software where you have full understanding of the deployment environment may be the obvious exception). That is why you can change the verbosity of the messages in a config file. It is why you can choose your own appender. If you use a rolling file appender then you can specify things like maximum size, number of files to keep and so on. Then it is just a discussion with business about how much storage they want to pay for vs the point where files get deleted. That's their decision, not yours, not devs. Your job is to make sure you explain the consequences of whatever set of numbers get thrown at you.
The other side of the coin is ensuring that the I/O can handle the volume you throw at it. If you have your loglevel set to debug on a multi threaded stack, it may not be adequate to dump log files to some slow HDD.
Wait, you made me defend Java you sneaky bastard. Is that the new Rick roll?