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