[Xymon] Process change

[David Welker]

Jeremy,

Yes, I used a status message as you described ("client" in place of color)
to get my data into the clientlog.  But, as I had seen in a previous post,
if I made this a blank for the default message id, this overwrote the
entire clientlog.  On the other hand, if I specified a "client" id, it
showed up in the clientlog as [collector:client], which, with your
information, I was finally able to figure out how to reference.

For example, to reference this...
[collector:mytest]

client/mytest hostname.example.com.linux client.mytest - This is a
client message test

I had to use this...
$XYMON $XYMSRV "clientlog hostname.example.com section=collector:mytest"

I know you mentioned there might be a delay, but if I insert a date in my
test message

client/mytest hostname.example.com.linux client.mytest - This is a
client message test Mon Aug 17 11:10:16 EDT 2015

I start seeing occasions when the clientlog date, the xymon header date
(upper right) on the status page, the first line date on the status page,
and this status message date are all exactly the same, down to the second,
but other times, 3 of the 4 are the same, but the status message date on
the status page still has the previous date/time. Why would this occur?

The reason I'm asking, the dates I provide in xymon status messages is
occasionally different from what's displayed on my graphs.

ALSO, and I realize this may be for a totally different reason, but why
would a history of a service show 4 changes of a status with the same
time?  How is that even possible?  I mean, other than a status message
being processed from four different places at the same time, of course.

 Thanks!

David


On Mon, Aug 10, 2015 at 11:17 PM, Jeremy Laidman <jlaidman at rebel-it.com.au>
wrote:

> Can you elaborate on "found a way"?  I'm guessing you sent a status
> message with testname="mytest" color="client" like so:
>
> $XYMON $XYMSRV "status hostname.example.com.mytest client $CLIENTDATA"
>
> This is a special case to support backwards compatibility.  It's probably
> better to use a client message like:
>
> $XYMON $XYMSRV "client/mytest hostname.example.com.$OSTYPE $CLIENTDATA"
>
> (In both cases, $CLIENTDATA might need to start with a newline.)
>
> That's all beside the point.  They should both work for you.  But what you
> end up with is simply an extra section in the clientdata, and that's all.
>
> What normally happens from here, for things like cpu, disk, memory and so
> on, is that the xymond_client process parses the client data, works out the
> status for each (typically against configurations in analysis.cfg) and then
> creating whatever graphs and status messages are relevant.  The important
> thing to note here is that xymond_client has special code to handle each
> and every case; if you want extra client data to be handled, you have to do
> it yourself, using a server-side script.  None of the code in xymond_client
> is generic enough to deal with new client data it hasn't been programmed
> for.
>
> Let's say you want to write your own code to parse the client data and
> create your own status messages.  You have a couple of options to do this.
> Firstly, you could create a script that uses "xymon clientlog" such as:
>
> $XYMON $XYMSRV "clientlog hostname.example.com section=mytest"
>
> Try this out using "cpu" and "df" and "free" instead of mytest, to get a
> feel for it.  You should be able to extract your "[mytest]" section in this
> way.
>
> Then, all you need to do is parse the output, and generate your own status
> (and optionally, data) messages.  You'd run your script every 5 minutes
> from tasks.cfg or cron.  There will almost certainly be a delay between
> when the client data message arrives and when your script runs, leading to
> delays in alerting of up to 5 minutes.
>
> The second way to do this is to create your own xymond_client module
> equivalent, attached to a new instance of xymon_channel.  This method
> allows you to parse the client data message as soon as it arrives, and act
> accordingly (presumably creating your own data/status messages).  When
> running xymond_client, you can specify a filter so that you only get the
> matching messages.  For example, in tasks.cfg you might have:
>
> [mytest]
>   ENVFILE /bla/bla/xymonserver.cfg
>   NEEDS xymond
>   CMD xymond_channel --channel=client
> --logfile=$XYMONSERVERLOGS/mytest.log name_of_your_script_here
>
> Your script will get the whole client data message as soon as it arrives,
> on standard input.  It's up to your script to parse this any way you need,
> such as matching hostnames and/or OS types, extracting the [section] you're
> interested in, separating each message from the next, and making
> status/data messages according to your needs.  Each message starts with
> "@@client#..." and ends with "@@".
>
> Something to try (running as the xymon user):
>
> xymond_channel --channel=client sed -n '/^\[cpu\]/,/^\[/p'
>
> This displays only the lines between [df] and the next line that starts
> with "[".
>
> Writing your own xymond_channel module is not a trivial task.  I would
> only entertain this strategy if you needed a fast response time.
>
> Cheers
> Jeremy
>
>
> On 7 August 2015 at 00:26, David Welker <dewelker at gmail.com> wrote:
>
>> Okay, in answer to my own question, I finally found, or so I thought, a
>> way to add my client data to the Xymon clientdata, but how do I get it to
>> show up under a specific section?  If I provide a TESTNAME, it ends up
>> under a different collector id - [collector id: mytest].  If I make
>> TESTNAME blank, it doesn't show up at all!
>>
>> Thanks,
>> ​
>> David
>>
>> _______________________________________________
>> Xymon mailing list
>> Xymon at xymon.com
>> http://lists.xymon.com/mailman/listinfo/xymon
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20150817/1990c98d/attachment.html>