INDEX

INTRODUCTION ABSTRACT EXISTING SYSTEM LIMITATIONS OS EXISTING SYSTEM PROPOSED SYSTEM ALERTING THROUGH SMS AND MAIL LITERATURE SURVEY SOFTWARE REQUIREMENT SPECIFICATION SYSTEM REQUIREMENT REQUIREMENT TRACEBILITY MATRIX SYSTEM ARCHITECTURE DATA FLOW DIAGRAMS

CENTRALIZED SERVER FOR CRITICAL OS SERVICE MONITORING

INTRODUCTION:
1.1 OVERVIEW
Server service alert tool is a software mainly used to monitor the critical system services in the server. Failure of the services in the server will be a drawback for the clients. In order to overcome this, timely alert is being sent to the system administrator about the service failure via Short Messaging Service (SMS) and E-Mail, to which the admin can quickly react by restarting the service remotely, provided the admin is in the same network. 1.2 PROBLEM STATEMENT The Service Monitoring and Control service addresses how to conduct real-time observation of critical service conditions in a computerized environment. This is for the purpose of monitoring many automated applications.

1.3 SOLUTION The main aim of this project is to intimate the failure of the server related services to the system administrator through the Short Messaging Service and E-mail. The administrator is intimated and notified every time the services fail. This facilities the administrator with the option to restart the failed services remotely within the network through any mobile device or a desktop computer. The administrator need not have to monitor the services physically all the time, Instead it allows the administrator to keep track of the server related services even when the administrator is not around.

Existing system:
The current systems have only message log maintenance towards the important services which is available in the form of text file. A person has to track and monitor these files manually and intimate the network admin about failure, so that further actions can be carried out.

EXAMPLE: There is a Stock market server requires to send updates of the market continuously to various registered clients by mail. If the service SMTP stopped for any of the above reason.

Mail based application cannot be able to send any mails and the clients who depends on the mail data will be in trouble. LIMITATIONS OF EXISTING SYSTEM: Usually the current system is manual and no intimation is sent on services failure, which leads to failure of many connected services. This is tedious, time consuming and prone to errors.

PROPOSED SYSTEM:
Proposed system is to develop network tool Monitoring and Alerting tool for System Daemon Services for windows OS, which is required for the company to monitor System and User Services

Admin chooses list of services from the system Admin can select services to monitor and allow the daemon process to control. Once services are selected it will be running in the background to check the status of selected services. If any services stopped for any reason, the application logs these details about the particular service. Based on the event logger details admin can connect through a centralized system/server. Centralized server to send alert ( Mail and SMS ) to admin. Web application should be created to view the logs and also to start services from the remote machine.

ALERTING THROUGH SMS AND MAIL:

LITERATURE SURVEY:
2.1 SURVEY FINDINGS: Normally happens like whenever the Operating System when the machine starts, along with the Operating System there are so many services will also get starts. Usually those services will be services which will detect automatically when the pen drive is inserted, may be a service which will automatically send an E-mail from that, so there are so many such services which will starts as soon as the machine gets starts. Those services are nothing but

the Operating System service which are very important for the entire Operating System itself to work. we are creating an application that is we will generate a program format that has options for, Getting the list of all the services which runs in the machine. Allow the administrator to identify important services required to monitor. Allow the services to run in the background. Our project has different modules like 1) Client application creation for allowing administrator to choose services to monitor.

2) Centralized system. 3) WEB application one can start and restart. 4) Mobile which is needed to send SMS.

SOFTWARE REQUIREMENTS SPECIFICATIONS

The purpose of this document is to present the software requirements in a precise and easily understood manner. This document provides the functional, performance, design and verification requirements of the software to be developed.

3.1 STAKE HOLDERS The stakeholders of our project are: System administrator Clients Company

FUNCTIONAL REQUIREMENTS:
3.2.1 SERVER APPLICATION a) WEB APPLICATION TO VIEW THE LOG AND CONTROL SERVICES Server application has created using the socket programming for each functions of the system. Web application to view all the services that are stopped. An option to start the service from the remote machine. Option to search based on the IP address and date and time.

b) CENTRALIZED SERVER APPLICATION A GSM mobile is connected to the centralized server to send SMS

 Email based on SMTP protocol to send alerts to the system administrator. 3.2.2 CLIENT APPLICATION Client Application or daemon program which are loaded in the client systems includes: Admin lists the services which are running in the each system. Admin can add / remove services to monitor Services which are added will be monitored by the daemon program. A message is sent to the centralized server, if any services stopped due to hardware failure, software failure, operating system bugs or viruses.

Figure: use case diagram

SYSTEM REQUIREMENTS:
3.4.1 HARDWARE REQUIREMENTS Minimum of 1 GB RAM. Pentium IV or higher. Standard computing. Network of minimum 4 systems to show complete demonstration and Reliability. 3.4.2 SOFTWARE REQUIREMENTS Operating System Programming Language Development Tool .NET Data base : SQL SERVER : : : Windows XP C# .NET VISUAL STUDIO PC configuration to carryout challenging

REQUIREMENTS TRACEABILITY MATRIX:

Slno

Requirement ID

Requirement in brief

Requirement Description

Design ID

Test case reference

REQ_ID-1

Execute/run the Server Server Application should application run without any interrupts

REQ_ID-2

Execute/run the Client application

Client Application should run without any interrupts

REQ_ID-3

Verification of Adding services systems in

In client systems list of

client services will be added and that added service should run continuously.

REQ_ID-4

Verification of Start button Server in

In

centralized

server

