Configuring Event Console

h6. Contents

This section reviews configuration for the GroundWork Monitor Event Console application.
{toc:minLevel=4|maxLevel=4|printable=false}

h4. Configuring Audible Alarms

h5. 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.
# Check interval defines the frequency at which the Event Console reads the topic server message queue. This is currently set to ten seconds.
# 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.
# 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.

h6. 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.

h5. Configuration Steps

h6. 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:
{code}alarm.file.status.mapping=DOWN:down.mp3,CRITICAL:critical.mp3,...{code}

h6. 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.

h6. 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:
{code}console.enable.audible.alarms=true{code}

h6. 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.
{code}# 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{code}

h4. 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.

h5. Configuring the Message Column

# Open the file:
{code}/usr/local/groundwork/config/console.properties{code}
# Set the text_message_size property to a valid numeric value, for example:
{code}text_message_size=40{code}
!ec_textmessagesize.gif|align=left|hspace=5px!

h4. 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:
{code}gwcollagedb=# select PropertyTypeID, Name, Description from PropertyType;{code}
Note: The prompt looks this way if you're connected to the gwcollagedb database, and the line needs to be terminated with a semicolon.

h5. Masking a Dynamic Column from a Command Line

# Open the file:
{code}/usr/local/groundwork/config/console.properties{code}
# Enter one or more properties to be excluded. For example;
To hide the column updatedBy in the UI, change the property
from:
{code}#invisible.dynamic.columns=updatedBy{code}
to:
{code}invisible.dynamic.columns=updatedBy{code}
or to hide the columns updatedBy and ipaddress in the UI, change the property
from:
{code}#invisible.dynamic.columns=updatedBy{code}
to:
{code}invisible.dynamic.columns=updatedBy,ipaddress{code}
If this property is commented out or empty, all dynamic properties are shown:
{code}#invisible.dynamic.columns=updatedBy
invisible.dynamic.columns={code}

h5. Masking a Dynamic Column from the UI

Dynamic Columns can also be configured from within GroundWork Monitor.
# Select Administration>Foundation>Manage Configuration.
# Next, select the configuration file {{console.properties}}, as displayed in the image below.
# 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}}
# Select Add, and then Save. The new property will be added to the properties file.
!d_consolepropertiesui.gif|align=left|hspace=5px!

h4. 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.

h5. 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|http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes] for a complete listing of all the ISO 639 codes.
# Open the file:
{code}/usr/local/groundwork/config/console.properties{code}
# Change the locale property code
from English (en)
{code}#Internationalization
locale=en{code}
to French (fr)
{code}#Internationalization
locale=fr{code}

h5. Configuring the Locale from the UI

Internationalization can also be configured from within GroundWork Monitor.
# Select Administration>Foundation>Manage Configuration.
# Next select the configuration file {{console.properties}}, as displayed in the image below.
# Scroll down the list and you will see the property locale. Enter the desired value. For example: fr for French.
# Select Add, and then Save. The new property value will be added to the {{console.properties}} file.
!d_consolepropertiesui2.gif|align=left|hspace=5px!

h5. Adding a New Message Bundle

In this example we will add a new message bundle for French.
# Open the file:
{code}/usr/local/groundwork/config/console.properties{code}
# Change the current locale property code to jp for Japanese.
{code}#Internationalization
locale=jp{code}
# 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}}.
# Then, restart {{gwservices}} with the following command:
{code}/usr/local/groundwork/ctlscript.sh restart gwservices{code}

h4. 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:

# Invoke a server side script
# Post to a URL
# Java API
{Note} You will need to restart {{gwservices}} after configuring actions {{/usr/local/groundwork/ctlscript.sh restart gwservices{}}}{Note}

h5. Valid Action Parameters

