On Tue, 9 Jun 2015, [email protected] wrote:
On 2015-06-08 13:23:04 +0200, [email protected] wrote:
I have a (surely) extremely exotic need. But I guess you have a good
hint for me to implement this with rsyslog ;)
There is one rsyslog daemon receiving log data via TCP, UDP and doing
some actions based on the data.
I want to dynamically start and stop a secondary rsyslog process (this
is done outside of rsyslog-scope). The second process should recieves
data from the first process and do some actions. If the second process
is unavailable this should have absolutly no impact to all activities
of the first rsyslog process.
I was thinking of doing the data-interchange by named pipes. Is this
a good idear? How to I prevent freezing of messages, because a
"target" is unavailable? Do you have an alternative idear to
implementing such a usecase?
Maybe describe *why* you want to do it like this. describe why you think
you cant do the complete handling in one instance.
darix
Hi darix,
Thanks for your response.
At least I need a dynamic to add or remove actions "on-demand" by an external
program. (start/stop) while at the same time, other actions should be still performed.
e.g. log to file_1 always; log to file_2 only if a flag is set.
Of course it would be possible to change the config of rsyslog and restart the
daemon each time, so that I have 2 different configurations. But a restart is
not really good, because my (tcp-) connections gets interrupted and in the
meantime of the restart I will loose messages.
By the way rsyslog works (from my understanding) if I have multiple actions in
my different rulesets, messages get stuck in the queue until all actions of the
ruleset are performed.
I also made the experience that this is a critical topic, because on very high-load with
full queues rsyslog tends to die unexpectedly on my RHEL servers. Dying of rsyslog is the
worst thing that can happen here, so I perfere to have 2 independent processes, one that
does the "basic" things without any interruption or change, and a second one,
that can be started and stoped as it is needed by external dependencies.
This is exactly the type of thing that global variables were designed for.
You can watch for a particular log message, and when you see it, set a variable
(and a different message to clear it)
Then you can test that variable to decide if you want to do the action in
question or not.
If you want to do this with multiple instances, then you will have to set the
main one to not retry failed messages to the second, but you will be subject to
false positives if the second is a smidge slow in reading data, and you will
ahve a lag when you start the second one up again (although i guess you could
HUP the first one to have it close/reopen all it's outputs)
really, the global variable is much cleaner.
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.
