APM Administration: Ten Central Myths
For religious scholars, the term central myth refers to key propositions about that faith which is often reinforced through the retelling of a story supporting the myth. In recent days, this has come to mean beliefs that are untrue. In talking to many APM administrators, they seem to support various implied beliefs that are left unsaid. Adherence to these beliefs can lead to time-consuming tickets, and unexpected outages.
Below are ten common APM administration central myths and what they could be replaced with.
Ten Central Myths:
Central Myth #1: APM Administration is "one and done." All I have do is install/upgrade the product, assist in adding more applications to monitor, and just make sure things stay up.
New Myth: APM Administration is far from a "one and done" proposition. Proactive maintenance and optimization ensures a smooth running system.
Central Myth #2: APM cluster architectures do not need periodic reviews. Only look at increasing server capacity or number of servers only after things break.
New Myth: Periodic architecture reviews at least 2-4 times a year can handle increases in demand as well as factor in successfully future scaling needs.
Central Myth #3 I can go with the default APM settings. This should handle my needs for some time
New Myth; APM default settings work in many cases. But they often make certain assumptions that may not apply to your environment. Fast growing environments need frequent configuration parameter review
Central Myth #4 No need to clean my network traffic for TIM. It can make do with what I provide
New Myth: Unfiltered network traffic may lead to higher decode failures (because of TCP false connections) and make the TIM/MTP work harder in processing the extra traffic.
Central Myth #5: I don't have time or need to review APM logs, Supportability Metrics, or the Status Tab.
New Myth: I will make it part of my Administration responsibilities to review each of the above to get a better understanding on what is typical behavior and be closer to problems when they first occur.
Central Myth #6: APM CE can monitor as many transaction as as I want.
New Myth: I will work with my application owners to only monitor what is really needed so to avoid filling up the APM database with unnecessary data and produce unneeded reports and metrics.
Central Myth #7: Using a virtual environment for APM means hands-free administration
New Myth: I will monitor the cluster health of my APM virtual environments with more scrutiny than my physical environments. They are more likely to hit limits faster and experience more performance problems,
Central Myth #8: There is no reason to read the documentation, release notes, KBs, community posts, attend APM Office hours etc. Whatever is out there is hard to find, unclear, and incomplete.
New Myth: Look at the resources as a first resort. APM Tech Docs and Support work hard to make documentation, release, and KBs as clear, complete, and current as possible. If this is not the case, then post a comment on wiki.ca.com with the details or send me a note and I will see it gets rectified. APM Office Hours is your time to directly ask APM Product Management and Support your questions and concerns
Central Myth #9: Reactive is cheaper and less time-consuming than proactive.
New Myth: Proactive administration stabilizes environments and anticipates future application monitoring needs.
Central Myth #10: I am going to be here for some time. There is no need to document operating tasks and best practices.
New Myth: Circumstances are always changing. Keep your run book, APM monitoring strategy/roadmap, and transaction definition "spreadsheet" current.
There are many more central myths that can be added here. Perhaps in a future article.
Molloy, Michael Experiencing the World's Religions: Sixth Edition. New York: McGraw-Hill Education 2012
1. What are your APM Administration Central Myths?
2. Have these been ever challenged? What happened as a result?
3. How frequently should one evaluate their APM Administration central myths?