4 ms·

Personally I'm not a fan of DEBUG level (unless you always keep it on). You can have a transient system issue that appeared for 30 minutes and then went away.

Personally I'm not a fan of DEBUG level (unless you always keep it on). You can have a transient system issue that appeared for 30 minutes and then went away. If DEBUG logs weren't turned on at the time, they won't help me.

Jowsey 5y ago
Why not have the program write logs to a temp file somewhere at trace/debug level, and only output the standard level to the console?
- Cicero22 5y ago
  Wouldn't that end up slowing down the whole system from writing to a file though?
  - Jowsey 5y ago
    Ah, suppose it depends on how much you're doing and/or how verbose your logs are. If you've got lines speeding past then yeah I maybe wouldn't write them all.
- grey-area 5y ago
  Writing verbose logs is very expensive.
  - worik 5y ago
    It depends which costs what. In a case where there are plenty of resources and the thing you are logging is very heavy then even verbose logging is trivial. If you are beset by failures it is much cheaper than making your developers guess.
raldi 5y ago
Of course you always keep it on — the point of the different levels is that you can filter them out at read time (e.g. to eyeball logs, or to alert when the rate of >= WARN is too high)
- sagichmal 5y ago
  Nope, this produces unmanageable log volume.
  - raldi 5y ago
    How does making these DEBUG logs into INFO logs make the volume manageable? Or, to flip that around, if you take a program that produces a manageable amount of INFO logs, and change some of those INFOs to DEBUGs, how does that suddenly become unmanageable?
    - sagichmal 5y ago
      My point is that DEBUG level logging is (hopefully!) not on by default, and that this is what it makes the production log volume manageable. My experience has been that 1 customer-facing byte tends to generate something like ~10 DEBUG-level telemetry bytes. This level of request amplification can't be feasibly sustained at nontrivial request volumes, your logging infrastructure would dwarf your production infrastructure.
- hacker_newz 5y ago
  Debug was not designed to always be left on. That's why you need to enable it in the first place.
- 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 ago
    That 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?

Jowsey 5y ago

Why not have the program write logs to a temp file somewhere at trace/debug level, and only output the standard level to the console?

Cicero22 5y ago
Wouldn't that end up slowing down the whole system from writing to a file though?
- Jowsey 5y ago
  Ah, suppose it depends on how much you're doing and/or how verbose your logs are. If you've got lines speeding past then yeah I maybe wouldn't write them all.
grey-area 5y ago
Writing verbose logs is very expensive.
- worik 5y ago
  It depends which costs what. In a case where there are plenty of resources and the thing you are logging is very heavy then even verbose logging is trivial. If you are beset by failures it is much cheaper than making your developers guess.

raldi 5y ago

Of course you always keep it on — the point of the different levels is that you can filter them out at read time (e.g. to eyeball logs, or to alert when the rate of >= WARN is too high)

sagichmal 5y ago
Nope, this produces unmanageable log volume.
- raldi 5y ago
  How does making these DEBUG logs into INFO logs make the volume manageable? Or, to flip that around, if you take a program that produces a manageable amount of INFO logs, and change some of those INFOs to DEBUGs, how does that suddenly become unmanageable?
  - sagichmal 5y ago
    My point is that DEBUG level logging is (hopefully!) not on by default, and that this is what it makes the production log volume manageable. My experience has been that 1 customer-facing byte tends to generate something like ~10 DEBUG-level telemetry bytes. This level of request amplification can't be feasibly sustained at nontrivial request volumes, your logging infrastructure would dwarf your production infrastructure.
hacker_newz 5y ago
Debug was not designed to always be left on. That's why you need to enable it in the first place.
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 ago
  That 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?