How RealOpInsight Works

RealOpInsight allows to leverage the capabilities of existing monitoring systems in a unified and integrated framework enabling effective operations management. Compatible with Nagios, Zenoss, Zabbix, Pandora FMS, Icinga, Shinken, Centreon, GroundWork, op5, to name a few, it can also be easily extended to support most of existing monitoring systems. In addition to its wide range of interoperability, RealOpInsight has been designed to make its integration easy, even in distributed and large monitoring environments.

This document introduces the set of supported monitoring systems (also called monitoring sources in RealOpInsight terminology), and describes how RealOpInsight interacts with each of them.

The Supported Monitoring Sources

A monitoring source, or simply source, defines a monitoring system from where RealOpInsight can retrieve status data in order to update the statuses of the business views it manages.

RealOpInsight currently supports more than a dozen of monitors listed in the following section. Here is an alphabetical list of monitors currently supported by RealOpInsight.

Monitor Versions Tested Comments
Centreon >= 3.x Requires MK Livetstaus
Check_MK >= 1.1.0 Requires MK Livetstaus
ManageEngine OpManager Any version having the REST API SDK RealOpInsight v3.3.0 or higher
Pandora FMS >= 4.0.2 RealOpInsight v3.2.0 or higher
Icinga >= 1.x Requires MK Livetstaus
GroundWork >= 5.0 Requires MKLivetstaus
Nagios >= 3.0.0 Requires Livestatus (>= 1.2.5i1 for Nagios 4)
op5 >= 5.0 Requires Livestatus
Shinken >= 1.0 RealOpInsight v2.3.0 or higher
Zabbix >= 1.8.0 RealOpInsight v2.1.0 or higher
Zenoss >= 4.0.0 RealOpInsight v2.2.0 or higher

Note

As of version 2.4.0, RealOpInsight can handle views relying on many monitoring backends simultaneously. Those backends can be homogeneous or heterogeneous, meaning that you can define service views that relies on data coming from any combination of supported monitoring systems at the same time.

The Architecture of Integration

RealOpInsight is built upon a loosely-coupled architecture to simplify its integration with the underlying monitoring systems. In this architecture, any status data is retrieved from the backed monitoring systems only through RPC APIs. This results to a scalable and powerful architecture able to handle large number of distributed, homogeneous, and heterogeneous monitoring systems simultaneously. This makes RealOpInsight especially useful for monitoring cloud environments.

The mechanism used to retrieve the status data depends on the underlying monitoring systems:

  • For Pandora FMS, RealOpInsight relies on its HTTP-based API.
  • For Zabbix, RealOpInsight relies on its native Zabbix API.
  • For Zenoss, it relies on its JSON-RPC API.
  • For Nagios and derived systems, RealOpInsight relies on MK Livestatus. Since Nagios does not provide native API, MK Livestatus appeared as a proved and effective approach to retrieve status data in real time. Alternatively, but only recommended for testing purpose, you can also use ngrt4nd, our specific daemon that relies on status.dat to serve Nagios status data for remote clients.
../_images/realopinsight-ultimate-architecture.png

Architecture of RealOpInsight Ultimate

Setting Up Monitoring Sources

Each monitoring source in RealOpInsight is defined by a set of parameters (see below for description) that set when and how RealOpInsight can access the backend monitor to retrieve status data. Whether it’s the Workstation edition or the Ultimate edition, RealOpInsight provides a GUI-based configuration manager to allow the user to easily set those parameters. The screenshot below is a capture of the Configuration Manager of RealOpInsight Workstation, the Ultimate edition also provides a similar web-based interface.

../_images/realopinsight-ms-preferences.png

Screenshot of the Configuration Manager of RealOpInsight Workstation

The following table lists all the supported configuration parameters. According to the backed monitoring system, some of parameters may be required, optional, or not applicable at all (NA).

Parameter Description Required
Monitor Web URL Sets the base URL to the web interface of the monitoring server. E.g. http://zabbix-server/zabbix/
  • Yes with Zabbix, Zenoss and Pandora FMS
  • No with Nagios and similar systems
Disable SSL Peer verification

When using secure connection with self-signed certificate, this option disable some SSL controls to avoid handshake failure.

WARNING: USE THIS OPTION AT YOUR OWN RISK. Even if enabling this option doesn’t compromise the cyphering of communication between RealOpInsight and the monitoring server, it disables many SSL security controls such as the verification of the certificate hostname.

  • Yes with Nagios and similar systems
  • Optional, but recommended with others
Auth String

Sets credentials string for authenticating against the remote API endpoint:

  • With Zabbix and Zenoss, this should be set with a couple login:password (note the : separator), representing a valid user account.

    NOTE: Prior to Zabbix 2.0, the user MUST belong to the group API Access.

  • With OpManager, this must be set with an API key (which can be generated/viewed in the settings page)

  • With Pandora FMS, you must set a triplet login, password, API key (optional) as follows: login:password:apikey (note the : separator)

    Additionally, make sure through the Pandora administration page that the RealOpInsight machine’s IP address is enabled to access to the Pandora API.

  • With ngrt4nd, this corresponds to its authentication token. See the corresponding manual for more details

  • Yes: Nagios with ngrt4nd
  • No: Nagios with Livestatus
  • Yes: Zabbix, Zenoss, Pandora FMS Manager OpManager
Server Address Sets the IP address or the hostname of the monitoring server (e.g. server.example.com).
  • Yes for Nagios and similar systems
  • No for others
Port Sets the port on which ngrt4nd or the Livestatus API is listening on on the monitoring server (e.g. 1983 for ngrt4nd).
  • Yes for Nagios and similar systems
  • No for others
Update Interval Set the interval after which the Operations Console will be refreshed with new status information retrieved from the monitoring servers
  • Yes for ALL