On Mon, Jun 17, 2013 at 7:48 PM, James Y Knight firstname.lastname@example.org wrote:
I'm surprised that a thread with 32 messages about logging doesn't seem to have once mentioned windows events, osx structured syslog, or systemd journal as important design points.
Maybe people are thinking about such things in the background but it looks a lot like this is being designed in a vacuum when there's plenty of air around.
And, no sane sysadmin should ever want a twisted-specific log file format or to write custom python log filters. That's crazy. Gimme a verbosity knob and the ability to emit structured log events to existing systems, with a fallback plain text file format. Great.
The prime goal, it seems to me, should be exposing features useful for facilities present in existing log systems.
And having a logging system which doesn't even support a basic log level is just silly. Hopefully the new system can at least have that.
The proposed logging module does include levels.
Also, I have definitely been thinking of real logging systems during this conversation -- in fact, I've been planning on experimenting with some of the popular *structured* logging systems these days and I plan on implementing and contributing log observers for them. I do think the "json file" log format is pretty pointless, though it might be a nifty exercise (unless there is some structured log aggregation system that reads json data from disk files?)
I think your accusations of design in a vacuum are too hasty and inflammatory. The whole reason I'm so interested in this discussion is to take advantage of *real* logging systems that can aggregate, filter, and search lots of log streams, based on structured event streams.