The Network connectivity monitor calculates health using Ping and TCP port tests.

In addition to health calculation, the monitor also persists metrics used in the health calculation.

The container monitor facilitate creation of health and supporting reasons from Docker containers.

The Container monitor consists of

• Configuration section covering settings like name of monitor and where the monitor should execute
• Container section defines which containers to monitor as well as how the information should affect health index and reasons.
• Default configuration section displaying output from test runs.
• Custom configuration section displaying output from test runs.

The Dbwatch monitor uses Dbwatch, as a source for information about alarms for databases, this information is transformed to health index & reasons for database instances mapped to assets.

Note that the targeted Dbwatch server needs to be configured to provide alarm information as webpages, please see section Configuring Dbwatch server for details.

The Dbwatch monitor consists of

• General settings section covering settings like name of monitor and where the monitor should execute
• Monitor settings section covering how to convert data from Dbwatch to health index and reason

The Eaton monitor monitors Eaton power supplies using the SNMP agent on the UPS.

The Eaton monitor consists of

• Configuration section covering settings like name of monitor and where the monitor should execute
• Severities section defining which and how UPS alarms should affect the health of the UPS asset

The Eventlog monitor supports the monitoring of events reported through Windows Eventlog.

The monitor may target a specific agent or an asset group (note that Ceeview monitors only assets of type Agent) and in the latter case, one of the agents in the group must be chosen as a template agent.

The external monitor is a generic monitor where external components calculate and send health indexes and reasons to Ceeview using the Ceeview Health Integration REST API.

The File search monitor facilitates monitoring of file attributes for a file or a set of files;

• Age
• Size
• Read time
• Number of files
• Existence of directory (returns monitor error if not existing)

The Groovy monitor is a generic monitor allowing the user to control how to calculate the health for one or more assets.

It requires the logic to be implemented using the Apache Groovy script language.

The HyperV monitor generates health and reasons for Microsoft HyperV systems.

This monitor supports a HyperV server and its guest systems.

To monitor multiple physical HyperV servers, please use the Virtual Machine Manager monitor.

NB! A guest or host system can only be monitored by one HyperV monitor, it will silently be ignored for subsequent HyperV monitors.

The IBM SAN Volume Controller (SVC) is a block storage virtualization appliance that belongs to the IBM System Storage (StorWize) product family.   

SVC implements an indirection (virtualization) layer in the Fiber Channel Storage Area Network (SAN).

The CeeView IBM SVC Monitor will extract performance counters (for the cluster and/or the cluster nodes) and event-log messages using the SVC CLI available on the appliance through a secure shell connection (SSH). The known supported IBM Storwize versions are: 7.3.x, 7.4.x and 7.5.x

While each rule will independently add health reasons to the asset’s reason set, the asset’s monitor health will be the aggregate (worst) health across all the monitor’s rules.

The monitor allows the user to:

• Configure a single asset, or for an asset group.
• Monitor the cluster (aggregated values for all nodes in cluster).
• Monitor the cluster nodes.
• Monitor the network connectivity to the SVC host.
• Monitor the event-log with the ability to ignore old messages that have not yet been “fixed”.

The log monitor generates health index and reasons based on log file content, the URL page source, and command output.

A monitor can have one or more profiles, and each profile can have one or more variables matched against the checked content.

Each monitor profile creates a health index and a corresponding set of reasons if all of the profile’s variables succeed in matching the content of the log record.

The Log monitor will create an asset group, with the same name as the monitor, and populate the group with all assets found, based on the settings defined in the profile(s).

The Mail Gateway monitor will check incoming mails in the configured mailbox and if the filters defined in the monitor matches the mails, assets will be created/updated with corresponding health indexes and reason sets.

The Metric monitor supports generating asset health using existing metric series.

If you do not have a Metric monitor in the list of available monitors, use the System account to install the Metric module using Management/Server/Modules.

The Metric monitor can run on the server.

The Microsoft cluster monitor calculates health and supporting reasons for a Microsoft cluster, including cluster nodes, network interfaces, roles (resource groups), cluster shared volumes, and disk partitions.

The MS Cluster monitor can run from any Ceeview agent with network access to the cluster IP. However the the Ceeview agent service needs to be running under a user with privileges to access the cluster, for instance, the same user as used when configuring the monitor.

The Modbus Monitor monitors devices supporting the Modbus protocol, for instance, emergency power generators.

The Modbus monitor consists of

• Configuration section covering settings like name of monitor and where the monitor should execute
• Profile section defining the tests against the Modbus device and how they should impact the health of a corresponding asset

The Nagios monitor integrates with a Nagios server and presents Nagios devices as assets with health based on information from Nagios.
If you do not have Nagios in the list of available monitors, use the System account to install the Nagios module using Management/Server/Modules.

The Nagios monitor can run from any Ceeview agent with network access to the Nagios server.

The Nimsoft monitor is a gateway monitor using Nimsoft as a source for assets and health (alarms in Nimsoft terminology).

If you do not have Nimsoft in the list of available monitors, use the System account to install the Nimsoft module using Management/Server/Modules. 

The Nimsoft monitor can run from any Ceeview agent with the following bundles installed and configured;

• com.ceesoft.ceeview.external.nimsoftintegration
• com.ceesoft.ceeview.healthmonitor.nimsoft

They should also be running on a machine with a Nimsoft robot installed.

The Processes monitor supports monitoring of Windows/Linux processes.

The monitor may target a specific asset or an asset group (monitors only assets of type Agent). In the latter case, choose one of the assets in the group as a template asset.

The PRTG monitor integrates with a PRTG server and presents PRTG devices as assets with health based on information from PRTG.

If you do not have PRTG in the list of available monitors, use the System account to install the PRTG module using Management/Server/Modules.

The PRTG monitor can run from any Ceeview agent with network access to the PRTG server.

The Remote IBM iSeries monitor supports monitoring of AS400 systems covering systems (users, batches, etc), subsystems, and pools.

If you do not have Remote IBM iSeries in the list of available monitors, use the System account to install the Remote iSeries module using Management/Server/Modules.

The Remote IBM iSeries monitor can run from any Ceeview agent with network access to the AS400 server.

The Remote System Monitor has the ability to monitor a single asset or an asset group remotely.

The monitor uses the WMI or WinRM protocol for accessing data from Windows hosts, and the SSH protocol for accessing data from Unix hosts.

The monitor can be configured to send Health indexes with reasons and metrics for the following categories:

• Cpu & Memory
  • Cpu Usage
  • Memory Usage
  • Cpu Queue length (Cpu Load on Unix)
• Disk
  • Disk Usage (%)
  • Disk Free (MB)
• Process
  • Running state
  • Expected instances
  • Cpu usage
  • Memory usage
• Service (only Windows)
  • Expected state

The script monitor facilitate creation of health and supporting reasons from Groovy or PowerShell scripts.

The Script monitor consists of the

• General section covering settings like name of monitor and where the monitor should execute
• Script section holding the actual script code
• Test output section displaying output from test runs.