From 8a0bb2b185497d3840c39b6f43493eaff86933b1 Mon Sep 17 00:00:00 2001 From: Tim Bishop Date: Fri, 25 May 2001 18:00:32 +0000 Subject: [PATCH] An overview of the system with a feature list. Taken from the Server User Guide. --- www/cms/features.shtml | 124 +++++++++++++++++++++++++++++++++++++++++ www/cms/features.xhtml | 124 +++++++++++++++++++++++++++++++++++++++++ www/features.shtml | 124 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 372 insertions(+) create mode 100644 www/cms/features.shtml create mode 100644 www/cms/features.xhtml create mode 100644 www/features.shtml diff --git a/www/cms/features.shtml b/www/cms/features.shtml new file mode 100644 index 0000000..3daf19c --- /dev/null +++ b/www/cms/features.shtml @@ -0,0 +1,124 @@ + + + + + + + + + Overview and Features + + + + + + + + + + + + +
+ + + + + + + + +
+ + +

Key Features of The System

+ +
    +
  • A centrally stored, dynamically reloaded, system wide configuration system
    • +
  • 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.
    • +
  • Central server and reporting tools all Java based for multi-platform portability
    • +
  • 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.
    • +
  • 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.
    • +
  • One location for all system messages, despite being distributed.
    • +
  • XML data protocol used to make data processing and analysing easily extendable
    • +
  • 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.
    • +
  • Simple and open end protocols to allow easy extension and platform porting of Hosts + and Clients.
    • +
  • 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).
    • +
  • 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
    • +
  • Large overhead monitor Helpdesk style displays for latest Alerting information
    • +
+ +

An Overview of the i-scream Central Monitoring System

+ +

+ 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. +

+ +

+ 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. +

+ +

+ 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. +

+ +

+ 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. +

+ +
+ + +
+ + + + diff --git a/www/cms/features.xhtml b/www/cms/features.xhtml new file mode 100644 index 0000000..3daf19c --- /dev/null +++ b/www/cms/features.xhtml @@ -0,0 +1,124 @@ + + + + + + + + + Overview and Features + + + + + + + + + + + + +
+ + + + + + + + +
+ + +

Key Features of The System

+ +
    +
  • A centrally stored, dynamically reloaded, system wide configuration system
    • +
  • 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.
    • +
  • Central server and reporting tools all Java based for multi-platform portability
    • +
  • 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.
    • +
  • 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.
    • +
  • One location for all system messages, despite being distributed.
    • +
  • XML data protocol used to make data processing and analysing easily extendable
    • +
  • 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.
    • +
  • Simple and open end protocols to allow easy extension and platform porting of Hosts + and Clients.
    • +
  • 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).
    • +
  • 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
    • +
  • Large overhead monitor Helpdesk style displays for latest Alerting information
    • +
+ +

An Overview of the i-scream Central Monitoring System

+ +

+ 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. +

+ +

+ 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. +

+ +

+ 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. +

+ +

+ 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. +

+ +
+ + +
+ + + + diff --git a/www/features.shtml b/www/features.shtml new file mode 100644 index 0000000..3daf19c --- /dev/null +++ b/www/features.shtml @@ -0,0 +1,124 @@ + + + + + + + + + Overview and Features + + + + + + + + + + + + +
+ + + + + + + + +
+ + +

Key Features of The System

+ +
    +
  • A centrally stored, dynamically reloaded, system wide configuration system
    • +
  • 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.
    • +
  • Central server and reporting tools all Java based for multi-platform portability
    • +
  • 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.
    • +
  • 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.
    • +
  • One location for all system messages, despite being distributed.
    • +
  • XML data protocol used to make data processing and analysing easily extendable
    • +
  • 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.
    • +
  • Simple and open end protocols to allow easy extension and platform porting of Hosts + and Clients.
    • +
  • 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).
    • +
  • 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
    • +
  • Large overhead monitor Helpdesk style displays for latest Alerting information
    • +
+ +

An Overview of the i-scream Central Monitoring System

+ +

+ 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. +

+ +

+ 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. +

+ +

+ 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. +

+ +

+ 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. +

+ +
+ + +
+ + + + -- 2.44.0