How I Automated Network Monitoring for 65 Hosts in Under a Day

I have a confession: for years, I manually maintained Nagios configuration files. Every time I added a server, switched out a network device, or changed a monitoring check, I’d SSH into the monitoring server, edit a config file, test the syntax, reload the daemon, and hope I didn’t break anything. It worked, but it was tedious, error-prone, and didn’t scale.

Last month, I finally solved this problem the right way. I built an automation pipeline that lets me manage monitoring for 65 hosts from a single web interface, no config files, no manual reloads, no context switching. When I update a device in NetBox, my monitoring system updates itself automatically within 5-10 seconds.

Here’s how I did it, and why the “single source of truth” pattern changed everything.

The Problem: Configuration Drift at Scale

If you’ve ever managed Nagios or Naemon at scale, you know the pain. You maintain device inventories in spreadsheets or wikis. You maintain monitoring configs in CFG files. You maintain network documentation in yet another system. Every change requires updating multiple places, and those systems inevitably drift out of sync.

In my lab, which runs production-like infrastructure including a five-node Proxmox cluster, UniFi network, and a dozen service VMs. I was managing 51 physical devices and 10 virtual machines. Adding a new server meant:

• Creating entries in NetBox (my IPAM/DCIM system)
• Documenting it in MediaWiki
• SSHing to the Naemon server
• Editing /etc/naemon/conf.d/devices.cfg
• Running naemon -v /etc/naemon/naemon.cfg to verify syntax
• Running systemctl reload naemon
• Checking the Thruk web UI to confirm it appeared

That’s seven steps, three different systems, and about 10 minutes of work, for one device. Multiply that across dozens of devices, plus ongoing changes, and you’ve got a significant operational burden.

The Solution: Single Source of Truth

The breakthrough was recognizing that NetBox should be the only place I define what gets monitored. NetBox already knew about every device, its IP address, its role, its location. Why should I duplicate that information in Naemon config files?

I designed a system with four components:

1. NetBox custom fields , Six fields that control monitoring behavior
2. Webhook receiver , A lightweight Python HTTP server that listens for NetBox changes
3. Ansible automation , Queries NetBox API, renders Jinja2 templates, deploys to Naemon
4. Naemon reload , Automatically picks up the new configuration

The entire pipeline runs in 5-10 seconds. I check a box in NetBox’s web UI, click Save, and within seconds the host appears in my monitoring dashboard. No SSH, no config files, no manual intervention.

Architecture Deep Dive

Custom Fields in NetBox

I added six custom fields to NetBox’s device model:

• mon_enabled (boolean) , Simple on/off switch for monitoring
• mon_check_type (select) , Ping, SNMP, HTTP, HTTPS, or SSH
• mon_hostgroup (text) , Groups like network-devices, proxmox-nodes, linux-servers
• mon_criticality (select) , Critical, high, medium, or low
• mon_check_interval (integer) , How often to check, in minutes
• mon_parent (text) , Parent host for dependency mapping

These fields give me fine-grained control without leaving NetBox. Want to monitor a new switch via SNMP every 2 minutes? Set mon_enabled=true, mon_check_type=snmp, mon_check_interval=2. Done.

Webhook Receiver

NetBox supports outbound webhooks when objects are created, updated, or deleted. I configured a webhook to fire on device updates, sending a JSON payload to a Python HTTP server running on port 5679 on my n8n automation server.

The receiver is intentionally simple, about 50 lines of Python. It validates the webhook signature, logs the event, and triggers an Ansible playbook via SSH. The webhook fires immediately when I click Save in NetBox, so there’s no polling delay.

Ansible Playbook

The playbook does the heavy lifting:

1. Queries the NetBox API for all devices where mon_enabled=true
2. Extracts device name, IP, monitoring fields, and relationships
3. Renders a Jinja2 template that generates valid Naemon configuration syntax
4. Copies the generated config to /etc/naemon/conf.d/netbox-devices.cfg
5. Runs naemon -v to verify syntax (fails the playbook if invalid)
6. Reloads Naemon with systemctl reload naemon

The Jinja2 template handles all the Naemon-specific syntax, host definitions, service checks, hostgroups, dependencies. I never touch that file manually anymore. It’s 100% generated from NetBox data.

End-to-End Flow

Here’s what happens when I add a new device:

1. I create the device in NetBox, set mon_enabled=true, configure check type and interval
2. NetBox fires a webhook to the automation server
3. The webhook receiver receives the POST request
4. The receiver triggers Ansible via SSH
5. Ansible queries NetBox API, renders the template, deploys to Naemon
6. Naemon reloads and starts monitoring the new device
7. The device appears in Thruk (Naemon’s web UI) within 5-10 seconds

Total latency: 5-10 seconds. Total manual steps: one (saving the device in NetBox).

Results: 65 Hosts, 102 Services, Zero Manual Config

Today, I’m monitoring 65 hosts across eight hostgroups:

• Network devices , Core switch, UniFi access points, IoT devices
• Proxmox nodes , Five-node cluster running 10 production VMs
• Linux servers , NetBox, MediaWiki, Ansible, Naemon, Grafana, Vaultwarden, WordPress
• Virtual machines , Application and service VMs

I’ve defined 102 service checks, ping, SNMP uptime, HTTP endpoints, SSH connectivity, all managed through NetBox. When I decommission a device, I set mon_enabled=false and it disappears from monitoring automatically.

The system handles dependency mapping too. My core switch is marked as the parent for access points and downstream devices. If the switch goes down, Naemon doesn’t spam me with alerts for every dependent device, it knows the root cause.

Why This Matters for Enterprise IT

This isn’t just a lab exercise. The pattern scales to enterprise environments:

• Eliminates configuration drift. One source of truth means your monitoring always matches reality
• Reduces onboarding time , New devices are monitored automatically when they’re added to your CMDB
• Enables self-service , Network engineers can enable monitoring without involving the monitoring team
• Improves audit compliance , NetBox provides change history and audit trails for monitoring changes
• Supports infrastructure as code. The entire monitoring config is reproducible from API data

In enterprise IT, I’ve seen teams spend weeks migrating monitoring systems because the old configs were so brittle and undocumented. With this approach, you can regenerate your entire monitoring configuration from your CMDB in minutes.

Lessons Learned

Start with the data model. The custom fields in NetBox took several iterations to get right. I initially overengineered it with too many options, then simplified to the six fields that actually matter.

Webhooks beat polling. I briefly considered having Ansible poll NetBox every 5 minutes. Webhooks are far better, near-instant updates, no wasted API calls, cleaner logs.

Validate before deploying. The Ansible playbook runs naemon -v before reloading. This caught several template bugs during development that would have broken production monitoring.

Keep the receiver simple. The webhook receiver doesn’t do any business logic, it just triggers Ansible. This separation of concerns made debugging much easier.

Document the architecture. I created a detailed architecture diagram in my wiki. When something breaks at 2 AM, I don’t want to reverse-engineer the system from code.

What’s Next

Now that the pipeline is stable, I’m extending it:

• Auto-discovery , New devices detected on the network get added to NetBox automatically via UniFi integration
• Service checks from NetBox , Adding custom fields for HTTP endpoints and SNMP OIDs so I can define service checks, not just host checks
• Alert routing , Using NetBox contact assignments to route alerts to the right teams
• Metrics integration , Feeding Naemon data into Grafana dashboards for historical trending

The end goal is a fully automated observability stack where I define what to monitor in NetBox, and the system figures out how to monitor it.

Want to learn more about building automated infrastructure? Check out my other posts on network automation, observability, and infrastructure as code. Or reach out. I’m always happy to talk shop with fellow infrastructure engineers.