Home

The versatility of our tool is evident: the Webmaster can choose to monitor a wide range of parameters, including all the headers associated with HTTP requests and responses, and can group the required conditions in a variety of ways. The configuration of the module can be better explained (briefly) by considering the following example configuration (as inserted in httpd.conf):

<MusicalLog> 
     MusicalPlayer    wonderland.dia.unisa.it
     EventCollector   zoo.diaedu.unisa.it:3000 
     StatisticsFrequency  30 
     <Channel> 
          ChannelName  "Demo" 
          ChannelDescription  "Simple Events Demo Channel" 
          SampleType MIDI
          SampleSet http://isis.dia.unisa.it/samp1
          TracksNumber 16
          Load [1-3] 10  
          StatusCode  "5[0-9]{2}"  4  
          StatusCode  ! "404" 5  
	  ResponseHeader  ContentType  ! "(text/.*)"  6
	  RequestUri "^/~vitsca/" 7  
    </Channel> 
    <Channel> 
          ChannelName  "Access"  
          ChannelDescription "Access control and authentication"    
          SampleType WAV
          SampleSet http://isis.dia.unisa.it/samp2
          TracksNumber 16
          Throughput [1-3] 10 10 1 
          <ComplexEvent> 
             StatusCode  "403|5.." 
             RequestUri "/cgi-bin/"  
             RemoteHost  ".*\.it"   
             Track  4 5 10 
          </ComplexEvent> 
          <ComplexEvent>    
	     RequestHeader Authorization  ".+" 
	     StatusCode  "401" 
	     Track 5 
	  </ComplexEvent> 
	  RemoteHost  ! ".*\.it"  6 50 
          HttpVersion "http/1\.0" 7
     </Channel> 
</MusicalLog> 
The configuration begins with setting some system parameters, namely, the network address of the host where the Collector is running and a list of authorized host addresses. If this list is not empty, then, only WebPlayers running on an authorized host machine can access the Collector's services. Important is the parameter StatisticsFrequency: it allows the Collector to know what is the time slice (in seconds) which the threshold directives apply to (more details follow).

In our example, the first Channel (Demo) defines some simple events to monitor StatusCodes and headers. Server load is monitored by using tracks 1 to 3. Track 1 to track t (t <= 3) are played together where t = floor((LOAD/10)+1). The StatusCode directive is followed by a regular expression and by a track number. In the example above, track 4 is played when server errors (HTTP status codes 5xx) happen while track 5 is played each time the Status code is not 404. Then, we monitor response headers ContentType so that track 6 is played whenever a MIME type text (including therefore html and plain text, for example) is served to the client. Finally, accesses to directory ~vitsca are monitored by track 7.

The second Channel (Access) contains the monitoring of the throughput by tracks 1 to 3, in steps of 10. The throughput is evaluated by counting the number of requests within a sliding temporal window of 10 seconds moved each second to the right. It also contains some also complex events: for example, in the first ComplexEvent, track 4 is played when 5 occurences of the event (described in the directive ComplexEvent) happen within 10 seconds. The event is represented by Status Code is 403 (Forbidden) or any server error (5xx) AND, the requested URI was a cgi-bin script AND the request came from an italian IP domain. In this way, we can listen when many (more than 5 in 10 seconds) italian clients accessing cgi-bin scripts fail for lack of authorization or for malformed parameters that can cause severe errors in the cgi-bin script.
The second complex event in this Channel is more alerting: the Webmaster wants to monitor on track 5 all the failed Authorization requests by monitoring non-empty Authorization request headers with status code 401 (Unauthorized).
Then, track 6 is played if there are more than 50 requests from domains that are not .it within the time slice defined at the beginning (default is 30 seconds). Finally, track 7 is played every time there is an access using HTTP version 1.0.

Several comments are due for threshold directives. By providing a threshold, it is possible not to be distracted by rare events while a sudden increase of events must play as one (possibly alarming) event. The examples of complex events presented above for Channel "Access" are good representatives: in the first case, we monitor repeated errors with cgi-bin scripts generated from italian accesses. In the other complex event, as already said, a more alarming situation is signaled if even a single authentication fails. One can choose to have a very recognizable and loud sound played if an extremely alarming situation happens, like an authomatic password hacker, by adding a complex event that plays only when several repeated authentications fail in a very short time range, as in the following example:

<ComplexEvent>
   RequestHeader Authorization ".+" 
   StatusCode "401" 
   Track 8 10 5
</ComplexEvent>