Overview

This section reviews configuration for the GroundWork Monitor Status application.

1.0 Status Host and Service Prefix Properties

By default, Status displays hostname prefixes (e.g., CACTI:<hostname>), which identify the application type and how the host was originally created. For example a host configured by Cacti will have a prefix CACTI, a host configured by Cloud Hub VMware will have VEMA as the prefix, and a host configured by Nagios will have the prefix NAGIOS.

In the status-viewer.properties configuration file, located in /usr/local/groundwork/config, you may turn the prefixing on/off (yes/no) for both hosts and services. The default hosts are set to yes (display a prefix) and services are set to no (do not display a prefix).

The distributed status-viewer.properties file sets the host prefix for Nagios to off (no).

The file contains entries in the form of, (e.g., CACTI):

#host.prefix.CACTI=yes
#service.prefix.CACTI=no

To change the default behavior, un-comment the property and set to yes or no, this example will result in Cacti configured hosts and services each having a CACTI prefix:

#host.prefix.CACTI=yes
service.prefix.CACTI=yes

If you change a property setting you will need to restart GroundWork services:

/etc/init.d/groundwork restart gwservices

2.0 Status Viewer Auto-Refresh

In its default configuration, the GroundWork Monitor Status application reflects current status updates with a minimal amount of time lag between an update and what is reflected in the portal. To minimize impact on system resources, this process involves logic to detect system changes and updates the status viewer accordingly, however for larger GroundWork installations this process can result in unacceptable amounts of delay, in some cases as large as 3-5 minutes.

You have the option to configure the Status application to auto-refresh, which will help ensure status updates are accurate and have a shorter and more predictable delay.

This option can increase the load on the GroundWork server, depending on the number of hosts/services and the frequency of the refreshes. This script will stop/start GroundWork which will result in a few minutes of downtime.

• Configure the properties file
  You will need to edit the status-viewer.properties indicating a gap value which is the length in seconds between auto refreshes. A gap of 30 is recommended and should be a good default value in most cases, but please contact GroundWork Support for advice or assistance in choosing a value that will provide the best overall experience.
  1. Edit the file:

     vi /usr/local/groundwork/config/status-viewer.properties

  2. Add the following and save the file:

     portal.statusviewer.autoRefreshGap=30

3.0 Defining URLs for Actions Portlet Connections

• The default template for defining the URL's that are used for the Connections menu in the Status application Actions portlet of the host and services view are defined in the file:

  /usr/local/groundwork/config/status-viewer.properties

• The default URLs are as follows:

  portal.statusviewer.action.url.ssh=ssh://$HOST
  portal.statusviewer.action.url.http="http://$HOST"
  portal.statusviewer.action.url.https="https://$HOST"
  portal.statusviewer.action.url.vnc=vnc://$HOST
  portal.statusviewer.action.url.rdp=rdp://$HOST

• The $HOST variable will be substituted with the host name of the selected page in Status. If a user applies any changes to the default URL's the portal needs to be stopped and started before any changes will show up.

  /usr/local/groundwork/ctlscript.sh stop gwservices
  /usr/local/groundwork/ctlscript.sh start gwservices

4.0 Creating Links to Status Pages

This topic covers how to define links from third party applications, inside the portal or from external applications, to the GroundWork Status application.

• URL Formats
  External applications can access Status hosts,host groups, services, and service groups by creating a URL with the actual host and service name as specified in the table below:

  URL Node Type	Format of URL
  Host Group	http://<server-name>/portal-statusviewer/urlmap?hostgroup=Linux%20Servers
  Host	http://<server-name>/portal-statusviewer/urlmap?host=localhost
  Service	http://<server-name>/portal-statusviewer/urlmap?host=localhost&service=local_memory
  Service Group	http://<server-name>/portal-statusviewer/urlmap?servicegroup=sg1

• External Application Redirection Scenarios
  Users of an external application will be redirected to the Entire Network view of the GroundWork Monitor Status application for the following scenarios:
  • An incorrect node name parameter is specified which does not exist. For example if the host parameter is set to host=abcd and the host abcd does not exist in the system.
  • When a URL translator makes use of ReferenceTreeMetaModel (RTMM) for mapping a name with the actual ID and creating the URL. If the managed bean for RTMM has not been instantiated/created and an external application tries to access the Status application the user will be redirected to the Entire Network view.