--- /dev/null
+<!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>
--- /dev/null
+<!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>
--- /dev/null
+<!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>
i-scream / www.i-scream.org.git / commitdiff
