4 ms·
This traditionally has not been log level's use case. syslog() and setlogmask() being the obvious examples. Many (if not all) companies I have worked out filt
by codemac 5y ago
This traditionally has not been log level's use case.
syslog() and setlogmask() being the obvious examples.
Many (if not all) companies I have worked out filtered out everything DEBUG at compile time to improve performance in production as well.
The best option I've seen is putting everything in DEBUG or lower into a memory ring buffer per process that's dumped and collated with other logs at each ERROR/FATAL log.
- spockz 5y agoThat is actually quite nifty. That way you can carry debug logs and only materialise/send them in case of errors when you are likely interested in it without having to put those logs at error and see them all the time etc. Does anyone know of an implementation for this in any of the Java logging frameworks?
- masklinn 5y agoFwiw sentry does that out of the box, anything below warning (I think) is used as context for “actual events”.
- hurflmurfl 5y agoI've actually used this idea in production and it worked great. In my web app if nothing unexpected happens, only INFO/LOG level stuff is pushed to logs. If, however, I get an exception, I will instead print out all the possible traces. I.e. I always store all the logs in-memory and choose what should be printed out based on the success/failure of the request. Now, of course, this is just a web API running in AWS Lambda, and I don't have to care overly much about the machine just silently dying mid-request, so this might not work for some of you, but this works great for my use-case and I'm sure it will be enough for a lot of people out there.