Performance Monitor

With expectations of consumers calling for more up-time on systems and companies looking for a higher profit, the ability to performance monitor applications and respond to their activity has become a common requirement for every company. The monitoring of applications minimizes downtime, records trends for management reports, identifies issues pertaining to the applications, and allows the support team to react and correct these issues.

Software applications affect all of our daily lives. We either use the applications directly such as using an internet browser to do online banking; or indirectly, such as an electric company running metrics on our energy use. For many of us an application crash or system downtime is just a minor inconvenience, but for a large company application downtime leads to not only consumer inconvenience, but also a loss in profit.

All major companies use software applications every day. The majority of these applications need to have very minimal downtime since this causes user inconvenience and likely a loss in profit for the company. This is where application monitoring comes into play. Application monitoring helps minimize downtime by monitoring applications to detect and respond to any problems that arise before the end user is aware of any such issue.

Performance Monitor: Types of Monitoring

Application monitoring can be broken down in five general categories; fault, performance, configuration, security and accounting. [1] These categories each play a specific role in monitoring within a company. Depending on the company’s needs, not all of the categories may be used.

Performance Monitor: Fault monitoring

Fault monitoring is used to detect major errors related to one or more components. This is generally the most used type of monitoring as it tests for errors. Network loss is an example of fault monitoring, this is where a network cable may have become unplugged or cut unintentionally. Fault monitoring also tests for faults such as a database going offline or an application running out of memory. These events are considered very important as many of them affect multiple applications. See Table 1.

Table 1: Fault Monitoring

Performance Monitor

Performance monitoring is used to watch for slow performance. Many companies have service level agreements or SLAs which must be met. These agreements lay out metrics for the application and the level of service expected from them. They include information such as a minimum and average target. For example, a database call may have a minimum target of one second, but the average should be only 100miliseconds. Performance monitoring logs the time it takes to call the database. If it takes longer than the time reported in the SLA there will be an alert flag set and optimizations made to either the application or database to get back on track with the SLA targets[4].

Performance monitoring may also be used to gather and record metrics on the application or the server it is running on. Some of the metrics often measured include start up times, database call times, central processor utilization, and memory usage. These metrics can then be stored and recalled at a later time to compare with a new version of the application to find areas of improvement and those which need to be improved. These performance metrics can also be displayed visually with different styles of graphs to see if problems are occurring within certain time spans. Maybe a system is being backed up at a certain time everyday which causes slowdowns and the backup may need to be throttled or moved to a less intrusive time of day.

Configuration monitoring

Configuration monitoring is the safeguard against changing configuration variables. This type of monitoring ensures connectivity, speed and performance. Some of the obvious types of configuration variables include items such as database connection strings, table names, timeouts and other common variables set in configuration files. But configuration monitoring should also be used to monitor items such as heap size of the Java Virtual Machine (JVM), or call splitting for database calls.

While some of the configuration items may result in non-connectivity, others may just impact performance. While both of these would be caught with performance or fault monitoring it is still better to be proactive about any possible problems than reactive.

Security Monitoring

Security monitoring monitors and records attempts to access the system by unauthorized users or programs. Some of the items that may be monitored include unnecessary open ports, hardware and software inventories, patch versions, firewall logs, dumped packets, system events, and blocked exploit attempts.

Security monitoring is one of the most challenging monitoring systems to set up. To be an all-inclusive system of databases, connections, computers, servers, and more is very difficult to set up since all systems require a different type of monitoring. Some companies use a honey pot technique in which they publicly publish compromising information in which a hacker or program misinterpret as real and attempt to make a pass at it. While the actual location published was incorrect, companies do monitor it and learn what people are doing to try and access systems. They then use this information to implement better defense on their actual servers. In 2010 Northwestern Mutual had over 3,000 outside attempts to access their servers. 89% of those attacks originated from China and less than 1% came from the United States. Due to good monitoring techniques and responding correctly no attempt was successful in compromising any information.

Performance Monitor Accounting

This type of monitoring monitors the usage of a product. This allows organizations to implement maintenance, usage and administration fees for the usage. Accounting monitoring also keeps track of profit/loss and can automatically adjust billing prices accordingly. A good example of this is electricity billing from an electric company. The company monitors how much you’ve used over the month and automatically generates a statement and mails it out.

Accounting monitoring also has the ability to monitor the accounting software to make sure that it is given the correct information and the output is correct given that information. One place where this would have been good to implement is in Verizon. In 2009 a man from Hayward, California received a $22,000 bill from Verizon Wireless. His average bill before was only $93. If the correct monitoring systems were in place the bill should never have been sent. The bill may have only required a phone call or some more investigation to clear up the issue.

Performance Monitor Conclusion

Monitoring with these five categories not only allows the developer or support maintenance workers to detect and correct the fixes; but also provides a way to gather logistics for management reports. Many application monitoring utilities allow for the user to graph the data from previous days; this allows the data trends to be easily seen. Being able to see common trends from the past is known as being able to see historical data.

Historical data is gathered by setting a baseline test at some arbitrary point in time that is determined by the testers to solve discrimination for performance. A client may say that the new system seems to be slower but in actuality the data is showing it is the same speed or faster. There also exists the possibility it is actually slower and the tester would be able to see where the slow downs are occurring.

This data allows for trends of the application to be seen and allows modifications to be made to the programs if necessary. Keeping track of these trends through multiple releases allows the user to see what areas of the program need the most improvement. The trends also allow to see response times. As a program progresses through its lifecycle and updates are released there tends to be more calls and background processes happening so there may come a time when optimization or renegotiation of the SLAs are needed.

Application monitoring is a very important part of the project, but generally, not much time is spent developing the monitoring aspect of the application during initial development. Once the project is live the need for monitoring may become clearer. Although almost nonexistent at first the monitoring aspect is developed after the implementation of the project. Generally monitoring is put in after the discovery of a flaw or problem. This causes the issue of monitoring within a program to be more heavily weighted in one section while another may not have any. Also, implementing monitoring directly within an application may cause downtime of the application if it doesn’t support live changes.