Application monitoring is a very important aspect of a project but unfortunately not much attention is paid to develop the effective
monitoring while the project is not live. Once project is live lack of
proper monitoring costs in terms of downtime when support persons are not
aware if application is having some problems or application not
working at all.

Discussion on application monitoring should start early at least from the
time when deployment details are being worked out. Some application may
require some specific scripts or tools or authorizations, an early
discussion on monitoring will make it in a better position to address the
delays in its implementation.

This document gives a basic introduction to the challenges , type of
monitoring and best practices which can be followed to ensure high
availability of the live systems. Following topics are covered in this article

1 Challenges in application monitoring
2. Types of Monitoring for application
3. Best Practices in application monitoring
4. Implementation of application monitoring

Challenges in Application monitoring :

Following are some of the challenges faced today for application
monitoring :

1. Proactive Monitoring : Proactive monitoring means
monitor the system and application health and take corrective
action when it reaches a certain threshold level .The threshold level is
defined as the level where application is not showing deterioration but can
deteriorate if corrective actions are not taken . The biggest challenges
is to gather the statistics to workout a threshold and number of parameters
and process that needs to be monitor . Applications which interact
directly with the customer for example ecommerce, banking needs to be monitored proactively so that problems are
detected even before it impacts the end user customer.

2. Complexity & number of applications: An application may
become more complex if it has a global user base. The application has to
support multiple languages, culture and currencies. Application may have
multiple instances located in different regions of the world and may be using
different time or logging format. To effectively monitor global
applications one has to under stand the application instances their
inter connectivity, flow coordinate with regional teams and in most cases
depend on regional teams for monitoring the application.

3. Shared Systems: Applications are often shared in a system in
order to utilize the full capacity of the hardware and this implementation brings
in its own set of challenges. For a single application system it is
easier to track the resources like memory, CPU, disk, network bandwidth but in
shared application environment some application may take the resources and
others may get impacted for apparently no fault of their own. Sometime
application owners may not be contactable to take corrective actions.

4. Clustered Systems: To avoid a single point of failure
applications are hosted in a clustered environment with number of machines
in different network and locations. From monitoring perspective it poses
another challenge of keeping track of the request &
failure logs , memory , CPU network , disk resources as one has to look
at all the cluster component machines logs and resource just to isolate which
one is giving bad performance .

5. Limited Logging in production environment : Since volume of
transactions are very high and application code has already been run
through performance , reliability and quality assurance cycles the
application code in the production environment is generally enabled for
minimum logging information . This may lead to situation when actually
indicator of a problem may not show up in the logs . The logs may not
show the error message until the logging level increased .

6. Custom logging in production : Logging in online production
environments at the most can be changed to higher level as provided by the
code. In case of particular problem when logging and other debugging methods
does not provide a clue to the problem special instrumented code has to
be developed and deployed to capture error condition events . The instrumented
code has to be deployed in production environment only since the problem
could not be replicated under test conditions .Deploying a custom code in
production calls for application downtime which may not be acceptable to
the application owners and business groups involved and also
require considerable efforts on part of supporting team to maintain it . This
custom code may get overwritten by the next release cycle code .

NextPage – Types of Monitoring for applications