| |||||||||||||
A few thoughts.A few thoughts.Posted Nov 19, 2011 7:47 UTC (Sat) by alankila (subscriber, #47141)In reply to: A few thoughts. by ebiederm Parent article: The Journal - a proposed syslog replacement
It seems to me that journald aims higher than this RFC, especially because it understands two important properties of logging:
1) messages in log tend to be highly repetitive, so they are amenable to significant reuse of the internally used field values. So you don't want to repeat the same data umpteenth time, especially if the value is long, you rather write the key-value -pair once into common area, and from that point onwards reference only the ID of that key-value pair.
2) log messages are useful information to end user and administrators alike, but it tends to require pair of eyeballs and experience to find the right log file and to know what entries to look for. This is an unnecessary chore. As a hypothetical example, you launched "foobard" and it says "failed", and you are wondering if it wrote anything in any log. I'm hoping you could say "logcat -d /usr/sbin/foobard" to find the latest messages from journal generated by that program.
I suppose 1) means that logs can be substantially more comprehensive than the RFC without requiring that much more disk space, and 2) is something that ought to make linux far more pleasant to use in general.
What follows next is my impression: I think Linux has a fairly soft underbelly, and it appears to have become the target of increasingly embarrassing attacks, and these attacks will continue if we don't get our act together. Journald is trying to harden the logging facility against things such as attacker process flooding the log and thus causing the system to run out of space on the /var filesystem, a problem that seems to be ignored today. My feeling is that a lot of our existing design choices at bottom of application stack are basically inadequate to meet the actual needs of well-designed robust systems, and we seem to believe that inadequacy at bottom level of stack can be repaired by pouring a layer of code on top of that insufficient foundation. However, the insufficient foundation remains insufficient due to the law of leaky abstractions.
The consequence from the above argument is that it is perfectly OK to design a monolithic piece of software as long as your monolithic design is _good_. If it is not good enough, then no amount of crap poured on top of it will fix it either. I'd be fully on board of this journald if it means that I don't have to go "log fishing" through zgrep foo /var/log/* anymore, but can rather say something like "just give me all entries from last 30 seconds" or "it was written by the process image /usr/sbin/x".
(Log in to post comments)
A few thoughts. Posted Nov 19, 2011 15:48 UTC (Sat) by NAR (subscriber, #1313) [Link] Journald is trying to harden the logging facility against things such as attacker process flooding the log and thus causing the system to run out of space on the /var filesystem, a problem that seems to be ignored today.And exactly how would journald solve this? All the attacker has to do is to flood the logs with unique messages...
A few thoughts. Posted Nov 19, 2011 18:40 UTC (Sat) by alankila (subscriber, #47141) [Link]
It is said to ratelimit the logging speed if it starts to run out of disk space (but ratelimit based on what criteria?), and to rotate and purge the logs when the alternative is running out of space (but what entries will be purged?). These changes ought to solve the problem to a degree, and I am hoping sufficient intelligence is applied to make the best possible effort in these adversarial conditions.
A few thoughts. Posted Nov 21, 2011 15:23 UTC (Mon) by sorpigal (subscriber, #36106) [Link]
Your 2) is possible with syslog, but it's spelled "tail /var/log/foobard" - just standardizing on the naming of these files would be enough to satisfy this.
I'm actually a fan of improving logging, because it could be so much better, but this proposal has so many things that make me go "Huh?" that I'd rather change nothing than adopt it as is.
> The consequence from the above argument is that it is perfectly OK to design a monolithic piece of software as long as your monolithic design is _good_.
I would say, rather, that the consequence of the above argument is that some of the simple systems we have long used are becoming no longer "just enough" for some uses and that some of them should be replaced with a new level of "just enough" that satisifies today's requirements... and this needs to happen before they are each replaced by ill conceived, grandiose, kitchen-sink solutions which throw the baby out with the bathwater.
A few thoughts. Posted Nov 21, 2011 15:43 UTC (Mon) by mpr22 (subscriber, #60784) [Link] I would say, rather, that the consequence of the above argument is that some of the simple systems we have long used are becoming no longer "just enough" for some uses and that some of them should be replaced with a new level of "just enough" that satisifies today's requirements... and this needs to happen before they are each replaced by ill conceived, grandiose, kitchen-sink solutions which throw the baby out with the bathwater. It really would be nice if more of the visible pro-Unix people in discussions of Lennartware would say "there may be a problem but Lennart's solution is wrong" instead of "Lennart is wrong to think there is a problem". It would be even nicer if they'd put their code where their prose is, of course :)
|
|||||||||||||