Across the IT industry, the term “transaction” is used in many different ways and with a variety of subtly-different meanings. In System Center 2012 – Operations Manager, the APM (“.NET application performance monitoring”) feature also uses the term “transaction” – and it does it in a very specific way, which might not be immediately intuitive to grasp. In this post I want to analyze how it is used, and what a “transaction” is, in APM.

First of all, I should mention that the feature is documented – the documentation for the .NET application performance monitoring template starts here http://technet.microsoft.com/en-us/library/hh457578.aspx 

In that documentation, you will find (among other things) that you can add transactions from the dialog where you “customize” settings for a specific application component (hint: for a definition of “application component”, see my previous post about the APM object model), and that we have different types of transactions:

Add transaction

and each one of them is described in its own paragraph:

The above three are what is available in OpsMgr 2012 RTM. It is likely that even more types of transactions will be added in the future as we start supporting more technologies.

The documentation tells you that

“[…] The application component continues to monitor the page specified in the transaction by using the performance threshold that is set for the application component. This threshold is used as a second measure on the same page in the application component. If you set this threshold higher than the application component threshold, you get two performance events for the transaction when the threshold is breached—one from the application component and one from the transaction. Transactions are typically used to monitor the individual page more aggressively than the parent application, at a lower threshold, or to monitor a page where monitoring has been disabled on the parent. […]”

While the documentation tells you how to use the settings, you might still be left wondering about the implementation details and what happens “under the hood” and the reasons behind certain behaviors.

When I blogged about the APM Object Model, I did not go into the topic of transactions, because I was already introducing many concepts in that post. But I promised I would come back to that topic. That day is today, and this post you are reading Smile 

What the "Add transaction..." buttons allow you to do is, essentially, to create additional, specific objects representing certain pages, web services and functions that reside within that application component. In other words, transactions enable scenarios such as:

  • Disable alerting at the application and application component level, and enable alerting only for specific pages/services/methods
  • Define some web pages, web services methods or functions in the code of that component that should have a lower threshold than the component they belong to

While the above might sound clear, here come a few “gotcha’s” or things to note:

  • A transaction is created as a separate OBJECT, HOSTED by the application component.
  • A transaction is therefore NOT an “override” for the application component.
  • Creating a transaction does not remove the specialize page/web method/function from the parent application monitoring.
  • If you leave alerting enabled for both the application component and for the transaction, you will get one alert from the parent application component as well as one for the transaction if both thresholds are surpassed.

Example scenario:

  • I set up a threshold for the application component of 15 seconds and leave the alerting rule on.
  • I set up a transaction for the “default.aspx” page with a threshold of 10 seconds and also set this with the alerting rule on.
  • If the “default.aspx” page takes 16 seconds, I get TWO alerts: 1 for the transaction and one for the application component, since BOTH thresholds are breached.

The following diagram illustrates this concept:

APM Operations Transactions

Of course, if used with care, transactions can allow you to enable alerting *just* for a specific page or web method as opposed to enabling it for the whole application component. Also note that APM “events” collection still occurs, for collection/visualization within Application Diagnostics, regardless of alerting settings (see my other post on APM Rules if this sounds unclear – I went into a lot more details in that one).

 

To summarize, it is important to know that transactions:

  • allow monitoring of individual entry points with different thresholds/settings
  • need to be used carefully as a “tuning” measure, as it is easy to get double alerts from them if not used in the proper way

Hope this helps explain how transactions can be used to fine-tune your .NET APM configuration!

 

…and by the way, if you are coming to MMS 2012, I will be teaching two instructor-led labs at the conference:

AM-IL302 System Center 2012 Application Performance Monitoring 
AM-IL304 System Center 2012 Operations Manager Java Monitoring

I hope to see you there!