Network Monitoring System by 55s6rHF


									Network Monitoring System

      Project Scope

      Submitted to: Mark Ramella, Network Supervisor
     Information Technology Services, Brock University

                                          May 7, 2004

                                  Melissa VanderLely
                                         COSC 3P99
                              Network Monitoring System

                                      Project Scope


       The network monitoring system (“the System”) will provide several services to

users based on their level of access. Any user will be able to view the basic connectivity

status of the system: whether it is completely functional, partially functional, or non-

functional. Both general users and system administrators will find use in the visual

representation of the monitored service. System administrators will be able to view a

more in-depth status assessment including measures of specific services on a given

server. Features such as Telnet, POP3 and others will be among those to be monitored.

       In addition to monitoring and displaying a server’s status, the System will also

maintain logs of all status events and changes. Text logs will be kept for each server and

each of its services. These logs will be protected and configurable by system


       No software other than a web browser will be required to use the System, and it

will be able to run on all browsers and on computers running Linux. All users should be

able to access and use the System from any computer; therefore it will be written in PHP

to ensure compatibility.

System Overview

       The System will have three main functions:

                      Monitor connectivity status of servers and services
                      Maintain logs of all status events and changes
                      Send e-mail notifications to Helpdesk when a service is down

Monitor Connectivity Status

The most important function of the System is to monitor the status of the servers. Using

some method of testing a service’s function, it will be able to determine if the service is

up or down. Users will use a web browser to view a simple status page with a graphical

representation of the server’s status: a red LED if the entire server is down, a yellow

LED if the server is up but some of its services are unavailable, and a green LED if the

server and all its services are working correctly.

       System administrators (“Administrators”) will have many more options available

to them as a protected service. They will be able to view a much more detailed status

report on the network, with the ability to monitor the status of specific services on the

server such as Telnet, POP3, IMAP and others. In addition to this, they will be able to

view the status logs. Administrators will also have the capability to configure several

options in the system. These options include:

                      Configuration of the log files
                      Additions to the log files
                      Choose who to notify in case of a problem with the network, and
                       the method of notification
                      Select the granularity of the monitoring cycle

The monitoring cycle granularity will determine how often a service is sampled by the

System. It will be possible for different services to have different monitoring cycle times;

however the minimum time between samplings will be one minute, as not to overload the

servers with unnecessary traffic.

Maintain Status Logs

       The System will keep log files which record two things: results of individual

polls, and any status changes that take place. Individual polls will be logged to ensure

that the System itself is monitoring the service as often as it should, and it will allow for

Administrators to easily isolate any trends that occur with regards to service up-time.

Status changes will be logged separately as well, for a quicker and easier way for

Administrators to view only samplings which resulted in a change in a service’s status, as

well as for message consolidation. It will also be possible for Administrators to add notes

to the log files for future reference.

        In order for them to be useful, logs must be kept on file for a significant period of

time. However, since this can consume a considerable amount of disk space, it will be

necessary for the log files to be consolidated, and subsequently removed, after a certain

time period. The life span of a log file will be configurable by Administrators, and log

files for different services will be able to have different life spans. Administrators will be

able to select the amount of time between when a log file is created and it is consolidated,

as well as the amount of time a log file is kept on the system. Aside from these

parameters, the log files will be completely self-maintaining.

Notify Helpdesk When a Service is Down

        Since the System will be continually monitoring every server and service on the

network, it will be able to quickly detect any problem that may occur. Upon this

detection, the System will automatically send a notification message to the appropriate

person. This notification will help the IT Centre respond more quickly and efficiently to

problems with the network. It will be possible for different services to have different

contact people and/ or different contact methods. Selection of the person who is notified,

and how they are notified, will be configurable by Administrators.

Design Considerations

        Because of the continuous nature of the System, the question arises that, if a

service which is sampled every minute were down for an hour, would its contact person

receive 60 messages notifying them of the problem. That question will be solved with

the use of the log files. Since there will be a separate file being kept of the times when

status changes occur, the System will be able to queue up and consolidate notification

messages and only inform the contact person when the status of the service changes, not

every time it is sampled.

       There are several considerations and question about the System that have not yet

been answered. These are:

                      Method of checking the status of a service
                      Which services need to be monitored
                      How to authenticate users

Method of Checking the Status of a Service

       There are several options that could be used in this situation, such as SMNP or

pinging, and it still remains to be seen as to which option, or collection of options, will be

the best for this purpose. Also, it has not been decided whether to test round trip or one-

way transmission to a service. If one way-transmission is tested, it would make the

sampling more efficient and therefore less taxing on the servers and services. However,

round-trip testing may be more useful for services such as e-mail which may be working

in one direction but not in the other. It is possible that this may become a configurable

option where Administrators can choose how they want to test.

Which Services Need to be Monitored

        Some services have been mentioned, such as basic connectivity to a server, and

Telnet, IMAP, and POP3 services. However, a complete list of all specific servers and

services that will be monitored will be needed, although not until much later in the

development. The System will be modular so that services can be added and/ or removed

from it in the future.

How to Authenticate Users

        There are several options for authentication, some more secure than others. The

options discussed so far were IMAP checking, a separate database for valid users and

passwords, local authentication, and RADIUS. When the security, configurability, and

convenience needs of Administrators become clearer, the proper choice for the System’s

needs will be chosen.


        In its most basic terms, the System will serve three purposes: to monitor the

connectivity status of servers and their services, to maintain logs of these status events

and changes, and to notify the appropriate individual when a service is unavailable.

Through many configurable options, Administrators will be able to customize the System

to suit the needs of each server and/ or service separately. Once the desired settings are

in place, the System will be completely self-sufficient including the clean-up of log files

and notification messages. Overall, the network monitoring system will be a useful

application, both for general users who wish to check the status of a server, and for those

working to maintain network and service availability.


To top