School of Computing  |  Napier  |  Cisco  |  SFC  |  NOS  |  Code |  Old page


[Home][Back]

Name:

Autonomous Application Recovery Agents

Skills:

 

Aim:

 

Focus:

 

Student:

A.Douglas [CNDS - 2001/02]

Documents:

Project report
Source code
Code PDF

Poster
Agent monitor
Database
EXE

The Agent will be a stand-alone application operating on a server, note that it could also run on a window NT workstation due to the design similarities.

In essence the Agent will have a number of items that can be monitored, these will be network connectivity, a target application like MS IIS or Apache for example and the operational environment, I.E different properties of the environment that the application is deployed on. Properties could include, free disk space, CPU activity, System Memory.

It will use an administrative alert or message system to relay information about these items if they breach certain limits or fail altogether.

Based on the events that are monitored predefined action will take place in an attempt to maintain the service provided to customers/users of the service that is the subject of monitoring.

To do this a mechanism will be devised that will allow each dependant items that the service require to be check and restarted in sequence if required, this could be operating environment, network, service and is each case reliant items. This could include all network devices between the monitored machine and its connection to outside networks.

The simplest for of this technology would be monitoring the Application event log for the monitored service and depending on the message, stop/start the service.

Implementation

The technology could be implemented in either C++ or visual basic depending on the level of control required over the applications. The application could be created as two application, one monitoring while the other interfaces with applications, this depends on the level of interaction that is required, it could involve restarting a service or a executable, or accessing menu items within the application and executing commands, while this is more sophisticated it may not be necessary, additionally it would require direct manipulation of the applications API. This is possible but would require that adjustments are made after every service pack and bug patch.

Monitoring

Ideally the monitoring part of the application would be developed in C++ using a Different class for each type of monitor, Network, Application, Operating Environment, each of these may require sub classes.

A Text file that contains the objects parameters will configure this application; this would include dependent components for each item.

Based on the dependent items would allow the monitor to select the cause and not just report all of the filed items. For example if there are three routers between the computer and an external network gateway, the failure of the first means the second two will be inaccessible. Only one should be reported.

Applications could be monitored by checking they are operational or possibly checking the ports that are used by probing the ports.

The Operating Environment will be slightly different because many of the items are not inter-related, i.e. disk space monitoring, items which are related would be application that are part of the operating systems services, these could be monitored and restarted if necessary.

In addition to this the application error logs could be used as a source of monitoring application activity, all monitors will operated on a timer, this is the easiest way to ensure that there has not been any failure.

Response

In each case a set of response actions will be required, these could be integrated into the class structure though Object Orientation techniques such as Inheritance, functional overloading, actions will be executed depending on the dependencies between the objects and the monitor object that are reporting errors.

Responses range from administrative alerts based around the alerter or messenger service of Windows NT deleting temporary files to starting/stopping services, running executable or direct interaction with applications API.

Conclusion

Due to the complexities involved in such a system a good aim would be to implement basic monitoring in the three areas mentioned, response systems for applications should include starting and stopping applications, deleting temporary files, and sending alerts to warn about potential failure, API control should not be necessary.

Downloads

Project report
Agent monitor
Database
EXE

 

 

 

 

 

School of Computing  |  Napier  |  Cisco  |  SFC  |  NOS  |  Code |  Old page

Page maintained by bill