XYMON(7)

📦
version 4.3.30 · 3 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

💖 XYMON(7) — the vibe check 💖

okay bestie, welcome to xymon(7) 💅 it lives in the Miscellaneous Information Manual and it's literally your intro tour to Xymon, so grab a snack 🍓

🌸 NAME 🌸

Xymon — Introduction to Xymon. that's it, that's the name, iconic 👑

✨ OVERVIEW ✨

Xymon is a tool for monitoring the health of your networked servers and the applications running on them. it gives you a simple, intuitive way of checking the health of your systems from a web browser, and it can also alert you to any problems that arise through alarms sent as e-mail, SMS messages, via a pager, or by other means. like, it will find you 🫶

Xymon is Open Source software, licensed under the GNU GPL. what that means for you: you are free to use Xymon as much as you like, and you are free to re-distribute it and change it to suit your specific needs. HOWEVER — and this is the part where you gotta listen — if you change it then you must make your changes available to others on the same terms that you received Xymon originally. see the file COPYING in the Xymon source-archive for details 📜

Xymon was called "Hobbit" until November 2008, when it was renamed to Xymon. this was done because the name "Hobbit" is trademarked. so yeah, legal reasons, not a vibe shift 😭

Xymon initially began life as an enhancement to Big Brother called "bbgen". over a period of 5 years, Xymon has evolved from a small add-on to a full-fledged monitoring system with capabilities far exceeding what was in the original Big Brother package. Xymon does still maintain some compatibility with Big Brother, so it is possible to migrate from Big Brother to Xymon without too much trouble. glow-up fr fr 🌈

Migrating to Xymon will give you a significant performance boost, and provide you with much more advanced monitoring. the Xymon tools are designed for installations that need to monitor a large number of hosts, with very little overhead on the monitoring server. monitoring of thousands of hosts with a single Xymon server is possible — it was developed to handle just this task. main character energy, no cap 💀

👑 FEATURES 👑

these are some of the core features in Xymon:

💜 Monitoring of hosts and networks

Xymon collects information about your systems in two ways: from querying network services (Web, LDAP, DNS, Mail etc.), or from scripts that run either on the Xymon server or on the systems you monitor. the Xymon package includes a Xymon client which you can install on the servers you monitor; it collects data about the CPU-load, disk- and memory-utilization, log files, network ports in use, file- and directory-information and more. all of that information is stored inside Xymon, and you can define conditions that result in alerts, e.g. if a network service stops responding, or a disk fills up 🔥

💜 Centralized configuration

all configuration of Xymon is done on the Xymon server. even when monitoring hundreds or thousands of hosts, you can control their configuration centrally on the Xymon server — so there is no need for you to login to a system just to change e.g. which processes are monitored. obsessed, honestly 🙈

💜 Works on all major platforms

the Xymon server works on all Unix-like systems, including Linux, Solaris, FreeBSD, AIX, HP-UX and others. the Xymon client supports all major Unix platforms, and there are other Open Source projects — e.g. BBWin, see http://bbwin.sourceforge.net/ — providing support for Microsoft Windows based systems. cross-platform queen 🌍

💜 A simple, intuitive web-based front-end

"Green is good, red is bad". using the Xymon web pages is as simple as that. the hosts you monitor can be grouped together in a way that makes sense in your organisation and presented in a tree-structure. the web pages use many techniques to convey information about the monitored systems, e.g. different icons can be used for recently changed statuses; links to sub-pages can be listed in multiple columns; different icons can be used for dial-up-tests or reverse-tests; selected columns can be dropped or unconditionally included on the web pages to eliminate unwanted information, or always include certain information; user-friendly names can be shown for hosts regardless of their true hostname. you can also have automatic links to on-line documentation, so information about your critical systems is just a click away ✨

💜 Integrated trend analysis, historical data and SLA reporting

Xymon stores trend- and availability-information about everything it monitors. so if you need to look at how your systems behave over time, Xymon has all of the information you need: whether it is response times of your web pages during peak hours, the CPU utilization over the past 4 weeks, or what the availability of a site was compared to the SLA — it's all there inside Xymon. all measurements are tracked and made available in time-based graphs 📈

