+++ /dev/null
-<!--#include virtual="/doctype.inc" -->
- <head>
- <title>
- CMS Features
- </title>
-<!--#include virtual="/style.inc" -->
- </head>
- <body>
- <div id="container">
- <div id="main">
-<!--#include virtual="/header.inc" -->
- <div id="contents">
- <h1 class="top">
- CMS Features
- </h1>
- <h2>
- Problem Specification
- </h2>
- <h3>
- Original Problem
- </h3>
- <p>
- This is the original specification given to us when we
- started the project. The i-scream central monitoring system
- meets this specification, and aims to extend it further.
- This is, however, where it all began.
- </p>
- <h3>
- Centralised Machine Monitoring
- </h3>
- <p>
- The Computer Science department has a number of different
- machines running a variety of different operating systems.
- One of the tasks of the systems administrators is to make
- sure that the machines don't run out of resources. This
- involves watching processor loads, available disk space,
- swap space, etc.
- </p>
- <p>
- It isn't practicle to monitor a large number of machines by
- logging on and running commands such as 'uptime' on the
- unix machines, or by using performance monitor for NT
- servers. Thus this project is to write monitoring software
- for each platform supported which reports resource usage
- back to one centralised location. System Administrators
- would then be able to monitor all machines from this
- centralised location.
- </p>
- <p>
- Once this basic functionality is implemented it could
- usefully be expanded to include logging of resource usage
- to identify longterm trends/problems, alerter services
- which can directly contact sysadmins (or even the general
- public) to bring attention to problem areas. Ideally it
- should be possible to run multiple instances of the
- reporting tool (with all instances being updated in
- realtime) and to to be able to run the reporting tool as
- both as stand alone application and embeded in a web page.
- </p>
- <p>
- This project will require you to write code for the unix
- and Win32 APIs using C and knowledge of how the underlying
- operating systems manage resources. It will also require
- some network/distributed systems code and a GUI front end
- for the reporting tool. It is important for students
- undertaking this project to understand the importance of
- writing efficient and small code as the end product will
- really be most useful when machines start run out of
- processing power/memory/disk.
- </p>
- <p>
- John Cinnamond (email jc) whose idea this is, will provide
- technical support for the project.
- </p>
- <h2>
- Features
- </h2>
- <h3>
- Key Features of The System
- </h3>
- <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>
- <h3>
- An Overview of the i-scream Central Monitoring System
- </h3>
- <p>
- 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>
- 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>
- 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>
- 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>
- </div>
-<!--#include virtual="/footer.inc" -->
- </div>
-<!--#include virtual="/menu.inc" -->
- </div>
- </body>
-</html>
i-scream / www.i-scream.org.git / blobdiff