CA Tuesday Tip: APM System Administration Philosophies

Discussion created by Hallett_German Employee on May 12, 2012
Latest reply on May 14, 2012 by MaryGreening
CA Wily Tuesday Tip by Hallett German, Sr. Support Engineer for 5/15/2012

This month, we take a brief vacation from the APM transaction definition lifecycle to talk about a largely ignored topic.

In having met or trained 70 APM Administrators, I've learned a lot about you. You are all very hard-working in a typically reactive environment. Application monitoring is just one part of your job.(When things go south with the application, application stakeholders soon nervously hover around your desk asking "what does APM say?") Also, APM is just one of many tools that you support. There isn't a lot of time for education. But there are those rewarding times where APM has shown what is wrong with an ailing application. As a result, customer satisfaction has been raised, revenues are maintained or increased, and the application gets heavily used for another day thanks to your efforts.

In my experience, companies have one of three types of system administration philosophies. Knowing the system administration
philosphy, can determine job responsibilities and expected outcomes. (Full disclosure. This is a topic I covered at some length in an unpublished work.)

MINIMAL OR DO NOTHING. In this environment, APM servers mostly are just left alone to generate metrics and reports until such time they stop doing that. Occasional system administration tasks such as upgrades, monitoring new APM agents or application transactions are performed. The advantage of doing this is that it doesn't take a lot of time to do. The disadvantage is the site is not leveraging full advantage of APM or making it an active part of their application lifecycle. Your APM environment is also likely to be unoptimized, and not current with your application's monitoring needs.

REACTIVE. This is the typical environment. APM is used as yet another "break/fix" tool. Administrative responsibilities may include some upgrades, adding new agents/application transactions, some report interpretation, and periodic upkeep of servers. The advantage is the site is using the solution to fix pressing issues and has some sense of what a successful application "steady state" is. The APM servers are also looked after and not outdated. The disadvantage is not using the product for things to get out of "reactive ****" such as capacity planning, application optimization, and event correlation. There are not always lessons learned reviews to avoid a performance issue in the future.

PROACTIVE. This is rarely encountered. There are a wide range of proactive APM monitoring activities that can be implemented as outlined in Mike Sydor's CA Press book -- all the way up to "monitoring nirvana". The advantage is that you have is your APM environment is keeping your application's needs. Application performance trends are well understood -- in the past, today, and tomorrow. The disadvantage is that it takes time and patience to see full results.

It is my wish that you reflect on this article and use it as a starting place on how you can serve your application users better.

Questions for discussion:
1) Did the opening describe your environment?
2) if in a reactive environment, what is your company doing to stabilize applications?
3) Are there other system administration philosophies that could apply to application performance monitoring?
4) How well do you know your application's past, present, and likely future performance?
5) Are you actively keeping up monitoring with the changes in your application?