|| ID || Parameter Name || Description || Example ||
| 0 | LogMessageIds | Comma separated list of selected Log Messages. | 3,4,5,6,7 |
| 1 | UserName | User name logged in to GroundWork Monitor portal. | admin |
| 2 | SendNotification | Parameter used by action to ensure notification is sent for acknowledgement. Hard coded. | nagios_send_notification |
| 3 | PersistentComment | Parameter used by action to ensure comment is persistent for acknowledgement. Hard coded. | nagios_persistent_comment |
| 4 | Comment | Comment used for action to acknowledge Nagios alert. Hard coded but includes the data and time ant the end. | Acknowledged from console at 09/21/2010 12:34:31 PM |
| 5 | nsca_host | Default address of the NSCA host. Hard coded. | localhost |
| 6 | user | Same as UserName parameter. | admin |
| 7 | comment | Comment used for the script to submit a passive result. Hard coded but includes the user parameter at the end. | Manual_reset_by_admin |
| 8 | host | Command separated list of Device Identification values for the selected Log Messages. | 192.168.0.11, 192.168.0.12 |
| 9 | service | Name of service for selected event. This is currently hard coded to be snmptraps_last if the application type is SNMPTRAP or otherwise it will be syslog_last. Since this Parameter is only used for an action that is available for either the SNMPTRAP or SYSLOG application types this seems reasonable, if limited. | syslog_last |
| 10 | state | StateID used for action script to submit a passive service check. Hard coded. | 0 |

h5. 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.
{Note}For script based actions, order of the arguments passed depends on order in the ActionParameter table for that action.{Note}

* Web Services - [DEVELOPER REFERENCE>API Documentation>Web Services API|Web Services API]

{Note}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.{Note}

{Note}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.{Note}

* 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.
{code}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'
);
{code}

* 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.
{code}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'
);
{code}
{Note}Make sure the shell script has the execute privilege for the {{nagios}} user.{Note}

* Step 3 - Map the Action to the Application Type
Apply the following script on the ApplicationAction.
{code}INSERT INTO ApplicationAction (ApplicationTypeID, ActionID) VALUES (
(SELECT ApplicationTypeID FROM ApplicationType WHERE Name = 'NAGIOS'),
(SELECT ActionID FROM Action WHERE Name = 'Invoke my script')
);{code}

* 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

h6. Script for Action Parameters

{code}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'
);{code}

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.

h6. 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.
{code}INSERT INTO Action (ActionTypeID, Name, Description) VALUES (
(SELECT ActionTypeID FROM ActionType WHERE Name = 'HTTP_REQUEST_ACTION'),
'HTTP Post Test',
'HTTP Post Test'
);{code}

* 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.
{code}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'
);{code}
Set the ReadTimeout in secs. ReadTimeout sets the number of seconds before a time-out occurs when a read operation does not finish.
{code}INSERT INTO ActionProperty (ActionID, Name, Value) VALUES (
(SELECT ActionID FROM Action WHERE Name = 'HTTP Post Test'),
'ReadTimeout',
'20'
);{code}
Set the ConnectionTimeout in secs. ConnectionTimeout sets the number of seconds before a connection time-out occurs .
{code}INSERT INTO ActionProperty (ActionID, Name, Value) VALUES (
(SELECT ActionID FROM Action WHERE Name = 'HTTP Post Test'),
'ConnectionTimeout',
'20'
);{code}

* Step 3 - Map the Action to the Application Type
Apply the following script on the _ApplicationAction_.
{code}INSERT INTO ApplicationAction (ApplicationTypeID, ActionID) VALUES (
(SELECT ApplicationTypeID FROM ApplicationType WHERE Name = 'NAGIOS'),
(SELECT ActionID FROM Action WHERE Name = 'HTTP Post Test')
);{code}

* Step 4 - Configure Action Parameters
These are the request parameters. Apply the following script on the ActionParameter table.
{code}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'
);{code}
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.

h6. Configuring Java based API Action in the Event Console

To implement actions using Java API, please refer to NagiosAcknowledgeAction (Java class)
{code}org.groundwork.foundation.bs.actionNagiosAcknowledgeAction{code}

