User Guide Functional Overview Requirements Architecture System Installation NetEye Additional Components Installation Setup The neteye Command Director NetEye Self Monitoring Tornado Business Service Monitoring IT Operation Analytics - Telemetry Geo Maps NagVis Audit Log Shutdown Manager Reporting ntopng Visual Monitoring with Alyvix Elastic Stack IT Operations (Command Orchestrator) Asset Management Service Level Management Cyber Threat Intelligence - SATAYO NetEye Update & Upgrade How To NetEye Extension Packs Troubleshooting Security Policy Glossary
module icon Requirements
Requirements for a Node Cluster Requirements and Best Practices NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation
Functional Overview Requirements Architecture System Installation NetEye Additional Components Installation Setup The neteye Command Introduction to NetEye Monitoring Business Service Monitoring IT Operation Analytics Visualization Network Visibility Log Management & Security Orchestrated Datacenter Shutdown Application Performance Monitoring User Experience Service Management Service Level Management & Reporting Requirements for a Node Cluster Requirements and Best Practices NetEye Satellite Requirements TCP and UDP Ports Requirements Additional Software Installation Introduction Single Node Cluster NetEye Master Master-Satellite Architecture Underlying Operating System Acquiring NetEye ISO Image Installing ISO Image Single Nodes and Satellites Cluster Nodes Configuration of Tenants Satellite Nodes Only Nodes behind a Proxy Additional NetEye Components Single Node Cluster Node Satellites Nodes only Verify if a module is running correctly Accessing the New Module Cluster Satellite Security Identity and Access Management External Identity Providers Configure federated LDAP/AD Emergency Reset of Keycloak Configuration Advanced Configuration Authorization Resources Tuning Advanced Topics Basic Concepts & Usage Advanced Topics Monitoring Environment Templates Monitored Objects Import Monitored Objects Data Fields Deployment Icinga 2 Agents Configuration Baskets Dashboard Monitoring Status VMD Permissions Notifications Jobs API Configuring Icinga Monitoring Retention Policy NetEye Self Monitoring 3b Concepts Collecting Events Add a Filter Node WHERE Conditions Iterating over Event fields Retrieving Payload of an Event Extract Variables Create a Rule Tornado Actions Test your Configuration Export and Import Configuration Example Under the hood Development Retry Strategy Configuration Thread Pool Configuration API Reference Configure a new Business Process Create your first Business Process Node Importing Processes Operators The ITOA Module Configuring User Permissions Telegraf Metrics in NetEye Telegraf Configuration Telegraf on Monitored Hosts Visualizing Dashboards Customizing Performance Graph The NetEye Geo Map Visualizer Map Viewer Configuring Geo Maps NagVis 3b Audit Log 3b Overview Shutdown Manager user Shutdown Manager GUI Shutdown Commands Advanced Topics Overview User Role Management Cube Use Cases ntopng and NetEye Integration Permissions Retention Advanced Topics Overview User Roles Nodes Test Cases Dashboard Use Cases Overview Architecture Authorization Elasticsearch Overview Enabling El Proxy Sending custom logs to El Proxy Configuration files Commands Elasticsearch Templates and Retentions El Proxy DLQ Blockchain Verification Handling Blockchain Corruptions El Proxy Metrics El Proxy Security El Proxy REST Endpoints Agents Logstash Elastic APM Elastic RUM Log Manager - Deprecated Overview Authorization in the Command Orchestrator Module Configuring CLI Commands Executing Commands Overview Permissions Installation Single Tenancy Multitenancy Communication through a Satellite Asset collection methods Display asset information in monitoring host page Overview Customers Availability Event Adjustment Outages Resource Advanced Topics Introduction Getting Started SATAYO Items Settings Managed Service Mitre Attack Coverage Changelog Before you start Update Procedure Single Node Upgrade from 4.41 to 4.42 Cluster Upgrade from 4.41 to 4.42 Satellite Upgrade from 4.41 to 4.42 DPO machine Upgrade from 4.41 to 4.42 Create a mirror of the RPM repository Sprint Releases Feature Troubleshooting Tornado Networking Service Management - Incident Response IT Operation Analytics - Telemetry Identity Provider (IdP) Configuration Introduction to NEP Getting Started with NEPs Online Resources Obtaining NEP Insights Available Packages Advanced Topics Upgrade to NetEye 4.31 Setup Configure swappiness Restarting Stopped Services Enable stack traces in web UI How to access standard logs Director does not deploy when services assigned to a host have the same name How to enable/disable debug logging Activate Debug Logging for Tornado Modules/Services do not start Sync Rule fails when trying to recreate Icinga object How to disable InfluxDB query logging Managing an Elasticsearch Cluster with a Full Disk Some logs are not indexed in Elasticsearch Elasticsearch is not functioning properly Reporting: Error when opening a report Debugging Logstash file input filter Bugfix Policy Reporting Vulnerabilities Glossary 3b

