RealOpInsight Workstation Editor User Manual

Any view manipulated by RealOpInsight needs to be described within a file called description file. Even if the format of description files is based on XML and thus editable via a text editor, RealOpInsight Editor is an utility built to ease the creation and the manipulation of description files. This document provides basic steps to create your first description file using the editor.

Launch the Editor

To run the RealOpInsight Editor, you have a command line interface and, on Windows, a quick access from the Start Menu.

Command Line Interface (Linux/OS X)

The CLI command is named realopinsight-editor. Here is usage:

realopinsight-editor [/path/to/description/file]

Changed in version 3.0.0: The former command ngrt4n-editor has been deprecated in version 3.0.0.

This launches the Editor and, optionally, loads a description file passed as parameter. If no description is provided, a new document will be initialized.

Type realopinsight-editor -h to learn more options.

Start Menu (Windows only)

On Windows, you can quickly launch the Editor via the Start Menu shortcut.

Start -> RealOpInsight Workstation -> RealOpInsight Editor


To get access to RealOpInsight Editor, you’re required to log in. Here are default user credentials:

Operator User (Limited Privileges)

  • Login: ngrt4n_op
  • Password: ngrt4n_op

Administrator User (Full Privileges)

  • Login: ngrt4n_adm
  • Password: ngrt4n_adm

User Interface

An annotated screenshot of RealOpInsight Editor is shown on the Figure below. The user interface consists of the following components:

  • The Menu bar enables access to the editor features. Some menus have shortcuts on the toolbar, which sits under the menu bar.
  • The Tree Explorer, at the left side, represents the hierarchy of the service view being edited. This active component enables drag-and-drop to ease the manipulation of the hierarchy. In addition, each service from the Tree Explorer has context menus giving access to various functionality, such as, the creation and the deletion of service, etc.
  • The Edition Pane, at the right side, is where the properties of services are edited. When user selects a service from the Tree Explorer, its properties are automatically loaded in the edition pane. Each modification made in the edition pane is actively applied to the selected service.

Overview of the RealOpInsight Editor’s User Interface

Create and Edit Description Files for Business Services

