Network Monitoring System
Submitted to: Mark Ramella, Network Supervisor
Information Technology Services, Brock University
May 7, 2004
Network Monitoring System
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.
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.
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.