faculty of science computer science department
TRANSCRIPT
i
FACULTY OF SCIENCE
COMPUTER SCIENCE DEPARTMENT
REMOTE SERVER MONITORING SYSTEM WITH SMS NOTIFICATIONS
BY
SHOKO EDDINGTON
(B1438879)
SUPERVISOR: MR MAPENDUKA
A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS
OF THE BACHELOR OF SCIENCE HONOURS DEGREE IN COMPUTER
SCIENCE
JUNE 2018
i
APPROVAL FORM
The undersigned certify that they have supervised the student Shoko Eddington (B1438879)
dissertation entitled, “Remote server monitoring system with SMS notifications”, submitted in
partial fulfilment of the requirements of the Bachelor of Computer Science Honours’ Degree
at Bindura University of Science Education.
………………………… …………………………
STUDENT DATE
....................................... …………………………..
SUPERVISOR DATE
……………………….......... …………………………
CHAIRPERSON DATE
ii
DEDICATION
Many thanks to my parents Mr C. Shoko and Mrs S. Matutu for the incredible support they
gave me in all good and bad times of my career. Without you, I could not have completed my
thesis. Secondly, I would like to dedicate this report to Steward bank ICT team, the managers
and all my friends for the inspiration they gave to my academic and professional endeavours
which contributed to the success of this thesis. May God bless you all the times.
iii
ACKNOWLEDGEMENTS
I would first like to thank God Almighty for his faithfulness and grace upon my life. My parents
Mr and Mrs Shoko thank you very much for the un-imaginable support, wise counsel and
sympathetic ear.
I would also like to thank the ICT team from my internship at Steward bank and Bindura
University of Science Education for the wonderful opportunity to complete my study, despite
all the challenges which had frustrated all my efforts. Without your support, guidance and
understanding, I wouldn’t have made it this far, especially with my dissertation.
Finally, there are my friends. We were not only able to support each other by deliberating over
our problems and findings but also happily talking about things other than just our papers.
Thank you very much, everyone!
iv
ABSTRACT
The stability of IT network and infrastructure has been of growing concern since most of the
enterprises run multiple serves to provide business critical services. The necessity for
exploiting the gaps in server monitoring has enlightened the need to design an effective remote
server monitoring system that addresses some of the gaps in the monitoring of servers. This
thesis delves into the design of an effective centralised server monitoring system with SMS
notifications that will notify the administrators about the health of the servers which will solve
some server monitoring gaps within ICT such as delayed response to server downtime.
v
Contents
CHAPTER ONE: INTRODUCTION ................................................................................................. 1
1.0 INTRODUCTION ....................................................................................................................... 1
1.1 BACKGROUND OF STUDY .................................................................................................... 1
1.2 PROBLEM STATEMENT ........................................................................................................ 2
1.3 AIM .............................................................................................................................................. 2
1.4 RESEARCH OBJECTIVES ...................................................................................................... 2
1.5 RESEARCH QUESTIONS ........................................................................................................ 2
1.6 SCOPE OF THE RESEARCH .................................................................................................. 3
1.7 SIGNIFICANCE OF THE RESEARCH .................................................................................. 3
1.8 ASSUMPTIONS OF THE STUDY ........................................................................................... 3
1.9 CHAPTER SUMMARY ............................................................................................................. 3
CHAPTER TWO: LITERATURE REVIEW .................................................................................... 4
2.0 INTRODUCTION ....................................................................................................................... 4
2.1 WHY MONITORING AUTOMATED? ............................................................................... 4
2.2 REMOTE ACCESS ................................................................................................................ 5
2.3 SIMILAR WORKS ..................................................................................................................... 5
2.3.1 Wireshark ............................................................................................................................. 5
2.3.2 Zabbix ................................................................................................................................... 5
2.3.3 Tcpdump ............................................................................................................................... 6
2.3.4 Nagios .................................................................................................................................... 6
2.3.5 Open-NMS. ........................................................................................................................... 7
2.3.6 Zenoss .................................................................................................................................... 7
2.3.7 Nim soft monitor .................................................................................................................. 7
2.4 CONCLUSION ........................................................................................................................... 8
2.5 PROPOSED SYSTEM ............................................................................................................... 9
CHAPTER 3: RESEARCH METHODOLOGY ............................................................................. 11
3.0 INTRODUCTION ..................................................................................................................... 11
3.1 TECHNOLOGY BEHIND MONITORING SNMP PROTOCOL ...................................... 11
3.2 RESEARCH DESIGNS ............................................................................................................ 12
vi
3.3 SOFTWARE DESIGN ............................................................................................................. 13
3.3.1 DESIGN TOOLS ............................................................................................................... 13
3.3.2 SYSTEM DESIGN PROCESS ......................................................................................... 13
3.3.3 SOFTWARE DEVELOPMENT METHODOLOGY .................................................... 14
3.3.4 METHODS USED IN THE SYSTEM DESIGN ............................................................. 14
3.3.5 USE CASE DIAGRAM ..................................................................................................... 15
3.3.6 ACTIVITY DIAGRAM ..................................................................................................... 15
3.3.7 SEQUENCE DIAGRAM ................................................................................................... 16
3.3.8 DATABASE DESIGN........................................................................................................ 17
3.3.9 USER INTERFACE DESIGN .......................................................................................... 17
3.4 IMPLEMENTATION .............................................................................................................. 19
3.4.1 SYSTEM FUNCTIONALLY AND SCREEN DUMPS .................................................. 19
3.4.2 CLIENT SIDE .................................................................................................................... 20
3.4.3 LIVE MONITORING SECTION .................................................................................... 21
3.4.4 SERVER SIDE ................................................................................................................... 22
3.5 POPULATION AND SAMPLING .......................................................................................... 22
3.6 SYSTEM TESTING AND EVALUATION ............................................................................ 23
3.7 RESEARCH INSTRUMENTS ................................................................................................ 23
3.7.1 QUESTIONNAIRES ......................................................................................................... 23
3.7.2 OBSERVATIONS .............................................................................................................. 24
3.8 METHODS OF DATA ANALYSIS TO BE USED ............................................................... 24
CHAPTER 4: DATA PRESENTATION AND ANALYSIS ........................................................... 26
4.0 INTRODUCTION ..................................................................................................................... 26
4.1 SYSTEM PERFORMANCE TESTS ...................................................................................... 26
4.1.1 COMPUTATIONAL TIME .............................................................................................. 26
4.2 ANALYSIS OF THE QUESTIONNAIRES ........................................................................... 27
4.2.1 QUESTIONNAIRES RESPONSE ................................................................................... 27
4.2 RESEARCH FINDINGS .......................................................................................................... 35
4.2.1 EFFICIENCY OF THE PROPOSED SYSTEM ............................................................. 35
4.3 CHAPTER SUMMARY ........................................................................................................... 35
CHAPTER FIVE: CONCLUSION ................................................................................................... 36
5.0 INTRODUCTION ..................................................................................................................... 36
vii
5.1 AIMS AND OBJECTIVES REALISATION ......................................................................... 36
5.2 FUTURE WORK ...................................................................................................................... 36
viii
Table of Figures
Figure 1: Use case Diagram .................................................................................................................. 15
Figure 2: Activity Diagram showing remote access ............................................................................. 16
Figure 3: Sequence Diagram showing the connection Process ............................................................ 17
Figure 4: User interface design process ............................................................................................... 19
Figure 5: Login screen .......................................................................................................................... 20
Figure 6: Configuration screen ............................................................................................................. 21
Figure 7: Live monitoring Screen ......................................................................................................... 22
Figure 8: Difficulties using the Remote server monitoring system ...................................................... 28
Figure 9: Frequency of downtime ......................................................................................................... 29
Figure 10: Time Effective method ........................................................................................................ 30
Figure 11: Simplifying System Administrators' work .......................................................................... 31
Figure 12: Improving response time ..................................................................................................... 33
Figure 13: Performance rating .............................................................................................................. 33
Figure 14: Overall rating ....................................................................................................................... 35
ix
List of Tables
Table 1: Problems identified and proposed system ................................................................................ 9
Table 2: Computational time results .................................................................................................... 27
Table 3: Response rate .......................................................................................................................... 27
Table 4: Downtime frequency .............................................................................................................. 29
Table 5: Time effective method ............................................................................................................ 30
Table 6: Simplifying work .................................................................................................................... 31
Table 7: Improving response time ........................................................................................................ 32
Table 8: Performance rating .................................................................................................................. 33
Table 9: Overall rating .......................................................................................................................... 34
1
CHAPTER ONE: INTRODUCTION
1.0 INTRODUCTION
In the past, maybe because the transactions were not as fast and voluminous back then, users
could simply wait until the service comes back up again or revert to manual methods. With the
fast adoption of Information and Communication Technology (ICT) and the expansion of the
internet has caused a lot of organisations to automate most of their business processes around
the world. Today organisations of all types around the globe utilise the ICT, not only for cutting
costs and improving efficiency but also for better service provision and reducing distance
barriers. There is an increase in business’ dependence on data and technology to deliver
business critical services to the end users. Multiple enterprises run multiple servers to deliver
their services. However, with the increase in the number of transactions, the cost of downtime
is also increasing.
Many of the ICT problems are reported by the end users which is not a health approach. It is
now the major concern in businesses that can affect the quality of service provided to the
customers and may damage business reputation and eventually lead to loss of business
productivity.
Server monitoring is basically a preventative measure to help on detecting most of the issues
with the servers and network before they cause any major issues that affect business
productivity and the customers. It is a process of continuously scanning servers on a designated
network for any failures or any irregularities that are detected by server monitoring software.
The performance of each server is very critical because the failure of one server can impact on
the delivery of business-critical services. Server monitoring tools help in picking up any small
issues before they evolve into a huge and costly problems.
Therefore, it is imperative to know any performance issues proactively so that they are
identified at the early stage and fixed before they turn big and pose a threat to business.
1.1 BACKGROUND OF STUDY
In the past, when only a small number of people used technology for transactions and
transactions were not voluminous and fast. If a service goes down, people would simply revert
to manual methods until the service is up. Now due to the increase in business dependence on
data and technology, several enterprises run multiple servers to deliver services to their
customers. The increase in the number of transactions leading to overload and the rapid change
2
of technology leading to additions of new features on systems causing the server failures and
crushes are a growing concern in ICT to ensure service availability to the customers and
maintain business reputation. Server monitoring tools have been developed which use charts,
graphs and colour codes to give data about the status of the servers.
As an attempt to solve and address some of the gaps in monitoring of ICT infrastructure and
networking, a remote desktop server monitoring tool is proposed.
1.2 PROBLEM STATEMENT
With the current server monitoring tools used in the server environment, there is a delay in the
response to any failures and faults on servers. In most organisation especially in Zimbabwe,
information on the availability and performance of servers can only be available within the
organisation network. Also, even within the server environment it takes time to notice a server
downtime because there is need to logon to the monitoring tool and check the status of the
servers. This causes administrators to be notified about the downtime late after some time of
service unavailability. Because of these monitoring gaps, many IT issues are reported by end
users which is not a heathy approach because it damages business reputation due to
unavailability of service to the customers. Delays in response to server downtime causes
business to lose a lot of opportunities and productivity.
1.3 AIM
To develop a remote server desktop monitoring tool that is capable of sending SMS
notifications to the administrators about the status of the servers.
1.4 RESEARCH OBJECTIVES
1. To develop a system that allows for remote monitoring of server availability and
performance through a desktop tool and SMS notifications.
2. To evaluate the usability of the resulting remote server monitoring system.
3. To evaluate the system’s response time to server downtime.
1.5 RESEARCH QUESTIONS
1. Why remote server monitoring with SMS notifications?
2. How will the remote server monitoring tool reduce the response time?
3. How do other users and server administrators evaluate the effectiveness of the Server
monitoring tool?
3
1.6 SCOPE OF THE RESEARCH
The research focuses to reduce the server monitoring gaps to ensure the availability of service
and good performance of servers in every organisation that uses servers and internet to provide
their services. The usage would be in small and medium sized organisations.
1.7 SIGNIFICANCE OF THE RESEARCH
Due to the high volumes of transactions in many systems, for example banking systems due to
the use of online transactions, servers tend to abnormally shutdown, restart or crush.
The project will be designed in such a way that whenever a server shutdown or restarts, the
system will notify the administrators. This allows fast attention to the servers to make sure
services are back in time and the business flow is back to normal before the end users start
complaining.
Logs are kept for inference and analysing of the causes of the crushes. This will help in the
decision making for example when disks are close to full they tend to perform slow. Also
ensure performance as measured by response time.
1.8 ASSUMPTIONS OF THE STUDY
In most cases the administrators have organisational VPN to connect to the organisational
network remotely and fix issues reported through SMS if they do not need physical attention.
1.9 CHAPTER SUMMARY
This chapter highlighted the introduction of the research project. The following chapters will
address the problems highlighted in this chapter based on the aims and objectives produced.
4
CHAPTER TWO: LITERATURE REVIEW
2.0 INTRODUCTION
Prior to implementation of the proposed system, a sufficient research on the published
literatures related to this topic was done. In this part, the summary of the mentioned researches
and investigations will be discussed. All the knowledge and information gained from the
investigation had been thoroughly helpful in order for the proposed system to be implemented.
The main idea has been inspired from the researches which have been previously done.
Two main areas useful for the implementation of the proposed system, have been investigated
in this part which are Server Monitoring and Remote Access. The purpose of this research will
be defined and concepts which have been helpful in understanding technologies used in
development of the proposed system have been collected.
Finding the faults and disconnections on the servers of organizations would be performed by
having a proper supervision and management on the servers. The servers must be managed to
capture the entire server’s performance and maintain any possible disconnections. In case of
any failure occurrences in the servers, an urgent monitoring and maintenance will be required.
In an enterprise for instance, having an urgent monitoring is significant as in such these cases
even a short delay can lead the enterprise to failure in achieving its goals. Thus, in an enterprise
or a large organisation, the main focus of remote server monitoring must be on monitoring the
internal and external behaviour and activities of the workstations connected to the network.
2.1 WHY AUTOMATED MONITORING?
Every business is growing in terms of systems, applications, hardware, number of servers and
each equipment has a number of parameters to check. It is very difficult to track data centre
precisely. Considering the normal 24X7X356 operations, do we really know what our servers
are doing? or how they are behaving? Do they have all vitals at place like temperature, RAM
threshold, CPU utilization, threads per CPU, Database services, Application cluster running
properly? or there is some deviation from the normal track?
Reactive Approach is the only option available for system administrators after information
passed about the system by end users. There is no mechanism for directly interacting with
server vitals. Industry is moving towards Pro Active approach where there is a layer between
system administrator and data centre that provides proactive measures to system administrators
to act precisely and pass on information to upper management with help of reports. With help
5
of Simple Network Management Protocol (SNMP) we can able to track all performance related
information in database for Management Information Systems (MIS) reporting and can link
with KPI (Key Performance Index).
2.2 REMOTE ACCESS
In a server monitoring system, remote access will give authorised access to server
administrators for performing required actions on the systems connected to server. For
providing access remotely, information of Transmission Control protocol (TCP) will be
translated by the proxy server for the router’s console port and will receive it back. As regards
this process, all connected devices to the mentioned proxy server would be ready for remote
access, performing by server’s user. The admin of the server will decide about the required
activity on each connected device.
2.3 SIMILAR WORKS
In this part of this chapter, the similar works to the proposed remote server monitoring
application will be discussed. For each mentioned software, some explanations along with its
pros and probably cons will be given in order to providing some familiarities with such these
applications.
2.3.1 Wireshark
According to a research by Mazaheri Shirin in 2015, one of the most famous tools for
monitoring and analysing servers is Wireshark. Wireshark provides many functionalities such
as packet monitoring and analysing, Voice over Internet Protocol (VoIP) analysing and traffic
monitoring (Suri, S. & Batra, V, 2010). This application captures the packets in the network
and allows to analyse and save the captured packets (Suri, S. & Batra, V., (2010). This tool has
many advantages as well as some disadvantages. For some instances, being free of charge,
being open source and ability to running on all operating systems (independent of platform)
can be considered as some of its strengths. Besides being an admirable packet analyser, its
interface is difficult to use. In addition, Wireshark requires full understanding of Transmission
Control Protocol/Internet Protocol (TCP/IP). The mentioned challenging issues, can be
considered as some weaknesses of this tool.
2.3.2 Zabbix
Zabbix was developed by Alexei Vladishev and was first released in 2001. It can monitor the
basic SMTP, HTTP, ICMP services without installation of agents. Zabbix has three core
components for its functioning which are Daemons, Agents and Web interface. It is capable of
6
using many flavour of commercial or open source databases like My SQL, SQLite, Oracle
(Kaushik, 2010). Daemons collects data and send it to the monitoring server. Zabbix is fully
configurable from its web front end and so it is easier to use Zabbix than the popular Nagios
whose configuration requires several text files. Further, Zabbix combines both monitoring and
trending functionality. The web monitoring function of Zabbix allows users to monitor the
availability and performance of web-based services over time. Moreover, this functionality
allows Zabbix to log into a web application periodically and run through a series of typical
steps being performed by a customer. It’s open-source and has a well-designed Web GUI and
overall concept. Zabbix offers dedicated agents and an active user community. However,
Zabbix is not suitable for large networks with 1,000+ nodes due to PHP performance and Web
GUI limitations, a lack of real-time tests, as well as complicated templates.
2.3.3 Tcpdump
Tcpdump is a famous network monitoring tool. Usually, the packets which are not addressed
to the network, are subject to be ignored in the network interface (Stephen, P., Olejniczak &
Kirby, B., 2007). This software captures all the packets in the network, regardless of the
addressing by placing the interface on promiscuous mode. So, by using this tool for monitoring
servers, administrator would be able to examine the packets and also based on the type of
information stored in the packets’ header, administrator will be able to analyse the network
traffic (Suri, S. & Batra, V. ,2010). Tcpdump is a powerful tool which is able to being run on
UNIX based platforms and its structure is command line. In practice, this software is similar to
Wireshark and both of them are packet capturing programs which capture packets of any
protocols and display the captured packets to administrator (Stephen, P., Olejniczak & Kirby,
B., 2007).
2.3.4 Nagios
Nagios is the most popular monitoring system and is bundled with almost all Linux
distributions. There are several other plugins, add-on scripts that can be customized and used
with the Nagios (Kaushik, Anshul, 2010). Nagios is a light weight program and provides a
comprehensive monitoring tool that can used to monitor all protocols and network devices. It
is also capable of providing real time comprehensive graphs and trend analysis. SLA (Service
Level Agreement) can be traced on the basis of data availability (Kaushik Anshul, 2010).
Nagios is developed in C and installation is neat and easy. Code is stable and bandwidth
resources requirement is lesser than any other tools. Automatic discovery is also available and
7
is quite efficient in identifying new servers. Although it was observed that a device is identified
another time by the server on reboot. Overall user interface is simple and easily accessible.
Alert definitions and escalations can be configured using templates at the granular level
(Kaushik, Anshul, 2010). The tool has a difficult configuration because it lacks automatic
device discovery.
2.3.5 Open-NMS.
Open NMS, initially a Network Management System and one of the oldest monitoring software
in the early 2000 identifies servers in the data centre and services are linked to the interfaces
(Kaushik, 2010). The system is developed on J2EE framework. The configuration is step by
step and very simple. Documentation is good and community is active. Being the oldest system
ample of support is available. Virtual appliances are not available but demo is available on the
NMS website. Open NMS has a service called eventd which differentiates between the events
being used by the Open NMS server itself. Installation on windows is easy and it is self-
explanatory. Ample of documentation is available on website. MIS repots can be generated for
the historic data.
2.3.6 Zenoss
This tool was developed by Bill, Erik Dahl, Mark Hinkle and is capable of monitoring all
devices, servers, network and application inside data centre (A. Kaushik, 2010). The core
database and the events are stored in MySQL database. It comes with an integrated package
with all incorporated modules. Data is also stored in Configuration Management Database and
ZODB. It has also enterprise version with support and additional functionalities. There are
several services used by the program like ZENPin, ZENStaus, ZENModellar, ZENSyslogs
which can be configured either separately on each server providing scalability to the
deployment. It is based on the SNMP.
2.3.7 Nim soft monitor
This tool delivers the essential capabilities that need to proactively monitor and manage
performance. It is a single platform with an extensible architecture that can help in monitoring
every system and service that matters. It is an efficient and scalable platform that is used to
monitor and manage servers such as Windows, Linux and UNIX. This proposes and provides
a mean to implement another solution which involves an effective and efficient use of ICMP
and SNMP protocols for effective network monitoring, both complementing each other with
network and management information (Mahajan, Joshi, & Khajuria, 2012).
8
According to (Zeng & Wang, 2009) introduced how to monitor servers through simple network
management protocol (SNMP). They expanded MIB (Management Information Base)
resources by defining MIB objects to monitor the resources of sever and use multi-threading
technology to collect data and process them, which can improve the collection efficiency. There
are two types of network management protocol in computer network management field, which
occupy the dominated position. One is common management information protocol and service
(CMIP/CMIS), which is proposed by OSI organization. And the other is SNMP, which is put
forward by IETF.
Liu Yucheng et. al. focused on real-time monitoring and so being difficult to more directly and
conveniently understand the software performance issues by the historical data analysis and
remote monitoring, this presents a server performance monitoring system program based on
B/S mode. That system uses B/S mode enables administrators to view the server-side situation
in the performance testing and network maintenance.
2.4 CONCLUSION
Rather than going for purely technological needs, we also need to look at the best solution that
can fit for any business scenario, skill set of people handling the system, its core users and
resource availability.
Nagios is the tool that is being used by the masses. Now we have options of virtual
images/appliances from Nagios. Zabbix has quick reporting capabilities but administrators may
waste precious trying to attend to small issues like a server hang which only needs a restart
which the system can do at its own. Open NMS is very well suited for the core networking
environments. It can be concluded that each of the solution has its own advantages and
drawbacks. SNMP protocol is widely used for developing latest monitoring solutions for
network devices because of its lean structure and presence in mostly all operating systems.
After implementing the proposed solution, we expected changes in the areas mentioned in the
trailing table. SNMP on its own its not enough unless it is implemented with other techniques
like a ping to verify that what the monitoring system is what it seems. Tcpdump and Wireshark
are packet capturing programs which capture packets of any protocols and display the captured
packets to administrator. Tcpdump is UNIX and has a command line interface which means
that it is platform dependent. Wireshark requires full understanding of Transmission Control
Protocol/Internet Protocol (TCP/IP). The system should address the problems listed in the table
below.
9
Table 1: Problems identified and proposed system
2.5 PROPOSED SYSTEM
There are several monitoring techniques and protocols used to successfully monitor a network,
server and systems. An application or monitoring software must be able to collect, process and
present data in a user-friendly format. There should be a protocol or method for transmitting
information between the monitored elements and the monitoring software. Some of techniques
are ping, simple network management protocol (SNMP), windows management
instrumentation (WMI) and scripts. The proposed system will combine the ping and SNMP to
complement the shortcomings of one protocol.
A ping is when the network administrator tests the reachability and availability of a host in an
IP network. The results determine whether a host in a network is active or not. Furthermore, it
can measure the transmission time and packet loss when communicating with a host. A ping
technique increases traffic on the network that causes the network to be slow. Therefore, it will
be costly to use this technique to monitor the servers continuously all the time.
SNMP is a network management protocol used for exchanging information between hosts in a
network that includes network monitoring software. SNMP works on the layer 7 of OSI model
(Application Layer) and uses UDP (User Datagram Protocol) port for communication. The
proposed system is an agent based. It contains the managed device, agent which is the
PROBLEMS PROPOSED SYSTEM
Manual punching and monitoring of
data
Automating data collection of server KPIs.
Long time for notification of system
down
Real time notifications through SMS and possible cause of the
problem with a possible corrective measure.
Difficulty in alerts to system owners
and administrators
Alerts are triggered if a certain threshold value is reached.
Loss of incidents and night time
monitoring
Remove the night monitoring.
Non-productive jobs by System
Administrators
Reduce the problem of continuous monitoring by system
administrators
No proper dashboard central system Using a simple and user-friendly desktop application
Network traffic Use an agent instead of a continuous ping
10
application that collects information about the status and performance of the monitored device
and a sever management system (client side). In the case that the proposed system fails, the
scripts are always an option.
11
CHAPTER 3: RESEARCH METHODOLOGY
3.0 INTRODUCTION
This chapter outlines all the methods and techniques that was used in the design and
development of the server monitoring tool. It involves the database structure and system
architecture of the information flows from one point to another. It also involves how the
implementation process was done. Thus, this chapter reveals the overview of each method used
to carry out the research.
3.1 TECHNOLOGY BEHIND MONITORING SNMP PROTOCOL
This protocol was used to develop the server monitoring tool. SNMP (Simple Network
Management Protocol) has a few pieces that combine to provide a powerful monitoring
solution. System Network Management Protocol is used for monitoring network devices and
other data centre equipment. It is part of the TCP/IP protocol suite. In a data centre environment
each server with an installed agent communicates with SNMP to broadcast the status of a
device on which agent is installed. The manager (Monitoring Server) collects the data from
various nodes.
The SNMP network consist of three key elements
1. Devices (Servers): On which the Agent is installed.
2. Agents: Installed on devices (Servers).
3. Monitoring Server: Software which receives captured data from agents.
Data can be gathered in several ways it can use Get Request, Set Request, GetNext Request
and Response Trap. Monitoring system can request a value from the server “get” or it can set
“trap” or a threshold of value by defining a trigger point.
Firstly, SNMP is comprised of a list of elements that return data on a particular device. It could
be CPU, the average bits per second transmitted in the last five minutes, or the number of
errored frames. Each of these elements is assigned a numeric ID which are grouped
hierarchically. Secondly, an SNMP service (also called an agent) runs on the target device,
keeping track of each of those elements and what their current values are. While it seems like
a lot of data, the agent is running locally, and the data points are small and easily managed.
Plus, the agent is only keeping the current number, so there is no on-going storage of
information.
12
Finally, that agent provides that data based on either an SNMP Trap trigger, or an SNMP Poll
request. The combination of both allows you to collect information about a device, either at
pre-set collection intervals (polls), or only when a specific threshold has been exceeded (traps).
3.2 RESEARCH DESIGNS
According to (Polit, D.F., Beck, C.T., Hungler, B.P. 2004), research design can be defined as
a plan that describes how, when and where data is to be collected and analysed for the purposes
of a research. This can be thought of as a light to how the study is to be conducted. System
design can be thought of as the process of designing and defining the architecture, components,
modules and data for the whole system to satisfy the specified requirements. The main
objective of this stage is to ensure that the system is developed efficiently, effectively,
maintainable and reliable. System interfaces should be designed with the end user in mind and
the designed work easier to implement.
In coming up with a model for the remote server monitoring system with SMS notifications,
the researcher had to review some of the models and their protocols in literature including their
designs. The functionality and performance of these systems was analysed in order to come up
with a design that would eliminate some of the problems that were found to exist with these
systems. The researcher also conducted unstructured interviews with the personnel at Steward
Bank with the aim of trying to understand how they are monitoring their servers and how the
cost of downtime is affecting business as measured by response time. This helped in coming
up with a model that encompasses most of the details and procedures to remotely monitor
server performance and availability. Suggestions and ideas concerning features that a remote
server monitoring tool should consist of were also taken from the Steward Bank ICT personnel
for the model design.
The researcher also gathered some data through observation and experiencing with the
problems of server downtime from the industrial attachment that lead to support the design of
the model. Software performance tests were carried out as a way of evaluating the system`s
performance in its intended environment. Different types of tests were conducted, each test
giving an evaluation of the system under different scenarios. The evaluation of the system`s
attributes that could not be directly determined by system performance tests the system users`
perceptions had to be taken into account and this was done by collecting the data from the
server administrators. An analysis of data from these questionnaires was then used for the
13
system evaluation, thus the evaluation of the system was a combination of system tests and
users` perceptions.
3.3 SOFTWARE DESIGN
3.3.1 DESIGN TOOLS
The proper development of the ideal system with the prescribed requirements and suits the
environment that it is going to be used in involves the use of appropriate development tools.
The researcher decided to use the following tools to achieve the objectives of this study.
1) DevExpress Winforms
2) Visual studio Vb.net
3) SMS API (json formatted)
4) MySQL database
5) Navicat
MySQL Database
This is a relational database management system (RDBMS) which was adopted for its typical
use of storing and retrieving data from a relational database making it perfect candidate for use.
Also, it generally offers fewer features than other databases, which then means that it is fast
and due to its speed, the system will overall be fast.
3.3.2 SYSTEM DESIGN PROCESS
3.3.2.1 REQUIREMENTS SPECIFICATION
These are the services that the system will be expected to provide to its end users. The system
users include the server administrators and system administrators.
3.3.2.2 FUNCTIONAL REQUIREMENTS
This is a declaration of the intended function of the system and its components that is how the
system is expected to respond or behave in the case a certain input. This is primarily what the
system is expected and should do:
The system should be able to monitor any server provided its IP address.
On reaching the threshold values of CPU utilisation and disk space, the system should
be able to send alerts to the administrators.
The system should be able to give a summary or status values of the server critical
parameter including the CPU utilisation and disk space.
14
The system should be able to send notifications to the administrators when the server
is not available (downtime).
The system should be able to produce a downtime and performance log.
The system should be able to verify a downtime using a ping.
3.3.2.3 Non-Functional Requirements
Basically, non- functional requirements describe how the system works i.e. how the system is
supposed to be (Glinz, M 2007). The below are the non-functional requirements of the remote
server monitoring system with SMS notifications:
Performance requirements
Availability requirements
Usability requirements
Reliability requirements
Accessibility requirements
3.3.3 SOFTWARE DEVELOPMENT METHODOLOGY
This is a framework that is used to structure, plan and control the process of developing a
software from a particular perspective. In the development of the remote server monitoring
tool, the researcher adopted the agile development methodology specifically extreme
programming. The agile software development methodology is a conceptual framework for
undertaking projects as incremental iterations. The adoption of this methodology saw the
development of the RSM model being done in small incremental parts, with each completed
part building on to the functionality of previously completed part of the model.
The reason for the adoption of the methodology is its ability to be used in the development of
time critical applications and its flexibility to change. It allowed the completion of the Remote
server monitoring system within a limited time frame. Because of the need to always make
additions and subtractions to the functionalities and features of the system during development
to achieve the stated objectives of the research, agile methodology was adopted because it
makes it easier to implement these changes.
3.3.4 METHODS USED IN THE SYSTEM DESIGN
Object Oriented Analysis and Design (OOAD) is a technical approach for analysing and
designing an application or system by applying object-oriented programming and using visual
modelling throughout the development life cycles. The analysis done using OOAD can be
15
visualised using the Unified Modelling Language (UML) which is a standard language for
specifying, visualizing, constructing and documenting the artefacts of software systems. UML
provides a variety of diagrams to represent the structure and design of the software system.
UML provides a variety of diagrams to represent the structure and design of a software system.
Of these various diagrams, the researcher decided to use the use case, activity diagram and the
sequence diagram.
3.3.5 USE CASE DIAGRAM
A use case diagram can summarise the details of the system’s users (actors) and their
interactions with the system. However, it does not show the details of each use case but only
summarises the relationships between use cases, actors and the system. The figure below
illustrates a use case diagram for Remote server monitoring system actors.
client adminserver admin
Start Server
Connection
Remote Access
Server parameters Status
Notifications and alerts
Disconnection
Figure 1: Use case Diagram for users’ interaction with the system.
3.3.6 ACTIVITY DIAGRAM
Activity diagram is another important diagram in UML to describe the dynamic aspects of the
system. Activity diagram is basically a flowchart to represent the flow from one activity to
another activity. The activity can be described as an operation of the system. The researcher
decided to use an activity diagram for the purpose of capturing the dynamic behaviour, and the
16
sequence from one activity to another of the Remote server monitoring system. Below is an
activity diagram for the Remote server monitoring system.
Client Application Server side Application
Connect to server,
using IP AddressStarting the server
Client system Server application
Disconnect and
notification
Figure 2: Activity Diagram showing remote access
3.3.7 SEQUENCE DIAGRAM
Sequence diagram is another method for UML technique. This method represents the sequence
of activities in this application. In this diagram the arrows are presenting methods and the
rectangles show the classes. Generally, the required number of sequence diagrams must be
identified based on the nature of application. For the application implemented in this thesis, for
the connection process, that client and server are both involved, a sequence diagram has been
created, as shown in the diagram below.
17
Client
Application
Client
SocketNetwork
Server
Application
Server
Socket
04:Create
05:Open port
01:Create
02:Open port
03:Listen
User
06:Listen
notify
Figure 3: Sequence Diagram showing the connection Process
3.3.8 DATABASE DESIGN
One of the tools listed earlier in this chapter is MySQL database which is a relational database
was adopted to work with the Remote server monitoring system. The following are the reasons
which led to the use of a relational database:
1. It offers better security by splitting data into tables thereby making certain tables
confidential.
2. It caters for future requirements by having data held in separate tables thereby making
it easier to add records that are not yet needed but may be in the future.
3. It is good in handling data through the support for diverse data needs.
3.3.9 USER INTERFACE DESIGN
The design process for the user interface calls for the software development model that suits
the windows platform. User interface design is concerned with describing user behaviour and
defining how a particular system will accommodate and respond to that behaviour (Jesse James
Garrett, 2011), where user interface is that part of a computer system which a user interacts
with in order to undertake certain tasks and achieve some particular goals (Stone, Jarrett et al,
18
2001). It involves researching into the behaviours and goals of the target users of a software
system. To ensure that the Remote server monitoring system is well communicated to the users,
the author applied the following aspects in the User Interface (UI) design:
1. Simplicity
One of the key principles that the author applied to the design of the UI for the system.
The UI of the Remote server monitoring system was designed to be as simple as
possible to be able to be used by the system administrator and be able to interpret its
design thus being more inclined to use it. The interface was designed in such a way that
it is clearly laid out, well organised and all the controls that need to be accessed by the
system users are as visible as possible.
2. Size
This is also an important consideration made in coming up with the UI for the system
because the size of the UI directly influences the time taken to load pages, hence the
size of the UI was minimized so as to make the overall system very light so that it can
respond quickly to the user`s requests
3. Structure
The UI of the Remote server monitoring system is clearly laid out, well organised and
controls are easy to identify. Servers are a sensitive area in the delivery of services,
therefore the UI of the system should be clear to avoid new users from attempting all
the options in order to achieve what they desire. In doing so, the users make a lot of
mistakes by enter the wrong data and go to wrong places. The author designed the UI
structure to minimise the occurrences of such.
The author used the sequence of steps as shown in the diagram below to incorporate
the above aspects in the Remote server monitoring system UI design.
19
Outline
Requirements
Specification
Determine
system users
User Path
Mapping
Structure
and
Navigation
Design
Interaction
Design
Layouts,
Icons,
Fonts,
Colour
scheme
User ResearchInformation
Architecture
Interaction
DesignVisual Design
Figure 4: User interface design process
3.4 IMPLEMENTATION
The main focus will be implementation of the proposed Remote server monitoring system. The
system was developed using the tools pointed earlier in this chapter. The reason of choosing
visual studio vb.net is that this programming language lets the programmer to design network
applications by using the features of windows networking. The implemented application will
be able to run on Windows operating system. The tool was developed using the SNMP poll
and trap to collect data (performance indicators) using the agent on the server side and a
monitoring tool on the client side. A connection is established through both sides of the
monitoring listening to the same network.
In the following, a detailed information about each part of the application will be given along
with the related screen shot with the intent of providing comprehension about the scope of the
study. The structure of this application is included of two parts, which are server side and client
ide. Thus, the specification of each part would be explained separately.
3.4.1 SYSTEM FUNCTIONALLY AND SCREEN DUMPS
Several screen shots showing the main user interface components of the system shall be used
to illustrate the test results at the end of each component development.
20
3.4.2 CLIENT SIDE
In the client side, as it has been completely explained in previous part of this study, all the
functionalities of the implemented system can be observed, as will be described in following
parts.
3.4.2.1 LOGIN SECTION
According to the provided screenshot for this section, shown in Figure 5, a dummy login has
been designed. Server administrator would be able to sign into the client side application, by
using pre-set username and password. The username and password had been set in the
application.
Figure 5: Login screen
3.4.2.1 CONFIGURATION SECTION
This section is the first section, provided for administrator of the server. In this part, as it can
be observed in Figure 6, there is a configuration section where the details of the server are set
that is the IP address and server name. Also, the details for notifying the administrators are set
on this screen through the set numbers button which allows five different mobile numbers to
receive the notifications and alerts. The first task for the server is to establish a connection to
allow the clients to be connected to the server. Although a pre-set IP address (static IP address)
21
has been set for the ease of use, but in case of need admin will be able to change the IP address.
By connecting to the client, which is connected to the server, the server will be able to send to
that particular client the status of it and its parameters. By pressing the start monitoring button
in this window, admin will be able to remotely monitor the server from the client side.
Figure 6: Configuration screen
3.4.3 LIVE MONITORING SECTION
After inserting the IP address of the server and setting the port number, which must be the same
as set port number in the server side, the client would be able to be connected to the server’s
system. The administrator should press the start monitoring button to start monitoring the
server by listening to the network and get data from the server application which is already
listen. The administrator should also be able to view the status of the server parameters and
view performance and downtime logs from the server live monitoring button.
22
Figure 7: Live monitoring Screen
3.4.4 SERVER SIDE
On the server-side application, it provides a configuration section where the server
administrator sets the port number which must be the same as the one to be set on the client
side. After configuration, start monitoring connection by clicking the start monitoring button.
3.5 POPULATION AND SAMPLING
Sampling was done from the target population and then visiting each individual within the
sample vicinity to perform the investigation. The target population of the study is the ICT
experts/ administrators. Both primary and secondary sources of data have been used in the
23
study. The primary source of the data is the unstructured interviews and observations. The
secondary sources include journals, textbooks and relevant. Sampling was done from the target
population and then visiting each individual within the sample vicinity to perform the
investigation. The method of data collection adopted for the study is through face to face
interviews with respondents.
3.6 SYSTEM TESTING AND EVALUATION
Software testing can be defined as the process of validating and verifying that the software
product produced meets the requirements and scope of its design and development and that it
works as expected (Hasling et al 2008). Software testing also involves verifying to see if the
software product can be implemented with the same characteristic. This refers to the steps used
to collect and analyse the system attributes. The researcher adopted the use of questionnaires
to test the Remote server monitoring system. Twenty ICT administrators were chosen from two
different organisations to respond to the questionnaires. After using the system, the
administrators gave their views and perceptions on the usability of the Remote server
monitoring system. The researcher selected fifteen Steward bank ICT administrators and five
ICT administrators at Bindura University of Science Education.
3.7 RESEARCH INSTRUMENTS
On research instruments I have opted to use the observations, questionnaires and the Remote
server monitoring system created. The observation was chosen as a factfinding technique
because the researcher would have first-hand information of observing the system behavior in
real time and how it will be exactly operating. The researcher distributed the questionnaires to
the system administrators for data collection.
3.7.1 QUESTIONNAIRES
A questionnaire is a set of printed or written questions with choice of answers, devised for the
intension of survey or for statistical analysis. The respondents will provide written responses
of questionnaires in the form of comments, ratings etc. A population of twenty people were
given questionnaires. According to (Thompson,2001) questionnaires covers a huge number of
respondents and hence the results are gathered instantly.
3.7.1.1 JUSTIFICATIONS OF USING QUESTIONNAIRES
Advantages of using questionnaires
Information is gathered at a lower cost with a huge number of population
The whole process of evaluation is done over a small length of time
24
The researcher acquired specific and appropriate information that he is looking from
respondents.
Disadvantages of using questionnaires
The respondents have the tendency of not finishing the whole questionnaire due to
boredom or wrong timing of the day. As a result, researcher gives adequate time to the
people for them to finish answering the questions.
Participants forget important issues due to many evaluation methods occurring after the
actual event. As a result, the researcher emphasizes on the most important questions on
the questionnaires not to omit. The researcher’s questions were classified so as to
address important questions which address or answers the objectives of the proposed
research.
3.7.2 OBSERVATIONS
Observation is the active acquisition of information from the prime source as the system
executes in real time, with user’s hands-on the object. It was exciting observing the system
confirming to its input to output relationship.
Advantages of using observations
System behavior is quickly analyzed i.e. interaction of class objects and errors of the
system is identified and solved as the researcher is allowed to view all stages of the
system in system execution
A solution is applied instantly if the conflicting objects are identified
Observation improves precision of the research results
Disadvantages of using observations
Logical system errors cannot be observed during the system run time, hence false
results would be identified on a later date. The researcher goes through system testing
before the system was implemented.
Observations are time consuming, the researcher have to wait to collect all the results
after the system complete executing.
3.8 METHODS OF DATA ANALYSIS TO BE USED
The Research study will carry out both qualitative and quantitative procedures to collect all the
relevant data and for data analysis methods to be used are tabulation and representative
25
diagrams such as the graphs and pie charts. Descriptive approach will be used to represent and
analyse qualitative data. For Quantitative analysis, data will be analysed using the percentages
of cumulative responses. From a variety of different data analysis software tools available that
can be used to come to a conclusion of the research, the researcher will adopt the Statistical
Package for the Social Sciences (SPSS). SPSS is a software package used for logical batched
and non-batched statistical analysis. The researcher adopted SPSS because it is specifically
made for analysing statistical data and it offers a great range of methods of summarising data
like graphs and charts. SPSS provides better output organization since it is designed to make
certain that the output is kept separate from the data itself.
26
CHAPTER 4: DATA PRESENTATION AND ANALYSIS
4.0 INTRODUCTION
In this chapter, the Remote server monitoring system implemented will be evaluated through
various system tests and the analysis of user perceptions. This chapter moves on to a
presentation of the findings produced by the original quantitative analysis conducted as a part
of this research project. These findings are then used to provide the foundation for the
conclusions and implications outlined in the final chapter. The usability of the Remote server
monitoring system in its intended environment was evaluated based on scalability and speed.
The system performance tests were evaluated and the users’ perceptions were analysed to
evaluate the system attributes that cannot be uncovered through system tests.
4.1 SYSTEM PERFORMANCE TESTS
This is the evaluation of the system carried out to test whether the system would be able handle
or cope with different environmental factors that may make it redundant. Most of the cases the
worst-case conditions are used. For this research, the most common performance concerns
related to a desktop application were adopted and these include the speed of the Remote server
monitoring system, the ability to handle stress and perform within capacity.
4.1.1 COMPUTATIONAL TIME
Computational time can be defined in this case as the time taken by the system from when the
server goes down to when the notification was received by the recipient i.e the server
administrators. This is a strong factor to consider in determining efficiency of the system and
is a strong determinant in measuring the success of the project. The objective of the system is
to notify the administrators in real time as soon as the server downtime occurs, therefore in
case of short computational time, the project is deemed successful.
Measuring the computational time was done three consecutive times by performing the
following steps:
Set the current time as initial time before server downtime.
Run the configured system.
Check the time exactly when a notification is received on the phone.
27
Table 2: Computational time results
Runs Computational time at poor
internet access speeds
Computational time at high
internet access speeds
First run 5 minutes 1minute
Second run 3.5 minutes 57 seconds
Third run 3 minutes 1.2 minutes
Table above shows the computational time for the system to notify the administrators at different
Internet Access Speeds. The system has proved to be more efficient whenever the internet speed is
high. And of the other side with poor internet speed, it took longer for an SMS notification to be
received by the administrators. Hence the results show that a high internet access speed reduces the
computational time thereby making the system more valuable and efficient.
4.2 ANALYSIS OF THE QUESTIONNAIRES
The analysis and interpretation of the results yielded two sets of data that were also used to
reach a conclusion of this research thesis. These two sets of data are non-numerical and
numerical data. Non-numerical data is the data that came as a result of the questionnaires
provided to the fifteen Steward bank system administrators and five BUSE system
administrators who took part in the research. This non-numerical data was used to create the
numerical data which was represented in the form of frequency tables as will be shown in this
chapter. The frequency tables show the occurrences of certain responses, and these frequencies
are the ones which were also used for representing data in the form of percentage bar charts.
The evaluation of the usability of the centralised application system was achieved through an
analysis of the data obtained from these questionnaires. The samples of the questionnaires are
included in the index.
4.2.1 QUESTIONNAIRES RESPONSE
Not all the questionnaires set were responded from both BUSE and Steward Bank Ltd. Table
2 below shows the response rate from the two organization who responded to the questionnaire.
TARGET GROUP QUESTIONNAIRES
SENT
RESPONSE
RECEIVED
RESPONSE
PERCENTAGE %
BUSE 5 4 80.0
Steward Bank Ltd 15 13 86.7
Table 3: Response rate
28
Assessment of the Questionnaires
The Questionnaires were used in this research for the purpose of gathering the users`
perceptions on the usability and performance of the Remote server monitoring system thereby
imparting a basis of evaluating the system`s usability and performance. This questionnaire
includes questions that focus on determining the systems administrators` views and opinions
regarding the usability and performance of the Remote server monitoring system and also
related factors to the system.
QN1 Did you experienced difficulties using the Remote server monitoring system?
In order to determine whether the design of the Remote server monitoring system enhanced
ease of its use, the researcher had to assess if the users found it easy to use from the experience
they had with the system. The pie chart below shows that the majority of the respondents did
not have much difficult with a percentage total of 85%. This result maybe as a result of testing
with the people who have prior experience with servers and networks. In conclusion, the
responses show that the system was easy to use.
Figure 8: Difficulties using the Remote server monitoring system
QN2 On average, how frequently do you experience server downtimes at your
organization?
The statistics in the graphs below shows that the outcome of the assessment of how often
downtimes occur is relatively high as a majority of the system administrators articulated that
29
is relatively high. A conclusion can therefore be drawn that organisations have gaps in server
monitoring as many of them use scripts and command line tools to verify a downtown and
observe status through performance failures.
Table 4: Downtime frequency
Frequency Percent Valid Percent Cumulative Percent
Valid High 3 15.0 15.0 15.0
Relatively high 13 65.0 65.0 80.0
Low 4 20.0 20.0 100.0
Total 20 100.0 100.0
Figure 9: Frequency of downtime
QN3 Which monitoring method is response time effective between Remote server
monitoring system and the current method being used by the organization?
The system administrators’ perceptions were sought on speed (response time) or time taken
between the server downtime until the SMS and/or email notifications and alerts are received
by the system administrators by asking them whether they see the likeliness of a reduction in
the administrators’ response time through the system where the majority consisting of 85% of
the respondents gladly agreeing that the administrators’ response time will be reduced,
highlighting that the use of scripts takes much time and the remaining 15% disagreeing that the
30
Remote server monitoring system will reduce the administrators’ response time. It can
therefore be concluded that the Remote server monitoring system reduces the time taken to
notice the downtime and failures of a server. A summary of the results is shown in the table
and graph below.
Table 5: Time effective method
Frequency Percent Valid Percent Cumulative Percent
Valid Remote server monitoring
system
17 85.0 85.0 85.0
Existing system 3 15.0 15.0 100.0
Total 20 100.0 100.0
Figure 10: Time Effective method
31
QN4 How good is the Remote server monitoring system in simplifying your work? For
example, effectiveness in notifying the administrators of the server downtime and alerting
tracking.
Table 6: Simplifying work
Frequency Percent Valid Percent Cumulative Percent
Valid Excellent 5 25.0 25.0 25.0
Very good 9 45.0 45.0 70.0
Good 4 20.0 20.0 90.0
Poor 2 10.0 10.0 100.0
Total 20 100.0 100.0
Figure 11: Simplifying System Administrators' work
The statistics shown from the graph above show that the outcome of the assessment of how the
IS administrators perceived carrying the server monitoring process on the Remote server
monitoring system. The majority of the respondents articulated that it is simple for them to use
or carry out their server monitoring using the Remote server monitoring system. However, a
marginal percentage of the respondents disagreed to having found carrying out the monitoring
process on the system simple. A conclusion can therefore be drawn that the design of the
32
Remote server monitoring system enables the IS administrators to simply monitor the servers
effectively through notifications and alerts.
QN5 The Remote server monitoring system improves the response time of the
administrators to the server status and downtime?
The respondents’ perceptions show that the time taken to notify the system administrators about
a server downtime and alerts on server performance parameter status is improved by the
Remote server monitoring system. As shown in the statistics tabulated below, 25% of the
respondents strongly agreed that they found the Remote server monitoring system relatively
improving the response time of the administrators with 50% also agreeing on the improvement
of administrator notifications using the Remote server monitoring system. However, 15% of
the respondents did not agree to this with a 10% strongly disagreeing. Responses on this
question can conclude that the Remote server monitoring system is quite an improvement in
terms of response time to notify the system administrators.
Table 7: Improving response time
Frequency Percent Valid Percent Cumulative Percent
Valid Strongly agree 5 25.0 25.0 25.0
Agree 10 50.0 50.0 75.0
Disagree 3 15.0 15.0 90.0
Strongly disagree 2 10.0 10.0 100.0
Total 20 100.0 100.0
33
Figure 12: Improving response time
QN6 How do you rate the Remote server monitoring system in terms of performance?
Table 8: Performance rating
Frequency Percent Valid Percent Cumulative Percent
Valid Excellent 6 30.0 30.0 30.0
Good 8 40.0 40.0 70.0
Neutral 4 20.0 20.0 90.0
Poor 2 10.0 10.0 100.0
Total 20 100.0 100.0
Figure 13: Performance rating
The table above shows the outcome of the overall rating of the system in terms of its
performance. A total percentage of 30 and 40 rated the system excellent and very good
respectively whereas a total percentage of 20 and 10 rated the system good and poor,
respectively. This shows that a significantly greater number of the population found the system
34
quite performing, and from this a wrap up can be made that the system holds very good
performance attributes. Below is a graphical representation of the overall rating of the system.
QN7 Give an overall rating of the Remote server monitoring system in terms of usability
and performance?
A great number of the population showed a high overall rating of the system usability and
performance. A majority of the respondents showed a total percentage rating of 20 and 55 as
excellent and good respectively whereas a total percentage of 20 standard with 5 rated it bad
which show that the system can be used and it was quiet performing.
Table 9: Overall rating
Frequency Percent Valid Percent Cumulative Percent
Valid Excellent 4 20.0 20.0 20.0
Good 11 55.0 55.0 75.0
Neutral 4 20.0 20.0 95.0
Poor 1 5.0 5.0 100.0
Total 20 100.0 100.0
35
Figure 14: Overall rating
4.2 RESEARCH FINDINGS
The implementation of the proposed system allowed the author to get insights and gaps in the
server and network monitoring implemented before.
4.2.1 EFFICIENCY OF THE PROPOSED SYSTEM
The system proved to be efficient and worth it as it is able to report the status of the server in
real time. From the tests carried out above, it has been proven already that the monitoring is
done in real time hence enabling notifications to be sent in real time. The status of the server
parameters will be noted before they pose the any performance issues to the server.
4.3 CHAPTER SUMMARY
This chapter gave an analysis of the evaluation of the system which was done using, the users`
perceptions of the system through the use of a questionnaire. This was used to determine the
usability of the system in its anticipated environment.
The sample of results shown in this chapter analyses the users` perceptions on the properties
of the system that could not be drawn from the system performance tests conducted. From these
research findings, a greater part of the population from the sampled data attested to the usability
of the system. Also, a greater number of the administrators who had the opportunity to use the
system showed satisfaction on how the system would reduce the response time to server down
time and failures. The server performance tests showed that a high internet access speed
reduces the computational time thereby making the system more valuable and efficient.
36
CHAPTER FIVE: CONCLUSION
5.0 INTRODUCTION
Through this study, concept of server monitoring, remote access and other concepts related to
this work, had been reflected. Besides that, the similar works which previously had been done
in this field, were investigated and comparison between the implemented application and the
existing tools had been given. In addition, the process, procedures and conditions of the
implemented application, step-by-step, have been explained.
5.1 AIMS AND OBJECTIVES REALISATION
According to the scope of this thesis, a simplified remote server monitoring system has been
implemented. The researches, which have been done prior to choosing this topic, show that all
existing server monitoring tools in the market have complicated user interface if they do not
work based on command line structure. Regarding this fact, the existing tools cannot be used
by beginners and they are designed for professional users with having strong understanding of
the network. Regarding the researches on related works, the attempts were to provide a simple
but functional remote server monitoring system to be useful for professional users as well as
novice users. The primary purpose of implementing this project was to provide a simple to use
remote server monitoring system which contains most of the necessary functionalities.
5.2 FUTURE WORK
As the future work, some features can be added to this application, such as providing statistical
report on the result of monitoring and transferring data by using File Transferring Protocol
(FTP). Additionally, this application, which has been designed to be run on Windows operating
system, might be written with another programming language for being used on other operating
systems. The system can also be improved to monitor more than one server at a time to
accommodate multiple servers as many organisations use many different servers to provide
their services.
37
REFERENCES
1. Kaushik, A. (2010). USE OF OPEN SOURCE TECHNOLOGIES FOR ENTERPRISE
SERVER MONITORING USING SNMP, 2(7), 2246–2252.
2. Mahajan, A., Joshi, H., & Khajuria, S. (2012). ICMP , SNMP : Collaborative Approach
to Network Discovery and Monitoring, (2248), 8–12.
3. Zeng, W., & Wang, Y. (200 Zeng Wei. Research on the Network Management
Technology Based on WinSNMP. Journal of Wuhan University of Technology
(Information & Management Engineering), 2007,29 (12):15-18. 9). Design and
Implementation of Server Monitoring System Based on SNMP, 1, 2–4.
https://doi.org/10.1109/JCAI.2009.34
4. Liu Yucheng and Liu Yubin, “A Monitoring System Design Program Based on B/S
Mode”, IEEE International Conference on Intelligent Computation Technology and
Automation, pp. 184-187, 2010.
5. Zeng Wei. Research on the Network Management Technology Based on WinSNMP.
Journal of Wuhan University of Technology (Information & Management
Engineering), 2007,29 (12):15-18.
6. Englander, I., (2013), The Architecture Of Computer Hardware, Systems Software &
Networking, Book, Fourth Edition.
7. Trimintzios, P., Polychronakis, M., Papadogiannakis, A., Foukarakis, M., Markatos, E.
P. & Oslebo, A., (2006), DiMAPI: An application programming interface for
distributed network monitoring, Conference on Network Operations and Management
Symposium, IEEE, pp. 382-393.
8. Fang, W., Zhijin, Z. & Xueyi, Y., (2008), A New Dynamic Network Monitoring Based
on IA, International Symposium on Computer Science and Computational Technology,
IEEE, Vol. 2, pp. 637 - 640.
9. Michalski, M., (2009), A Software and Hardware System for a Fully Functional Remote
Access to Laboratory Networks, Fifth International Conference on Networking and
Services, IEEE, pp. 561 – 565.
10. Suri, S. & Batra, V., (2010), Comparative Study of Network Monitoring Tools,
International Journal of Innovative Technology and Exploring Engineering (IJITEE),
Vol. 1, No. 3, pp. 63-65.
11. Feldkuhn, L. & and Erickson, J., (1989). Event management as a common functional
area of open systems management, Proceedings of the First IFIP Symposium on
38
Integrated Network Management, pp. 365-376.
12. Rosenberg, D. & Scott, K. (1999), Use Case Driven Object Modeling with UML: A
Practical Approach, Molecular Informatics, Massachusetts, Addison-Wesley.
13. http://www.networkmanagementsoftware.com/network-management-software-
smackdown
14. Liu Yucheng and Liu Yubin, “A Monitoring System Design Program Based on B/S
Mode”, IEEE International Conference on Intelligent Computation Technology and
Automation, pp. 184-187, 2010.
15. NimSoft. NimBUS for Server Monitoring. Solution Overview Paper,
http://www.nimsoft.com.
39
RESEARCH ASSESSMENT QUESTIONNAIRE
My name is Shoko Eddington and I am a computer science undergraduate student doing the
final year at Bindura University of Science Education (BUSE). It is a requirement of the
university that all students carry out a research project in partial fulfilment of the degree
requirements. I am doing a research on the improving the monitoring of Servers by
implementing a remote server monitoring system with SMS notifications. Therefore, I am
kindly asking for your faithful contribution, as your responses will help in coming up with the
results for this study. Information below will be kept confidential and for academic support
only.
You can respond to the question by ticking one box of your choice or by giving a brief opinion.
1. Did you experienced difficulties using the Remote server monitoring system?
Yes No
2. On average, how frequently do you experience server downtimes at your organization?
High Relatively high Low
3. Which monitoring method is time effective between Remote server monitoring system
and the current method being used by the organization?
Remote server monitoring system Existing system
4. How good is the Remote server monitoring system in simplifying your work? For
example, effectiveness in notifying the administrators of the server downtime and
alerting tracking.
Excellent Very Good Good Poor
40
5. The Remote server monitoring system improves the response time of the administrators
to the server status and downtime?
Strongly agree Agree Disagree Strongly Disagree
6. How do you rate the Remote server monitoring system in terms of performance?
Excellent Good Neutral Poor
7. Give an overall rating of the Remote server monitoring system in terms of usability and
performance?
Excellent Good Neutral Poor
8. What are your views about replacing the current server monitoring method being used
by the organization with the Remote server monitoring system?
…………………………………………………………………………………………………
……………………………………………………………………………………………
Thank you so much for your support. May you kindly fill in the following details for reference
purpose.
Name(s):…………………………………………………………………………………..
Address:…………………………………………………………………………………..
Phone number:……………………………………………Signature:……………………