when you need to drill down into events that have occurred, Xymon provides a powerful tool for viewing the event history for each status log, with overviews of when problems have occurred during the past and easy-to-use zoom-in on the event.

for SLA reporting, you can configure planned downtime, agreed service availability level, service availability time and have Xymon generate availability reports directly showing the actual availability measured against the agreed SLA. such reports of service availability can be generated on-the-fly, or pre-generated e.g. for monthly reporting. the receipts are RIGHT THERE bestie 🧾

💜 Role-based views

you can have multiple different views of the same hosts for different parts of the organisation, e.g. one view for the hardware group, and another view for the webmasters — all of them fed by the same test tools. one source of truth, many moods 💅

if you have a dedicated Network Operations Center, you can configure precisely which alerts will appear on their monitors — e.g. a simple anomaly in the system log file need not trigger a call to 3rd-level support at 2 AM, but if the on-line shop goes down you do want someone to respond immediately. so you put the web-check for the on-line shop on the NOC monitor page, and leave out the log-file check. protect their sleep, they deserve it 😴

💜 Also for the techies

the Xymon user-interface is simple, but engineers will also find lots of relevant information. e.g. the data that clients report to Xymon contain the raw output from a number of system commands. that information is available directly in Xymon, so an administrator no longer needs to login to a server to get an overview of how it is behaving — the very commands they would normally run have already been performed, and the results are on-line in Xymon. never SSH again, basically 🔐

💜 Easy to adapt to your needs

Xymon includes a lot of tests in the core package, but there will always be something specific to your setup that you would like to watch. Xymon allows you to write test scripts in your favorite scripting language and have the results show up as regular status columns in Xymon. you can trigger alerts from these, and even track trends in graphs just by a simple configuration setting. bring your own chaos, we'll monitor it 🦋

💜 Real network service tests

the network test tool knows how to test most commonly used protocols, including HTTP, SMTP (e-mail), DNS, LDAP (directory services), and many more. when checking websites, it is possible to not only check that the web server is responding, but also that the response looks correct by matching the response against a pre-defined pattern or a check-sum. so you can test that a network service is really working and supplying the data you expect — not just that the service is running. it ate and left no crumbs ✅

protocols that use SSL encryption such as https web sites are fully supported, and while checking such services the network tester will automatically run a check of the validity of the SSL server certificate, and warn about certificates that are about to expire. it WILL remind you before that cert dies, you're welcome 🔒

💜 Highly configurable alerts

you want to know when something breaks. but you don't want to get flooded with alerts all the time. Xymon lets you define several criteria for when to send out an alert, so you only get alerts when there is really something that needs your attention right away. while you are handling an incident, you can tell Xymon about it so it stops sending more alerts, and so that everyone else can check with Xymon and know that the problem is being taken care of. quiet on set, we're handling it 🎀

💜 Combined super-tests and test inter-dependencies

if a single test is not enough, combination tests can be defined that combine the result of several tests to a single status-report. so if you need to monitor that at least 3 out of 5 servers are running at any time, Xymon can do that for you and generate the necessary availability report. math girlies stay winning 🔢

tests can also be configured to depend on each other, so that when a critical router goes down you will get alerts only for the router — and not from the 200 hosts behind the router. one alert, not two hundred. the way that this saves your phone battery 😭

🔐 SECURITY 🔐

all of the Xymon server tools run under an unprivileged user account. a single program — the xymonping(1) network connectivity tester — must be installed setuid-root, but has been written so that it drops all root privileges immediately after performing the operation that requires root privileges. it takes root, does the one thing, and gives it right back. respectful king 👑

it is recommended that you setup a dedicated account for Xymon. yes, a whole separate account, do it 💖

