Infrastructure and network monitoring
Monitoring that tells you
the truth.
Most monitoring estates are not under-instrumented. They are full of alerts nobody trusts, hosts that stopped reporting without anyone noticing, and configuration that exists only inside a database. This is the work of fixing that — and of building estates that do not get there in the first place.
Alerts nobody reads
A problem list full of known-false entries is not coverage. It is a habit of ignoring the screen, and it will hold the day something real appears on it.
Silent gaps
A host renumbered, an interface never set, a registration that half-completed. The system reports healthy because nothing is asking whether it is actually watching.
Configuration with no history
Thresholds changed at 3am and never written down. No diff, no review, no way back. The monitoring becomes the only record of itself.
Services
Engagements range from a short audit to designing and building an estate end to end. Each of these is work that has been delivered, not a list of things that could in principle be offered.
Monitoring architecture and deployment
Design and build of a monitoring estate that fits what you actually operate. Zabbix, Prometheus, Grafana and LibreNMS, with SNMP and agent-based collection sized to the equipment rather than to a template's defaults.
- Collection method chosen per device class, not applied uniformly
- Retention and rollup sized so history stays affordable
- Proxy topology for remote sites and constrained links
High availability and resilience
Monitoring is the thing you need working during an incident. Clustered servers with automatic failover, replicated databases, and a floating address so collectors follow the active node instead of going dark with it.
- Native clustering with tested, documented failover
- Database replication with a deliberate promotion procedure
- Failover verified end to end, not assumed from configuration
Alert hygiene
A problem list nobody reads is worse than no monitoring, because it looks like coverage. Work here is unglamorous and high value: removing false positives, correlating alarms, and making severity mean something again.
- Audit of standing problems, with false positives traced to cause
- Trigger dependencies so one fault raises one alert
- Severity conventions that produce a real work queue
Monitoring as code
Configuration that exists only inside a database cannot be reviewed, diffed or rolled back. Templates and thresholds move into version control with a promotion path from a test instance into production.
- Templates under version control with idempotent import
- A test instance that cannot page anyone or overload production
- CI that gates changes before they reach a live server
Integration and custom tooling
Most monitoring problems are integration problems. Inventory that disagrees with reality, systems that hold the same truth differently, and gaps between tools that nobody owns.
- Reconciliation between inventory and what is actually monitored
- API automation for bulk operations and audits
- Webhook and notification pipelines built and tested properly
Operations centre displays
Wall displays and dashboards for people who need to read state from across a room, built on live data rather than screenshots, and degrading to something legible when a backend is unavailable.
- Dashboards driven by live APIs, not static exports
- Graceful degradation when a data source is down
- Kiosk deployment that survives reboots unattended
How the work is done
Verify before changing
The first deliverable on any engagement is usually a list of things that are not true: hosts reported as down that are running fine, checks configured against addresses that moved, alerts that cannot clear. Fixing those costs little and changes how much the rest of the system is trusted.
Make failure modes explicit
Every automated change is reversible, every destructive one asks first, and anything that could contact a real person during testing is disabled by default. Tooling that quietly does the wrong thing at scale is worse than tooling that refuses.
Test the thing you are relying on
A failover that has never been performed is a plan, not a capability. High availability work includes stopping the primary and watching what actually happens — including whether collectors follow, which is the part usually missed.
Leave it maintainable
Configuration in version control, runbooks written for someone who was not there, and a documented reason for each non-obvious decision. The measure of the work is whether it survives without the person who did it.
Coverage
Monitoring platforms
- Zabbix 6.x and 7.x
- Prometheus and Grafana
- LibreNMS
- ntopng
Network
- SNMP v2c and v3, MIB work, trap handling
- Carrier and service provider equipment
- Optical transport and access networks
- Multi-site routing and overlay tunnels
Infrastructure
- Proxmox VE, KVM and LXC
- PostgreSQL, TimescaleDB, MariaDB
- Linux systems and service hardening
- ZFS storage and backup verification
Delivery
- Infrastructure as code and CI pipelines
- Runbooks written for the person on call at 3am
- Handover documentation as a deliverable
- Open-source tooling where it is reusable
Open source
Tooling built during client and internal work, generalised and published under MIT. The write-ups include the failures, because those are the parts worth reading.
zabbix-ops
Operational tooling for Zabbix 7.x. Reconciles an inventory against what Zabbix is actually polling and reports the hosts it believes it is watching but is not.
Read the write-upgalaxy dashboard
A 3D monitoring console for Proxmox estates. Each node renders as a galaxy and each guest as a planet, driven entirely by live data.
Read the write-upStart a conversation
Describe what you are running and what is currently going wrong with it. A short exchange is usually enough to say whether there is useful work here, and roughly what it would take.