On Sun, Feb 24, 2013 at 11:47 PM, Aditya Dogra (addogra) <[email protected]> wrote: > My point was since syslogs are tried up mostly with > the base/OS layer , hence it comes pretty much earlier > than the management plane comes up . And remote > logging comes in picture when management plane > comes up . Should syslog's be so reliable that we > buffer them (in case of udp protocol) or maintain > sessions (in case of tcp) (and maintain sessions > during failover/switchovers) so that once management > plane comes up , we send previous messages also.
Hi Aditya, I have had servers fail with processes blocked on a syslogger stuck trying to forward logs to a network syslog server that was no longer available. Or trying to output logs to a serial console at 9600 bps. The syslog blocks and then everything else blocks waiting for the syslog. The equipment's overall reliability comes _way_ before the reliable transmission of any particular log line. I want the logger to quickly dispose of the message and then accept the next one so that the processes generating those logs don't A colleague of mine has something he calls "reliable UDP". The idea goes like this: 1. Transmit the message with a sequence number AND add it to a local ring buffer. 2. If the receiver receives an out-of-sequence message, it requests the retransmission of the missing sequence numbers. 3. If the sender receives a retransmission request, it examines the ring buffer and retransmits if the message is still available. 4. The ring buffer overwrites its own tail as additional messages are sent. If retransmission isn't requested before the message is overwritten then the message is lost. That sort of thing might be handy for syslog messages, but it the logger is trying much harder than that, I think it risks getting in the way of the much more important processes generating the logs. Regards, Bill Herrin -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
