As a sysadmin I spend much of my day trawling though log files looking for problems. Unfortunately many developers don’t appear to know how to use log levels effectively which can make a sysadmin’s life a small hell when it comes to debugging.
As a general rule I advise the following:
Be quiet about successful operations and verbose about unsuccessful ones.
Yes I like to see what an application is doing but I don’t need to know every function call that it’s making, yes this is useful when developing an application but can make isolating a problem in production a real pain.
Generally I use 4 different log levels:
- DEBUG
- INFO
- WARN
- ERROR
The definitions for these go something as follows:
| DEBUG | Things that should happen but you don't want to see in production. This includes function tracing, SQL statements, variable values etc... |
| INFO | Things that should happen that give you just enough idea about what's going on. This should be limited to 1 or 2 lines per transaction, |
| WARN | Things that shouldn't happen but the end user should see no difference. For example $foo failed so falling back to $bar instead |
| ERROR | Houston we have a problem! This is a serious error that has caused a problem for the end user. If you want to dump variables to the logs then now is a good time to do it. |
Some applications do logging in a completely different way, they have more log levels. Generally in production you want to know just enough to know what the application is doing + all the warnings and errors.
If something goes wrong then you need enough information to be able to replicate it. If all is well then, as sysadmins, we don’t care.
sheepy.org
