www/cms/features.shtml

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<!--
    features.shtml
    Created by tdb1 30/10/2000
    Last edited 10/05/2001
-->


<html>

<head>
 <title>Overview and Features</title>
 <meta name="description" content="The i-scream Project is a central monitoring system for Unix, Linux and NT servers.">
 <meta name="keywords" content="i-scream, project, central monitoring system, unix, linux, nt, server, alert">
 <meta name="generator" content="notepad on acid, aye.">
</head>

<body bgcolor="#ffffff" link="#0000ff" alink="#3333cc" vlink="#3333cc" text="#000066">

<table border="0" cellpadding="2" cellspacing="2">
 <tr>
  <td valign="top">
<!--#include virtual="left.inc" -->
  </td>
  <td valign="top">
<!--#include virtual="title.inc" -->

    <table border="0" width="500">
     <tr>
      <td>
       <font size="2" face="arial,sans-serif">
       
       <center><h3>Key Features of The System</h3></center>
       
       <ul>
        <li>A centrally stored, dynamically reloaded, system wide configuration system</li>
        <li>A totally extendable monitoring system, nothing except the Host (which
          generates the data) and the Clients (which view it) know any details about
          the data being sent, allowing data to be modified without changes to the
          server architecture.</li>
        <li>Central server and reporting tools all Java based for multi-platform portability</li>
        <li>Distribution of core server components over CORBA to allow appropriate components
          to run independently and to allow new components to be written to conform with the
          CORBA interfaces.</li>
        <li>Use of CORBA to create a hierarchical set of data entry points to the system
          allowing the system to handle event storms and remote office locations.</li>
        <li>One location for all system messages, despite being distributed.</li>
        <li>XML data protocol used to make data processing and analysing easily extendable</li>
        <li>A stateless server which can be moved and restarted at will, while Hosts,
          Clients, and reporting tools are unaffected and simply reconnect when the
          server is available again.</li>
        <li>Simple and open end protocols to allow easy extension and platform porting of Hosts
          and Clients.</li>
        <li>Self monitoring, as all data queues within the system can be monitored and raise
          alerts to warn of event storms and impending failures (should any occur).</li>
        <li>A variety of web based information displays based on Java/SQL reporting and
          PHP on-the-fly page generation to show the latest alerts and data</li>
        <li>Large overhead monitor Helpdesk style displays for latest Alerting information</li>
       </ul>
       
       <center><h3>An Overview of the i-scream Central Monitoring System</h3></center>

       <p align="left">
        The i-scream system monitors status and performance information
        obtained from machines feeding data into it and then displays
        this information in a variety of ways.
       </p>
       
       <p align="left">
        This data is obtained through the running of small applications
        on the reporting machines.  These applications are known as
        "Hosts".  The i-scream system provides a range of hosts which are
        designed to be small and lightweight in their configuration and
        operation.  See the website and appropriate documentation to
        locate currently available Host applications.  These hosts are
        simply told where to contact the server at which point they are
        totally autonomous.  They are able to obtain configuration from
        the server, detect changes in their configuration, send data
        packets (via UDP) containing monitoring information, and send
        so called "Heartbeat" packets (via TCP) periodically to indicate
        to the server that they are still alive.
       </p>
       
       <p align="left">
        It is then fed into the i-scream server.  The server then splits
        the data two ways.  First it places the data in a database system,
        typically MySQL based, for later extraction and processing by the
        i-scream report generation tools.  It then passes it onto to
        real-time "Clients" which handle the data as it enters the system.
        The system itself has an internal real-time client called the "Local
        Client" which has a series of Monitors running which can analyse the
        data.  One of these Monitors also feeds the data off to a file
        repository, which is updated as new data comes in for each machine,
        this data is then read and displayed by the i-scream web services
        to provide a web interface to the data.  The system also allows TCP
        connections by non-local clients (such as the i-scream supplied
        Conient), these applications provide a real-time view of the data
        as it flows through the system.
       </p>
       
       <p align="left">
        The final section of the system links the Local Client Monitors to
        an alerting system.  These Monitors can be configured to detect
        changes in the data past threshold levels.  When a threshold is
        breached an alert is raised.  This alert is then escalated as the
        alert persists through four live levels, NOTICE, WARNING, CAUTION
        and CRITICAL.  The alerting system keeps an eye on the level and
        when a certain level is reached, certain alerting mechanisms fire
        through whatever medium they are configured to send.
       </p>
       </font>
      </td>
     </tr>   
    </table>

<!--#include virtual="bottom.inc" -->
  </td>
 </tr>
</table>

</body>

</html>
Revision:	1.1
Committed:	Fri May 25 18:00:32 2001 UTC (23 years, 7 months ago) by tdb
Branch:	MAIN
Log Message:	An overview of the system with a feature list. Taken from the Server User Guide.
#	User	Rev	Content
1	tdb	1.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>