centralized system admin clicks on start button respective

services should be Start in client system 5 REQ_ID-5 Verification of Stop button Server in In centralized server

centralized system admin clicks on Stop button respective

services should be Stop in client system 6 REQ_ID-6 . Service stop in client systems If added services stop in client system then it should report to centralized server

System Architecture:
Starts when Server boots

Server 1
192.12.3. 6

http SQL Server FTP

WEB APPLICATION
Wi-Fi Router

YE S

Daemon Services

Is Service List present in the servicelist? Service List User List U

N O

DB Serv er
Acts like GSM Modem MOBIL E

Services which the user wants to monitor

Interact with event logger to find the error log just like a block box
IP Address

SQL Server Stopped

Click Here
BROWSER IP Address 192.12.3.6 Sql Server Start

Network

Black Box Event Log Details Service Name

Fig: System Architecture The system is designed in the following manner. The services which the admin wants to monitor are taken as the input, also to the mobile number of his choice for which the admin wants to get the alert. When the alert is sent, the admin can restart the service.

Monitoring the services This module is designed for the following purpose, Select a set of services for which the user wants to monitor. Continuously check the recently added list (monitoring list) with the services list of the server. Sending the service failure details to the Server database This module is designed for the following purpose When the services are getting monitored, send a message having the IP address of the server, details regarding the crash to the centralized server. Sending an SMS and E-Mail from the Centralized Server When an entry is received in the centralized server, the message with the service crash details is sent via SMS and EMail. Restarting the Service from a Wi-Fi mobile or browser The failed service can be restarted from a web browser or from a Wi-Fi enabled mobile.

DATA FLOW DIAGRAMS:

This DFD explains the general overview of the system, the sequential execution.
Server Starts Enter the Service which you wish to Monitor by selecting from a list of active Service running in the System. USER

LIST
Compare the list of Services you selected from the Services in the System. PROCESS

LIST

Is USER LIST present in the PROCESS LIST ?

Find out which Service has failed from which Server (IP) collect the Event Log details and then store it in a DBS.

Send the Message stored in the DBS to the admin through the SMS and Email

Message sent and services restarted

The services stopped can be restarted by the admin through a Wi-Fi enabled mobile or by using a web browser using RPC

Fig: Overview of the system

When any server starts, there are a few services that start as soon as the server starts, these are called daemon processes. These daemons once failed need to be restarted in order to work properly and to serve the client systems. When the server starts the admin will want to monitor a set of services that are very important to him, these services might be very critical to the client systems. So, when the admin adds the critical processes for example antivirus service, to a list, it needs to be monitored from time to time so that that the critical services do not fail, If they do so, they need to be restarted as soon as possible to serve the client systems . The administrator can search the failure of services in the servers by searching the IP address of the server or by viewing the Log of that particular day. The transmissions of messages from the Centralized Database Server to the different servers take place and vice versa take place via the TCP.Once this is done, the service at the Servers side is restarted this ensures the availability of the servers to the client systems.

DETAILED DESIGN FOR MONITORING OF THE SERVICES MODULE:

Enter the Services you want to monitor from a list of Systems Daemon Services.

Continuously check the Users Monitoring list with the Servers list.

Users process list present in the Servers Service list? YE S

NO

Send the Name of the Services, and other details regarding the failure, to the Centralized Server.

Figure: Monitoring Services

In this module, the services which the user wants to monitor are taken as input from the servers list. The list got from the user is compared with the servers services list. The above process is continuously monitored in a thread, this program is run at the server side.

Detailed Design for Sending the Service failure details to the Centralized Database Server module:
Message sent via TCP port 4321 Failure Messages sent from Servers (Client) on Service Failure to Centralized Database Server Message stored in MSSQL Database to maintain Services failure log.

Failure Message displayed on the Centralized Database Server GUI.

The Message to be sent to the administrator via SMS and E-Mail

Figure: Sending Services Failure to Server

In this module, when messages are received at the centralized database server via TCP port 4321, the complete message which includes the IP of the server on which the service failed, the reason for the failure taken from the Event logger of the OS and the date on which the service failed is once stored in the MSSQL Database for maintaining the service logs.

Detailed Design of Sending an SMS and E-Mail from the Centralized server module:

Message sent via TCP port 2555

Failure Message and link of Centralized Database Server sent to the administrator via SMS.

Failure Message sent to the administrator via E-mail.

Figure: Sending SMS and Mail to Admin

CONTROL FLOW DIAGRAM:

Admin will login

He will View the services

Adding services to database

Select type: intimate or restart

Infinite application range

Check for services stored in database either it is being running or stopped.

Intimate or restart the services being services that have been stopped.

Closing the application

Fig: Control Flow diagram

When the administrator login into the system, he will be provided with the list of services but need to be monitored

ones he select the preferred services the application will make them entered into the database he will be provided with the options either to intimate himself, if the problem is critical. Or it will be restarted by the application, if the problem is minor. The applications will simultaneously upgrading the information about services that is either been running or stopped. The intimation or stopped service restart depends upon the admins preferences this is the application that we are willing to develop.

SEQUENCE DIAGRAM:
Admin
View services

Application

Add service to database

Show list of services added to database

Select services to restart or intimate

Intimate service list/restart service list Showing services started & stopped

Keep checking for service status Centralized System If service stopped intimate to admin

The sequence model elaborates the themes of use cases. It shows the participants in an interaction and sequence of messages among them. It shows the interaction of the system with its actors to perform all or part of a use case. It shows the interaction between the system admin and application along with the sequence of messages among them.