| Core Concept |
| To remotely monitor and forward system status information to a central operators centre. |
| monitoring |
| Achieved by adding sensors to each application component of interest, sensor data is aggregated by a collecting component 'MonitorBean' |
| concepts |
| Activities abstracted into concepts and organised into a hierarchy of visits, events & tasks. By structuring at collect-time related activities appear together - rather than in separate text logs requiring post-processing. |
| visits |
| All interactions by a particular user |
|
| events |
| Individual interactions, e.g. page requests, received datagrams |
|
| tasks |
| Operations performed by application in response to an event - each has a status code (OK, WARNING, CRITICAL) |
|
|
| visualisation |
| Collected information can be visualised in real-time through web interface |
|
|
| aggregation |
| The refining of collected observations into a small set of service states reflecting current state of the system. This abstraction process is handled by a dedicated aggregator component configured by rules. |
| service mapping |
| Rules describe mapping between incoming information source and a particular service state |
|
| update model |
| Incoming monitored events (errors) may change the aggregator component's model, the service state moving from OK to an error state. |
|
| communication channel |
| Service states are written to a database which is asynchronously polled by a system daemon (e.g. Nagios) that sends the results to a network operations centre. |
|
|
|
