Infrastructure monitoring in 2026: revisit Zabbix, Checkmk and Netdata before you add another host to your monitoring

In most Indian companies, monitoring starts with a person, not a tool. Somebody in the IT team logs in to the file server every morning, checks the disk, looks at the UPS panel, pings the branch router, and goes back to work. Then one day the ERP server stops at 11 AM because a log partition filled up overnight, and the owner asks a simple question: “Why did nobody know?”

The usual answer is to install something. A free tool gets set up on a spare machine, a few servers are added, and email alerts start flowing. Two years later there are three hundred alerts a day, half the hosts in the tool have been decommissioned, the switches were never added because SNMP “did not work”, and the person who set it up has left. The tool is still running. Nobody trusts it.

This post is about the tools that sit at the centre of classic infrastructure monitoring: servers, virtual machines, switches, firewalls, UPS units, printers, databases and the services on them. We compare three open source options that Indian IT teams look at in 2026: Zabbix, Checkmk and Netdata. We look at where each came from, what versions are current at the end of October 2026, how each one collects data, how it scales, how you run and upgrade it, what security advisories came out this year, what the licences really say, and when each one fits. We keep it practical, and we try to be fair to all three.

This post sits next to several earlier ones and tries not to repeat them. If you already run Prometheus and your problem is keeping metrics for months, Prometheus long-term storage is the right post. If your question is “is the website up from outside”, read Uptime monitoring in 2026; here we look from inside the network. Logs and traces have their own posts: Log storage in 2026, Distributed tracing in 2026 and the pipeline that carries logs, Fluent Bit, Vector and the OpenTelemetry Collector. Monitoring data is time series data, so Time-series databases in 2026 is a useful neighbour. And because agents must be installed and configured on every host, Configuration management in 2026 matters more than people expect.

We end with a small drill. We ran the Checkmk 2.5.0p17 Linux agent script as a normal user on a test machine and read the shipped configuration files of Zabbix 7.0.32 and the Netdata 2.12.2 SNMP collector. We did not run a Zabbix server, a Checkmk site or a Netdata agent, and we say so clearly in that section.

A scenario to keep us honest

Imagine a pump manufacturer in Coimbatore. The company is invented for this post. It makes domestic and agricultural pumps and motors, has a main factory in an industrial estate on the edge of the city, a second assembly unit about twenty kilometres away, a warehouse, and sales offices in Chennai, Bengaluru and Hyderabad. Dealers across Tamil Nadu, Karnataka and Andhra Pradesh order through a dealer portal.

The IT estate looks like this:

• About 45 Linux and Windows servers and virtual machines: an ERP on a Windows server with SQL Server, a PostgreSQL database for the dealer portal, a file server, Active Directory, a mail relay, a backup server, two hypervisor hosts and a few small Linux machines for internal tools.
• Around 60 network devices: core and access switches at the main factory, smaller switches at the assembly unit and warehouse, two firewalls, Wi-Fi controllers, site-to-site VPN routers in the branch offices.
• Several things that only speak SNMP or a web page: UPS units, two air conditioners in the server room with network cards, label printers on the shop floor, and a temperature sensor.
• A dealer portal and a small set of APIs hosted on a cloud provider in the Mumbai region.

Today they use an old Nagios Core installation that one engineer set up years ago, plus a free trial of a commercial tool on the cloud machines that expired last month. Last monsoon three things went wrong. A UPS at the assembly unit ran on battery for forty minutes during a power cut and nobody knew until the servers there shut down. The ERP database drive reached 100 percent during month-end closing. And the VPN to the Hyderabad office flapped for two days; users complained about the ERP being slow, and the team spent a day blaming the ERP vendor.

The IT team is three people: a manager who also handles vendor contracts, one system administrator, and one network engineer. They want:

1. One place that shows servers, network devices, UPS units and the cloud machines, with the network devices discovered rather than typed in one by one.
2. Alerts that reach the right person by email and a messaging app, and that are few enough to be read.
3. History of at least a year for capacity planning, so they can tell management when the file server needs more disks.
4. Something the next engineer can understand without the person who built it.
5. Zero licence cost for now, with an option to pay for support later if the management agrees.

We will come back to Coimbatore with a step-by-step plan.

The short version

• Zabbix is a mature, all-in-one monitoring server with a database at its centre, agents, proxies for remote sites, very strong SNMP and template support, and its own alerting and dashboards. It is AGPLv3 from version 7.0 onwards. The current long-term support line is 7.0 LTS, with 7.0.32 released on 20 October 2026. Zabbix 8.0 LTS is in release candidate stage (8.0.0rc3 on 29 October 2026) and the Zabbix roadmap lists November 2026 as its planned release. It suits teams that want one tool for servers and network gear and are ready to look after a database.
• Checkmk grew out of the Nagios world and is now a full product with its own agent, a rule-based configuration model and strong automatic service discovery. The free edition, earlier called Checkmk Raw, is now called Checkmk Community and is GPLv2. The current stable line is 2.5.0, released on 28 April 2026, and the latest patch tag at the time of writing is 2.5.0p17 (21 October 2026). Several convenient features, such as the Agent Bakery and the faster Checkmk Micro Core, are only in the paid editions. It suits teams that like “discover everything, then tune with rules”.
• Netdata is a per-second, agent-first monitoring system. Each agent collects and stores its own metrics, detects anomalies with local machine learning and raises alerts. Agents can stream to parent agents for central storage. The agent is GPLv3 or later, but the modern dashboard UI is closed source under the Netdata Cloud UI License (NCUL1), and Netdata Cloud is a closed service with free and paid tiers. The current release is v2.12.2 (23 October 2026). It suits teams that want deep, high-resolution visibility into Linux hosts and containers very quickly.
• Alternatives worth naming: Prometheus with Grafana for teams already on Kubernetes and pull-based metrics; Icinga for teams who like the Nagios check model with a modern core and API; Nagios Core if you have it and it is working; LibreNMS if your estate is mostly network devices.

