OpManager enterprise edition follows a Central-Probe architecture that allows IT admins to monitor an entire distributed network from a single console.
The entire data communication between a Probe and Central takes place via the push-pull mechanism to ensure that the connectivity between the Central and Probe is robust.
The probes present in remote sites monitor the network and send (push) the data to the Central.
In turn, the Central collects the data from all the connected probes and offers a consolidated view of the geographically distributed networks that are monitored individually by the probes.
Usually, the following data is sent from the Probes to the Central:
Configuration changes done in the Central will be reflected in the Probes. Once a configuration change is made, say, adding a new device template, the Probes will fetch (pull) the configuration update.
During the Probe installation process, users have to specify the Central URL details in the installation shield to establish connection between the respective Probe and the Central.
The device snapshot page in OpManager presents data about availability, response time, associated monitors, and other relevant information particular to a monitored device. To access the device snapshot page, go to Inventory → Devices and click on the device name.
When users access the snapshot page of a device, the Central presents the data by fetching it from the respective Probe through an API request. Here, as the Central and Probe are in the same network and are capable of accessing the monitored information, the communication approach followed is bidirectional.
To ensure proper Probe-Central connectivity, the following must be configured:
Users can change the Probe name after installation from the Central UI. (If you are planning to scale your network, it is advisable to read the Scalability Recommendations to facilitate the scaling process.)
As discussed above, the Central receives only necessary information from the Probes to help the NOC team or key decision makers in an organization's headquarters gain a high level picture of network's health. Users can also view detailed data available in the Probes on the Central's UI.
When a user tries to access any detailed Probe level data in the Central server, the Central makes a request to the Probes, fethces the data and displays it.
For example, when a user tries to access a device snapshot page, the Central fetches the data from the Probe through an API request. To access Probe-level information from the Central server, the port at which the Central server establishes contact with the Probe should be open.
Blocking the ports in a Probe (or disabling the option to receive inbound requests from the Central) will impact certain capabilities, and restricts the user from accessing the following data, and features in the Central's UI.
The following is how the probe-central connectivity is ensured, to maintain a hassle-free monitoring experience.
There will be some limitations in using the Unified Console feature when the communication port in a Probe is blocked. To understand the impact on this feature, it is important to consider how this feature is provisioned to the users.
The Unified Console features provides a drop-down menu in the Central server, and enables users to select a Probe and perform Probe-level actions such as device discovery from the Central server's UI.
But, when the port that receives requests from the Central is blocked in a Probe, a user will not be able to perform any Probe-level action from the Central. The user can only select the 'All Probes' option and receive a summary of the monitoring data.
Thank you for your feedback!