[Xymon] Serial alarm feeds

Kevin King kc6ovd at gmail.com
Tue Aug 27 17:27:50 CEST 2013


I do use that script. However it does not do anything with message files.
(Unless the author has done some updates to it.) The other issue is I am
dealing with a ROP feed. This is a serial stream of message data from port
we have tied to a term server. So I have no OS to login to and run commands.

 

Thanks for the tip!

 

-Kevin

 

From: Galen Johnson [mailto:Galen.Johnson at sas.com] 
Sent: Tuesday, August 27, 2013 11:02 AM
To: Kevin King; 'Jeremy Laidman'; 'KING, KEVIN'; xymon at xymon.com
Subject: RE: [Xymon] Serial alarm feeds

 

Look on the front page of xymonton.org.  There is a link to a "clientless"
xymon client (xymon-rclient) that might do what you are looking for.

=G=

  _____  

From: Xymon [xymon-bounces at xymon.com] on behalf of Kevin King
[kc6ovd at gmail.com]
Sent: Tuesday, August 27, 2013 10:38 AM
To: 'Jeremy Laidman'; 'KING, KEVIN'; xymon at xymon.com
Subject: Re: [Xymon] Serial alarm feeds

Jeremy,

 

This is good food for thought. I think I might need to run this as an
external script. That way I can pass the host information, (I have more than
one of these) Then I should be able to enter a hostname in the
logfetch-special.cfg file. I then could do this for almost any collector
that cannot use a local client.

 

I seem to remember we had a tool like this way back in the BB days, I ether
found something or I modified bb. Wish I still had that server! I built many
a tool for BB. That is when I was on top of my game, I am a retread in this
admin stuff. I look at some of the stuff I wrote in the early 2000s and I
say wow nice code, what does it do? 

 

Thanks for the kick start!

 

-Kevin

 

From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Jeremy Laidman
Sent: Tuesday, August 27, 2013 12:14 AM
To: KING, KEVIN; xymon at xymon.com
Subject: Re: [Xymon] Serial alarm feeds

 

 

On 27 August 2013 13:31, KING, KEVIN <KK1051 at att.com> wrote:

No no snmp. It is a very closed system. The messages we get are out of a
serial port to a term server.

 

:-(

 

I guess I do not know the client tool then. How can I save the files on my
xymon server and use entries  in the client config and alert rules to make
if show up under the correct server?  Maybe I am getting myself stuck in the
mud, but if the file is on the xymon host how can I process it like it was
on the client?

 

A server is almost always also a client.  You should have the Xymon server
name in hosts.cfg, yes?  Also, the Xymon server can be listed in
client-local.cfg and analysis.cfg.  Just create appropriate entries in those
two files for the server and the logfile, and it will report the errors as
they appear.

The down-side to this is that the errors are assigned to the Xymon server.
If you want them assigned to the device name instead, then you will probably
have to do something a bit more complex, such as writing a custom script on
the Xymon server to do the log analysis and reporting.  I don't see a way
that you can do this with the built-in log monitoring features.

 

Hmm, here's an idea.  You could create a script that simply replicates the
log file into a client message, which would be a substitute for the
client-local.cfg entry.  So then you'd be able to use the standard "LOG"
definitions in analysis.cfg to match whatever you want.

 

The easiest way to do this, I think, would be to run a second copy of
logfetch on the Xymon server (the standard one is usually run from
xymonclient.sh, from the [xymonclient] section of tasks.cfg).  The logfetch
tool requires a configuration file and a state file as parameters.  Normally
the config file is simply extracted from client-local.cfg and pushed to the
client during the client message interaction, but you can simply create your
own.  For example (untested), create in $XYMONTMP the file
logfetch-special.cfg, containing the following:

 

log:/var/log/mylogfile:10240

    ignore THIS

    ignore THAT

 

Then add the following into tasks.cfg or a new file in tasks.d:

 

[xymonclient-special]

    NEEDS xymond

    ENVFILE $XYMONCLIENTHOME/etc/xymonclient.cfg

    LOGFILE $XYMONCLIENTLOGS/xymonclient-special.log

    INTERVAL 5m

    CMD sh -c '( printf "eagle.example.com.eagle
eagle\n[msgs:/var/log/mylogfile]\n"; $XYMONCLIENTHOME/bin/logfetch
$XYMONTMP/logfetch-special.cfg $XYMONTMP/logfetch-special.status ) | $XYMON
$XYMSRV "@"'

 

This creates a header, using the device's hostname, and a [msgs:] section
for the logfile being monitored.  Then it uses logfetch to get the latest
bunch of lines from the logfile, and filter out any "ignore" entries from
the config file logfetch-special.cfg.  Finally, all of this is piped into an
instance of xymon that creates a client message and sends it to the server.

 

The end result is a client message that should start to generate a "msgs"
dot against the device name (assuming you added the device name into
hosts.cfg - probably with a "noping" tag).  If this works, you can then
start using analysis.cfg to have the Xymon server parse the log file from
the client data.

 

This is all a bit kludgy.  You might prefer to extract the CMD bit into a
separate script, and just put the script name after the CMD keyword.

 

J

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20130827/ac241f82/attachment.html>


More information about the Xymon mailing list