Most Read This Week
Choosing the #APM System that Is Right for You | @DevOpsSummit [#DevOps]
A lot of the arguing in the APM space is about the fundamental approach to monitoring application transactions
By: Andreas Grabner
Oct. 5, 2014 07:00 PM
In my role as technology evangelist I spend a lot of time helping organizations, big and small, make their IT systems better, faster and more resilient to faults in order to support their business operations and objectives. I always find it frustrating to "argue" with our competitors about what the best solution is. I honestly think that many APM tools on the market do a good job - each with advantages and disadvantages in certain use cases. There is no "one size fits all" - there is just a "this tool fits best for your APM Maturity Level" (not saying the others wouldn't do a good job).
A lot of the arguing in the APM space is about the fundamental approach to monitoring application transactions: monitor and capture ALL details vs. monitor and capture relevant details. Along with that come topics like "overhead impact", "scalability" and "data hording vs smart analytics".
Ultimately, you want to pick the right tool to solve your problems. As you have multiple tools to choose from let me - in my role as technology evangelist - highlight some of the use cases that our customers solve. As a technologist and a blogger, what I really care about is that the right technology is applied to the right problem. As such, I feel compelled to share what I have learned working with customers in the trenches. Hopefully, this will help you understand the technology and what problem it can solve in real life problems, and cut through the propaganda. Let me start with a few use cases today and follow up with some more in follow up blog posts.
Use Cases from Steven - A Performance Engineer
They identified the following key problems they need to solve and what they really required from an APM solution in order to get to where they are heading:
How a user got to a problem, and not just seeing the problem itself
Number of transactions executed per user and tenant used for business and cost reporting
Eliminate homegrown tools which are costly to maintain
Eliminate the need to make people look at other tools and data
Ability to extend to custom frameworks, systems and protocols
Full Automation to support Continuous Delivery
Replace traditional application logging
One solution for everything
Active community forum
Let me give you some examples for Steven's use case so that you can better decide on whether that is relevant for you as well:
Every Transaction with All Details
Transaction Flow: One View that tells it all to Devs, Architects and Operations Teams
What if you don't capture all transactions but be "smart" and focus on capturing the problematic ones? While this approach allows you to find and fix the easy-to-find problems that can be analyzed by analyzing those transactions that fail or violate the average response-time based baseline, it falls short when it comes to problems that are caused by transactions that are not "outside the norm". One example here is a database deadlock we recently analyzed for a customer. The "smart" approach only highlighted the transaction that hit the deadlock but no information was captured for those transactions actually causing the deadlock with their data manipulations. Being able to see which transactions executed which UPDATE statements at the time leading up to the deadlock is required to solve this problem.
As companies - such as Steven's - are getting into a maturity level where they grow out of "smart" average response time-based analysis it is important to have the ability to look at everything and not just the average problem. As a follow up read the blog Why Averages Suck and Percentiles are great!
Capture Custom Business Context
Business Reporting requires Business Context data for every Transaction
This was only possible because dynaTrace allows you to selectively capture business context in the context of every single executed transaction. Along the PurePath you will then see things like method arguments, return values, bind values, session variables, HTTP parameters or cookie values. All to be later used for your business reporting or targeted root cause diagnostics. Here is a follow up blog post that explains business transactions in more technical detail.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads