Managing the Event Monitor

Event Monitor sinks contain events, including log, database, e-mail, and JMX notification. Any number of sinks may be defined. For example, multiple SMTP sinks can be defined with a single purpose for each sink.

One SMTP sink can be used to send all Error events to an administrator e-mail address or pager. Another SMTP sink can be used to send all template events to a group of users who need to know about template changes (newly imported, deleted, etc.).

Note that if SMTP information is supplied in event-monitor-sinks.xml, in either the email.admin or Retention Policy Sink, these values will override the SMTP settings in the config-settings.xml.

You can filter events so that you do not overload the Event Monitor tables with unnecessary data, but still allow the reports you need to be generated. For details about configuring sinks and filtering, see Event Monitor.

Sinks define a destination for an event. The benefit of a sink depends on the nature of the destination sink type.

Database sink: In a database sink, the events are stored in the database.

SMTP sink: In an SMTP sink, events are sent to e-mail addresses or even pagers to alert on-call personnel of potential issues with the system.

JMX sink: In a JMX sink, live events are sent to a monitoring application (for example, Tivoli) so that operations personnel can be notified of potential issues with the system.

What are the consequences of having too many sinks?

The Event Monitor processes events asynchronously. Events are received in a queue and are processed sequentially. Some events take longer to process depending on the sink configuration.

If an event is set for delivery to a log, database, SMTP, and JMX, it will take a while for the Event Monitor consumer to process that event. Adding more sinks increases the processing time. The more sinks, the more CPU time required to process each event.

Limiting the number of events

In order to limit the number of events in the queue, certain event priorities can be disabled in Event Monitor, and will not be entered in the queue.

There are four types of event priorities:

For example:

<setting>
<key>eventLoggingLevel</key>
<value>DEBUG</value>
</setting>

Performance indications of event logging

To handle performance implications of logging events, configure event-monitor-sink.xml to log only “critical” events and exclude “trivial” events. For example, the sample filter below shows exclusion of the debug event logging:

<filters>
 <filter>
 <property name="eventType" exclude="Debug" />
 </filter>
</filters>

Event Monitor tables comprise the largest part of the EngageOne database and can become out-of-date, providing little value past a certain age. EngageOne includes an Event Monitor purge function that works much like batch purge. The Event Monitor purge is run using a command line script; purge-em.bat for Windows and purge-em.sh for Unix. It can also be run in parallel with the purge.bat script, however the -numDaysRentention <offset days> must correspond to the -onOrBeforeDate of this script. Make sure that you have them scheduled correctly.

Note that you cannot specify specific events to purge. You can only purge all events that are logged before a user-specified date.

Purged events are not shown in EngageOne Administration Diagnostic panel and once deleted are no longer traceable. To remove all events related to a pending item, remove the pending items using batch purge with the -pendingdelivery option.

Run Event Monitor purge at the same frequency as batch purge. The run frequency depends on your system’s daily workload.

To launch Event Monitor purge from a batch file:

use purge-em.bat/purge-em.sh.

purge-em -onOrBefore 2009-11-27

purge –delivered –numDaysRetention 3