| 1 |
< |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> |
| 1 |
> |
<!--#include virtual="/doctype.inc" --> |
| 2 |
|
|
| 3 |
< |
<!-- |
| 4 |
< |
$Author$ |
| 5 |
< |
$Id$ |
| 6 |
< |
--> |
| 3 |
> |
<head> |
| 4 |
> |
<title>CMS Features</title> |
| 5 |
> |
<!--#include virtual="/style.inc" --> |
| 6 |
> |
</head> |
| 7 |
|
|
| 8 |
+ |
<body> |
| 9 |
|
|
| 10 |
< |
<html> |
| 10 |
> |
<div id="container"> |
| 11 |
|
|
| 12 |
< |
<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> |
| 12 |
> |
<div id="main"> |
| 13 |
|
|
| 14 |
< |
<body bgcolor="#ffffff" link="#0000ff" alink="#3333cc" vlink="#3333cc" text="#000066"> |
| 14 |
> |
<!--#include virtual="/header.inc" --> |
| 15 |
|
|
| 16 |
< |
<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" --> |
| 16 |
> |
<div id="contents"> |
| 17 |
|
|
| 18 |
< |
<table border="0" width="500"> |
| 19 |
< |
<tr> |
| 20 |
< |
<td> |
| 21 |
< |
<font size="2" face="arial,sans-serif"> |
| 18 |
> |
<h1 class="top">CMS Features</h1> |
| 19 |
> |
|
| 20 |
> |
<h2>Problem Specification</h2> |
| 21 |
> |
|
| 22 |
> |
<h3>Original Problem</h3> |
| 23 |
> |
|
| 24 |
> |
<p> |
| 25 |
> |
This is the original specification given to us when we |
| 26 |
> |
started the project. The i-scream central monitoring |
| 27 |
> |
system meets this specification, and aims to extend it |
| 28 |
> |
further. This is, however, where it all began. |
| 29 |
> |
</p> |
| 30 |
|
|
| 31 |
< |
<center><h3>Key Features of The System</h3></center> |
| 31 |
> |
<h3>Centralised Machine Monitoring</h3> |
| 32 |
> |
|
| 33 |
> |
<p> |
| 34 |
> |
The Computer Science department has a number of different machines |
| 35 |
> |
running a variety of different operating systems. One of the tasks |
| 36 |
> |
of the systems administrators is to make sure that the machines |
| 37 |
> |
don't run out of resources. This involves watching processor loads, |
| 38 |
> |
available disk space, swap space, etc. |
| 39 |
> |
</p> |
| 40 |
|
|
| 41 |
+ |
<p> |
| 42 |
+ |
It isn't practicle to monitor a large number of machines by logging |
| 43 |
+ |
on and running commands such as 'uptime' on the unix machines, or |
| 44 |
+ |
by using performance monitor for NT servers. Thus this project is |
| 45 |
+ |
to write monitoring software for each platform supported which |
| 46 |
+ |
reports resource usage back to one centralized location. System |
| 47 |
+ |
Administrators would then be able to monitor all machines from this |
| 48 |
+ |
centralised location. |
| 49 |
+ |
</p> |
| 50 |
+ |
|
| 51 |
+ |
<p> |
| 52 |
+ |
Once this basic functionality is implemented it could usefully be |
| 53 |
+ |
expanded to include logging of resource usage to identify longterm |
| 54 |
+ |
trends/problems, alerter services which can directly contact |
| 55 |
+ |
sysadmins (or even the general public) to bring attention to problem |
| 56 |
+ |
areas. Ideally it should be possible to run multiple instances of |
| 57 |
+ |
the reporting tool (with all instances being updated in realtime) |
| 58 |
+ |
and to to be able to run the reporting tool as both as stand alone |
| 59 |
+ |
application and embeded in a web page. |
| 60 |
+ |
</p> |
| 61 |
+ |
|
| 62 |
+ |
<p> |
| 63 |
+ |
This project will require you to write code for the unix and Win32 |
| 64 |
+ |
APIs using C and knowledge of how the underlying operating systems |
| 65 |
+ |
manage resources. It will also require some network/distributed |
| 66 |
+ |
systems code and a GUI front end for the reporting tool. It is |
| 67 |
+ |
important for students undertaking this project to understand the |
| 68 |
+ |
importance of writing efficient and small code as the end product |
| 69 |
+ |
will really be most useful when machines start run out of processing |
| 70 |
+ |
power/memory/disk. |
| 71 |
+ |
</p> |
| 72 |
+ |
|
| 73 |
+ |
<p> |
| 74 |
+ |
John Cinnamond (email jc) whose idea this is, will provide technical |
| 75 |
+ |
support for the project. |
| 76 |
+ |
</p> |
| 77 |
+ |
|
| 78 |
+ |
<h2>Features</h2> |
| 79 |
+ |
|
| 80 |
+ |
<h3>Key Features of The System</h3> |
| 81 |
+ |
|
| 82 |
|
<ul> |
| 83 |
|
<li>A centrally stored, dynamically reloaded, system wide configuration system</li> |
| 84 |
|
<li>A totally extendable monitoring system, nothing except the Host (which |
| 105 |
|
<li>Large overhead monitor Helpdesk style displays for latest Alerting information</li> |
| 106 |
|
</ul> |
| 107 |
|
|
| 108 |
< |
<center><h3>An Overview of the i-scream Central Monitoring System</h3></center> |
| 108 |
> |
<h3>An Overview of the i-scream Central Monitoring System</h3> |
| 109 |
|
|
| 110 |
< |
<p align="left"> |
| 110 |
> |
<p> |
| 111 |
|
The i-scream system monitors status and performance information |
| 112 |
|
obtained from machines feeding data into it and then displays |
| 113 |
|
this information in a variety of ways. |
| 114 |
|
</p> |
| 115 |
|
|
| 116 |
< |
<p align="left"> |
| 116 |
> |
<p> |
| 117 |
|
This data is obtained through the running of small applications |
| 118 |
|
on the reporting machines. These applications are known as |
| 119 |
|
"Hosts". The i-scream system provides a range of hosts which are |
| 128 |
|
to the server that they are still alive. |
| 129 |
|
</p> |
| 130 |
|
|
| 131 |
< |
<p align="left"> |
| 131 |
> |
<p> |
| 132 |
|
It is then fed into the i-scream server. The server then splits |
| 133 |
|
the data two ways. First it places the data in a database system, |
| 134 |
|
typically MySQL based, for later extraction and processing by the |
| 145 |
|
as it flows through the system. |
| 146 |
|
</p> |
| 147 |
|
|
| 148 |
< |
<p align="left"> |
| 148 |
> |
<p> |
| 149 |
|
The final section of the system links the Local Client Monitors to |
| 150 |
|
an alerting system. These Monitors can be configured to detect |
| 151 |
|
changes in the data past threshold levels. When a threshold is |
| 155 |
|
when a certain level is reached, certain alerting mechanisms fire |
| 156 |
|
through whatever medium they are configured to send. |
| 157 |
|
</p> |
| 158 |
< |
</font> |
| 112 |
< |
</td> |
| 113 |
< |
</tr> |
| 114 |
< |
</table> |
| 158 |
> |
</div> |
| 159 |
|
|
| 160 |
< |
<!--#include virtual="bottom.inc" --> |
| 117 |
< |
</td> |
| 118 |
< |
</tr> |
| 119 |
< |
</table> |
| 160 |
> |
<!--#include virtual="/footer.inc" --> |
| 161 |
|
|
| 162 |
< |
</body> |
| 162 |
> |
</div> |
| 163 |
|
|
| 164 |
+ |
<!--#include virtual="/menu.inc" --> |
| 165 |
+ |
|
| 166 |
+ |
</div> |
| 167 |
+ |
|
| 168 |
+ |
</body> |
| 169 |
|
</html> |
