ViewVC Help
View File | Revision Log | Show Annotations | Revision Graph | Root Listing
root/i-scream/web/www/cms/features.xhtml
(Generate patch)

Comparing web/www/cms/features.xhtml (file contents):
Revision 1.2 by tdb, Sat Feb 9 15:00:42 2002 UTC vs.
Revision 1.4 by tdb, Tue Mar 23 20:22:31 2004 UTC

# Line 1 | Line 1
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
# Line 58 | Line 105
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
# Line 81 | Line 128
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
# Line 98 | Line 145
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
# Line 108 | Line 155
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>

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines