> You absolutely DO want all of those log levels. I agree, this is a very clear fact that's readily understood by anyone with any experience developing and ope

> You absolutely DO want all of those log levels. I agree, this is a very clear fact that's readily understood by anyone with any experience developing and operating a service. It's weird that we see claims arguing one of the core tools of troubleshooting isn't needed, without providing any sound argument. Among the long list of arguments that can be presented, I'm only going to point out one which might be obscure: cost. Cloud providers charge a premium for data generated through log ingestion, and the more logs you generate the more you pay. Most of the time needlessly so. One strategy to work around that is only logging error/critical in production. That avoids the invoice caused by all other log levels, which dominate the whole event dump. However, when the shit hits the fan you will want as much info as you can to help you quickly troubleshoot problems. With the standard log level hierarchy that's as easy as tweaking an environment variable in prod to output additional log levels. If you want to, you can drive the level down to dumping tracing info. Modern production-ready logging frameworks even support filtering log events based on the namespace/package/class level, for this very reason. You pepper your code paths with the relevant log messages corresponding to adequate log levels, and once you have your infrastructure sorted out you have all the tools you need to adapt your logs to the operational needs you have. You absolutely cannot do that with simplistic info/error logs.