3.7. Configuring Event-based Monitoring

Some monitoring involves capturing that a particular activity happened, when it happened and some metadata associated with the activity. A concrete example of event monitoring is watching file transfers from a web-server: one might wish to monitor for requests for missing files (404 HTTP status-code) to be alert to some broken part of a web-site. One might also look for which parts of a website are under heavy load, so to better load-balance the operation.

With any event there is some associated metadata. For a web request, this metadata includes the web-browser's User-Agent string, the browser's hostname (or IP address), how much data was transferred, etc. Within MonAMI, this information is presented as a datatree. Events are merely new datatrees that can be directed to one (or more) reporting targets.

A monitoring target that provides events typically will split those events into separate channels. The channels form a hierarchy of different activity. For example, an apache target can be configured to provide events based on HTTP requests the Apache server receives. These events can be provided as the access channel. Events from the access channel can be further divided into events from the access.1xx, access.2xx, access.3xx and access.4xx channels based on the resulting HTTP status-code. The access.4xx channel is further subdivided based on the actual code, so into access.4xx.401, access.4xx.402 and so on.

3.7.1. dispatch

The dispatch targets describe which events are to be monitored, what information is to be send and to which reporting targets the information is to be sent. Event monitoring works using a subscription model. The dispatch target subscribes to one or more channels to receive events that match. A dispatch that subscribes to a branch (within a channel hierarchy) will receive all events that match any of the more-specific events: subscribing to access.4xx will receive events on channel access.4xx.401, access.4xx.402, access.4xx.403, and so on.

When receiving a datatree, the dispatch can select some subset of the available data. Each event might have a large amount of information that, in some particular case, is not needed. The select attribute specifies which data is needed. It uses the same format as the sample target's read attribute (see Section 3.6.1, “The read attribute”).

Finally, a dispatch section must specify to which reporting target the datatree is to be sent. The send attribute contains a comma-separated list of reporting targets to which the data should be sent.

A simple example is:

  log = access: /var/log/apache/access.log [combined]

 subscribe = apache.access.4xx.404
 select    = apache.user-agent
 send      = apache-404-useragent-log

 name = apache-404-useragent-log
 filename = /tmp/monami-apache-ua.log