As posted yesterday on the Server Cloud blog, we have released the Release Candidate of Operations Manager 2012. This is a significant milestone release, and in this article we will explore how Operations Manager 2012 Release Candidate delivers application performance monitoring.
For those of you who have downloaded and tested the Operations Manager Beta, there is new content and capabilities in the Release Candidate, so read on!
For many years Operations Manager has delivered infrastructure monitoring, providing a strong foundation on which we can build to deliver application performance monitoring. It is important to understand that in order to provide the application level performance monitoring, we must first have a solid infrastructure monitoring solution in place. After all, if an application is having a performance issue, we must first establish if the issue is due to an underlying platform problem, or within the application itself.
A key value that Operations Manager 2012 delivers is a solution that uses the same tools to monitor with visibility across infrastructure AND applications.
To deliver application performance monitoring, we provide 4 key capabilities in Operations Manager 2012:
So it must be hard to configure all this right? Lots of things to know, application domain knowledge, settings, configurations? Rest assured, this is not the case! We make it incredibly easy to enable application performance monitoring!
It’s as easy as 1 – 2 – 3 …
1. Define the application to monitor.
2. Configure server-side monitoring to be enabled and set your performance thresholds
3. Configure client-side monitoring to be enabled and set your performance thresholds
And that’s it, you’re now set to go. Of course setting the threshold levels is the most important part of this, and that is the one thing we can’t do for you… you know your application and what the acceptable performance level is.
It’s great that we make the configuration of application performance monitoring so easy, but making that information available in a concise, impactful manner is just as important.
We have worked hard to make the creation of dashboards incredibly easy, with a wizard driven experience. You can create an application level dashboard in just 4 steps:
1. Choose where to store the dashboard
2. Choose your layout structure. There are many different layouts available.
3. Specify which information you want to be part of your dashboard.
4. Choose who has access to the dashboard. As you will see a little later in this article, publishing information through web and SharePoint portals is very easy.
And just like that, you’ve created and published an application performance monitoring dashboard!
Anyone who has either worked in IT, or been the owner of an application knows the conversations and finger pointing that can go on when users complain about poor performance. Is it the hardware, the platform, a code issue or a network problem?
This is where the complete solution from Operations Manager 2012 really provides an incredible solution. It’s great that an application and associated resources are highly available, but availability does not equal performance. Indeed, an application can be highly available (the ‘5 nines’) but performing below required performance thresholds.
The diagram below shows an application dashboard that I created using the 4 steps above for a sample application. You can see that the application is available and ‘green’ across the board. But the end users are having performance issues. This is highlighted by the client side alerts about performance.
Once you know that there is an issue, Operations Manager 2012 provides the ability to drill into the alert down to the code level to see exactly what is going on and where the issue is.
An important aspect of application performance monitoring is to be able to see how your applications are performing over time, and to be able to quickly gain visibility into common issues and problematic components of the application.
In the report shown below, you can see that we can quickly see areas of the application we need to focus on, and also understand how these components are related to other parts of the application, and may be causing flow-on effects.
With Operations Manager 2012, we have made it very easy to delegate and publish information across multiple content access solutions. Operations staff have access to the Operations Manager console, and we can now easily publish delegated information to the Silverlight based Operations web console and also to SharePoint webparts.
And best of all, the information looks exactly the same!
It looks great, you want to get started and see how Operations Manager application performance monitoring will work for you in your environment, so where do you start?
Send me an e-mail Follow me on Twitter Connect with me on LinkedIn
thanks for the great article. I still have to install RC to see all those features since they were not available in Beta, and that's a great step forward.. but I would really love SCOM team to address some usage scenarios which were possible with AVIcode and became somewhat difficult to support in SCOM, yet there are some that were impossible with AVIcode and they are still impossible with SCOM APM.
For example, domain and application knowledge is required in order to use APM for application troubleshooting. Without that, all you can do is to identify some well-known problems (such as slow calls to the web services etc). However, just imagine a "for" loop in the application that takes 5 ms for each of the steps. Such a loop can ruin your application response time, but you will never know it using default configuration settings. In order to figure out that sort of problems, you'll have to invite developers and ask them to do code review. And, then, based on what they tell you, you may be able to configure APM in order to troubleshoot your applications.
Here is another the problem.. You can identify high-level bottlenecks using default SCOM APM settings. In other words, you can figure out that your web service is causing problems, for instance. But why? It's like answering part of the question without really answering the other part (if you follow the chain of events, you will, eventually, find an element that is slow by itself. Maybe because of the loop I described above, maybe because of something else).
And I can go on with this sort of examples. Besides troubleshooting, there are problems around reporting.. For instance, event throttling affects the meaning of Advisor reports - those reports make sense under some favorable conditions only. Put it into production where you have tons of performance problems, and it's becoming a mess.
I apologize for a bit of critisizm - it would be nice to see an evolution of AVIcode that can compete with other APM tools on the market, but so far it just does not seem to be the case yet. But.. with that said, I do wish the best of luck to the team and hope SCOM APM will find its niche.
Alex, thank you for the feedback.
Operations Manager, like AVIcode 5.7 was, is designed to work in production environments. As such the goal is to capture the information needed to effectively triage the issues and get the right people from the dev team involved in looking at the root cause. Keeping your production environment up and running at peak efficiency is the goal of the operations teams and APM in Operations Manager is focused on doing that while having the lowest possible impact on the monitored application. For cases such as a run-away for loop, improperly handled input, or some other code defect they are investigated by the development team in staging or test environments based on the data collected from production. Performance events and chains help you see that function foo is taking 5 minutes to complete or is throwing an exception due to an invalid cast, and this information greatly reduces the MTTR for the dev team because they now know where to start the investigation. Data such as the parameters and variables are used to help see what kind of input was passed, and again in the case of the run-away for loop they should help show that the for loop is running 1,000,000 times and impacting performance.
For direct feedback on the capabilities of Operations Manager look into getting involved in the CEP I mentioned above, or bring your thoughts to the TechNet forums. Our goal with APM is to enable ops teams everywhere to more effectively manage the applications they support and as we continue to build on APM you will see more developer centric scenarios being lit up.
Comments in this blog are open and monitored for each post for a period of two weeks after the posting date. If you have a specific question about a blog post that is older than two weeks, please submit your question via our Twitter handle @MSCloud