The hierarchical cluster architecture was originally introduced to allow multiple ntopng instances to be organized in a parent/child topology. Child instances collected and analyzed local traffic, while parent instances aggregated information from multiple children to provide a centralized view of the network.
At the time, this approach addressed a common requirement: monitoring geographically distributed sites while maintaining a central point of visibility. However, networking environments and the ntop ecosystem have both evolved considerably since then.
Building a distributed deployment with nProbe and ntopng
Today, the same use cases can be addressed without requiring ntopng instances to communicate with each other through a hierarchical architecture. Instead of forwarding aggregated information between ntopng instances, nProbe can export the same flow stream to multiple destinations simultaneously. This allows organizations to deploy:
- a local ntopng instance at each site, providing operators with immediate visibility into local traffic
- one or more centralized ntopng instances, receiving exactly the same flow data for enterprise-wide analysis and long-term monitoring
This approach offers several advantages:
- each ntopng instance operates independently
- there is no hierarchy to configure or maintain
- failures in one instance do not impact the others
- deployments are simpler, more resilient, and easier to scale
In practice, every ntopng receives the original flow data directly from nProbe, eliminating the need for intermediate aggregation layers.
For example, nProbe can publish flows using a ZMQ endpoint:
# nprobe -i eth0 --zmq "tcp://*:5556"Packet capture from a mirror has been used in the example above, however the same applies to Netflow collection.
The local and centralized ntopng instances can then connect to the same ZMQ flow stream:
local# ntopng -i "tcp://10.0.10.10:5556"centralized# ntopng -i "tcp://10.0.10.10:5556"Additional ntopng instances can subscribe to the same endpoint as required. Each instance processes the received flows independently and maintains its own state.
When required by the network topology and deployment, replication can also be implemented at the Netflow level. For example when you migrate to nProbe but you need to keep running your legacy monitoring system, you need to collect flows and send them to multiple NetFlow collectors. nProbe provides a solution also for this thanks to the nfFanout companion tool. This application allows you to collect sFlow/NetFlow/IPFIX and send them to multiple collectors simultaneously.
Suppose you need to collect flows on port 2055 and send them to two collectors 192.168.0.1:1234 and 192.168.0.2:1234, all you need to do is to run the command below:
# nfFanout -c 2055 -a 192.168.0.1:1234 -a 192.168.0.2:1234And you can use nProbe to collect NetFlow on a remote location:
# nprobe -i none -n none --collector-port 2055 --zmq "tcp://*:5556"Monitoring multiple ntopng instances with the Infrastructure Dashboard
One of the original motivations for hierarchical clusters was obtaining a centralized overview of multiple monitoring installations. Today, this requirement is fulfilled by the ntopng Infrastructure Dashboard.
The Infrastructure Dashboard allows administrators to monitor multiple ntopng instances from a single interface, providing an overall view of the monitoring infrastructure, including:
- monitored instances
- traffic volumes
- system health
- resource utilization
- operational status
Rather than aggregating traffic data through a hierarchy, the dashboard aggregates operational information, giving administrators a clear picture of the entire monitoring deployment while allowing each ntopng instance to remain autonomous.
This model is simpler and better aligned with modern distributed deployments.
Since hierarchical clustering is no longer the recommended architecture, keeping obsolete functionality in the codebase adds maintenance effort and complexity, and can create confusion for users evaluating deployment options, we have decided to remove the feature from ntopng.
The ntop ecosystem continues to evolve toward modular components that can be combined to build scalable monitoring infrastructures.