h4. 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.
!d_c_addingpublicfilters.gif|align=left|hspace=5px!

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
| Name | \[Required\] Name of the filter. Just for identification. Not referenced anywhere. |
| Label | \[Required\] Label displayed in the UI on the navigation panel. |
| AppType | \[Optional\] Application type. Valid values: SYSTEM, NAGIOS, SNMPTRAP, SYSLOG only |
| HostGroup | \[Optional\] HostGroup. Case sensitive. Multiple Host Groups are specified with comma separated values:&nbsp;<HostGroup>HostGroup1,HostGroup2</HostGroup> |
| MonitorStatus | \[Optional\] Status of a message delimited by a colon with operator. Valid values: WARNING, CRITICAL, UNKNOWN, OK, UP, UNREACHABLE, DOWN, PENDING. Valid values for operator: EQ, NE. Supports multiple monitor status delimited by a comma. For example: <MonitorStatus>OK:NE,UP:NE</MonitorStatus> |
| Severity | \[Optional\] Severity of the message. For example: FATAL, NORMAL etc. Multiple Severity can be supplied with comma delimiters. For example: <Severity>FATAL:EQ,NORMAL:NE</Severity> Public Filters support multiple values for Severity including: AND, OR, EQUAL, NOT EQUAL |
| Fetch | \[Optional\] Sets the fetch size and order. |
| Size | \[Optional\] Sets the fetch size. If set, it should be greater than 0. |
| Order | \[Optional\] Sets the fetch order. Valid values are ASC and DESC. |
| Time | \[Optional\] Maps to reportDate attribute on the server. |
| Unit | \[Optional\] Units. Always referenced from the current time. For example: To represent the last 10 minutes, set Unit as \-10 and measurement at MIN. |
| Measurement | \[Optional\] Measurement unit for time. Valid values are MIN and SEC only. |
| OpStatus | \[Optional\] Operation status of the message. Valid values: NOTIFY, ACCEPT, OPEN, CLOSED. Multiple operation statuses can be supported with comma delimiters. Public Filters support multiple values for OpStatus including AND, OR, EQUAL, NOT EQUAL. |
| DynaProperty | \[Optional\] Dynamic Property. PropName should be same as the one defined in the PropertyType database table. |
| DataType | \[Optional\] DataType for the Dynamic Property. Valid values are STRING, BOOLEAN, LONG, INT, DATE or DOUBLE. Mandatory if Dynamic Property is specified. |
| PropValue | \[Optional\] Value for the Dynamic Property. Prop value is TRUE or FALSE for DataType BOOLEAN. For DataType DATE, format is MM/DD/YYYY. Mandatory if Dynamic Property is specified. |
| Operator | \[Optional\] Operator for the Dynamic Property. Mandatory if dynamic property specified. Valid values are LT, LE, GT, GE, EQ, NE, LIKE, IN. For String DataType, system recognizes LIKE only. For BOOLEAN system recognizes EQ only. |

h5. 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.
!d_c_reload.gif|align=left|hspace=5px!

h6. Example

{code}<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>{code}

h4. 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.

h5. 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.
# Open the file:
{code}/usr/local/groundwork/config/foundation.properties{code}
# By default, event pre-processing is disabled and the operation status set to ACCEPTED, as shown here:
{code}event.pre.process.enabled=false
event.pre.process.opstatus=ACCEPTED{code}
# 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:
{code}event.pre.process.enabled=true
event.pre.process.opstatus=[selected Operation Status Value]{code}
# This change requires a restart of gwservices.
{code}/usr/local/groundwork/ctlscript.sh restart gwservices{code}

h5. Configuring Pre-Processing of Log Messages

Event pre-processing can also be configured from within GroundWork Monitor.
# Select Administration>Foundation>Manage Configuration.
# Next select the configuration file foundation.properties.
# 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.
# Select Add, and then Save. The new property value will be added to the foundation.properties file.
!d_c_preprocessing.gif|align=left|hspace=5px!

h4. Appendix A: console.properties

The Event Console package console properties are presented below.

{code}######################################################
# 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 support@groundworkopensource.com.
#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{code}