When I write code, a certain amount of it is just for the purpose of logging, tracing, or otherwise "testing" what the program is doing. This not unit testing; this is not when it is running in "debug" mode or something similar; it is not things like assert statements that get stripped out by some compiling step. But actual production code and runtime execution for the purpose of knowing what the system is doing and writing it out somewhere. Naturally, there have to be various settings in various places (config files, admin interfaces, etc), that allow for more or less of such things. But even if all settings are at their lowest level, I still like to have my system keep track of its own state and report it in some minimalist manner that I or operations people can use to troubleshoot even without turning on/up the other settings.
So here is my question: how much of your code or system run-time do you typically devote to such permanent-troubleshooting purposes? I say both code and run-time as they are two measures: how many lines of code relative to all lines of code, because the more the code the more the maintenance; and how much run-time performance because these things do consume CPU time, however small. And there is not always a direct connection between lines of code and run-time consumption.
Personally, I'm happy to devote up to 10% of my code to such things and up to 5% of the run-time. Have you ever read any industry authorities that have an opinion on this? Who? What is your opinion?