Cluster Requirements and Best Practices

This section focuses mostly on best practices for a NetEye deployment in a cluster environment, since system requirements for each Cluster Node correspond to those for a Single Node.

These guidelines are subject to change and should not be considered as hard requirements, because they may vary significantly depending on the running services and logging level.

The design of a network infrastructure in which NetEye is involved should be carefully designed in order to take advantage all of its functionalities, especially in the case of a particularly complex setup, in which the experience of a NetEye specialist can prove useful. To get in touch with one of them, please contact us at info@wuerth-phoenix.net.

Cluster Networking Requirements

This section illustrates in details the requirements and their rationale for all networking involving a NetEye Cluster: inbound, outbound (“Corporate Network”), and among the nodes composing the cluster (called “intra-cluster communication” or “Private (Heartbeat) Network” in the remainder).

The remainder of this section is therefore rather conversational, to summarize the content, we point out a few good practices:

  • setting up a (NetEye) Cluster requires a dedicated network for intra-cluster communication, separated from the Corporate Network

  • intra-cluster communication should be allowed freely without limitations

  • Each NetEye Cluster node should have its own IP Address in the Private Network

Corporate Network

Configuring the NetEye Cluster and allowing communication between Cluster and Corporate Network impacts several parts of networking and requires to open a number of ports. Key concepts and points to focus on include:

Network Layer: Monitoring and Management Network

This network will be used by NetEye to collect monitoring and performance data, system logs and allow access to:

  • NetEye Web interface

  • Each node SSH interface

  • Any other running services

The bottom line for this network is that it must be able to access–and must be reached by–every system that needs to be monitored by NetEye.

Network Link

Although a single NIC will suffice, to allow service continuity in case of hardware malfunction we suggest that you plan for bonding of two network adapters in an active/standby (failover) configuration.

IP Addresses: Physical node

A dedicated IP address for each node. Each IP should be in the same network segment. This IP is used both for management tasks and active (from NetEye to devices) monitoring.

IP Addresses: Management (iDRAC)

A dedicated IP address for the management interface of each node.

Cluster Virtual IP Address

One IP address used by the clustered system to allow monitoring and management from the public network

Depending on the services enabled on the NetEye Cluster, a number of ports must be used for the communication flow with the Corporate Network.

In general, Satellite Nodes, while they are NetEye instances, do not need to respect all these requirements. Indeed, Satellite Nodes already communicate securely with the NetEye Master node using NATS/Tornado. Moreover, the purpose of Satellite Nodes is to monitor the infrastructure and collect data, therefore they only need to allow traffic for NATS (Master/Satellite communication), Icinga (monitoring), and Elastic (EBP and related services).

Private (Heartbeat) Network

Intra-cluster communication should be usually freely allowed. Key concepts and points to focus on include:

Network Layer: Internal Communication Network

This network will be used for internal communication between each NetEye service. NetEye cluster nodes should be able to talk to each other without restriction. For security reasons, you should not share this network with other systems.

Network Link

Although a single NIC will suffice, to allow service continuity in case of hardware malfunction we suggest that you plan for bonding of two network adapters in an active/standby (failover) configuration. Ensure inter-node, round-trip latency between each node is less than 300ms, with a target of 2ms as optimal, as stated in the RHEL Corosync documentation.”

IP Addresses

Internal services running on a NetEye Cluster with all modules installed require at least 30 IP Addresses. It is therefore strongly recommended to always configure a dedicated /24 network (e.g., 172.20.12.0/24) to avoid running out of available IPs and being forced to reconfigure the whole network if the cluster is expanded.”

Note

None of these IPs should be publicly exposed, because they are used only by services running on the NetEye cluster.

Blog Online Demo Training
Contact Us
© 2025, Wuerth Phoenix S.r.l.
VAT ID 01054690217
Privacy Cookies