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.
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:
[apache] log = access: /var/log/apache/access.log [combined] [dispatch] subscribe = apache.access.4xx.404 select = apache.user-agent send = apache-404-useragent-log [filelog] name = apache-404-useragent-log filename = /tmp/monami-apache-ua.log