Shopping

I was reading the this entry from the very good blog of Correlsense and liked the analogy of transaction monitoring and shopping.  It’s not an analogy I’d heard before now.  My own personal favorite analogy is a Restaurant – I promise to write that one up soon.

Nir mentions tracking every individual transaction across all elements, to meter how much time the transaction spends on each element, and how many times it invokes each element.

So that:

• Transaction = Shopper
• Elements = Shelves
• Metric = How much time the transaction (Shopper) spends at each element (Shelf)

But for us at WestGlobal, this simplified transaction analogy glosses over some important aspects required for transaction monitoring.  It isn’t possible to distinguish the different types of interactions possible.  For example:

• View (examine shelf to see if an item is available
• Get (take an item from the shelf)
• Put (put an item on the shelf)

Without distinguishing each type of interaction, at the application layer, all interactions are lumped together.  So, for example, an aggregated view might show:

The above example might represent a normal period of processing.  But a detailed breakdown of different interactions is required for the full picture:

Both examples represent an average of 0.23 seconds per shelf.  But the bottom example clearly highlights the different operational characteristics of each interaction type, and enables an organization to react appropriately whenever metrics change.  For example,  if the volume of Put interactions increases, without increasing the min/max/avg metrics, the average response time can jump dramatically.

In this example, an operations team reacting to an increase in average response times will simply not have the ability to diagnose or fix any issues, simply because the volume and response time metrics all look within normal limits.

At WestGlobal, we’re big fans of monitoring software interactions at the application layer.  It provides far more useful, meaningful and actionable information than techniques involving aggregating network data.  It slashes the time it takes to detect a real problem, reducing the number of false positives, and provides an evidence-based approach to take back to development teams on software bottlenecks or other problems.