| 1 |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| 2 |
|
| 3 |
<!-- |
| 4 |
$Author$ |
| 5 |
$Id$ |
| 6 |
--> |
| 7 |
|
| 8 |
|
| 9 |
<html> |
| 10 |
|
| 11 |
<head> |
| 12 |
<title>Overview and Features</title> |
| 13 |
<meta name="description" content="The i-scream Project is a central monitoring system for Unix, Linux and NT servers."> |
| 14 |
<meta name="keywords" content="i-scream, project, central monitoring system, unix, linux, nt, server, alert"> |
| 15 |
<meta name="generator" content="notepad on acid, aye."> |
| 16 |
</head> |
| 17 |
|
| 18 |
<body bgcolor="#ffffff" link="#0000ff" alink="#3333cc" vlink="#3333cc" text="#000066"> |
| 19 |
|
| 20 |
<table border="0" cellpadding="2" cellspacing="2"> |
| 21 |
<tr> |
| 22 |
<td valign="top"> |
| 23 |
<!--#include virtual="left.inc" --> |
| 24 |
</td> |
| 25 |
<td valign="top"> |
| 26 |
<!--#include virtual="title.inc" --> |
| 27 |
|
| 28 |
<table border="0" width="500"> |
| 29 |
<tr> |
| 30 |
<td> |
| 31 |
<font size="2" face="arial,sans-serif"> |
| 32 |
|
| 33 |
<center><h3>Key Features of The System</h3></center> |
| 34 |
|
| 35 |
<ul> |
| 36 |
<li>A centrally stored, dynamically reloaded, system wide configuration system</li> |
| 37 |
<li>A totally extendable monitoring system, nothing except the Host (which |
| 38 |
generates the data) and the Clients (which view it) know any details about |
| 39 |
the data being sent, allowing data to be modified without changes to the |
| 40 |
server architecture.</li> |
| 41 |
<li>Central server and reporting tools all Java based for multi-platform portability</li> |
| 42 |
<li>Distribution of core server components over CORBA to allow appropriate components |
| 43 |
to run independently and to allow new components to be written to conform with the |
| 44 |
CORBA interfaces.</li> |
| 45 |
<li>Use of CORBA to create a hierarchical set of data entry points to the system |
| 46 |
allowing the system to handle event storms and remote office locations.</li> |
| 47 |
<li>One location for all system messages, despite being distributed.</li> |
| 48 |
<li>XML data protocol used to make data processing and analysing easily extendable</li> |
| 49 |
<li>A stateless server which can be moved and restarted at will, while Hosts, |
| 50 |
Clients, and reporting tools are unaffected and simply reconnect when the |
| 51 |
server is available again.</li> |
| 52 |
<li>Simple and open end protocols to allow easy extension and platform porting of Hosts |
| 53 |
and Clients.</li> |
| 54 |
<li>Self monitoring, as all data queues within the system can be monitored and raise |
| 55 |
alerts to warn of event storms and impending failures (should any occur).</li> |
| 56 |
<li>A variety of web based information displays based on Java/SQL reporting and |
| 57 |
PHP on-the-fly page generation to show the latest alerts and data</li> |
| 58 |
<li>Large overhead monitor Helpdesk style displays for latest Alerting information</li> |
| 59 |
</ul> |
| 60 |
|
| 61 |
<center><h3>An Overview of the i-scream Central Monitoring System</h3></center> |
| 62 |
|
| 63 |
<p align="left"> |
| 64 |
The i-scream system monitors status and performance information |
| 65 |
obtained from machines feeding data into it and then displays |
| 66 |
this information in a variety of ways. |
| 67 |
</p> |
| 68 |
|
| 69 |
<p align="left"> |
| 70 |
This data is obtained through the running of small applications |
| 71 |
on the reporting machines. These applications are known as |
| 72 |
"Hosts". The i-scream system provides a range of hosts which are |
| 73 |
designed to be small and lightweight in their configuration and |
| 74 |
operation. See the website and appropriate documentation to |
| 75 |
locate currently available Host applications. These hosts are |
| 76 |
simply told where to contact the server at which point they are |
| 77 |
totally autonomous. They are able to obtain configuration from |
| 78 |
the server, detect changes in their configuration, send data |
| 79 |
packets (via UDP) containing monitoring information, and send |
| 80 |
so called "Heartbeat" packets (via TCP) periodically to indicate |
| 81 |
to the server that they are still alive. |
| 82 |
</p> |
| 83 |
|
| 84 |
<p align="left"> |
| 85 |
It is then fed into the i-scream server. The server then splits |
| 86 |
the data two ways. First it places the data in a database system, |
| 87 |
typically MySQL based, for later extraction and processing by the |
| 88 |
i-scream report generation tools. It then passes it onto to |
| 89 |
real-time "Clients" which handle the data as it enters the system. |
| 90 |
The system itself has an internal real-time client called the "Local |
| 91 |
Client" which has a series of Monitors running which can analyse the |
| 92 |
data. One of these Monitors also feeds the data off to a file |
| 93 |
repository, which is updated as new data comes in for each machine, |
| 94 |
this data is then read and displayed by the i-scream web services |
| 95 |
to provide a web interface to the data. The system also allows TCP |
| 96 |
connections by non-local clients (such as the i-scream supplied |
| 97 |
Conient), these applications provide a real-time view of the data |
| 98 |
as it flows through the system. |
| 99 |
</p> |
| 100 |
|
| 101 |
<p align="left"> |
| 102 |
The final section of the system links the Local Client Monitors to |
| 103 |
an alerting system. These Monitors can be configured to detect |
| 104 |
changes in the data past threshold levels. When a threshold is |
| 105 |
breached an alert is raised. This alert is then escalated as the |
| 106 |
alert persists through four live levels, NOTICE, WARNING, CAUTION |
| 107 |
and CRITICAL. The alerting system keeps an eye on the level and |
| 108 |
when a certain level is reached, certain alerting mechanisms fire |
| 109 |
through whatever medium they are configured to send. |
| 110 |
</p> |
| 111 |
</font> |
| 112 |
</td> |
| 113 |
</tr> |
| 114 |
</table> |
| 115 |
|
| 116 |
<!--#include virtual="bottom.inc" --> |
| 117 |
</td> |
| 118 |
</tr> |
| 119 |
</table> |
| 120 |
|
| 121 |
</body> |
| 122 |
|
| 123 |
</html> |
