This article http://engineering.linkedin.com/distributed-systems/log-what... says that by the time you're done satisfying every requirement of a distributed logging system with multiple writers and readers and various reliability requirements, you've essentially rebuilt Apache Kafka.
Introducing LoggerFS (2013)
41–47 of 47 posts
Re: Introducing LoggerFS (2013)
#42Think about the different use cases for logs. I've spent an insane number of hours thinking about it, unfortunately. Live data is useful for graphing or alerting on things. Prehistoric data which is made to be searchable is useful for troubleshooting, or doing forensics work. These use cases require widely varying types of technology to make them scalable, reliable and useful, where 'useful' is defined as saving me time and money.
I LOVE the idea of turning the idea of logging on it's head!
Re: Introducing LoggerFS (2013)
#43Earlier quoted context omitted.
Depending on your disk not to magically fill up is very different from relying on this FUSE daemon to be up and operational.
To be clear, I do think it's a valid concern -- my point was that "what if log location isn't writable/disk is full" is pretty basic concern that any daemon should account for (what happens if somehow mount -oro /var/log?). And writes failing shouldn't be that much of an alien error condition. In sum, if fuse/loggerfs together can guarantee that every possible state will result in sane (error) state on writes -- this…
>what if log location isn't writable/disk is full
These are two different cases though. If a disk is full the write fails and software usually handles that well. Depending on the state of FUSE, it will just block indefinitely.
Re: Introducing LoggerFS (2013)
#44Alternatively one could just log to a queue/network directly...
Assuming one's software allows for that. Which a lot of software either doesn't do, doesn't do with sufficient configuration, does badly, or does but doesn't support your particular logging method.
As an example, nginx only recently gained the ability to log to syslog; Apache has a logging module but it's not exceptionally customizable if you wanted to log to, say, ActiveMQ, or to a custom service (unless you write a separate binary to accept logs on stdin).
Re: Introducing LoggerFS (2013)
#45Alternatively one could just log to a queue/network directly...
[deleted]
Re: Introducing LoggerFS (2013)
#46so it's basically systemd-journal, except more fragile and significantly harder to use (requiring open, fwrite, etc) than the simple printf.
This isn't a way of adding logging to your own software; it's a way of taking any software's logging (yes, even printf) and sending it to a remote server without having to modify the software directly.
So, basically, it's like systemd-journal except not actually like systemd-journal, significantly easier to use, and can use printf directly instead.
Re: Introducing LoggerFS (2013)
#47Alternatively one could just log to a queue/network directly...
Assuming one's software allows for that. Which a lot of software either doesn't do, doesn't do with sufficient configuration, does badly, or does but doesn't support your particular logging method. As an example, nginx only recently gained the ability to log to syslog; Apache has a logging module but it's not exceptionally customizable if you wanted to log to, say, ActiveMQ, or to a custom service (unless you write a…
Yup. Given that those logging mechanisms also expose all the problems with file based logging, you have a much more significant effect with a lot less complexity by working on fixing those deficiencies than this route.