Overview

This section reviews custom configuration for the GroundWork Monitor Event Console application.

1.0 Configuring Audible Alarms

1.1 About Push Updating

The Event Console application subscribes to the event topic server using the specifications for the current view to specify the events that it wants to be notified about. The topic server then places the list of events onto the JMS queue for the particular console session. Periodically, at intervals defined by three directives, the console application picks up the list of topics and issues the corresponding web services calls to Foundation to get the events which are then displayed. The three operative directives and their functions are described below. The purpose of this arrangement is to arrive at a configurable compromise between latency and performance of the user interface.

1. Check interval defines the frequency at which the Event Console reads the topic server message queue. This is currently set to ten seconds.
2. Batch size is the number of topic server messages which if met or exceeded causes the Event Console to issue the web service request for all of the topic listed since last request which would result in a batch of events being requested that is at least 50 or more since this directive is currently set to 50 events.
3. Interval size is the time interval at the expiration of which all of the event topics are requested regardless of the number of them. It is currently set to 30 seconds. When this interval is reached, the Event Console requests all of the events for the topics on the topic server queue even if there are less than 50.

Functionality of the Audible Alarm Process (AAP) - The purpose of the AAP is to attract the attention of a busy or distracted operator to look at the Event Console. At the same time, it is important not to create alarm fatigue by barraging the operator with an incessant sequence of low priority alarms. The AAP scans through the events for each batch update received from Foundation via web services. It selects the highest priority event in each batch and sounds an alarm on the local browser system.

1.2 Configuration Steps

Alarm Selection and Configuration

The System Administrator can choose up to eight different alarm sounds (e.g. critical.mp3, down.mp3, unreachable.mp3) corresponding to the eight different levels of alarm severity in the Foundation database. If desired, the same alarm tone can be selected for all levels of severity or by not configuring all of the lower severity events, have alarms only sound for the higher severity events.

This is a system wide selection to avoid confusing NOC operators by having different tones conveying different meaning on different browsers within earshot of each other. Obviously alarms are sounded on the browser only for events that the Event Console on that browser is currently configured to get, i.e. post filters, post custom view tabs, etc.

The alarm .mp3 files are located in the media directory /usr/local/groundwork/config/media/. The System Administrator can replace these files if desired. In the console.properties file set each monitor status:file-name combination separated by a comma (,). If no alarm is chosen for a particular severity level, no alarm will be sounded for that level. Example:

alarm.file.status.mapping=DOWN:down.mp3,CRITICAL:critical.mp3,...

Alarm Duration

The length of an alarm is the length of the assigned the .mp3 file. Additionally, an operator can stop an alarm sound by clicking the Silence Alarm button on the Event Console display. The Silence button will stop the alarm if it is sounding, but it will not result in acknowledgement of the alarm. Acknowledging the alarm will also not stop the alarm sounding. There will be no alarm generated for the other events that are in the same batch of events as the highest priority event.

Turning the Audible Alarm Functionality On or Off

To enable or disable console event alarms, set the console.enable.audible.alarms property in the console.properties file to ON (true) or OFF (false). The system alarm functionality is ON by default. Example:

console.enable.audible.alarms=true

Properties File

The console.properties file, located in the directory /usr/local/groundwork/config, contains the audible alarm properties. See Appendix A in this document to view the entire console.properties file.

# Audible Alarm properties
alarm.file.media.path=/usr/local/groundwork/config/media/
# please enter mp3 file name (stored in above specified path - alarm.file.media.path) against monitor status.
# Each "monitor status:file-name" combination must be separate by comma (,). Example: DOWN:test-1.mp3,CRITICAL:test-2.mp3
# If you do not want to specify alarm file for any of the monitor status, please specify empty file name. Viz. DOWN:,CRITICAL:test-1.mp3
alarm.file.status.mapping=DOWN:down.mp3,CRITICAL:critical.mp3,UNREACHABLE:unreachable.mp3, WARNING:warning.mp3,PENDING:pending.mp3,UNKNOWN:unknown.mp3,UP:up.mp3,OK:ok.mp3
# enable /disable alarm
console.enable.audible.alarms=true

2.0 Configuring the Message Column Size

