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

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

The Central enables users to view a summarized data of their probes and the entire network. When a user tries to access any detailed Probe level data in the Central server, the Central makes a request to the Probes, fetches the data and displays it. Click here to know more about the ports used by the Enterprise edition.

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.

• Inventory data: The list of discovered devices will be available in the Central, but an user cannot access the device snapshot page (Inventory → Devices and click on the device name) to view basic device information such as availability, response time, associated monitors and other device-specific data. This applies to devices of all categories.
• Diagnostic page: This page enables you to view and compare database tables, and identify any mismatch between the Central and a Probe. It will not be accessible.
• Root Cause Analysis: Root cause analysis enables users to visualize monitoring data of multiple metrics of the one or more devices in a single window for easier troubleshooting. This feature will be disabled.
• Network path analysis: This feature helps in analyzing the hop-by-hop patterns, identifying packet loss or latency throughout the path, and predicting any upcoming network outages. It will be disabled.
• Add-on specific widgets in the Dashboard: Widgets of add-ons like NFA and NCM will be disabled in the Central server's Dashboard.
• 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.