On 10/16/23 6:39?PM, Jeremy Laidman wrote:
Responding inline:
:-)
Agreed. Xymon/Hobbit, and its spiritual predecessor BigBrother, come from a tradition of using a common collection of disparate tools for monitoring networked devices and hosts. One of these foundational tools is RRD, which is used by other network monitors (Cacti, MRTG, etc).
Yep. I was exposed to RRD via MRTG, and subsequently Cacti, probably two decades ago. Both surprisingly and thankfully I've not needed to use RRD directly as things like MRTG, Cacti, and Xymon have abstracted them away for me. But I've long appreciated the suite of tools.
The "culture" of Xymon can sometimes assume knowledge of how the other tools work. And while there's references to RRD in the Xymon doco, it couldn't hurt to add some extra definitions or explanations within the Xymon doco, to help those who don't have a history in this space that extends back to the last millenium (showing my age, aren't I).
Waiter / waitress, the next cup of $COFFEE is on me.
Yes and no. The central/local mode choice relates to the bulk of the core OS resource metric collection and processing. Choosing central mode doesn't prevent the use of client-side processing and status messages (with colour) being sent from the client. I know you didn't ask this, but I'm just making sure I'm not giving the wrong idea.
ACK
Sounds like use what's best for the situation, even if there might be a slight affinity one way or the other.
With local mode, the client looks for faults, and sends a status message with the colour in the header and a text report in the body.
I've been making extensive use of this. I've been augmenting many cron jobs that historically have sent email to now also report to Xymon. I'm making extensive use of lifetime to make lack of reports stand out by going purple.
Honestly, this work effort has gotten me the closest "single pane of glass" visibility into environments. We're still a long way away from it. But we're getting closer every day.
With central mode, client data messages are sent to the server, into the xymond daemon. Then code on the server asks the xymond daemon for the client message of each host, parses them for possible problems, and constructs a status message with the colour in the header and a text report in the body.
My understanding is that's one way to do it.
My understanding that another way to do it is to hook in as a channel and receive a copy of all messages (of the proper type) and act appropriately.
So the last part of the process is the same. The Xymon server receives status messages from itself for clients in central mode, or from the clients when they're in local mode.
ACK
To bring it back to your phrasing, local mode uses status messages with colo(u)r and central mode also uses status messages with colo(ur) but those messages come from the Xymon server itself. In central mode, the colours are determined by the server (eg in analysis.cfg), whereas in local mode, the colours are determined by the client.
ACK
Yes, the "client/sections" directory is a relatively recent feature that was added as a "patch" to the original client-side script. My mistake for assuming that everyone had this.
After inheriting the -- let's go with -- existing legacy install at $DAY_JOB, I've since upgraded $DAY_JOB to 4.3.30, installed 4.3.30 at home, and installed 4.3.28 (what comes in distro files).
I've got a smattering of clients from 4.3.30 down to 4.2.3 (installed yesterday on an ancient FreeBSD 4.11). -- As in the green faces have just recently turned to green diamonds for that FreeBSD 4.11 system.
I'm trying to get my hands on a compilation of any version for AIX 5.3 (?). For now I'm running the hobbitclient-aix.sh via telnet w/ echo scheduled via cron. It's working and providing most of what I need and much of what I want.
I've sort of taken what previous colleagues poked once in a while and ran with it to make things better for $DAY_JOB, myself, and a friend that I help. I've also intrigued another friend enough to install and play with it.
I think I say that I'm liking Xymon. ;-)
The patch is applied to the packages available from the Terabithia repository, but I don't believe it's included when Xymon is built from original source code.
Please elaborate and / or point me where I can go do some more reading.
I've seen references to 4.4 being in alpha status.
The "client/local" directory is "standard" Xymon (as long as you create the directory), but it has the side-effect of making section names with the "local" prefix. There are probably good reasons for this prefixing (I'm guessing to prevent collisions with standard section names), so if it works for you, that's great.
Yep. Naming things and knowing where / how to start counting are three of the hardest things in computers.
My guess is that the next release of Xymon will include client/sections in the source, in addition to supporting client/local.
I'll keep that in mind.
A snippet from the README in client/sections/ from the Terabithia package:
"This directory is intended for use with automatically deployed files. Local scripts for this host should be placed in the client/local/ directory instead."
/me chuckles to himself muttering something about "/" vs "/usr" vs "/usr/local" vs "/opt".
Exactly. The client is as simple as it can be, so that it doesn't need constant tweaking. The server does all the smarts, including parsing, graphing, thresholding, so that the client host can spend more cycles doing its main function.
:-)
You're well on your way, so well done! Thank you.
Feel free to ask more questions on this list. The more questions the better our shared knowledge! (Although it's easier to respond to if each question is in a separate thread.)
ACK
I tend to try to keep any given thread relatively contained and start a new thread as needed.
-- Grant. . . . unix || die