analysis tolerances not applying to scripted MacOS host

Thanks Zak.  I finally got back to working on my Mac client and have made significant progress now that I'm sending things to the server in the correct format.  I am now hitting an issue that I was also running into previously regarding the server not generating a cpu (la) graph.  It seems that everything else works fine with my client, but no matter what I do I can't get the server to generate a cpu graph when sending the data as
client $hostname.$ostype $clientclass

The cpu graph works perfectly if I send data as
status $hostname.cpu green\n$cpuData

But of course I can't do that because it forces the color green and then I can't use the analysis.cfg tolerances on it.
If I send it with no color it doesn't work at all.
status $hostname.cpu $cpuData

I've looked all through the original XymonPSclient for Windows that I'm using as a functioning example, but I'm not seeing the magic sauce that makes the cpu graph work.  All the other tests graphs work just fine, but this cpu graph has given me trouble since I first started this project.  Any ideas?

I've tried the following $ostype $clientclass options with none seeming to change anything.
linux
freebsd
netbsd
openbsd
darwin
bbwin
powershell
generic

Kris Springer

Hi Kris

Jeremy is right – for server side analysis, don’t send multiple individual status messages for these core tests. I don’t think analysis is triggered for status messages.

Instead, send one ‘client’ message with [cpu], [disk], [memory] sections, and send it as a client message, e.g. this from the Windows Powershell client:

client $($clientname).$($script:XymonSettings.clientsoftware) $($script:XymonSettings.clientclass) XymonPS

The defaults here are ‘powershell’ for clientsoftware (which is really OSTYPE) and clientclass.

If you have a Windows host running the Powershell client, you can see the last client message sent to xymon in the xymon-lastcollect.txt file. This is verbatim what is sent to the server via TCP.

https://www.xymon.com/help/manpages/man1/xymon.1.html

client[/COLLECTORID] HOSTNAME.OSTYPE [HOSTCLASS]

Used to send a "client" message to the Xymon server. Client messages are generated by the Xymon client; when sent to the Xymon server they are matched against the rules in the analysis.cfg(5) configuration file, and status messages are generated for the client-side tests. The COLLECTORID is used when sending client-data that are additions to the standard client data. The data will be concatenated with the normal client data.

You need to find the right OSTYPE for MacOS… xymond/xymond_client.c in the server source is what handles these messages, you’ll see a bunch of includes to match different OS types:

#include "client/linux.c"

#include "client/freebsd.c"

#include "client/netbsd.c"

#include "client/openbsd.c"

#include "client/solaris.c"

#include "client/hpux.c"

#include "client/osf.c"

#include "client/aix.c"

#include "client/darwin.c"

#include "client/irix.c"

#include "client/sco_sv.c"

#include "client/bbwin.c"

#include "client/powershell.c" /* Must go after client/bbwin.c */

#include "client/zvm.c"

#include "client/zvse.c"

#include "client/zos.c"

#include "client/mqcollect.c"

#include "client/snmpcollect.c"

#include "client/generic.c"

These included files handle the different OSTYPEs and differences in message formats between each (e.g. the output of the df command has different headings for some OSes).

My guess is Darwin is something like OS X, you’re right that there’s nothing for modern MacOS. Maybe Darwin would work.

Alternatively, if you can make the output resemble what you’d get from a Unix client then you could use OSTYPE = one of the unix types (possibly one of the BSDs, as MacOS has BSD origins).

I‘d be tempted to start with darwin, and look in xymond/client/darwin.c - note that xymond_client is probably expecting to see some sections that you may not be sending yet:

                timestr = getdata("date");

                uptimestr = getdata("uptime");

                clockstr = getdata("clock");

                msgcachestr = getdata("msgcache");

                whostr = getdata("who");

                psstr = getdata("ps");

                topstr = getdata("top");

                dfstr = getdata("df");

                inodestr = getdata("inode");

                meminfostr = getdata("meminfo");

                msgsstr = getdata("msgs");

                netstatstr = getdata("netstat");

                ifstatstr = getdata("ifstat");

                portsstr = getdata("ports");

Cheers

Zak

From: Kris Springer <user-c2caa0a7a8d5@xymon.invalid>
Sent: Wednesday, July 10, 2024 5:37 AM
To: Xymon mailinglist <xymon@xymon.com>; Jeremy Laidman <user-0608abae5e7c@xymon.invalid>
Subject: [External] [Xymon] Re: analysis tolerances not applying to scripted MacOS host

CAUTION: External email. Be cautious with links and attachments.

Understood, and thanks for the info. I thought it might be something like that. The problem is that there isn't a modern functioning MacOS xymon client that uses the xymond_client process. All the math is wrong in the 2015 version. The cpu, mem, and disk checks are all different in the modern MacOS versions than they were 10 years ago. For whatever reason Xymon has seemed to ignore that Mac's need monitored too. I've got a good script that produces good data, but it's not using any xymond_client process. I'd be happy to share my code with anyone who can assist with getting this working the 'correct' way. We could wrap it up into an App.dmg for easy install. Then we'll finally have a MacOS client available just like we already have the Windows PS client and the Linux clients. 

---

Kris Springer

On July 9, 2024 10:01:28 PM Jeremy Laidman <user-0608abae5e7c@xymon.invalid> wrote:

The analysis.cfg thresholds are applied in central mode. If you are operating in local mode (which you appear to be, as you are sending status messages from the client) then the CPU thresholding needs to be done on the client.

In central mode, the xymond_client process parses client messages for relevant sections (eg [df] for disk data, [uptime] for CPU load averages) and performs thresholding checks against settings in analysis.cfg. It's my understanding that in local mode, the xymond_client process runs on the client side, so if you're implementing a full client that runs in local mode, you have to replicate the behaviour of xymond_client.

It's far simpler to make a client that runs only in central mode. You construct a client message consisting of all of the sections you're interested in, and send it to the server for it to parse for thresholding and extracting metrics for rrd files. The structure of the client message contents is important, as the parser expects the sections to be in a format that matches the OS ID of the client ("darwin" for MacOS?).

J

On Wed, 10 July 2024, 07:28 Kris Springer, <user-c2caa0a7a8d5@xymon.invalid> wrote: