Architecture and Deployment Planning

Horizon is a unified platform for ingesting, correlating, and acting on network monitoring data. This section describes the architecture at a conceptual level: what a deployment consists of, which components are optional, and what each component is for. It does not replace the installation instructions in the rest of the Deployment section; it provides context for deciding which components you need.

Data domains

Horizon ingests several kinds of network data and correlates them around a shared inventory:

  • Inventory: The nodes, interfaces, and services you monitor, populated through provisioning.

  • Events and alarms: State changes, faults, and messages from the network and from Horizon itself.

  • Performance metrics: Numeric time series gathered by collectors and pollers, or pushed to Horizon through streaming telemetry.

  • Flows: Traffic summaries (NetFlow, IPFIX, sFlow) exported by network devices.

  • Topology: Layer 2 and layer 3 relationships discovered from the network.

Each kind of data arrives through its own ingestion path, but all of them attach to the same inventory. An alarm, a graph, a flow record, and a topology map can therefore refer to the same node. Data Domains and Processing describes these paths in more detail.

One core, optional components

Every deployment is built around a single core instance and a PostgreSQL database. The core runs the ingestion, correlation, and web components; PostgreSQL holds inventory, events, alarms, and most other state. In many environments, these two components are the entire deployment, and can even co-locate on the same system.

Two optional Horizon components distribute work beyond the core, and each addresses a specific problem:

  • Minion: Minions extend the core’s reach into networks it cannot address directly, such as remote sites, overlapping address space, or networks behind firewalls.

  • Sentinel: Sentinels process and persist high-volume push data (flows and streaming telemetry) in place of the core.

Third-party components can take over storage and transport roles as a deployment grows:

  • Time series storage: By default, the core writes performance metrics as RRD files on its local disk. Through a pluggable time series layer, alternative time series backends fit deployment scenarios where metric volume outgrows the local disk.

  • Search and analytics storage: An Elasticsearch or OpenSearch cluster stores flows, and can also store historical events and alarms.

  • Message broker: The core includes an embedded ActiveMQ broker for communication with distributed components. An external broker (typically Apache Kafka) replaces it as a deployment grows, and can also serve as an integration point for other systems.

Horizon does not provide clustering of the core itself. A deployment scales by giving the core a larger host, by adding Minions and Sentinels around it, and by moving storage onto dedicated systems. Deployment Scenarios discusses the practical limits.

Horizon in an Operational Support System (OSS) stack

Horizon provides the ingestion, inventory, and fault management layers of an OSS stack, and offers several paths for passing data to other tools:

  • REST APIs expose inventory, measurements, events, alarms, and flows.

  • The Kafka Producer streams events, alarms, metrics, and topology to Kafka for downstream consumers, and enriched flows can be forwarded to Kafka as well.

  • The Prometheus RemoteWrite plugin persists time series data to a Prometheus remote-write compatible store (such as VictoriaMetrics, Mimir, or Cortex), where other tools in the stack can query it.

  • The OpenNMS Plugin for Grafana supports building dashboards in Grafana, outside the Horizon UI.

  • Built-in notifications (email, SMS, chat, and webhooks) and ticketing integrations push alarms and events to people and workflow systems such as Jira or ServiceNow.

A complete stack often pairs Horizon with a visualization tool such as Grafana and an external ticketing or notification system fed from alarms or events. Many other combinations fit different usage scenarios; Deployments in Practice describes some of them.

In this section