For each business service view managed by RealOpInsight, you need to create a description file, manually (i.e. service by service), or automatically by importing hostgroup information <import-monitoring-items-as-businessview>`. The automatic hostgroup-based importation works for all monitoring systems supported by RealOpInsight, i.e. Nagios, OpManger, Zabbix, Zenoss, Pandora FMS, etc. See the step-by-step tutorial on hostgroup-based business service importation for more details.

The next steps present how to create and edit a business service view manually:

  • Select the menu File -> New Description File (keyboard shortcut: Ctrl + N) to start the edition of a new description file. This shall initialize a new document hierarchy with only a root service. You should then populate it in order to have a consistent business service hierarchy.

    The next steps decribe how to start with a service and populate it with child services in order to have a consistent service dependency tree.

  • Select the service from the Tree Explorer (left pane), right click and choose Add sub service. Alternatively, you can select the service in the Tree Exporer and select the menu File -> Add sub service (keyboard shortcut: Ctrl + Shift + N).

    This action shall lead to the following behaviour: (i) a new service will be created and added as child of the selected service; (ii) the newly created service will be selected (2); and, finally, (iii) the edition pane will be cleaned and filled with the default properties of the newly created service.

    Fulfil the properties of the service as outlined in Section Service Properties.

  • Repeat the last step as long as you want to ad new services in your business service hierarchy.

    The Tree Explorer of Editor enables relevant features that significantly simplifies the edition of a business service hierarchy, regardless of the complexity of the related business service:

    • When a node is selected, its properties are automatically filled up into the Edition Pane, each change in the edition pane is automatically applied on the corresponding service property (but not yet saved).
    • You can use drag-and-drop and drill-down to easily (re)organize your hierarchy.
    • The context menu of each service in the Tree Explorer also provides a menu to delete the service on-the-fly.
  • Once you have finished the editing of your business service hierarchy, save the result as a RealOpInsight description file (see the menu File -> Save, the menu File -> Save as..., or their corresponding shortcuts on the toolbar).

Service Properties

Each service has a set of properties. Some of them are required, others are optional, and may have implicit values. The following list outlines the different properties.


Serves as label for the service.


Possible values are Native Check (or IT service) or Business Process (default), according to the role of the service in the hierarchy.

Status Calculation Rule

Defines how the status of the service is computed according to the severities propagated by its subservices. For the Weighted Average With Thresholds calculation rule, you should traditionally set threshold escalation rules.

Read more about Status Calculation Rules and Severity Escalation.

Status Propagation Rule

Defines how the severity of the service shall be propagated to its parent service. In addition to the propagation rule.

Read more about Status Propagation Rules.


In addition to the propagation rule, each service should have a weight factor that tells how important the service is to its parent service, i.e. compared to other sibling services. The default weight is 1 (basic weight).

Learn more about Service Weighting.


Sets an icon to associate to the service on the Operations Console Map.


Optional, this field allows to set more information about the service.

Alarm Message

Optional and specific to native checks, this property holds the custom message to show on Operations Console when an incident arises (when the state changes from NORMAL to another state).

The message can include one or more contextual tags to enable context-specific information, like the hostname and the event threshold, in the message delivered in the Event Console. When leaving empty, its default value corresponds to the raw output returned by the monitoring plugin, and is equivalent to use the tag {plugin_output}.

Read more about contextual tags.

Notification Message

Optional and specific to native checks, this holds the custom message to show on Operations Console when the service is recovered (when the status changes to another state to NORMAL.

As for alarm message, the notification message can include one or more contextual tags. In the same way, when leaving empty its default value corresponds to the raw output delivered by the monitoring plugin. The equivalent of using the tag {plugin_output}.

Data Point

Specific to IT services, this sets the monitoring item to associate to the service (i.e. Nagios check, Zabbix trigger, Zenoss component, OpManager service...). By convention, and, as rule of thumb, a valid defintion of data point must match the following pattern: SourceId:HostOrDevice/MonitoringItem, where:

  • SourceId must match the identifier of a valid monitoring source. Before version 3.3.0, this element was optional when using mono-source monitoring description file,
  • HostOrDevice must match a host or a device monitored by your backed monitoring system.
  • MonitoringItem must match a monitoring item (e.g. Nagios service, Zabbix trigger, Zenoss component, Padora FMS module, OpManager monitor), and associated to the host or device named HostOrDevice.

Concrete use cases illustrating the definition of data points according to your monitoring system are provided below:

  • For Nagios and similar monitoring systems, the definition of data point must have the following form: SourceId:host_name/service_description. E.g. Source1:mysql-server/Current Load identifies the check allowing to monitor the CPU load on the server named mysql-server, monitored by the Nagios server associated to Source1. (i.e. localhost).
  • For Zabbix, a data point must have the following format: SourceId:host_name/trigger_name. E.g. Source0:Zabbix server/Lack of free swap space on{HOST.NAME} identifies the trigger allowing to monitor the swap space on the Zabbix server associated to Source0.
  • For Zenoss, a data points must have the following form SourceId:device_name/component_name. E.g. Source2:locahost/httpd identifies the component responsible for monitoring the Apache server process (httpd) on the Zenoss Server (i.e. localhost) associated to Source2.
  • For Pandora FMS, a data point must have the following form SourceId:agent_name/module_name. E.g. Source3:locahost/CPU Load identifies the module responsible for monitoring the CPU load on the Pandora server (i.e. localhost) associated to Source3.


In order to avoid typo erros, the RealOpInsight Editor enables since the version 3.0.1 the ability to automatically import data points from the underlying monitoring systems (Nagios, Zenoss, Manager OpManger, Zabbix...). See the section Importing Data Points for more details.

Importing Monitoring Items as Data Points

To ease the setting of data points when editing a description file, the RealOpInsight Editor provides the ability to automatically fetch monitoring items from your backed monitoring server and organize them as data points. Using this feature, the user can import and set data points in a few clicks, thereby avoiding typo errors.


Data points importation depends on the same configuration settings than the RealOpInsight Operations Console. This means that, to that works, you must first set your monitoring sources properly.

Importing monitoring items as data points involves the following steps:

  1. Select the menu File -> Import Monitoring Items as Data Points (shortcut icon: import-data-points-icon) to load the importation window.

  2. In the source selection list, select the source from which to import data. The source selection list should only contain declared as Zabbix-based. In addition, the selected source should have been properly configured (monitor URL, login, password) so to enable access to Zabbix API.


  3. You may optionally set a host or a host group filter. By default the importation retrieves all triggers available in Zabbix. When the filter is set, only data matching the filter shall be imported.

  4. After all input set, click on OK to start the importation. This will close the importation window to start the processing in background. The status bar of the editor provides details on the processing.