Early planning is the best way to start an implementation of monitoring. Planning early allows for the monitoring to be added into the application at the time development instead of a later time. Adding monitoring later in the process tends to focus on only areas of known issues, this may allow some issues to go undetected.
Implementing Application Monitoring Proactively
Proactive application monitoring is the hardest monitoring to implement. In proactive application monitoring the problems are found and dealt with before the consumer even knows there is a problem. This involves monitoring very deep and specifically into the application. This way if an error does happen, the system knows exactly where it occurred and what caused it. [1]
The best approach to proactive monitoring involves a tools based approach. With a tools based approach the monitoring involves no code. This is the best advantage to this approach, allowing for the collection of data to be very easily and readily set up. This is done through class loader instrumentation. This also means that the tools aren’t specific to a single application and can be reused across multiple applications of the same language. The other approach is a code based approach where logging and or monitoring software is inserted directly into the code base during development or by the support team thereafter the initial development. This approach is less efficient as the developers have less time to spend on logic within the program since they have to worry about how to monitor it as well.
Implementing Application Monitoring: Create a Recovery Plan
Having a recovery plan in place is vital to a fast resolution of an issue. Overtime applications may migrate to different support groups. Having a recovery plan with common issues and their fixes helps the teams stay current. An example on how to create a recovery plan is displayed in Figure 1 courtesy of a free spreadsheet available from the website governancesforum.com.
Figure 1: Recovery Plan Template
Implementing Application Monitoring: Create and Use Service Level Agreements
Even if the service level agreement is unofficial it still is worthwhile to have a structure in place.
Service level agreements include items such as the following:
- What percentage of time that the services will be up (uptime)
- How many people can use the application at once without performance issues
- Performance metrics and benchmarks to be used with performance monitoring alerts
- The rules for notification announcements
- What statistics will be monitored and when and where they will be available
- Acceptable response time
An Example of an SLA is given in Figure 2.
Figure 2: Example of SLA