In the Event Console, the Message (TextMessage) column size can be adjusted to avoid event messages from wrapping. The system truncates the message beyond the set value and show it as ellipses, as seen in the image below. When a message text is truncated a user can mouse-over the message to display the entire message. The default message size in characters is 40.

1. Open the file:

   /usr/local/groundwork/config/console.properties

2. Set the text_message_size property to a valid numeric value, for example:

   text_message_size=40

   Figure: Message column
   

3.0 Masking Dynamic Columns

In the Event Console, the dynamic properties for any application type can be masked/made invisible, thus excluded from the Event Console view. To do this the invisible.dynamic.columns property is added in the console.properties file, the entry is case sensitive and multiple values are separated by commas. The value needs to match to the PropertyType database table.

• See Appendix A in this document to view the entire console.properties file.
• To view the PropertyType database table you can use the following:

  gwcollagedb=# select PropertyTypeID, Name, Description from PropertyType;

  Note: The prompt looks this way if you're connected to the gwcollagedb database, and the line needs to be terminated with a semicolon.

3.1 Masking a Dynamic Column from a Command Line

1. Open the file:

   /usr/local/groundwork/config/console.properties

2. Enter one or more properties to be excluded. For example;
   To hide the column updatedBy in the UI, change the property
   from:

   #invisible.dynamic.columns=updatedBy

   to:

   invisible.dynamic.columns=updatedBy

   or to hide the columns updatedBy and ipaddress in the UI, change the property
   from:

   #invisible.dynamic.columns=updatedBy

   to:

   invisible.dynamic.columns=updatedBy,ipaddress

   If this property is commented out or empty, all dynamic properties are shown:

   #invisible.dynamic.columns=updatedBy
   invisible.dynamic.columns=

3.2 Masking a Dynamic Column from the UI

Dynamic Columns can also be configured from within GroundWork Monitor.

1. Select GroundWork Administration > Foundation and Manage Configuration.
2. Next, select the configuration file console.properties, as displayed in the image below.
3. If the Property Name invisible.dynamic.columns is not listed, then in the New Property box type invisible.dynamic.columns and enter the property value(s). For example: invisible.dynamic.columns and udatedBy, ipaddress
4. Select Add, and then Save. The new property will be added to the properties file.
   
   Figure: Dynamic column
   

4.0 Configuring Internationalization

The Event Console application supports Internationalization (i18n). The standard supported languages include English, French and others, and are configurable using new message bundles. Note that only the labels are localized and not the data.

4.1 Configuring the Locale from a Command Line

In this example we will configure the Event Console to the French locale. The ISO 639-1 code for the French language is fr. Refer to this link; List of ISO 639-1 Codes for a complete listing of all the ISO 639 codes.

1. Open the file:

   /usr/local/groundwork/config/console.properties

2. Change the locale property code
   from English (en)

   #Internationalization
   locale=en

   to French (fr)

   #Internationalization
   locale=fr

4.2 Configuring the Locale from the UI

Internationalization can also be configured from within GroundWork Monitor.

1. Select Administration > Foundation > Manage Configuration.
2. Next select the configuration file console.properties, as displayed in the image below.
3. Scroll down the list and you will see the property locale. Enter the desired value. For example: fr for French.
4. Select Add, and then Save. The new property value will be added to the console.properties file.
   
   Figure: Configuring locale
   

4.3 Adding a New Message Bundle

In this example we will add a new message bundle for French.

1. Open the file:

   /usr/local/groundwork/config/console.properties

2. Change the current locale property code to jp for Japanese.

   #Internationalization
   locale=jp

3. Next you will need to translate all of the messages into a new file by copying the file messages_en.properties (use current locale property) to a new file named messages_jp.properties.
4. Then, restart gwservices with the following command:

   /usr/local/groundwork/ctlscript.sh restart gwservices

5.0 Configuring Actions

The Event Console enables users to select messages and apply various actions such as Open Log Message, Close Log Message, Accept Log Message, and other application type specific actions for selected message(s).

The list of actions is driven by the message(s) that are selected. There are two sets of action types:

• Standard System Actions - OPEN, CLOSED, NOTIFIED, ACCEPTED
• Application Actions - Nagios Acknowledge and Submit Passive Check

