Forwardede from [email protected]; please include [email protected] in responses. dbh
-----Original Message----- From: Pekka Savola [mailto:[EMAIL PROTECTED] Sent: Thursday, February 01, 2007 3:30 PM To: David W. Hankins Cc: [email protected] Subject: Re: draft-ietf-syslog-protocol: "Reliable delivery considered harmful." On Thu, 1 Feb 2007, David W. Hankins wrote: > If you insist on keeping all 50,000 lines of output, there is no > solution to that problem. If you block, that's a big problem as > it ultimatley totally disables the service attempting to log > information. If you write to a growing backing store, well you'll > run out of space eventually (even disk is not infinite). > Compression can only get you so far. As an operator, I would find a reliable syslog useful. However, I do not see this as a problem. 95% of the problem (from our perspective) is solved if no messages are lost _on the wire_ between the sender and the recipient of syslog messages. It's acceptable for the syslog sender to replace overflowing lines of syslog (if some messages need to be dropped due to lack of resources) with a message about rate-limiting, messages being dropped, or whatever -- just the same way as messages might get dropped when syslogging to a local media. As long as a) there is a message about syslogs getting dropped, and b) this is infrequent in a well operated system (i.e. the system log levels are set so that typically the amount of logging is OK), this should be no problem. > May be adequate to the point of suggesting that reliable delivery > might not be desirable. But on the whole the draft doesn't read > that way, and it doesn't state the truth: reliable delivery of > syslog output is always harmful. The point of bothering with > reliable syslog delivery, if there is one, is for those very > rare cases where losing the data is more harmful than harming > system services. IMHO, "reliable delivery of syslog output is always harmful" is very much an over-statement. It seems your concern is limited to the corner case where the syslog sender would already have a full syslog buffer, and the sender would get even more syslog to send. While this is a serious problem when it occurs, it should be easily solvable: just drop the messages (with a suitable note in syslog or in the local log) that exceed the buffer size or prune messages from the buffer using some more advanced strategy. As a particular example, we'd be very interested in getting reliable syslog from our routers to cover for messages lost due to network outages (fixed usually quickly with rerouting). We are talking of 1-200 messages being lost within a 10 minute period -- a very reasonable packet rate in average. A 1,000 or 10,000 line buffer in the router should be very reasonable in recent control processors. I'd rather the control processor reserve 0.1% of its memory (or CPU) to store and transmit these messages rather than try to use the last 0.1% when it's already chugging at 99.9%; the last 0.1% would not make a meaningful difference anyway for whatever it's using almost all of its resources. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
