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