None of the three will fix a monitoring setup that nobody owns. The tool decides how you collect and alert; the team decides what is worth an alert.

Where things stand on 30 October 2026

The versions and dates below come from the official download pages, release notes, version pages and GitHub releases, checked on 30 October 2026 (IST).

Zabbix:

• Zabbix 7.0 LTS: released on 4 June 2024. Latest patch 7.0.32, dated 20 October 2026. Full support until 30 June 2027 and limited support (critical and security fixes) until 30 June 2029, according to the Zabbix life cycle page.
• Zabbix 7.4 (standard release): released on 1 July 2025; latest 7.4.16, dated 20 October 2026. Limited support ends in the first quarter of 2027.
• Zabbix 6.0 LTS: latest 6.0.49, dated 20 October 2026; limited support until 28 February 2027.
• Zabbix 8.0 LTS: 8.0.0rc2 on 21 October 2026 and 8.0.0rc3 on 29 October 2026. The roadmap page says the planned release date is November 2026, and the life cycle page plans full support until the fourth quarter of 2029 and limited support until the fourth quarter of 2031. Until the final 8.0.0 is out, treat 8.0 as a release candidate.
• Licence: AGPLv3 from 7.0.0. Versions up to 6.4 were GPLv2.

Checkmk:

• Checkmk 2.5.0: stable release on 28 April 2026. The Checkmk versions page lists end of passive maintenance as 28 April 2028; active maintenance ends six months after a future 3.0.0, for which no date was set when we checked.
• Latest 2.5 patch tag on GitHub: v2.5.0p17, committed on 21 October 2026 (evening, IST). A 2.5.0p18 release candidate tag also exists.
• Checkmk 2.4.0: released on 6 May 2025; active maintenance ended on 28 October 2026 and passive maintenance runs until 6 November 2027.
• Checkmk 2.3.0: passive maintenance ended on 29 October 2026. If you are on 2.3, you are now unsupported.
• Edition names changed: Checkmk Raw became Checkmk Community, Enterprise became Pro, the self-hosted Cloud edition became Ultimate, the MSP edition became Ultimate with Multi-Tenancy, and the SaaS product is now simply Checkmk Cloud. In 2.4 only the titles changed; in 2.5 the package names and internal identifiers changed too (for example cre became community).
• Licence: the Community edition source on GitHub is GPLv2. The other editions are commercial.

Netdata:

• Netdata Agent v2.12.2: released on 23 October 2026 (evening, IST). Before that, v2.12.1 on 8 October, v2.12.0 on 30 September, v2.11.0 on 12 August and v2.10.0 on 9 April 2026.
• Licence: the agent is GPLv3 or later. The dashboard UI shipped with the agent and served from a CDN is closed source under NCUL1. Netdata Cloud is a closed service with free and paid tiers.

The first question: what are you actually monitoring?

Before comparing features, write down what is in your estate and how each part can be watched. Most teams fall into one of four shapes.

Shape 1: mostly servers and virtual machines

You have Linux and Windows servers, perhaps a hypervisor, and a few databases. Network gear is simple. Here the quality of the agent, the speed of setup and the depth of host metrics matter most. All three tools work. Netdata is the fastest to give you detail; Zabbix and Checkmk give you more structure for a long list of hosts.

Shape 2: mixed servers and network devices

This is the Coimbatore shape and the most common one in Indian small and medium businesses. Switches, firewalls, UPS units and printers only speak SNMP. Here SNMP support, device templates, network discovery and interface graphs matter a lot. Zabbix and Checkmk are both strong. Netdata has an SNMP collector with device profiles and virtual nodes, and it improved a lot through 2025 and 2026, but its centre of gravity is still the host.

Shape 3: many sites with weak links

Branch offices, plants and warehouses connected by VPN or MPLS. Links drop. You need a component at each site that keeps collecting when the link is down and sends data later. Zabbix proxies, Checkmk distributed sites (and, in the paid editions of 2.5, the new Checkmk Relay), and Netdata parent and child streaming all try to solve this, in different ways.

Shape 4: containers and cloud native workloads

Kubernetes, short-lived containers, autoscaling. Hosts come and go every hour. Here pull-based metrics with service discovery, such as Prometheus, often fit better, and the classic tools become one part of a wider setup. Netdata handles containers well on each node. Zabbix and Checkmk both have Kubernetes integrations, but if this is your main shape, read the Prometheus posts first.

