> > I think it sounds a bit weird that the syslog server is losing data just > > because of one host sending to much information. Most likely, what's happening is that the output queues on the sending machine are overrunning and it's dropping the UDP packets before they even get sent out onto the network. A couple years ago I did some testing of Massive Syslog Servers and discovered that basically syslog is a piece of junk, design-wise. If you send a load of syslog messages and have a sniffer standing by you'll see that a significant number of them are dropped as I described above - especially at peak loads - which is exactly when you want them most. :( >I am running standard syslogd. The syslog server is running Red Hat 7.0 >and is dedicated to the syslog function. I bet you that the problem's not your server but rather your client. If it's an older BSD machine you can bump up the interface output queue lengths (if maqueuelen) and it may help. But that's only a temporary solution; the reality is that syslog doesn't really cut it. What kind of logging protocol uses datagrams, anyhow? It's acceptable to lose your logs if the loghost is down or the network is interrupted? Ridiculous! I can't speak for syslog-NG; presumably (hopefully!) it dodges many of the flaws of syslog by using TCP and doing the right thing. I've found it's easier to just install a syslog proxy on the client and have done with it. You can use something like my old flog(8) utility (which correctly handles log wrapping, file renaming) and just make it copy stuff over a socket to a server with reliable reconnection. That's pretty much what the client for the NFR SLR does. mjr. --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Mon Aug 13 2001 - 15:02:37 PDT