The problem with putting all your syslogs on a remote system is that it can eat quite a bit of bandwidth. I honestly haven't seen any systems actually configured for remote syslog in my time in the industry. In contrast, sending a single hash to a central single-purpose server every hour doesn't raise any bandwidth issues.
This whole project was motivated by the administrators' inability to trust the kernel.org syslogs after the breakin. It's always a good sign when a project solves a real problem that some smart people encountered.
> Haven't we seen this story enough times to see the pattern? The tool will
> be minimal, just for quick use by UNIX diehards to shut them up, while all
> 'serious' use will be expected to be through the API/library.
I agree that there is a lot of DBUS-itis and shared-library-itis out there, especially from the GNOME devs. (The GNOME devs have done a lot of good work as well, but I have to call it like I see it.) But I don't think this falls into that category.
As long as 'logger' continues to work, and there is some way to cat the syslog to a file, it will be as easy to use syslog on the command line as it ever was. I mean, syslogd has been a daemon and syslog(2) has been an API since the seventies; you can hardly complain that Lennart is adding yet more daemons and APIs to the system. If you add a FUSE interface that exposes a writable file named /var/log/syslog that has all the log entries, it's as scriptable as it ever was.
Posted Nov 23, 2011 21:14 UTC (Wed) by jeremiah (subscriber, #1221)
[Link]
> I honestly haven't seen any systems actually configured for remote syslog in my time in the industry.
um... We do this on all of our servers. I love being able to tail one single file and get everything going on. Now, we don't do this outside of our local network. But a gig network seems to be able to handle the bandwidth just fine. I'd love a nice tool that would allow us to securely archive log files. And to me it seems that Journal is trying to do both, Archive, and transport. I don't think these two processes should effect each other. We also find that Splunk works pretty for the archiving and searching. As well as getting a hold of log files that don't output to syslog ie. request.log.
The Journal - a proposed syslog replacement
Posted Nov 23, 2011 23:36 UTC (Wed) by dlang (✭ supporter ✭, #313)
[Link]
splunk is great for searching logs (I have a large cluster of machines for doing exactly this), but in terms of gathering and transporting logs, it's far from the best.
take a look at syslog-ng and rsyslog and the options they have to gather data from log files written by other apps.
The Journal - a proposed syslog replacement
Posted Nov 25, 2011 15:02 UTC (Fri) by jeremiah (subscriber, #1221)
[Link]
those are on my list. It's mostly an issue of upgrading servers at this point to version that support them.