A quick test

Count three things: hosts with an agent, devices that only speak SNMP, and sites. If SNMP devices are more than a third of the total, put network monitoring strength first. If sites are more than two, put the remote collection model first. If almost everything is Linux and you want answers this week, start with Netdata on a few hosts and see if it is enough.

What each tool is

Zabbix

Zabbix is a single product with a clear centre: the Zabbix server. The server holds the configuration and the collected history in a relational database, runs the pollers, evaluates triggers and sends alerts. A web frontend written in PHP reads the same database. Around this centre are:

• Zabbix agent (written in C) and Zabbix agent 2 (written in Go, with a plugin system for things like databases and Docker). Agents can be passive, where the server connects to the agent on port 10050 and asks for a value, or active, where the agent fetches its list of checks from the server and pushes results. Active mode works better through firewalls and NAT, because only the agent opens a connection.
• Zabbix proxy, a smaller process with its own local database that collects data on behalf of the server, usually at a remote site, and forwards it. Since 7.0, proxies can be grouped for load balancing and failover.
• SNMP, IPMI, SSH, Telnet, HTTP agent, JMX, ODBC, script items, and external checks. SNMP traps arrive through snmptrapd and a helper.
• Templates: a template bundles items (what to collect), triggers (when it is a problem), graphs, dashboards and low-level discovery rules that find interfaces, file systems, disks or database instances and create items for each one. Zabbix ships a large set of official templates for operating systems, network vendors, databases and applications.
• Network discovery and auto-registration: the server can scan IP ranges and add devices according to rules, and active agents can register themselves with metadata such as “linux, erp”.

The database is the heart and the main thing to plan. Zabbix supports MySQL or MariaDB and PostgreSQL, and many larger installations use PostgreSQL with the TimescaleDB extension for history compression and faster housekeeping. Zabbix stores raw history and hourly trends separately, and you set how long each is kept.

A minimal active agent configuration looks like this:

# /etc/zabbix/zabbix_agent2.conf (example, not from a real host)
ServerActive=zabbix-proxy-plant2.example.internal
Hostname=erp-db-01
HostMetadata=windows erp
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=erp-db-01
TLSPSKFile=C:\zabbix\erp-db-01.psk

High availability for the server itself has been native since 6.0: you run two or more server nodes against the same database, each with its own HANodeName, and one is active at a time. The database still needs its own high availability.

Checkmk

Checkmk began as Check_MK, an add-on to Nagios that replaced many small check plugins with one agent call per host. It has since become a complete monitoring system that installs as one package and runs sites, each a self-contained instance managed with the omd command. A site contains:

• A monitoring core. The Community edition uses Nagios Core underneath. The paid editions use the Checkmk Micro Core (CMC), which Checkmk says is faster and uses fewer resources; treat that as the vendor’s own claim and test it with your own load.
• The Setup layer (earlier called WATO), where hosts, folders, rules and users are configured in the web UI or through the REST API.
• Livestatus, a fast query interface to the current state of the core.
• Graphing based on round robin files, and the web interface with views and dashboards.

The Checkmk agent is simple at its heart. On Linux it is a shell script that prints plain-text sections, one per topic: memory, CPU, file systems, interfaces, processes, systemd units and so on. The server pulls it, so it is a pull model. In modern versions an agent controller (cmk-agent-ctl) wraps the script, registers the host with the site and serves the output over TLS. The server then parses the sections and creates services. This is the core idea of Checkmk: service discovery. You add a host, Checkmk runs the agent, finds every file system, interface and known application, and proposes services. You accept them in bulk.

Configuration is rule-based. Instead of editing each host, you write rules such as “for all hosts in folder Plant 2 with tag ’erp’, warn at 85 percent disk and go critical at 92 percent”. Rules match on folders, host tags and labels, and the most specific rule wins. Once a team understands this, it scales well. Before that, it can feel like magic.

For SNMP devices, Checkmk ships many check plugins that recognise vendor MIBs. Network discovery and automatic host creation exist, though some automation (for example automatic agent updates and the Agent Bakery that builds per-host agent packages) is in the paid editions.

Checkmk 2.5, released in April 2026, added a reworked user interface with global search, rebuilt dashboards, OpenTelemetry and Prometheus scraping (in the Cloud and Ultimate editions), better Azure, Proxmox, Hyper-V and Podman monitoring, Checkmk Relay for remote networks (Cloud and Ultimate), and an “Explain with AI” button (Cloud). Read the edition list for each feature before you plan around it.

A rule in Checkmk is usually created in the UI, but the idea fits in a few lines:

Rule: Filesystems (used space and growth)
Condition: folder = /plant2, host tag "Criticality" = "Business critical"
Value: levels warn 85 %, crit 92 %; magic factor off

Netdata

Netdata started in 2013 as a personal project by Costa Tsaousis to see what a Linux server was doing every second, and grew into a company with a large open source agent. It takes a very different view from the other two.

