Checkmk network and infrastructure monitoring: review, pricing, and alternatives

Checkmk monitors hosts through two collection methods that can coexist in the same environment. The Checkmk agent — a lightweight daemon available for Linux, Windows, AIX, HP-UX, and Solaris — runs on the monitored host and sends structured metric data back to the Checkmk server using a proprietary TCP protocol. - Agent-based monitoring provides significantly deeper visibility than SNMP: on a Linux host, the agent exposes CPU per-core metrics, memory details, running process counts, file system usage per mount point, open TCP connections, scheduled job status, log file monitoring, and many more metrics that SNMP cannot surface. - The agentless path uses SNMP (v1, v2c, v3) for network devices and devices where agent installation is not possible, REST API polling for cloud services and modern devices with API access, and IPMI for hardware monitoring on servers with baseboard management controllers.

Checkmk's auto-discovery engine is the operational feature that distinguishes it most clearly from Nagios and older monitoring frameworks. When a host is added — either manually or through network discovery — Checkmk's discovery process connects to the host via agent or SNMP and enumerates every monitorable service. - On a Linux server running Apache, MySQL, and several cron jobs, discovery identifies each running process, each mount point with a filesystem, each network interface with traffic, each log file configured for monitoring, and each application service with available metrics — typically yielding 80 to 200 check items without any manual configuration. - On a Cisco switch, discovery finds every active interface and configures monitoring for throughput, errors, and operational state.

Checkmk's SNMP monitoring covers network devices from over 500 vendors, including Cisco IOS, Cisco NX-OS, Juniper Junos, Fortinet, Palo Alto, HP/Aruba, Ubiquiti, MikroTik, and many others. - For each supported device type, Checkmk ships check plugins that know the relevant OIDs for interfaces, CPU, memory, temperature, fan status, power supply state, spanning tree topology, BGP peer status, and other device-specific metrics. - Interface monitoring covers operational state, administrative state, traffic throughput (in/out bytes), error rates, discards, and duplex/speed mismatches — with pre-configured alert thresholds based on best-practice values that administrators can override.

Checkmk's cloud monitoring integrates with AWS, Microsoft Azure, and Google Cloud Platform through official API-based check plugins, without requiring agent installation on cloud instances. - The AWS integration polls CloudWatch metrics and AWS service APIs to monitor EC2 instance health, RDS database performance, ELB load balancer status, S3 bucket metrics, Lambda function invocation counts and error rates, ECS container service health, Auto Scaling group states, and cost-related CloudWatch metrics. - GCP monitoring covers Compute Engine instances, Cloud SQL, Cloud Functions, Kubernetes Engine, and Cloud Storage.

Checkmk's container and Kubernetes monitoring covers Docker hosts, Docker containers, and Kubernetes clusters from both the infrastructure level and the application level. For Docker, Checkmk monitors container health, resource consumption per container (CPU, memory), container status transitions, image pull events, and Docker daemon metrics on the host. - Kubernetes monitoring works through both the Kubernetes API server (agentless) and through the Checkmk agent deployed as a DaemonSet for deeper per-node metrics. - This approach is meaningful for teams running mixed environments where container workloads coexist with traditional servers and network devices — all visibility lives in the same Checkmk interface rather than requiring a separate container monitoring tool.

Checkmk's distributed monitoring architecture allows a central Checkmk site to aggregate and display results from multiple remote monitoring sites, each running its own Checkmk server. In this architecture, remote sites monitor the devices and hosts in their local network segment and push results to the central site, which provides a unified view across all locations. - This is operationally important for organizations with geographically distributed infrastructure: branch offices, data centers in multiple regions, or multi-tenant MSP environments where each customer has a dedicated monitoring scope. - Remote sites can operate independently — continuing to monitor and alert even if connectivity to the central site is interrupted — and synchronize state when the link is restored. - The Enterprise Edition's sub-instance feature extends this to MSP-specific multi-tenancy, where each customer's monitoring environment is isolated while the MSP views all customers centrally.

Checkmk's alerting system is built around a flexible notification engine that routes alerts based on host group, service group, contact group, time period, alert severity, and custom rules. Alert conditions trigger through a state machine — OK, WARNING, CRITICAL, UNKNOWN — with configurable re-notification intervals and escalation paths. - The event console receives SNMP traps, syslog messages, and Windows Event Log entries from monitored devices and applies rule-based correlation to convert raw events into actionable monitoring alerts, reducing the noise of high-volume log and trap streams into a manageable alert queue. - Notifications are delivered via email, SMS, PagerDuty, OpsGenie, Slack, Microsoft Teams, Jira, and many other integrations through Checkmk's notification plugin system. - The acknowledged state system lets operators explicitly mark known issues, preventing repeated notification storms while the underlying problem is being addressed.