More recently, I have been talking to a number of people such as TAP customers, colleagues doing internal testing, etc. One question that came up was about understanding, when you run thru the APM Template/Wizard, what objects are in fact being created by the template – in other terms, how do the options I select in the wizard influence the way my application will be monitored? How will my application “look like” in OpsMgr once APM Monitoring has been set up for it?
To be completely clear, we have published a fair chunk of official documentation on Technet for APM to guide users thru the process and describe the various settings and thresholds in details. In particular you should be referring to the following two locations:
Anyway, to make things a bit more clear about how the object model actually looks like (for the geeks out there), I created the following diagram, essentially mapping the Wizard elements to the objects that get created by the template:
As you can see, every template instance that you create by running the wizard, represents a single application – this is called an “Application group” and it is a singleton object – similar to a Distributed Application, although it does not appear in the “distributed application” view because it has a different base class.
The diagram above can be accessed from the “Monitored Applications” state view (which shows all the applications that have been configured thru the APM template) by right clicking an app and selecting the Diagram View for that object:
The template also creates Folders and Views, following the same hierarchy:
So, as already written, the “top level” object is called an “Application group” and it is a singleton object – similar to a Distributed Application. It hosts other singleton objects – the “Application components” – which typically represent the “tiers” of your SOA Application. In the current (RC) implementation they can be Web Application or Web Services (both .asmx web service and WCF services hosted in IIS), but there could be more “types” appearing in the future. Some components (Web Applications) are considered appropriate for Client-Side monitoring – some are not, and are only appropriate for Server-Side monitoring, since they probably do background processing, or serve XML files as opposed to HTML web pages, and so on. Enabling Server-side or Client-side monitoring for the components, enables the “third” level – the green rectangles in the illustrations above – those are “component roles” – these represent if the component (“tier”) hosts a Web Application, a Web Service, an IIS-hosted WCF Service and if it has been enabled for Client-Side monitoring. You can also see this breakdown in “application components” and which “component roles” they host/are monitoring, in the first State view for the “Application group”:
All the objects described so far (those in the dark blue, red and green rectangles in the illustrations above) are singleton classes which get created on management servers – like other singletons, they live in the
“All Management Servers” resource pool
. All these objects are created to give a distinction in “groups” or “tiers” for applications that can be running the same component on multiple machines in a server farm that can scale horizontally.
The fourth level in the diagram is, finally, the actual monitored instances on the
– those are the “worker bees” collecting data from the APM Service and feeding it thru the OM channel, as described in
my first post on this blog
. These instances are contained within the component roles above, and at the same time they are hosted by the APM Agent object.
And that should be it, we have come full circle from the high-level configuration in the console to the agent. To be fair, there is one additional set of objects that I am not showing here, that come into play when defining transactions. I’ll maybe get to that in a separate post, since it requires an understanding of what transactions are, in APM terminology. For now I hope this post helps clarify how the base/common object look like with APM in OM12, and enable you to understand more clearly what you are seeing!