• Every agent is a full monitoring system. It collects metrics, stores them in its own time-series engine on local disk, evaluates alerts, runs machine learning models for anomaly detection and serves an API and dashboard. There is no central database needed.
• Per-second collection by default. Many collectors run every second. The storage engine keeps several tiers: high resolution for a short time, then lower resolution for longer.
• Auto-detection. On start, the agent finds the operating system metrics, containers, and many applications (databases, web servers, queues) and starts collecting without configuration. More than a thousand integrations are listed by Netdata.
• Parents and children. An agent can stream its metrics to a parent agent, which stores them for many children. Parents can be chained and paired for high availability. This gives you a central place to look and lets small machines keep very little data locally.
• Netdata Cloud. A closed service that connects to agents and parents for login, role-based access, a combined view of all nodes and alert routing, without storing the metrics centrally; the metrics stay on your agents.
• SNMP and Nagios checks. The Go collector framework has an SNMP collector with device profiles, and a “virtual node” concept so that a switch appears as its own node. Release 2.10.0 (April 2026) added a collector that runs Nagios-compatible plugins.

The catch is the user interface. Since the v2 era, the dashboard you see when you open an agent is the Netdata UI, which is closed source under NCUL1. That licence allows you to use the UI only with Netdata’s own agent and Cloud, and forbids reverse engineering or modification. You can still query the agent API, export metrics to Prometheus or other systems, and use Grafana. But if “fully open source stack” is a hard requirement in your company, the default Netdata dashboard does not meet it.

A child streaming to a parent needs only a few lines:

# stream.conf on the child (example)
[stream]
    enabled = yes
    destination = netdata-parent.plant1.example.internal:19999
    api key = 11111111-2222-3333-4444-555555555555

Prometheus with Grafana, Icinga, Nagios and LibreNMS, briefly

• Prometheus with Grafana: pull-based metrics from exporters, PromQL, Alertmanager and Grafana dashboards. Excellent for Kubernetes and for teams who think in labels and queries. For SNMP you run the SNMP exporter and generate modules from MIBs, which works but takes more effort than a ready template. Long-term storage is a separate question, covered in our Thanos, Mimir and VictoriaMetrics post.
• Icinga: started in 2009 as a fork of Nagios and later rewritten as Icinga 2, with its own configuration language, a REST API, distributed zones and a modern web interface. Good if you like the Nagios plugin model and want something actively developed.
• Nagios Core: the classic. Many plugins still come from its world, and all three tools in this post can run Nagios-style checks in some form. If your Nagios works and is understood, there is no shame in keeping it, but the configuration grows by hand.
• LibreNMS: a community fork of Observium focused on network devices, with strong SNMP auto-discovery, port and traffic graphs and a long device support list. Very good for a network team; weaker as a general server monitoring tool.

Side by side

Licence and governance

• Zabbix: AGPLv3 from 7.0, owned and developed by Zabbix SIA. All features are in the open source product; the company sells support, training and consulting. AGPL matters only if you modify Zabbix and offer it to others over a network; using it internally, unmodified, is the normal case.
• Checkmk: Community edition GPLv2. Pro, Ultimate, Ultimate with Multi-Tenancy and Cloud are commercial, owned by Checkmk GmbH. The difference between free and paid is not only support; real features are paid-only.
• Netdata: agent GPLv3 or later. Dashboard UI closed (NCUL1). Netdata Cloud closed, with free and paid plans that have changed more than once in the last two years, so read the current plan page before you depend on a limit.

Data collection model

• Zabbix: both pull (passive agent, SNMP polling) and push (active agent, trapper items, Zabbix sender). You choose per item.
• Checkmk: pull. The site fetches agent output or polls SNMP at an interval, by default once a minute. Results from other sources can be pushed in through spool files or passive checks.
• Netdata: the agent collects locally (pull from the system and applications) and streams to parents (push). Per-second by default.

Database and storage

• Zabbix: a relational database (MySQL or MariaDB, PostgreSQL, with TimescaleDB as a common choice). The database size and write speed set your limits. Housekeeping old history is a real job.
• Checkmk: no external database. State lives in the core; metrics in round robin files on disk, one per metric, with fixed size. Simple to back up, predictable in size, but less flexible for ad hoc queries.
• Netdata: its own tiered storage engine on each agent or parent. Disk is set per tier. No external database, but you size parents carefully.

Templates, discovery and SNMP

• Zabbix: templates are the main unit of reuse, with low-level discovery for interfaces, file systems and more. Network discovery and agent auto-registration add hosts automatically. Very strong SNMP and SNMP trap support; official templates for many network vendors.
• Checkmk: service discovery is the core experience. Add a host and accept discovered services. Strong SNMP checks for many vendors. Rules, folders and tags replace templates.
• Netdata: auto-detection on hosts is excellent. SNMP collector with profiles and virtual nodes; good for common devices, younger for unusual ones. No equivalent of large ready-made network topology views.

Alerting

• Zabbix: triggers with expressions, severities, dependencies (so a dead switch does not cause fifty host alerts), actions with escalation steps, and media types for email, webhooks and many chat tools. Maintenance windows suppress alerts.
• Checkmk: soft and hard states inherited from Nagios, parent-child host relationships, notification rules that route by host, service and contact group, bulk notifications, and scheduled downtimes.
• Netdata: hundreds of pre-configured alerts with sensible thresholds, plus anomaly rates from local machine learning. Notifications from the agent or, with more routing options, from Netdata Cloud. Recent releases added silencing rules and testing alert definitions against past data.

