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