communications between the Xymon server and Xymon clients use the Big Brother TCP port 1984. if the Xymon server is located behind a firewall, it must allow for inbound connections to the Xymon server on tcp port 1984. normally, Xymon clients — i.e. the servers you are monitoring — must be permitted to connect to the Xymon server on this port. however, if that is not possible due to firewall policies, then Xymon includes the xymonfetch(8) and msgcache(8) tools to allows for a pull-style way of collecting data, where it is the Xymon server that initiates connections to the clients. so if the firewall said no, there's still a way 🫶

heads up bestie: xymonping(1) is the one that needs setuid-root, and it drops the root privileges immediately after the operation that needs them — that's by design, not an accident ✨

the Xymon web pages are dynamically generated through CGI programs.

access to the Xymon web pages is controlled through your web server access controls, e.g. you can require a login through some form of HTTP authentication. lock the door, babe 🔑

🌈 DEMONSTRATION SITE 🌈

a site running this software can be seen at http://www.xymon.com/ — go look, it's giving live demo energy 🦋

more coming, this is only part 1, don't go anywhere bestie 💖

🎀 PREREQUISITES AND INSTALLATION 🎀

Okay so before we even start, bestie, you need a Unix-like system — think Linux, Solaris, HP-UX, AIX, FreeBSD, Mac OS X or something similar — and you need a web server installed on it. You're also gonna need a C compiler plus a few extra libraries, but ngl a lot of systems already come with the required development tools and libraries pre-installed, so check before you spiral. The required libraries are:

  • RRDtool — this one stores and presents all your trend-data. It is required, no skipping it.
  • libpcre — this handles the advanced pattern-matching of text strings inside configuration files. Also required. Both of these are non-negotiable, periodt.
  • OpenSSL — used for talking to SSL-enabled network services. Technically optional, but fr fr, install it anyway, because so many network tests use SSL.
  • OpenLDAP — used for testing LDAP servers. Using this is optional.

Want the deep lore on Xymon system requirements and how to actually install it? Go read the on-line documentation "Installing Xymon", which lives on the Xymon web server (find it via the "Help" menu), or in the docs/install.html file inside the Xymon source archive. 💖

💌 SUPPORT and MAILING LISTS 💌

xymon@xymon.com is an open mailing list for discussions about Xymon. Wanna join the convo? Send an e-mail to xymon-subscribe@xymon.com to join the list, or go visit http://lists.xymon.com/mailman/listinfo/xymon. 🌸

There's also an archive of the mailing list at http://lists.xymon.com/archive/ if you wanna lurk the old threads.

And if you literally just want to be notified when new Xymon releases drop, subscribe to the xymon-announce mailing list. It's moderated and used only for announcing new Xymon releases — no chaos, just announcements. To get added, e-mail xymon-announce-subscribe@xymon.com or hit up http://lists.xymon.com/mailman/listinfo/xymon-announce. ✨

👑 XYMON SERVER TOOLS 👑

These are the tools that implement the core functionality of the Xymon server:

xymond(8) is the core daemon that collects all the reports about the status of your hosts. It uses a bunch of helper modules to get certain tasks done, like updating log files and sending out alerts: xymond_client, xymond_history, xymond_alert and xymond_rrd. There's also a xymond_filestore module for compatibility with Big Brother. (iykyk 😌)

  • xymond_channel(8) — implements the communication between the Xymon daemon and all the other Xymon server modules. The group chat infrastructure, essentially.
  • xymond_history(8) — stores historical data about all the things Xymon monitors.
  • xymond_rrd(8) — stores trend data, which is what gets used to generate those graphs of the data Xymon monitors.
  • xymond_alert(8) — handles alerts. When a status flips into a critical state, this module decides if an alert should go out, and to whom. It's the one making decisions 💅
  • xymond_client(8) — handles data collected by the Xymon clients, analyzes it, and feeds several status updates back to Xymon to build the view of the client status.
  • xymond_hostdata(8) — stores historical client data for when something breaks. Like, when a web page stops responding, xymond_hostdata saves the latest client data so you can look at a snapshot of how the system state was right before it failed. Forensic queen. 🔍

🦋 XYMON NETWORK TEST TOOLS 🦋

