Q: What happens to rsyslogs when logserver goes offline?

[wyoder]

Hello:

We want to take our single and lonely logserver down for maintenance. For now, there is no companion server in a cluster. Once this logserver goes down, there will be no place for the remote agents to send their logs. The question is, what will happen to the logs while our logserver is offline?

• - Will the events occurring during this interval be lost? Hope not.
  - Will they be queued up and resume sending when the logserver goes back online? Hope so.
  - Since we're using TCP connections between the agents and the logserver, will the agents suffer congestion/constipation--holding their events in some huge buffer while waiting for the logserver to return to service?

Thanks in advance for your response.
--Bill

[tmcdonald]

This will all depend on the sending servers, and whether their logging daemons can spool. What remote syslog agents are you using?

[wyoder]

Hello, tmcdonald:

Thanks for your reponse.

Both types of our server senders (RHEL 6 and Ubuntu 12.04) are running Version 3.21.1 of the rsyslogd agent. So far, the Nagios logserver environment has been great--both reliable and useful. Is this enough information?

--Bill

[hsmith]

I've normally witnessed the behavior where the logs are spooled for days assuming you're using TCP. UDP logs are generally just gone.

[eloyd]

rsyslog will queue messages up to a point. That point is memory dependent. When it gets full, it blocks. This is the same as writing to local log file and running out of disk space. You can tell rsyslog to drop new messages if the queue fills up and/or to start queuing to local disk. Both of which are explained in rsyslog search engine results and beyond the scope of Nagios Log Server support.

[rkennedy]

Thanks @eloyd!

@wyoder - let us know if you have any further questions.

[wyoder]

Thanks, Folks, for your help.

We took our logserver offline, upgraded it from RHEL6.7 to RHEL6.8, brought it back online, and everything seems fine.

Accordingly, please close this post at your convenience.

Best regards,
Bill Yoder