If the message(s) selected belong to a single application type, the action list will consist of Standard System Actions plus the specific Application Actions. If the message(s) selected belong to multiple application types then only Standard System Actions will be listed. Other than System and Nagios actions (except Nagios Acknowledge) all actions will have user input dialog for entering comments.

Developers can configure Event Console actions for a specific application type. These actions can submit data via 3 modes:

1. Invoke a server side script
2. Post to a URL
3. Java API

   You will need to restart gwservices after configuring actions /usr/local/groundwork/ctlscript.sh restart gwservices

5.1 Valid Action Parameters

5.2 Custom Action Parameters

At present there is no capability to define custom action parameters that are supplied to actions from the Event Console code. Customers are encouraged to use the available APIs in GroundWork Monitor to retrieve additional details about log messages. API documentation can be accessed through the links listed below. Please contact support if you require additional information. We also offer professional services to those customers interested in extending GroundWork Monitor with actions but who do not feel comfortable performing the work themselves. See Developer Reference > API Documentation.

For script based actions, order of the arguments passed depends on order in the ActionParameter table for that action.

Configuring Script Based Actions in the Event Console

Starting with GroundWork Monitor 6.5 all custom application types should include two dynamic properties UpdatedBy and Comments to store the user comments. Below is a table of valid action parameters.

Any script errors will be shown in the Event Console as a popup message, when the user clicks on a script based action from the action menu.

• Step 1 - Login and Define an Action Menu Name
  Login to the GWCollageDB schema in the database. Apply the following action table script. The Name field will be displayed in the Action menu in the Event Console. This field can contain any text and should describe the action.

  INSERT INTO Action (ActionTypeID, Name, Description) VALUES (
      (SELECT ActionTypeID FROM ActionType WHERE Name = 'SCRIPT_ACTION'),
      'Invoke my script',
      'Invoke a script for the selected message'
  );
  

• Step 2 - Configuring the Action Property
  Apply the following script on the actionProperty table. Name is a constant ”Script” for serverside script. Value is the path of the shellscript.

  INSERT INTO ActionProperty (ActionID, Name, Value) VALUES (
      (SELECT ActionID FROM Action WHERE Name = 'Invoke my script'),
      'Script',
      '/usr/local/groundwork/foundation/scripts/my_script.sh'
  );
  

  Make sure the shell script has the execute privilege for the {{nagios}] user.

• Step 3 - Map the Action to the Application Type
  Apply the following script on the ApplicationAction.

  INSERT INTO ApplicationAction (ApplicationTypeID, ActionID) VALUES (
      (SELECT ApplicationTypeID FROM ApplicationType WHERE Name = 'NAGIOS'),
      (SELECT ActionID FROM Action WHERE Name = 'Invoke my script')
  );

• Step 4 - Configure Action Parameters
  These are the command line arguments. Apply the following script on the ActionParameter table. Name and value are the same. Parameters available from the console include:
  • LogMessageIds - LogMessageIds in comma separated text
  • UserName - Login user name

Script for Action Parameters

INSERT INTO ActionParameter (ActionID, Name, Value) VALUES (
    (SELECT ActionID FROM Action WHERE Name = 'Invoke my script'),
    'LogMessageIds',
    'LogMessageIds'
);
INSERT INTO ActionParameter (ActionID, Name, Value) VALUES (
    (SELECT ActionID FROM Action WHERE Name = 'Invoke my script'),
    'UserName',
    'UserName'
);

If multiple messages are selected, the value for LogMessageIds will be delimited with comma. To get other parameters from the log message, developers can use web service call by passing the LogMessageId.

Configuring HTTP Request Actions in the Event Console

• Step 1 - Login and Define An Action Menu Name
  Login to GWCollageDB schema in the database. Apply the following action table script. The Name field will be displayed in the Action menu in the Event Console. This field can contain any text and should describe the action.

  INSERT INTO Action (ActionTypeID, Name, Description) VALUES (
      (SELECT ActionTypeID FROM ActionType WHERE Name = 'HTTP_REQUEST_ACTION'),
      'HTTP Post Test',
      'HTTP Post Test'
  );