These ones are used on servers that execute tests of network services.

  • xymonping(1) — performs network connectivity (ping) tests.
  • xymonnet(1) — runs the network service tests.
  • xymonnet-again.sh(1) — an extension script for re-doing failed network tests at a higher frequency than the normal network tests. This lets Xymon pick up the recovery of a network service the moment it happens, which means less downtime gets recorded. We love a fast comeback. 🫶

🌈 XYMON TOOLS HANDLING THE WEB USER-INTERFACE 🌈

These tools take care of generating and updating the various Xymon web-pages.

  • xymongen(1) — takes care of updating the Xymon web pages.
  • svcstatus.cgi(1) — this CGI program generates an HTML view of a single status log. It's what presents the Xymon status-logs to you.
  • showgraph.cgi(1) — this CGI program generates graphs of the trend-data collected by Xymon.
  • hostgraphs.cgi(1) — when you wanna combine multiple graphs into one, this CGI lets you combine graphs so you can, e.g., compare the load on all of the nodes in your server farm. Chef's kiss comparison energy. 👑
  • criticalview.cgi(1) — generates the Critical Systems view, based on the currently critical systems plus the configuration of what systems and services you want to monitor when.
  • history.cgi(1) — this CGI program generates a web page with the most recent history of a particular host+service combination.
  • eventlog.cgi(1) — this CGI lets you view a log of events that have happened over a period of time — for a single host or test, or for multiple systems.
  • ack.cgi(1) — this CGI program lets a user acknowledge an alert they got from Xymon about a host that's in a critical state. Acknowledging an alert does two things: first, it stops more alerts from being sent so the technicians aren't bothered with more alerts, and second, it gives feedback to the people looking at the Xymon web pages that the problem is being handled. Communication, she's an icon. 💅
  • xymon-mailack(8) — a tool for processing acknowledgments sent via e-mail, like as a response to an e-mail alert.
  • enadis.cgi(8) — a CGI program to disable or re-enable hosts or individual tests. When you disable a host or test, you stop alarms from being sent and any outages don't affect the SLA calculations. So this tool is your bestie when systems are being brought down for maintenance. 🙈
  • findhost.cgi(1) — a CGI program that finds a given host in the Xymon web pages. As your Xymon installation grows it gets genuinely hard to remember which page a host is on, so this CGI script lets you find hosts easily.
  • report.cgi(1) — this CGI program triggers the generation of Xymon availability reports, using xymongen(1) as the reporting back-end engine.
  • reportlog.cgi(1) — this CGI program generates the detailed availability report for a particular host+service combination.
  • snapshot.cgi(1) — a CGI program to build the Xymon web pages in a "snapshot" mode, showing the look of the web pages at a particular point in time. It uses xymongen(1) as the back-end engine.
  • statusreport.cgi(1) — a CGI program reporting test results for a single status but for several hosts. It's used for stuff like seeing which SSL certificates are about to expire, across all of the Xymon web pages. So useful it hurts. 😭
  • csvinfo.cgi(1) — a CGI program to present information about a host. The information gets pulled from a CSV (Comma Separated Values) file, which you can easily export from any spreadsheet or database program.

🍓 CLIENT-SIDE TOOLS 🍓

  • logfetch(1) — a utility used by the Xymon Unix client to collect information from log files on the client. It can also monitor various other file-related data, like file meta-data or directory sizes.
  • clientupdate(1) — used on Xymon clients to automatically update the client software with new versions. Through this tool, updates of the client software can happen without an administrator having to logon to the server. No cap, admin-free glow-ups. ✨
  • msgcache(8) — this tool acts as a mini Xymon server to the client. It stores client data internally so that the xymonfetch(8) utility can pick it up later and send it to the Xymon server. It's typically used on hosts that can't contact the Xymon server directly because of network- or firewall-restrictions.

🔥 XYMON COMMUNICATION TOOLS 🔥

