At 09:36 AM 8/13/2001 -0400, Marcus J. Ranum wrote: >>> 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 bunch of devices will also drop UDP packets if they don't have an association between the MAC and IP addresses at the time of queuing (no ARP entry). They'll continue dropping until they get ARP resolution. If you __really__know__ that will _never_ change, then you may want to hard-code in that ARP entry. (That's probably a bad idea in almost all cases.) Those drops will (probably) occur far less than the head-of-line blocking mentioned above but it's worth looking at if you're really trying to get all messages delivered. Check the aggregation points as well. >A couple years ago I did some testing of Massive Syslog Servers >and discovered that basically syslog is a piece of junk, design-wise. Bah! syslog is performing exactly as it was designed. - It is lightweight - Anyone can use it - Nothing really bogs it down - It has loose rules (very liberal in what it accepts) Even with all of that, it still passes a lot of event notification messages. Because of these, it is very widely accepted and almost ubiquitously deployed. >What kind of logging protocol >uses datagrams, anyhow? ummm.. The one that is used by almost everybody? ;-) >It's acceptable to lose your logs >if the loghost is down or the network is interrupted? Ridiculous! Agreed. >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. There are still some problems with just "tcp delivery". Most notably, you may still run into the situation of having a high priority message sit behind many informational messages in the output queue. Hopefully that and other weaknesses of syslog delivery are being addressed in the IETF Working Group. http://www.ietf.org/html.charters/syslog-charter.html :-) Later, Chris --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Tue Aug 14 2001 - 14:49:17 PDT