• Step 2 - Configuring the Action Property
  Apply the following script on the actionProperty table. Name is a constant URL for serverside HTTP Request. Value is the URL.

  INSERT INTO ActionProperty (ActionID, Name, Value) VALUES (
      (SELECT ActionID FROM Action WHERE Name = 'HTTP Post Test'),
      'URL',
      'http://172.28.113.102:8081/TestHTTPPost/TestServlet'
  );

  Set the ReadTimeout in secs. ReadTimeout sets the number of seconds before a time-out occurs when a read operation does not finish.

  INSERT INTO ActionProperty (ActionID, Name, Value) VALUES (
      (SELECT ActionID FROM Action WHERE Name = 'HTTP Post Test'),
      'ReadTimeout',
      '20'
  );

  Set the ConnectionTimeout in secs. ConnectionTimeout sets the number of seconds before a connection time-out occurs .

  INSERT INTO ActionProperty (ActionID, Name, Value) VALUES (
      (SELECT ActionID FROM Action WHERE Name = 'HTTP Post Test'),
      'ConnectionTimeout',
      '20'
  );

• Step 3 - Map the Action to the Application Type
  Apply the following script on the ApplicationAction.

  INSERT INTO ApplicationAction (ApplicationTypeID, ActionID) VALUES (
      (SELECT ApplicationTypeID FROM ApplicationType WHERE Name = 'NAGIOS'),
      (SELECT ActionID FROM Action WHERE Name = 'HTTP Post Test')
  );

• Step 4 - Configure Action Parameters
  These are the request parameters. Apply the following script on the ActionParameter table.

  INSERT INTO ActionParameter (ActionID, Name, Value) VALUES (
      (SELECT ActionID FROM Action WHERE Name = 'HTTP Post Test'),
      'UserName',
      'UserName'
  );
  INSERT INTO ActionParameter (ActionID, Name, Value) VALUES (
      (SELECT ActionID FROM Action WHERE Name = 'HTTP Post Test'),
      'LogMessageIds',
      'LogMessageIds'
  );

  If multiple messages are selected, value for LogMessageIds will be delimited with comma. To get other parameters from log message, developers can use web service call by passing the LogMessageId.

Configuring Java based API Action in the Event Console

To implement actions using Java API, please refer to NagiosAcknowledgeAction (Java class)

org.groundwork.foundation.bs.actionNagiosAcknowledgeAction

6.0 Adding Public Filters

The Event Console provides viewing options for different monitoring data types; you can view System Filters which include specific Applications, Host Groups, or specified Operation Status including values: OPEN, CLOSED, NOTIFIED, and ACCEPTED. You can also view monitoring data through defined Public Filters.

GroundWork Monitor comes with seven defined Public Filters including All Events, Critical, Warning, Nagios Warning, Last 5 SNMPTRAP Warning, Last 10 Minutes NAGIOS Critical, and Current Troubled Open Events. The Event Console application allows a developer to customize additional Public Filters.

Figure: Public filters


The file used to customize Public Filters is console-admin-config.xml found in the /usr/local/groundwork/config directory. The structure is as follows:

Table: Setting Descriptions

6.1 Sample XML Structure

Once you finalize your changes, save the file and simply click Reload on the Event Console UI to find the new filter. Changes to this file does not require any restart gwservices.

Figure: Reload filters

Example

<PublicFilters>
    <Filter>
        <Name>All Events</Name>
        <Label>All Events</Label>
        <AppType></AppType>
        <HostGroup></HostGroup>
        <MonitorStatus></MonitorStatus>
        <Severity></Severity>
        <Fetch>
            <Size></Size>
            <Order>DESC</Order>
        </Fetch>
        <Time>
            <Unit></Unit>
            <Measurement></Measurement>
        </Time>
        <OpStatus></OpStatus>
        <DynaProperty>
            <PropName></PropName>
            <PropValue></PropValue>
            <DataType></DataType>
            <Operator></Operator>
        </DynaProperty>
    </Filter>
    <Filter>
        <Name>Critical Events</Name>
        <Label>Critical</Label>
        <AppType></AppType>
        <HostGroup></HostGroup>
        <MonitorStatus>CRITICAL:EQ</MonitorStatus>
        <Severity></Severity>
        <Fetch>
            <Size></Size>
            <Order>DESC</Order>
        </Fetch>
        <Time>
            <Unit></Unit>
            <Measurement></Measurement>
        </Time>
        <OpStatus></OpStatus>
        <DynaProperty>
            <PropName></PropName>
            <PropValue></PropValue>
            <DataType></DataType>
            <Operator></Operator>
        </DynaProperty>
