I used this approach several times in the past and it worked great in
detecting:
a) unforeseen problems for which we didn't have specific checks
b) problems in mechanisms for which there was no convenient check to
find otherwise.
c) problems resulting from "logical misbehaviour" - when a service seems
to work but returns a wrong result
Of course it's best implemented in conjunction with simpler technical
checks for various steps along the way so it's easier to come up with
the answer not only _what_ doesn't work but also _why_ because the
longer the "workchain" is, the harder it is of course to pinpoint the
cause in case of malfunction if you have only the final error.
On 11/01/2021 12:04, Adam Chalkley wrote:
Good tip.
We currently have a service check that runs client-side on our senders (and edge receiver
which forwards downstream to other instances) that monitors forward queues. This has been
extremely helpful in the past catching "stuck" messages.
I like your suggestion and will consider implementing this when time allows.
Thanks.
-----Original Message-----
From: rsyslog <rsyslog-boun...@lists.adiscon.com> On Behalf Of Mariusz Kruk via
rsyslog
Sent: Monday, January 11, 2021 12:40 AM
To: rsyslog@lists.adiscon.com
Cc: Mariusz Kruk <m...@safecomp.com>
Subject: Re: [rsyslog] Is there an easy way to send a msg to rsyslog via RELP
as a Nagios check?
I'd approach it from a "functional" point of view. Have some host
generate a message periodicaly, send it via RELP to your destination
host, make a rule that outputs this message to a file and check that
file for a message written recently. This way you check the whole
process. If you send the data from the rsyslog further down to some log
management or SIEM solution, you can even check the whole process by
checking for the message on the final destination.
It has nothing to do with rsyslog itself it's just how you do such
checks - look for a string on returned web page, send an email and check
whether it gets delivered and so on.
On 10/01/2021 21:58, Adam Chalkley via rsyslog wrote:
Hi,
In the past I've used a standard check_tcp Nagios plugin to confirm that
rsyslog was accessible on our receivers. This produces a bit of noise in the
logs since the connections don't follow what I assume would be standard client
connect/disconnect behavior. I've always ignored the noise as it's
intermittent, but figured it might be worth crafting a proper check.
I'd like to craft a plugin that sends a small test message to rsyslog via RELP
(since that is what we're primarily using). I'd setup a rule in rsyslog to
match/ignore it, but receiving it would be enough for a future Nagios check to
confirm (that at a basic level) remote rsyslog connections are working.
Any pointers? I considered digging into the C source code, but I don't think my
skills are up for that task just yet.
Thanks in advance.
_______________________________________________
rsyslog mailing list
https://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.
_______________________________________________
rsyslog mailing list
https://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.
_______________________________________________
rsyslog mailing list
https://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.
