OpManager Central-Probe Connectivity

OpManager enterprise edition follows a Central-Probe architecture that allows IT admins to monitor an entire distributed network from a single console.

Data transfer between a Probe and the Central

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.

Push

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:

  • Devices discovered
  • Details about alarms and events
  • Archived data

Pull

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.

Accessing device snapshot data

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 InventoryDevices 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.

Prerequisites

To ensure proper Probe-Central connectivity, the following must be configured:

  • The protocol used by the probe to communicate with the client device.
  • The port used by the device must be rightly mentioned in the probe.
  • If SSL Configuration is enabled the common name (CN) of the client must be mentioned rightly.
  • If it is self signed SSL, that certificate should be trusted/imported in respective browser.

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.)

Impacts of blocking communication ports in Probes

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.

Ensuring probe-central connectivity

The following is how the probe-central connectivity is ensured, to maintain a hassle-free monitoring experience.

  • The probe server will contact the central server in one-minute intervals, and the probe's last contacted time will be recorded by the central server.
  • If the last contacted time exceeds 2 minutes, i.e. if the probe server has not contacted the central server for more than 2 minutes, an alarm will be raised, and a mail will be sent from the central server.
  • Once the probe successfully contacts the central server, the alarm will be automatically cleared.

Impacted monitoring data

  • Inventory data: This allows you to view the list of devices discovered in the Probes, and gives in-depth device information including availability, response time, associated monitors, and other device specific data.
  • Diagnostic page: Enables you to view and compare database tables and identify any mismatch between the Central and a Probe.

Impacted features

  • Root cause analysis
  • Network path analysis
  • Add-on specific widgets in the dashboard.

Impacted scalability feature: Unified Console (from build version 126322)

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.

  • For existing users who have upgraded to version 126322, an option to enable the Unified Console feature is provided and the user can enable it based on their preferences.
  • For users who have downloaded and installed the latest version, the Unified Console option will be enabled by default.

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.

Important advisory

  • When establishing contact with the Central or a Probe server, ensure that the contact is made via the host name or FQDN provided in the SSL certificate.
  • If the connection is made via the host address, an error might occur, because usually the the host address, and the SSL certificate name do not match.
  • Click here to understand in detail about the practical consequences of host name mismatch.

 

Thank you for your feedback!

Was this content helpful?

We are sorry. Help us improve this page.

How can we improve this page?
Do you need assistance with this topic?
By clicking "Submit", you agree to processing of personal data according to the Privacy Policy.