opHA Architecture

opHA Message Bus

Real-time, fault-tolerant, multi-tenant NMIS at any scale

opHA Message Bus is the next-generation architecture for distributed NMIS. It replaces scheduled syncs with a peer-to-peer message bus, so events, configuration, and health data flow between primaries, pollers, and mirrors in real time. The result is a monitoring platform that can scale from one site to thousands of pollers, isolate every tenant cleanly, and keep running through failures that would take older architectures down.

What You See On Day One

Every peer, every daemon, one screen

opHA-MB Home in a small lab deployment, showing two pollers and one mirror with peer health, streaming state, node counts, and per-daemon status
A two-poller, one-mirror lab. Each peer card shows peer type, heartbeat, streaming state, node count, ophad health, and the live status of every NMIS daemon (opchartsd, opeventsd, opconfigd, nmis9d, omkd, ophad).

The opHA-MB Home view is the operational heartbeat of the platform. From this single screen, an operator can see at a glance which pollers are streaming, which daemons are healthy on every peer, and how many nodes each peer is responsible for. There is no need to log into each server, run a status command, or wait for a scheduled sync to complete. The information is live, refreshed by the message bus itself.

Built For Production

From a lab to a globally distributed network

opHA-MB Home in a globally distributed production deployment, showing pollers in Chicago, San Francisco, Frankfurt, and other regions, each paired with a mirror in another region for failover, monitoring thousands of nodes per peer
A real production deployment running opHA Message Bus across multiple regions. Pollers in Chicago, San Francisco, and Frankfurt each have a paired mirror in a different region, monitoring thousands of nodes with real-time streaming and automated failover.

This is the same screen as the lab view, only the numbers and the geography are larger. Pollers carry 1,500 to 2,000 nodes apiece, mirrors track every change in real time from a different region, and every daemon is visible at a glance. When one of those numbers ticks the wrong way, the operator knows in seconds, not minutes.

The architecture is intentionally flat. Add another region, and you add another poller-mirror pair. The message bus handles the rest.

Distributed Service Monitoring

Up, degraded, down, across every site

Service status table aggregating across pollers, with KPI cards for Up, Degraded, and Down counts, and a table of services showing node, status, description, response time, and last run
Aggregated service-level view across an opHA Message Bus estate. KPI cards summarise the global state at a glance, while the table drills into individual checks across nodes and pollers.

opHA Message Bus carries service-level state, not just device-level state. SSL expiry checks, port checks, application stack checks, and any other service NMIS or opCharts is running, all stream into one consolidated view. Operators triage from a single table, click through to the source poller, and resolve faster.

For MSPs, Telcos, and ISPs

Real isolation, real visibility, real flexibility

opHA Message Bus is the architecture FirstWave recommends for any deployment with more than one customer behind it. Tenants are isolated at the data layer, not bolted on with filters, and the message bus is what makes that isolation work without forcing every customer onto the same physical server.

Tenant data stays separate

Each tenant's nodes, events, and configuration are isolated end-to-end. A poller can be dedicated to a single customer, shared with strict isolation, or run in a hybrid model. Operators see one consolidated view; customers only ever see their own.

Per-tenant scale, no per-tenant servers

Add a customer, add their pollers, point them at the message bus. There is no need to spin up a parallel NMIS stack per tenant unless you want one. Most MSPs do not.

Single billing surface, single ops surface

One platform to operate, one platform to bill against. Per-tenant counts roll up into the same management views that operators already use.

Capabilities

What the message bus brings to NMIS

Real-time event streaming

Events flow from pollers to primaries the moment they happen, not on the next scheduled sync. MTTR drops because operators see what is happening as it happens.

Zero event loss with replication

Messages are replicated across peers. A server failure does not lose the events that were in flight, and a recovering peer catches up automatically.

Automated primary failover

When a primary peer fails, redundant peers take over the primary role without operator intervention. Monitoring continues, dashboards keep updating, customers do not see downtime.

Horizontal and vertical scale

Add more pollers to cover new sites, or scale existing pollers vertically to carry more nodes. The message bus adapts to either.

Centralised poller configuration

Push poller configuration changes from the primary, not poller by poller. Onboarding new sites becomes a one-step operation.

Live daemon health

Every NMIS daemon on every peer (opchartsd, opeventsd, opconfigd, nmis9d, omkd, ophad) reports health to opHA-MB Home in real time.

Geographic distribution without bandwidth pain

Pollers monitor their local infrastructure. Only the resulting events and metrics travel over the WAN, not the raw polling traffic.

Mirrors for cross-region resilience

Every poller can be paired with a mirror in another region, giving each tenant a live, ready-to-promote replica without manual replication scripts.

NMIS Ecosystem

Drop it in, leave the rest alone

NMIS Core Platform

The message bus extends NMIS into a fully distributed, highly available architecture. Existing configuration, device models, and monitoring policies work unchanged.

opCharts Consolidated View

Dashboards, maps, and charts reflect data from every poller in real time, no more refresh delays or stale tiles.

opEvents Distributed Correlation

Events arrive at opEvents the instant they are generated, anywhere in the estate. Correlation, deduplication, and escalation work across the entire deployment.

All Commercial Modules

opConfig, opReports, opFlow, and opAddress all benefit from the same distributed fabric, with centralised configuration management from the primary.

Under The Hood

Technical Specifications

Architecture
Peer-to-peer message bus with primary, poller, and mirror peer types
Peer types
Primary (Main Primary, redundant primaries), Poller, Mirror
Sync model
Real-time message streaming, with replication across peers
Heartbeat
Continuous, surfaced on opHA-MB Home as "A few seconds ago" under healthy conditions
Daemons monitored per peer
opchartsd, opeventsd, opconfigd, nmis9d, omkd, ophad
Deployment models
Single-tenant, multi-tenant, or hybrid
Failover
Automated primary poller failover with zero event loss
Scaling
Horizontal (add pollers and mirrors) and vertical (scale existing peers)
Configuration
Centralised poller configuration management from the primary
Geographic distribution
Pollers and mirrors can be deployed in any region

Ready to run NMIS at message-bus scale?

Talk to our team about how opHA Message Bus can support your distributed, multi-tenant monitoring requirements. We will walk you through the lab view, the production view, and how the architecture fits your deployment.

opHA Message Bus is part of the opHA product family on the NMIS 9 platform.