9 ms·
This assumes though that you only have a single log. Often times I find breaking up logs based on concerns/packages/names or even level to be useful, which you
by enoren 15y ago
This assumes though that you only have a single log. Often times I find breaking up logs based on concerns/packages/names or even level to be useful, which you could not do without reinventing the wheel of output filtering.
This also assumes that anyone is actually really reinventing the appenders as most frameworks already have a library of common appenders.
- imbriaco 15y agoI would argue that you want to do the filtering at the aggregation layer and not at the application level. So while you may want to set different flags or parameters that will be logged (ie: severity, component, etc) those parameters should be injected into the log stream rather than to alternative streams. Let the aggregation point use those clues to filter the logs appropriately.
- prodigal_erik 15y agoIf you have multiple streams, you can give lower latency or better durability to critical or low-volume messages.
- imbriaco 15y agoYou can do the same thing with the local or aggregation tier syslog daemon if desired.
- encoderer 15y agoThis should definitely take place at the aggregation level. There are great tools for this already. This is definitely an implementation detail we developers should delegate to the systems guys. Not to mention, it's just less development work to send out messages with, say, different syslog levels and be done with it.