</Filter>
<Filter>
        <Name>Warning Events</Name>
        <Label>Warning</Label>
        <AppType></AppType>
        <HostGroup></HostGroup>
        <MonitorStatus>WARNING:EQ</MonitorStatus>
        <Severity></Severity>
        <Fetch>
            <Size></Size>
            <Order>DESC</Order>
        </Fetch>
        <Time>
            <Unit></Unit>
            <Measurement></Measurement>
            </Time>
            <OpStatus></OpStatus>
            <DynaProperty>
                <PropName></PropName>
                <PropValue></PropValue>
                <DataType></DataType>
                <Operator></Operator>
            </DynaProperty>
    </Filter>
    <Filter>
        <Name>Nagios Warning Events</Name>
        <Label>Nagios Warning</Label>
        <AppType>NAGIOS</AppType>
        <HostGroup></HostGroup>
        <MonitorStatus>WARNING:EQ</MonitorStatus>
        <Severity></Severity>
        <Fetch>
            <Size></Size>
            <Order>DESC</Order>
        </Fetch>
        <Time>
            <Unit></Unit>
            <Measurement></Measurement>
        </Time>
        <OpStatus></OpStatus>
        <DynaProperty>
            <PropName></PropName>
            <PropValue></PropValue>
            <DataType></DataType>
            <Operator></Operator>
        </DynaProperty>
    </Filter>
    <Filter>
        <Name>Last 5 SNMPTRAPs of MonitorStatus Warning Events</Name>
        <Label>Last 5 SNMPTRAP Warning</Label>
        <AppType>SNMPTRAP</AppType>
        <HostGroup></HostGroup>
        <MonitorStatus>WARNING:EQ</MonitorStatus>
        <Severity></Severity>
        <Fetch>
            <Size>5</Size>
            <Order>DESC</Order>
        </Fetch>
        <Time>
            <Unit></Unit>
            <Measurement></Measurement>
        </Time>
        <OpStatus></OpStatus>
        <DynaProperty>
            <PropName></PropName>
            <PropValue></PropValue>
            <DataType></DataType>
            <Operator></Operator>
        </DynaProperty>
    </Filter>
    <Filter>
        <Name>Last 10 Minutes worth of NAGIOS Critical Events</Name>
        <Label>Last 10 Minutes NAGIOS Critical</Label>
        <AppType>NAGIOS</AppType>
        <HostGroup></HostGroup>
        <MonitorStatus>CRITICAL:EQ</MonitorStatus>
        <Severity></Severity>
        <Fetch>
            <Size></Size>
            <Order>DESC</Order>
        </Fetch>
        <Time>
            <Unit>-10</Unit>
            <Measurement>MIN</Measurement>
        </Time>
        <OpStatus></OpStatus>
        <DynaProperty>
            <PropName></PropName>
            <PropValue></PropValue>
            <DataType></DataType>
            <Operator></Operator>
        </DynaProperty>
    </Filter>
    <Filter>
        <Name>Current Troubled Open Events</Name>
        <Label>Current Troubled Open Events</Label>
        <AppType>NAGIOS</AppType>
        <HostGroup></HostGroup>
        <MonitorStatus>OK:NE,UP:NE</MonitorStatus>
        <Severity></Severity>
        <Fetch>
            <Size></Size>
            <Order>DESC</Order>
        </Fetch>
        <Time>
            <Unit></Unit>
            <Measurement></Measurement>
        </Time>
        <OpStatus>OPEN</OpStatus>
        <DynaProperty>
            <PropName></PropName>
            <PropValue></PropValue>
            <DataType></DataType>
            <Operator></Operator>
        </DynaProperty>
    </Filter>
</PublicFilters>

7.0 Pre-processing Log Messages

For all incoming new events the operation status is set to OPEN which guarantees a historical view of console events and leaves it up to the console user to organize the events. Below we'll cover a common use case from the command line and also from within the GroundWork Monitor user interface.