These tools handle communications between the Xymon server and the Xymon clients. If there are no firewalls then they're not needed, but network or firewall issues may make it necessary for you to make use of them anyway.

  • xymonproxy(8) — a proxy-server that forwards Xymon messages between clients and the Xymon server. The clients have to be able to talk to the proxy, and the proxy has to be able to talk to the Xymon server.
  • xymonfetch(8) — used when the client isn't able to make outbound connections to either xymonproxy or the Xymon server (typically, for clients located in a DMZ network zone). Together with the msgcache(8) utility running on the client, the Xymon server can contact the clients and pick up their data.

💀 OTHER TOOLS 💀

  • xymonlaunch(8) — a program scheduler for Xymon. It acts as a master program for running all of the Xymon tools on a system. On the Xymon server it controls running all of the server tasks. On a Xymon client it periodically launches the client to collect data and send them to the Xymon server. The main character of process scheduling. 👑
  • xymon(1) — the tool used to communicate with the Xymon server. It's used to send status reports to the Xymon server, through the custom Xymon/BB protocol, or via HTTP. It can also be used to query the state of tests on the central Xymon server and retrieve Xymon configuration files. The server-side script xymoncgimsg.cgi(1) used to receive messages sent via HTTP is included too.
  • xymoncmd(1) — a wrapper for the other Xymon tools which sets up all of the environment variables used by Xymon tools.
  • xymongrep(1) — a utility for use by Xymon extension scripts. It lets an extension script easily pick out the hosts that are relevant to a script, so it doesn't have to parse a huge hosts.cfg file with tons of unwanted test-specifications.
  • xymoncfg(1) — a utility to dump the full hosts.cfg(5) file following any "include" statements.
  • xymondigest(1) — a utility to compute message digest values for use in content checks that use digests.
  • combostatus(1) — an extension script for the Xymon server, letting you build complicated tests from simpler Xymon test results. E.g. you can define a test that uses the results from testing your web server, database server and router to have a single test showing the availability of your enterprise web application. Combining slays. 💅
  • trimhistory(8) — a tool to trim the Xymon history logs. It will remove all log entries and optionally also the individual status-logs for events that happened before a given time.

⭐ VERSIONS ⭐

Time for the Xymon lore dump, bestie. Sit down, this is a whole glow-up timeline:

  • Version 1 of bbgen was released in November 2002, and optimized the web page generation on Big Brother servers.
  • Version 2 of bbgen was released in April 2003, and added a tool for performing network tests.
  • Version 3 of bbgen was released in September 2004, and eliminated the use of several external libraries for network tests, which resulted in a significant performance improvement. Glow-up era.
  • With version 4.0 released on March 30 2005, the project was de-coupled from Big Brother, and the name changed to Hobbit. This version was the first full implementation of the Hobbit server, but it still used the data collected by Big Brother clients for monitoring host metrics. (An era, truly.)
  • Version 4.1 was released in July 2005 and included a simple client for Unix. Log file monitoring was not implemented.
  • Version 4.2 was released in July 2006, and includes a fully functional client for Unix.
  • Version 4.3 was released in November 2010, and implemented the renaming of the project to Xymon. This name was already introduced in 2008 with a patch version of 4.2, but with version 4.3.0 this change of names was fully implemented. Periodt. 💖

Ok so legal bestie moment, but make it cute 💖 Xymon is Copyright (C) 2002-2011 Henrik Storner <henrik@storner.dk>.

Some parts of the Xymon sources came from public-domain or other freely available sources. Specifically, these are the the Red-Black tree implementation, and the MD5-, SHA1- and RIPEMD160-implementations. The license details for those live in the README file that ships with the Xymon sources.

Every other file is released under the GNU General Public License version 2, with the extra exemption that compiling, linking, and/or using OpenSSL is allowed. See the file COPYING for details.

🌈 SEE ALSO 🌈

If u wanna go down the Xymon rabbit hole — and honestly, same — these are the pages to tap next:

That’s the whole Xymon page, bestie: source Xymon, Version 4.3.30, dated 4 Sep 2019, and the page is XYMON(7). Go be iconic with ur monitoring 💅✨🫶

📦 where this page comes from