Dashboards

• Zabbix: built-in dashboards, graphs, maps and reports; Grafana through a well-known plugin.
• Checkmk: built-in views and dashboards, rebuilt in 2.5 with responsive layouts in the commercial editions; Grafana through an official plugin.
• Netdata: very rich, interactive charts out of the box (closed UI); Grafana or Prometheus through exporters if you need an open dashboard.

Remote sites

• Zabbix: proxies with a local buffer. Since 7.0 a proxy can buffer in memory, on disk or in a hybrid mode, and proxy groups can share and take over hosts.
• Checkmk: distributed monitoring with separate remote sites and a central site; in 2.5, Checkmk Relay in the Cloud and Ultimate editions for small segmented networks.
• Netdata: children stream to parents; a parent at each site can stream onward to a central parent.

Scaling and performance

All three vendors publish large numbers. Treat every number below as the vendor’s own description, not as a measurement of ours.

• Zabbix describes installations with tens of thousands of hosts and very high new values per second. In practice, the limit is the database: disk write speed, table partitioning or TimescaleDB, and how much history you keep. Proxies take polling load off the server.
• Checkmk says the Micro Core in the paid editions can run many more checks per second than Nagios Core with lower CPU use. On the Community edition with Nagios Core, very large single sites are harder; distributed sites are the answer.
• Netdata says the agent uses little CPU per node for per-second collection and that parents can take thousands of children. Machine learning adds some CPU on each agent; it can be turned off or moved to parents.

For a Coimbatore-sized estate of about 150 monitored devices, any of the three on one modest virtual machine is enough. Scaling is not the deciding factor at this size; operations and fit are.

Operations and upgrades

• Zabbix: packages for major Linux distributions from the Zabbix repository, and official container images. Major upgrades change the database schema automatically on first start of the new server, so take a database backup first and test on a copy. Agents are backward compatible within reason, so you can upgrade the server first. Configuration lives in the database; export templates and hosts to YAML and keep them in Git.
• Checkmk: install the new version package next to the old one, then run omd update on the site. The update path is strict: go to the latest patch of your version first, then to the latest patch of the next major, and do not skip a major. In 2.5 the package names changed, so update scripts must be fixed. Back up the whole site with omd backup. Configuration lives in plain files under the site, so it is easy to keep in Git.
• Netdata: install through the kickstart script, native packages or a static build, with automatic updates on by default in many methods; you can turn them off and pin a version. Configuration is in files under the Netdata config directory, small per node. The main work is keeping hundreds of agents consistent, which is a configuration management job.

Security

All three run an agent with access to system data on every host, and a central component that knows about your whole network. That makes them a target. Recent advisories show the kinds of things that go wrong.

Zabbix (from the Zabbix issue tracker):

• CVE-2026-59786 (CVSS 4.0 score 6.9): the server and proxy accepted the active agent heartbeat without checking the configured PSK or certificate, so someone with access to the trapper port could mark a host as available. Fixed in 7.0.29 and 7.4.13.
• CVE-2026-59783 (2.3): binary items could crash the server or proxy with certain input, only on MySQL or MariaDB. Fixed in 7.0.29 and 7.4.13.
• CVE-2026-23938 (2.1): an authenticated admin could crash the server or proxy with crafted JavaScript preprocessing. Fixed in 6.0.47, 7.0.27 and 7.4.11.
• CVE-2026-59781 (5.4): the Windows agent installer did not check permissions on custom install folders, which could allow DLL sideloading. Fixed in 6.0.48, 7.0.29 and 7.4.13.

Checkmk (from Checkmk Werks):