7.1 Configuring Pre-processing of Log Messages from the Command Line

A common Event Console use case is to only show the latest message for a type (Host or Host/Service) and classify previous events in a different category. In order to achieve this feature a system administrator would enable and specify the pre-process property. When the event.pre.process.enabled property is enabled (set to true), Foundation checks (for new and non-consolidated messages only) if an old message for the same Host or Host/Service exists. If an old message exists and the new message is a state change the system sets the Operation Status of the old message to what is defined in the event.pre.process.opstatus property. Otherwise it just leaves the default. The event pre-processing works with new incoming message and not existing messages.

1. Open the file:

   /usr/local/groundwork/config/foundation.properties

2. By default, event pre-processing is disabled and the operation status set to ACCEPTED, as shown here:

   event.pre.process.enabled=false
   event.pre.process.opstatus=ACCEPTED

3. For our use case we need to enable (set to true) event pre-processing and set the Operation status to a valid value; OPEN, CLOSED, NOTIFIED, or ACCEPTED:

   event.pre.process.enabled=true
   event.pre.process.opstatus=[selected Operation Status Value]

4. This change requires a restart of gwservices.

   /usr/local/groundwork/ctlscript.sh restart gwservices

7.2 Configuring Pre-Processing of Log Messages from the UI

Event pre-processing can also be configured from within GroundWork Monitor.

1. Select Administration > Foundation > Manage Configuration.
2. Next select the configuration file foundation.properties.
3. Scroll down the list and enter a true value for the property event.pre.process.enabled and a valid value (OPEN, CLOSED, NOTIFIED, or ACCEPTED) for the event.pre.process.opstatus property. See image below.
4. Select Add, and then Save. The new property value will be added to the foundation.properties file.
   
   Figure: Pre-processing of log messages
   

8.0 Sending specific events processed by Nagios as other application types

This section reviews options for controlling special-case treatment of events for certain services.

The status feeder has a configuration feature that allows you to send specific events that are processed by Nagios as other application types. This is useful when processing messages from custom feeders or from syslog_ng, for example. The feature is configured with the file /usr/local/groundwork/config/event-feeder.conf, by adding some text to indicate what events to process and what app type to make them. This is an advanced configuration feature.

The settings here are designed to modify certain aspects of the events sent to Foundation. By default, all events processed by this feeder are sent to Foundation using an application type of NAGIOS and a consolidation criteria of NAGIOSEVENT. Those settings make sense because the event feeder is most commonly processing events for services that originate in Nagios itself. However, there may be exceptional situations in which an override is desired. Consult with GroundWork Support if that is the case. This section of the configuration allows such exceptions to be locally configured at your site.

This capability currently only works if use_rest_api in this event-feeder.conf file is set to a true value.

In each of the following stanzas, you can specify a Perl-compatible regular expression in the <service> element to match the particular service(s) whose event attributes you wish to alter from the defaults.

The expression you specify will be automatically anchored at both ends (^ and $) when it is evaluated. So you must not specify those pattern elements, but you must ensure that your expression otherwise characterizes the full service name(s) you wish to match for that particular attribute mapping. You may enclose your pattern in "double-quotes" if that makes it easier to delineate here; those enclosing quotes will not become part of the pattern itself.

Be careful and precise in how you define your service-name patterns. If a service name matches more than one stanza, an arbitrary choice will be made, and the other matches will be ignored for that service. So, don't do that.

Specifying a consolidation criteria here only makes sense if both the event feeder and the status feeder actually send all of the individual fields needed for that criteria. (The status feeder is involved because it manufactures a few events to compensate for situations in which Nagios does not create events for certain state transitions.) In some cases, such data might not be available to the event feeder or status feeder. So, some checking of the code against the definition of the consolidation criteria in the database may be needed to validate that your choice will actually work.

Examples

We show some examples here just to give you the general idea; these may or may not be useful mappings. A <service> stanza can be fully commented out by just commenting out all of its interior options.

