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 |
< |
|
1 |
> |
<!--#include virtual="/doctype.inc" --> |
2 |
> |
<head> |
3 |
> |
<title> |
4 |
> |
CMS Features |
5 |
> |
</title> |
6 |
> |
<!--#include virtual="/style.inc" --> |
7 |
> |
</head> |
8 |
> |
<body> |
9 |
> |
<div id="container"> |
10 |
> |
<div id="main"> |
11 |
> |
<!--#include virtual="/header.inc" --> |
12 |
> |
<div id="contents"> |
13 |
> |
<h1 class="top"> |
14 |
> |
CMS Features |
15 |
> |
</h1> |
16 |
> |
<h2> |
17 |
> |
Problem Specification |
18 |
> |
</h2> |
19 |
> |
<h3> |
20 |
> |
Original Problem |
21 |
> |
</h3> |
22 |
> |
<p> |
23 |
> |
This is the original specification given to us when we |
24 |
> |
started the project. The i-scream central monitoring system |
25 |
> |
meets this specification, and aims to extend it further. |
26 |
> |
This is, however, where it all began. |
27 |
> |
</p> |
28 |
> |
<h3> |
29 |
> |
Centralised Machine Monitoring |
30 |
> |
</h3> |
31 |
> |
<p> |
32 |
> |
The Computer Science department has a number of different |
33 |
> |
machines running a variety of different operating systems. |
34 |
> |
One of the tasks of the systems administrators is to make |
35 |
> |
sure that the machines don't run out of resources. This |
36 |
> |
involves watching processor loads, available disk space, |
37 |
> |
swap space, etc. |
38 |
> |
</p> |
39 |
> |
<p> |
40 |
> |
It isn't practicle to monitor a large number of machines by |
41 |
> |
logging on and running commands such as 'uptime' on the |
42 |
> |
unix machines, or by using performance monitor for NT |
43 |
> |
servers. Thus this project is to write monitoring software |
44 |
> |
for each platform supported which reports resource usage |
45 |
> |
back to one centralised location. System Administrators |
46 |
> |
would then be able to monitor all machines from this |
47 |
> |
centralised location. |
48 |
> |
</p> |
49 |
> |
<p> |
50 |
> |
Once this basic functionality is implemented it could |
51 |
> |
usefully be expanded to include logging of resource usage |
52 |
> |
to identify longterm trends/problems, alerter services |
53 |
> |
which can directly contact sysadmins (or even the general |
54 |
> |
public) to bring attention to problem areas. Ideally it |
55 |
> |
should be possible to run multiple instances of the |
56 |
> |
reporting tool (with all instances being updated in |
57 |
> |
realtime) and to to be able to run the reporting tool as |
58 |
> |
both as stand alone application and embeded in a web page. |
59 |
> |
</p> |
60 |
> |
<p> |
61 |
> |
This project will require you to write code for the unix |
62 |
> |
and Win32 APIs using C and knowledge of how the underlying |
63 |
> |
operating systems manage resources. It will also require |
64 |
> |
some network/distributed systems code and a GUI front end |
65 |
> |
for the reporting tool. It is important for students |
66 |
> |
undertaking this project to understand the importance of |
67 |
> |
writing efficient and small code as the end product will |
68 |
> |
really be most useful when machines start run out of |
69 |
> |
processing power/memory/disk. |
70 |
> |
</p> |
71 |
> |
<p> |
72 |
> |
John Cinnamond (email jc) whose idea this is, will provide |
73 |
> |
technical support for the project. |
74 |
> |
</p> |
75 |
> |
<h2> |
76 |
> |
Features |
77 |
> |
</h2> |
78 |
> |
<h3> |
79 |
> |
Key Features of The System |
80 |
> |
</h3> |
81 |
> |
<ul> |
82 |
> |
<li>A centrally stored, dynamically reloaded, system wide |
83 |
> |
configuration system |
84 |
> |
</li> |
85 |
> |
<li>A totally extendable monitoring system, nothing except |
86 |
> |
the Host (which generates the data) and the Clients (which |
87 |
> |
view it) know any details about the data being sent, |
88 |
> |
allowing data to be modified without changes to the server |
89 |
> |
architecture. |
90 |
> |
</li> |
91 |
> |
<li>Central server and reporting tools all Java based for |
92 |
> |
multi-platform portability |
93 |
> |
</li> |
94 |
> |
<li>Distribution of core server components over CORBA to |
95 |
> |
allow appropriate components to run independently and to |
96 |
> |
allow new components to be written to conform with the |
97 |
> |
CORBA interfaces. |
98 |
> |
</li> |
99 |
> |
<li>Use of CORBA to create a hierarchical set of data entry |
100 |
> |
points to the system allowing the system to handle event |
101 |
> |
storms and remote office locations. |
102 |
> |
</li> |
103 |
> |
<li>One location for all system messages, despite being |
104 |
> |
distributed. |
105 |
> |
</li> |
106 |
> |
<li>XML data protocol used to make data processing and |
107 |
> |
analysing easily extendable |
108 |
> |
</li> |
109 |
> |
<li>A stateless server which can be moved and restarted at |
110 |
> |
will, while Hosts, Clients, and reporting tools are |
111 |
> |
unaffected and simply reconnect when the server is |
112 |
> |
available again. |
113 |
> |
</li> |
114 |
> |
<li>Simple and open end protocols to allow easy extension |
115 |
> |
and platform porting of Hosts and Clients. |
116 |
> |
</li> |
117 |
> |
<li>Self monitoring, as all data queues within the system |
118 |
> |
can be monitored and raise alerts to warn of event storms |
119 |
> |
and impending failures (should any occur). |
120 |
> |
</li> |
121 |
> |
<li>A variety of web based information displays based on |
122 |
> |
Java/SQL reporting and PHP on-the-fly page generation to |
123 |
> |
show the latest alerts and data |
124 |
> |
</li> |
125 |
> |
<li>Large overhead monitor Helpdesk style displays for |
126 |
> |
latest Alerting information |
127 |
> |
</li> |
128 |
> |
</ul> |
129 |
> |
<h3> |
130 |
> |
An Overview of the i-scream Central Monitoring System |
131 |
> |
</h3> |
132 |
> |
<p> |
133 |
> |
The i-scream system monitors status and performance |
134 |
> |
information obtained from machines feeding data into it and |
135 |
> |
then displays this information in a variety of ways. |
136 |
> |
</p> |
137 |
> |
<p> |
138 |
> |
This data is obtained through the running of small |
139 |
> |
applications on the reporting machines. These applications |
140 |
> |
are known as "Hosts". The i-scream system provides a range |
141 |
> |
of hosts which are designed to be small and lightweight in |
142 |
> |
their configuration and operation. See the website and |
143 |
> |
appropriate documentation to locate currently available |
144 |
> |
Host applications. These hosts are simply told where to |
145 |
> |
contact the server at which point they are totally |
146 |
> |
autonomous. They are able to obtain configuration from the |
147 |
> |
server, detect changes in their configuration, send data |
148 |
> |
packets (via UDP) containing monitoring information, and |
149 |
> |
send so called "Heartbeat" packets (via TCP) periodically |
150 |
> |
to indicate to the server that they are still alive. |
151 |
> |
</p> |
152 |
> |
<p> |
153 |
> |
It is then fed into the i-scream server. The server then |
154 |
> |
splits the data two ways. First it places the data in a |
155 |
> |
database system, typically MySQL based, for later |
156 |
> |
extraction and processing by the i-scream report generation |
157 |
> |
tools. It then passes it onto to real-time "Clients" which |
158 |
> |
handle the data as it enters the system. The system itself |
159 |
> |
has an internal real-time client called the "Local Client" |
160 |
> |
which has a series of Monitors running which can analyse |
161 |
> |
the data. One of these Monitors also feeds the data off to |
162 |
> |
a file repository, which is updated as new data comes in |
163 |
> |
for each machine, this data is then read and displayed by |
164 |
> |
the i-scream web services to provide a web interface to the |
165 |
> |
data. The system also allows TCP connections by non-local |
166 |
> |
clients (such as the i-scream supplied Conient), these |
167 |
> |
applications provide a real-time view of the data as it |
168 |
> |
flows through the system. |
169 |
> |
</p> |
170 |
> |
<p> |
171 |
> |
The final section of the system links the Local Client |
172 |
> |
Monitors to an alerting system. These Monitors can be |
173 |
> |
configured to detect changes in the data past threshold |
174 |
> |
levels. When a threshold is breached an alert is raised. |
175 |
> |
This alert is then escalated as the alert persists through |
176 |
> |
four live levels, NOTICE, WARNING, CAUTION and CRITICAL. |
177 |
> |
The alerting system keeps an eye on the level and when a |
178 |
> |
certain level is reached, certain alerting mechanisms fire |
179 |
> |
through whatever medium they are configured to send. |
180 |
> |
</p> |
181 |
> |
</div> |
182 |
> |
<!--#include virtual="/footer.inc" --> |
183 |
> |
</div> |
184 |
> |
<!--#include virtual="/menu.inc" --> |
185 |
> |
</div> |
186 |
> |
</body> |
187 |
|
</html> |