• CVE-2026-8833 (CVSS 4.0 score 8.5, Werk #20002): an XSS in URL handling in all editions. Fixed in 2.5.0p5, 2.4.0p31 and 2.3.0p48.
• CVE-2026-2859 (Werk #18994): the agent deploy endpoint revealed whether a host name existed. Fixed in 2.4.0p23 and 2.3.0p43.
• Werk #19262 (21 October 2026): the Checkmk Docker image was rebuilt with patched PHP for CVE-2026-109618 and CVE-2026-109619. Only Docker installations needed a new image; package installations get PHP fixes from the Linux distribution.

Netdata (from GitHub security advisories, published 2 September 2026, all fixed in v2.10.4):

• CVE-2026-83603 (high): local root through the ndsudo helper with a crafted socket path.
• CVE-2026-83602 (medium): an unauthenticated PUT to /api/v3/settings bypassed the IP allow list.
• CVE-2026-83599 (high): WebSocket decompression bomb.
• CVE-2026-83600 and CVE-2026-83601 (medium): streaming protocol bugs that could crash or corrupt a parent.
• CVE-2026-83597 and CVE-2026-83598 (high): local privilege escalation through the Windows installer repair path.
• Older ones worth remembering: CVE-2024-32019 (ndsudo untrusted search path) and CVE-2023-22496 and CVE-2023-22497 (streaming command injection and authentication bypass).

The pattern is clear. The helper that runs privileged commands, the port that accepts data from agents, the streaming link between nodes, and the web UI are where problems appear. Plan for them:

• Encrypt agent traffic (Zabbix PSK or certificates; Checkmk agent controller TLS registration; Netdata streaming over TLS with unique API keys).
• Do not expose the monitoring server, trapper ports, Livestatus or a Netdata agent dashboard to the internet. Netdata in particular listens on port 19999 by default; bind it to localhost or a management network on children.
• Keep system.run and remote commands disabled unless you really need them. Zabbix agents add DenyKey=system.run[*] by default; keep it that way.
• Treat the monitoring server like a domain controller: it has SNMP communities, database passwords and often SSH keys. SNMPv3 with authentication and privacy is worth the extra work for switches and firewalls.
• Subscribe to the advisory feed of whatever you choose and patch within days, not quarters.

When a spreadsheet and a few scripts are still fine

If you have five servers, one office, and one person who looks at them every day, a cron job that checks disk and emails you, plus a free external uptime check, may be honest enough. The moment you have more than one site, network devices you depend on, or a second person on call, you need a real tool. The cost of installing one is small compared with one bad month-end.

A worked plan for Coimbatore

Here is a plan the three-person team could follow over about six weeks. We pick Zabbix 7.0 LTS as the main tool for this scenario, because the estate is mixed with many SNMP devices, there are several sites, and the team wants every feature without a licence fee. We add Netdata on a few critical Linux hosts for per-second troubleshooting. We explain after the plan when Checkmk would be the better pick for the same company.

1. Inventory first (week 1). List every host and device with its IP, site, owner, criticality and how it can be monitored (agent, SNMP v2c or v3, web only). Put it in a Git repository as a CSV file. This list is the most valuable output of the whole project, whatever tool you pick.
2. Decide what an alert is (week 1). Agree on three severities: page now (ERP down, UPS on battery, core switch down, disk above 95 percent on database servers), fix today (disk above 85 percent, backup failed, interface errors), and look weekly (everything else, shown on a dashboard, never emailed). Write it on one page and get the manager to sign it.
3. Build the server (week 2). One Linux virtual machine at the main factory for the Zabbix server and frontend, with PostgreSQL on the same machine for now and TimescaleDB if the team is comfortable. Give it fast disks and a separate disk for the database. Keep history for 14 days and trends for 400 days to meet the one-year capacity goal. Use the official Zabbix 7.0 packages, not the old version in the distribution repository.
4. Proxies at remote sites (week 2). A small proxy at the assembly unit and the warehouse, and one in the cloud network for the dealer portal machines, each with a local buffer so data survives VPN drops. Agents and devices at a site talk only to their proxy.
5. Agents with configuration management (week 3). Install Zabbix agent 2 on all servers using Ansible (or whatever tool the team already uses), in active mode, with PSK encryption, a unique host name and HostMetadata such as “linux plant2 erp”. Configure auto-registration actions so new hosts land in the right host groups with the right templates.
6. Network devices (week 3). Create SNMPv3 users on switches and firewalls where supported; use v2c with a non-default community and an access list only where a device cannot do v3. Use network discovery rules per site subnet to find devices, and link the official vendor templates. Add UPS units with the UPS template and set a trigger for “on battery” as page-now.
7. Dependencies (week 4). Set trigger dependencies so that when a site VPN router is down, the hosts behind it do not each raise an alert. This one step removes most of the noise in a multi-site setup.
8. Netdata on a few hosts (week 4). Install the Netdata agent on the PostgreSQL server and the file server, bound to localhost or the management network, with alerts sent only to the system administrator. Use it when Zabbix says “something is wrong” and you need second-by-second detail. Decide consciously whether to use Netdata Cloud; it is not needed for this role.
9. Alerts to people (week 5). Email for fix-today, and a messaging app webhook for page-now, with escalation to the manager if not acknowledged in 30 minutes. Maintenance windows for planned work and the monthly patch night.
10. Dashboards for people who are not in IT (week 5). One screen for the owner: ERP up, internet links up, UPS state, disk trend on the file server. Keep it small.
11. Backups and upgrades (week 6). Daily PostgreSQL dump of the Zabbix database to the backup server, weekly YAML export of templates and host configuration into Git, and a written upgrade note. Plan to move to Zabbix 8.0 LTS only after its first few patch releases, tested on a copy of the database.
12. Retire Nagios (week 6). Run both in parallel for two weeks, compare, then switch off the old one. Do not keep two sources of truth.

If the team was more comfortable with the Checkmk way, the plan changes only in its middle: one Checkmk Community site with distributed sites at the plant and warehouse, agents installed by Ansible and registered with TLS, folders per site, host tags for criticality, and rules for thresholds. Service discovery would find most of what Zabbix templates find, with less clicking. The team would miss the Agent Bakery and the Micro Core, and would need to decide whether to buy Pro later.

When each is better

• Zabbix is better when you have many SNMP devices and several sites, when you want every feature without paying, when you want fine control over what is collected and when, and when your team is happy to run a database and learn templates and triggers properly. It is also a common choice in Indian system integrators and data centres, so hiring help is easier.
• Checkmk is better when you want quick discovery and a rule-based model that keeps hundreds of hosts consistent, when you like the Nagios plugin world but want a modern product, and when you are open to paying for the Pro edition later for the bakery, faster core and support. Its documentation is also very thorough.
• Netdata is better when most of your estate is Linux servers and containers, when you want per-second detail and good default alerts within minutes, when you want troubleshooting more than long reports, and when you are comfortable with a closed dashboard UI or plan to use your own (Grafana) on top.

When not to adopt each

• Not Zabbix if nobody in the team wants to look after a database, or if you expect “install and it just knows”. Out-of-the-box Zabbix is powerful but needs design: template choice, intervals, history settings and trigger tuning.
• Not Checkmk Community if you need features that are paid-only and have no budget, or if your estate is so large that a single Nagios Core based site will struggle and you do not want distributed sites. Also be careful if scripts or Docker images assume the old cre names; 2.5 breaks them.
• Not Netdata as your only tool if your company requires a fully open source stack, if most of your monitoring is SNMP network gear, or if you need structured reports such as monthly availability per service for management. Also not if you cannot control agent ports; a public Netdata dashboard on a server is a real risk.

A short history

• Nagios began in 1999 as NetSaint, written by Ethan Galstad, and was renamed Nagios in 2002. It shaped the vocabulary of monitoring: hosts, services, checks, soft and hard states, and plugins that return OK, WARNING, CRITICAL or UNKNOWN.
• Zabbix was started by Alexei Vladishev as an internal project in the late 1990s, released publicly in 2001, and reached 1.0 in 2004. Zabbix SIA, based in Riga, Latvia, was founded to develop it. Long-term support releases arrived with 2.0 and the policy of an LTS every one and a half years settled over time. Native server high availability came in 6.0, proxy groups in 7.0, and the move from GPLv2 to AGPLv3 also in 7.0.
• Check_MK was started by Mathias Kettner around 2008 as a Nagios add-on with one agent call per host and automatic service discovery. It became a complete distribution with its own core, and the company later became tribe29 and then Checkmk GmbH, in Munich. In 2026 it renamed its editions, and Checkmk Raw became Checkmk Community.
• Netdata started on GitHub in June 2013 as Costa Tsaousis’s per-second monitoring project, became a company, added Netdata Cloud, parents and children, machine learning and a tiered database, and moved the main dashboard to a closed UI licence while keeping the agent open.

Decision guide

Start with your estate

• Mostly Linux and containers, one or two sites: try Netdata first, then add more if needed.
• Mixed servers and a lot of network gear, several sites: shortlist Zabbix and Checkmk.
• Mostly network devices and a network team: also look at LibreNMS.
• Mostly Kubernetes: start with Prometheus and Grafana, and read our long-term storage post.

Then look at your team

• Comfortable with databases and detailed configuration: Zabbix.
• Prefer discovery and rules, and like file-based configuration in Git: Checkmk.
• Want results quickly and troubleshoot more than report: Netdata.

Then check licence and money

• Need every feature free, open source: Zabbix (AGPLv3).
• Free now, paid later for convenience and support: Checkmk Community then Pro.
• Open agent, closed UI and cloud acceptable: Netdata.

Checklist

1. Inventory every host and device with site, owner, criticality and monitoring method.
2. Write a one-page alert policy with three severities.
3. Pick a supported version: Zabbix 7.0 LTS (7.0.32 or later), Checkmk 2.5 (2.5.0p17 or later), Netdata 2.12.x.
4. Size disk for history and trends, and decide retention before you start.
5. Put proxies, remote sites or parents at every site with an unreliable link.
6. Install agents through configuration management, never by hand on each host.
7. Encrypt agent traffic and use unique keys or certificates per host.
8. Use SNMPv3 where devices support it; restrict SNMP by access list.
9. Keep remote commands disabled unless there is a written reason.
10. Set dependencies so a site link failure gives one alert, not fifty.
11. Use maintenance windows or downtimes for planned work.
12. Send page-now alerts to a channel people actually read at night.
13. Back up the monitoring database or site daily, and keep configuration in Git.
14. Subscribe to the vendor’s security advisories and patch quickly.
15. Review noisy alerts every month and delete or tune them.
16. Write an upgrade note and test upgrades on a copy before production.

Common mistakes

• Adding everything, alerting on everything. Default templates and default alerts are a starting point. Without tuning, people start ignoring email from the monitoring server within weeks.
• No dependencies. One VPN drop produces dozens of “host unreachable” alerts and hides the real cause.
• SNMP with “public”. Default communities on switches and UPS cards are still common. They are readable by anyone on the network and sometimes writable.
• Monitoring server on the same hypervisor it monitors, with no external check. When that host goes down, the monitor goes with it and nobody is told. Add one external uptime check for the monitoring server itself.
• Keeping raw history forever. In Zabbix this fills the database; keep raw history short and trends long.
• Exposing dashboards. A Netdata agent on port 19999 or a Zabbix frontend reachable from the internet is an invitation.
• Skipping versions. Checkmk does not allow skipping a major version, and jumping several Zabbix majors at once makes the database upgrade risky.
• One person owns everything. If only one engineer knows how the templates or rules work, the tool will decay when that person leaves.

The drill we ran

We kept the drill small and safe on a shared test machine: normal user only, no sudo, no system services, no ports opened, and nothing installed under system folders. We did not run any monitoring server.

What we did:

• Checkmk Linux agent 2.5.0p17. We downloaded the agent script from the v2.5.0p17 tag on GitHub (about 78 KB, with a GPLv2 header) and ran it once as a normal user, with its configuration, data, plugin and log folders pointed at a scratch folder. It finished in about a third of a second and printed 724 lines in 21 sections, including check_mk (version, OS), df_v2, mounts, ps_lnx, mem, cpu, uptime, lnx_if, tcp_conn_stats, diskstat, kernel and systemd_units. Nothing went to standard error. This made the Checkmk model very concrete: the agent is a script that prints text, and all the intelligence is on the server side, which turns those sections into services through discovery. We did not try the agent controller or TLS registration, which need a site.
• Zabbix 7.0.32 configuration files. We downloaded the source tarball from the Zabbix CDN and read only the sample configuration files. Three things stood out. The agent sample adds DenyKey=system.run[*] by default, so remote commands are off unless you allow them. Agent encryption defaults to unencrypted on both sides (TLSConnect and TLSAccept), so encryption is your job. And the proxy sample file, while documenting the default buffer mode as disk, actually sets ProxyBufferMode=hybrid with ProxyMemoryBufferSize=16M uncommented, so a proxy built from the sample file buffers in memory first and falls back to disk. Check which file your packages ship before you size proxy disks. The server sample also shows small default caches (for example CacheSize 32M and HistoryCacheSize 16M) and HANodeName empty, which means standalone mode.
• Netdata 2.12.2 SNMP collector configuration. We read the snmp.conf sample from the v2.12.2 tag. All jobs are commented examples, with SNMP v2c and an example community, and options to attach a device to a virtual node so that a switch appears as its own node.

What we did not run: a Zabbix server, proxy or agent; any database; a Checkmk site (which needs system packages and root); the Checkmk agent controller; a Netdata agent (its normal installers need system paths and a service); SNMP polling against real devices; and any performance test. All drill processes were stopped and a process check showed nothing left running.

Unlearn, re-learn

• Unlearn “monitoring is installing a tool”. Re-learn that monitoring is an inventory, an alert policy and an owner, and the tool comes after.
• Unlearn “more alerts mean more safety”. Re-learn that an alert nobody acts on is noise, and noise hides the real failure.
• Unlearn “open source agent means open source product”. Re-learn to read the licence of the server, the UI and the cloud part separately.
• Unlearn “Raw edition” and “cre”. Re-learn the new Checkmk names, and fix your scripts before the 2.5 upgrade.
• Unlearn “the agent is safe because it is inside”. Re-learn that agents, helpers and streaming ports have had real CVEs this year, and encrypt and patch them like any server.
• Unlearn “one minute is always enough” or “one second is always better”. Re-learn to choose resolution per question: per second for troubleshooting, per minute for alerting, hourly trends for capacity.

Sources

Zabbix:

• Download sources (7.0.32, 7.4.16, 6.0.49, 8.0.0rc3): https://www.zabbix.com/download_sources
• Release notes: https://www.zabbix.com/release_notes
• Roadmap: https://www.zabbix.com/roadmap
• Life cycle and release policy: https://www.zabbix.com/life_cycle_and_release_policy
• Licence: https://www.zabbix.com/license
• Zabbix 7.0 to be released under AGPLv3: https://blog.zabbix.com/striking-the-right-balance-zabbix-7-0-to-be-released-under-agplv3-license/27596/
• Security advisories: https://www.zabbix.com/security_advisories , https://support.zabbix.com/browse/ZBX-28196 , https://support.zabbix.com/browse/ZBX-28194 , https://support.zabbix.com/browse/ZBX-28075 , https://support.zabbix.com/browse/ZBX-28077

Checkmk:

• Checkmk 2.5 is out (forum): https://forum.checkmk.com/t/checkmk-2-5-is-out/58949
• Checkmk versions and life cycle: https://docs.checkmk.com/latest/en/cmk_versions.html
• Update to version 2.5.0: https://docs.checkmk.com/latest/en/update_major.html
• Werk #19391, edition renaming: https://checkmk.com/werk/19391
• Meet the new Checkmk lineup: https://checkmk.com/blog/meet-new-checkmk-lineup
• Checkmk source on GitHub (GPLv2): https://github.com/Checkmk/checkmk
• Werks #20002, #18994 and #19262: https://checkmk.com/werk/20002 , https://checkmk.com/werk/18994 , https://checkmk.com/werk/19262

Netdata:

• Netdata repository and licence section: https://github.com/netdata/netdata
• Releases (v2.12.2, v2.12.0, v2.10.0): https://github.com/netdata/netdata/releases
• Netdata Cloud UI License (NCUL1): https://app.netdata.cloud/LICENSE.txt
• Security advisories: https://github.com/netdata/netdata/security/advisories

Related posts on Revisit.Tech: Prometheus long-term storage, uptime monitoring, log storage, distributed tracing, log pipelines, time-series databases, configuration management.