<attribute_mappings>
    <service "syslog_.*">
        # application_type       = "SYSLOG"
        # consolidation_criteria = "SYSLOG"
    </service>
    <service gdma_21_wmi_cpu>
        # application_type       = "GDMA"
        # consolidation_criteria = "NAGIOSEVENT"
    </service>
    <service nedi_switch>
        # application_type       = "NEDI"
        # consolidation_criteria = "NEDIEVENT"
    </service>
</attribute_mappings>

Appendix A: console.properties

The Event Console package console properties are presented below.

######################################################
# console.properties
# All GW Console properties are configured here.
######################################################
#Webservices URL
foundation_webserviceURL=http://localhost:8080/foundation-webapp/services/
#Page size for the data table in console.A numeric value.Set this to a reasonable limit
# say upto 1000.Increasing beyond may have performance impact.
page_size=20
#JMS Client properties
java.naming.factory.initial=fr.dyade.aaa.jndi2.client.NamingContextFactory
java.naming.factory.host=localhost
java.naming.factory.port=16400
context.factory=cf0
event.topic.name=foundation_events
topic.name=foundation_entities
ui.events.topic.name=ui_events
#Datatable built-in or common columns.Order of columns appears exactly the way listed here.
#Delimited with commas.To change the column label change the second part of the column.For ex,
#to change the reportDate column label, change Received By GW to something else.
built_in_columns=reportDate:Received  By GW,msgCount:Message  Count,device:Device,monitorStatus:Status,textMessage:Message,applicationType:Application  Type,severity:Severity,lastInsertDate:Last  Detected,firstInsertDate:First Detected
#Invisible dynamic columns. Case insensitive. Separated by commas. Should match the values from
#PropertyType DB table. If specified, these dynamic columns will be excluded from the event console view.
# If this property is commented out or empty, all dynamic properties are shown.
#invisible.dynamic.columns=updatedBy
# Text message size in characters.Default 40 characters to show. Full message will be showed on the mouseover.
# If you want to ignore this setting, just comment out.
text_message_size=40
#Nagios specific properties.valid values are true or false.
nagios_send_notification=true
nagios_persistent_comment=true
#Service name for SNMPTRAP and SYSLOG Passive resets.Valid values are required.
snmptraps_last=snmptraps_last
syslog_last=syslog_last
#Internationalization
locale=en
#Console DateTime pattern.Default is US format.
#For European format, change it to dd/MM/YYYY h:mm:ss a
#For example, to display date in Sep 19, 2008 10:00:00 am, use MMM dd, yyyy h:mm:ss a
#Date separators can be / . ,
#MM-Month
#dd-Date
#yyyy-Year
#h-Hour
#mm-Minutes
#ss-Secs
#a-AM/PM
console_datetime_pattern=MM/dd/yyyy h:mm:ss a
#Console error message
com_groundwork_global_error_message1=We're Sorry. You have experienced an error with the Groundwork Monitor.
com_groundwork_global_error_message2=Please logout close your browser and try again.
com_groundwork_global_error_message3=If  you continue to experience problems, please contact Groundwork Customer  Technical Support at [email protected].
#Enable/disable links (on device, services on popup etc.) to statusviewer from console.
sv.links.enabled=true
# alarm severity -from highest to lower severity.Delimited with commas
alarm_severity=UNSCHEDULED DOWN,UNSCHEDULED CRITICAL,DOWN,CRITICAL,UNREACHABLE,SCHEDULED DOWN,WARNING,PENDING,SCHEDULED CRITICAL,UNKNOWN,UP,OK
# Audible Alarm properties
alarm.file.media.path=/usr/local/groundwork/config/media/
# please enter mp3 file name (stored in above specified path - alarm.file.media.path) against monitor status.
# Each "monitor status:file-name" combination must be separate by comma (,). Example: DOWN:test-1.mp3,CRITICAL:test-2.mp3
# If you do not want to specify alarm file  for any of the monitor status, please specify empty file name. Viz.  DOWN:,CRITICAL:test-1.mp3
alarm.file.status.mapping=DOWN:down.mp3,CRITICAL:critical.mp3,UNREACHABLE:unreachable.mp3,WARNING:warning.mp3,PENDING:pending.mp3,UNKNOWN:unknown.mp3,UP:up.mp3,OK:ok.mp3
#  enable /disable alarm
console.enable.audible.alarms=true