On Thu, 25 Apr 2013, Alan Edmonds wrote:
Greetings. I'm looking for some advice/help. I would like to
send all syslog logs from clients to an syslog server via RELP.
I currently have a syslog-server receiving UDP syslogs.
I would like to move to using RELP for obvious reasons (reliability).
In the interim, I will send logs to both servers; UDP logs to the
existing
server and RELP logs to a new syslog server. I will eventually remove
the
UDP syslog server once this is rolled out.
I implemented this strategy with rsyslog 5.8 (rsyslog5 package from
CentOS 5)
with varied and disappointing results. I had problems with queued logs
being sent when the RELP server resumed, queue files not being cleaned
up etc.
I have since moved to rsyslog v7 stable from the adiscon repo (thank you
for providing these RPMs).
I have read the docs on queues and actions, but I would appreciate any
feedback
regarding the configuration below.
My requirements are (in my mind) simple:
1) send all syslog logs to a central server reliably.
2) No local log file storage.
3) Queue logs locally if the syslog server is down.
4) Sended queued logs to syslog server when it becomes available.
5) Discard logs if queue are is full.
6) If the syslog server is down, the applications logging should not
be impacted.
This is actually a very complex set of requirements. It's also not a complete
set of requirements (what are the reliability requirements on each system in the
face of system failures for example)
a full writeup and investigation of this would be a cunsulting gig, or the type
of work that would rate a published article in ;login or similar industry
publication.
several of the pieces are simple, it's when you put them all together and add
your reliability and performance (no impact) requirements that the overall setup
gets complicated.
Some information about the environment. The java applications either
log
to syslog directly (using syslog udp protocol to localhost - the rsyslog
daemon
If you are using UDP here, why not use it elsewhere (there can be good reasons,
but you have a lack of reliability from the very beginning). There's also the
issue of which logging library you are using (some of the common ones are not
that good)
forwards them to the relp server) or to a named pipe (read by logger <
NAMED_PIPE
or tail -F NAMED_PIPE | logger -p local0.info -t application).
Any comments are appreciated. I would like to provide the final
configuration
on the web site as a helpful starting configuration.
A good writeup of this, especially if the author can explain all the failures
they are and are not defending against, would be a very good thing to have.
I would suggest starting from scratch with a simple, stratighforward
configuration and document each step in the process of the log message, listing
each thing that could possibly happen to it.
When you hit a problem that isn't acceptable, make a new iteration of your
configuration to deal with that problem.
Then go through the documentation/analysis process again to see what effect this
has (sometimes you will find that adding reliability at one step can cause
problems at earlier steps)
When you are done, I would strongly encourage you to format your work (not just
the final configuration, but also the analysis and decisions made to get to that
final configuration) and submit it as an article for publication.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
