SCOM 2012 Beta is here, and, apparently, .NET Monitoring has been given a new look and feel in this version. Whether it is for the best is a big question for me since some very important pieces of information are missing yet, and they will probably be missing until we see the RTM.
From what I can see now, .NET monitoring has been oversimplified to the point where developers may stop being interested in the information collected by SCOM. That leaves the question about .NET Monitoring usage scenarios open since many rivals emphasises their ability to provide diagnostic and troubleshooting data. As it stands in 2012 beta, troubleshooting information is pretty much reduces to the statistical analysis of slow pages and external resources (such as SQL and Web Services). It’s almost impossible to dig down to the root cause using call stack information, though, yet all that fine-tuning we were used to in AVIcode has gone.
The good thing is that it’s now much more friendly and straightforward for the operations folks since it does not assume that application-specific knowledge is required to configure .NET Monitoring anymore. Again, that brings up a question about usage scenarios, but let’s stick to the facts as we know them.
1. As of Beta, there is no support for windows services and executables. Only Web Applications(including web services) are supported.
This is a serious limitation since that cuts off a huge number of real-life scenarios. Desktop applications monitoring becomes impossible, not to mention windows services and non-IIS hosted WCF, for instance.
2. You can add more than one application to the same template instance.
That’s an improvement since it becomes much easier to configure monitoring of multiple applications now.
3. Server-side configuration is limited to a couple of checkboxes and one threshold
This is, likely, the worst of it. Since that essentially means that now .NET Monitoring is expected to choose what to monitor and what not to monitor, which is great for Operations but that also greatly reduces the value of .NET Monitoring for dev teams.
In other words, what if you wanted to capture fast SQL calls? What if you wanted to capture details about your application internal calls? Those options are missing in Beta, and I can only hope they will eventually be added in the RTM.
4. Standalone version
It’s not there, and that was expected of cause. One of the problems with this approach is that monitoring becomes highly operations-oriented since developers are, usually, not familiar with the operations manager. Not to mention that they often have no access to the Operations Manager. That goes in line with the changes I mentioned before, though.
This is where we can really congratulate the team, since deployment is, not, much more straightforward:
– .NET Monitoring agent is deployed as part of SCOM. No fancy configuration is required anymore
– Former AVIcode Advisor is deployed as part of SCOM Web Console installation. It’s actually called “App Advisor” now, but it’s still the same AVIcode Advisor:
– Client Side monitoring is integrated with .NET Monitoring. No additional management packs/deployments are required.
6. Data Analysis
AVIcode SEViewer is somewhat hidden now. However, we can still use to the SCOM alert context and use “click here” option to bring up so-called “App Diagnostics” web application:
That shows us the same event details SEViewer windows we were used to before:
However, that seems to be the only piece of the former SEViewer that is still there, so there is no grouping and filtering functionality in the App Diagnostics UI.
There is no separate database for .Net Monitoring, and that’s good. All the data has been moved to the Operations Manager database. It’s not clear if that’s going to affect existing best practices for SCOM database maintenance, but, at the very least, we don’t have to worry about maintaining separate database for APM. On the screenshot below, you’ll see how it looks like (Ops Mgr DB on the left side, and SEViewer DB for 5.7 on the right side):
That’s a rather brief overview, and it assumes some familiarity with AVIcode products. In fact, it’s more a comparison than an overview. However, just to conclude the comparison, there are a few things that bother me in this version:
- No support for anything but web application
- Very limited set of server-side configuration options that makes the product hardly usable for application deep-dive troubleshooting
- Separation of the product from the development teams. This one can be overcome to some extent by educating developers on the SCOM 2012 interfaces, but, still, it’s there.