Web Editor

The Web Editor provides features to ease the creation and the edition of service views.

This document provides basic steps to create and edit a service view.

Overview and User Interface

Log into RealOpInsight Ultimate as administrator and select the Editor menu.

The user interface consists of the following components:

  • A Tree Explorer (1) displays service view hierarchy. It’s an active component that enables various features to ease the manipulation of the hierarchy.
  • A Edition Pane (2) where the properties of services are edited. When a service node is selected in the Tree Explorer its properties are automatically filled in the edition fields. Any changes made in the edition pane is automatically applied to the selected service.
  • A Menu area (3) enables access to various features as descrived hereafter.

Overview of RealOpInsight Web Editor’s User Interface

Edit A Service Tree

Assume that you’ve open a new or an existing service view, the edition of service tree work as follows:

  • When a node is selected from the Tree Explorer, the edition pane is automatically filled in with the properties of the associated service.
  • You can doubleclick on a tree node to enable its context menus (e.g. context menus to add sub a sub-service or to remove it). You can also use menu shortcuts instead.
  • When a tree node is selected and that the Add sub service menu is triggered, the following happens:
    • A new service is created and added as child of the selected service in the Tree Explorer;
    • The newly created service is automatically selected;
    • The edition pane is filled in with the properties of the newly created service.
    • You can fulfil the properties of the new service as explained here: Section Service Properties.
  • When a tree node is selected and that the Remove service menu is triggered, the service and all its descendants are destroyed. Please note that no confirmation is asked.
  • You can add many sub-services as you want under a Business Service node. It’s worth to mention that adding sub-services under IT Service or External Service node is forbidden.
  • Your changes can be saved at any time by clicking on the appropriated button, or by triggering its keyboard shortcut (Shift + S)

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.
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:Host/MonitoringItem.

Understand How Data Points Works

  • SourceId sets he identifier of a valid monitoring source.
  • Host must match a host or a device monitored by your backed monitoring system.
  • MonitoringItem must match a monitoring item associated to the host named Host, i.e. a Nagios check, a Zabbix trigger, a Zenoss component, a Padora FMS module or an OpManager monitor.


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

Easying the Selection of Data Points

To ease the setting of data points when editing service view so as to to avoid typo errors, the Web Editor provides the ability to automatically retrieve monitoring items from your backed monitoring servers and organize them as data points. Using this feature, the user can import and set data points in a few clicks.


This feature requires that your monitoring sources have been already configured.

Importing monitoring items as data points involves the following steps: