In the previous post, I shared my experience on how to configure a SCOM APM to get the most from it. In this post, I will write about a SCOM APM Transaction and what an excellent feature it is. At the end of this short article, I am sure, you will discover that if you use it right. By investment in a small amount of time, you will decrease the downtime of your organization.
I have seen many administrators using the transaction feature to monitor only business workflows. Although this is good, you should use the transaction to monitor endpoints or resources that are used by the application, so if something goes wrong, you will quickly figure out what causes to do so.
So, how you achieve it?
It begins by investigating monitored endpoints or resources that are used by the application we want to monitor, and what triggers them. Once we know it, we continue by creating a transaction to monitor in a SCOM APM transaction wizard for each monitored endpoint or resource based on a trigger.Β In addition, we end it with a big smile π
To clarify my point, I will use a ridiculous simple metaphor. Let us assume that a store has four departments. Each department is a “transaction.” And each has only one unique supplier. Therefore, whenever one of them has a problem, let’s say, a series of bad products, a manager quickly contacts the supplier that is responsible for it.
For each application type, there are several transaction types you can choose to monitor
Application type | Transaction types for System Center 2012 | Transaction types for System Center 2012 SP1 |
---|---|---|
ASP.NET Web application |
|
|
ASP.NET Web service |
|
|
WCF service | Not available |
|
Windows service | Not available |
|
This table is from a Microsoft documentation about .NET Application Performance Monitoring Template. I recommend to read it. You will find there all the necessary technical information that you need to use the transaction feature.
If you have any questions, I will be happy to help you.