[Xymon] Can custom client-side tests leverage the server-side value in analysis.cfg?

[Grant Taylor]

On 10/14/23 11:28 PM, Jeremy Laidman wrote:
> Grant, a few quick responses to your message:

Thank you for the reply Jeremy,

> The "DS" means "data source". It's a term used by the RRD (round-robin 
> database) library (and tools) that Xymon uses for storing historical data.

Thank you for clarifying.  I sort of deduced that as I got further into 
the custom graphs, which I've now got working.  But it's one of those 
things that when you're newer to something "DS" is unfortunately vague 
and lost in a sea of new information.

> As a general principle, Xymon clients operate in local mode or central 
> mode. In (the older) local mode, the clients do all of their own 
> analysis and create their own data and status messages. In (the more 
> modern) central mode, the clients do a lot less of that, and instead 
> simply gather data for the server to parse and alert on.

Would it be fair to say that the older local mode uses status messages 
with color and newer central mode use data messages without color?  -- 
As a rough generalization, not a hard and fast rule.

> For your requirement, what I would do is to have the client collect the 
> queue size (and other data) and include this in the client message and 
> one of the sections, eg [mailq]. The contents of this could simply be 
> the output of the "mailq" command.

That's the path that I've gone with my initial swing at monitoring the 
Sendmail queue.

I did so by adding an ext(ension) script and adding said ext(ension) as 
a task to the Xymon client.  It's working quite well.

> You could create a script in the "sections" subdirectory, and the 
> Xymon client will automatically run it and include the output in 
> the [mailq] section of the client message.

This is very intriguing.  I spent a moment looking for "section" (case 
insensitive) in the client directory tree (`fgrep -ir "section"` type 
thing) and found reference to the client/local directory.  Upon testing, 
I see that I end up with the output of my executable (currently a 
script) with a heading named `[local:test_script.sh]`.

This is EXTREMELY useful.  It will make adding / removing additional 
data sections trivial.

It will also be cleaner than trying to use include files via 
clientlaunch.cfg  --  I was worried about central management of tasks 
accidentally overriding local things in the clientlaunch.cfg file.

> Then on the server, run a script (eg from tasks.cfg or something like 
> tasks.d/mailq) that dumps the client data message for every client, 
> and if a [mailq] section is found, create a status message.

I will be exploring this.

It seems like the gist of the idea is to receive the client status 
message, extract the section, and generate updates therefor.

> And optionally turn the mail queue size into a graphable data point 
> (either create a trends message with the number, or use a 
> colon-separated value format for the Xymon parser to detect). The Xymon 
> doco has a "how to setup custom graphs" page with a few different ways 
> to do this type of thing.

Yep.  I used that very page to get NCV based custom graphs working 
Friday evening.

I still need to explore the DS analysis / color declaration therefor.

Thank you again Jeremy.  I've learned a few more things that will make 
Xymon easier to deploy, maintain, use, and gain insightful information.  :-)



-- 
Grant. . . .
unix || die