Nagios is an open-source monitoring system built around a simple, durable idea: a scheduler runs small executable checks against hosts and services, each check returns an exit code and one line of text, and the state machine on top of those exit codes decides what is broken and who hears about it. Everything else — the web interface, the notification engine, the reporting — is layered over that contract, which is why Nagios can monitor anything you can write a script for.
The configuration model is object-based. Hosts, services, hostgroups, servicegroups, contacts, contactgroups, timeperiods, commands and templates are defined in text files, inherited and reused, and that structure is what determines whether a Nagios estate stays maintainable at five hundred hosts. States matter as much as objects: a check result is SOFT until it has been confirmed by max_check_attempts, and only a HARD state triggers notifications — the mechanism that stops a single failed poll from paging anyone.
In practice Nagios covers Linux and Windows hosts through NRPE and NSClient++, network devices over SNMP and ICMP, websites and TCP or UDP services with the standard plugin set, and everything else through custom plugins. Event handlers can act on a state change rather than just report it. Nagios Core is the open-source engine; Nagios XI adds the Core Config Manager, dashboards, wizards, auto-discovery and user administration on top of the same scheduling model.
Why this skill matters now
Nagios is not the fashionable choice, and that is precisely why the skill is valuable. It is still running in banks, telcos, manufacturing plants, hospitals and government estates, monitoring hardware, network gear, legacy applications and appliances that no cloud-native metrics stack was designed to touch. Somebody has to keep those systems observed, and the pool of engineers who genuinely understand the configuration model is shrinking rather than growing.
There is also a migration story. Many organisations are moving toward Prometheus, Zabbix or a hosted platform, and every one of those projects starts with the same question: what exactly are the eleven hundred checks in the existing Nagios configuration actually testing, and which of them still matter? Answering that requires reading Nagios properly, not replacing it blind.
And the check model itself remains the right tool for a whole class of problems. Anything with a binary answer — is the certificate valid, is the backup job finished, is the tape library online, is this appliance reachable — is a check, not a time series. Teams that understand both models choose correctly; teams that know only one force everything into the wrong shape.