- Azure Sentinel—A real-world example - Tue, Oct 12 2021
- Deploying Windows Hello for Business - Wed, Aug 4 2021
- Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021
Troubleshooting application performance issues is a very difficult area, often requiring intimate knowledge of the workings of a particular program. Is the problem in the code, the server hardware, the server software or in the network? Developers need deep insight and detailed logs to debug whereas IT Professionals need standard metrics across all applications and a way to easily pinpoint in which tier the problem might lie.
Microsoft acquired AVIcode in late 2010; this product is designed to look for performance problems in application code without requiring instrumentation to have been built in by the developers. The standalone AVIcode product version 5.7 will be the last as it’s now integrated into SCOM as Application Performance Monitoring (APM).
If you’re a current user of AVIcode 5.7 be aware that its management packs won’t work in SCOM 2012 (templates still work though) ; also APM will only work with .NET / web applications, not stand alone executables and it will only monitor IIS 7 / 7.5 not IIS 6. On the upside the infrastructure is totally integrated in SCOM, there’s no separate database and if it’s monitoring a Server 2008/2008 R2 machine with the IIS management pack the agent will automatically be deployed, although it’s not activated. Another improvement is that you can set an overall SLA for all web applications rather than having to configure monitoring for each individual application, the SLA can then be tweaked for particular programs as needed.
For corporations with many IIS web applications the power of APM might just be the feature that justifies the upgrade to SCOM 2012.
When the interceptors are activated and loaded into IIS the server will require a restart, after that, even if you add additional applications to be monitored; only the particular app pool needs to be recycled.
The beauty of the integration becomes apparent when you see network, hardware and OS monitoring right next to the application performance information, making it much easier to zero in on exactly where the problem lies. The actual monitoring is done in the Diagnostics and Advisor consoles. Similar events are grouped and it also lists Session events or “what else did the user do when this problem happened”. Performance counters are also displayed; 15 minutes of OS and hardware data leading up to the event to let you easily determine if the problem is the underlying platform or in the application code. All of this data enables the IT Pro to communicate facts when liaising with developers and DBAs.
The separate Application Diagnostics and the Application Advisor web consoles is probably where developers are going to spend their time troubleshooting, without having to deal with a full SCOM console.
APM can monitor both the server side of an application and the client side (IE only at this stage but support for other browsers is coming) which gives visibility into performance and reliability. The synthetic transaction feature already in SCOM on the other hand gives insight into availability and together the two provided excellent data on overall application performance. APM monitoring carries minimal overhead, as a rule of thumb is uses about 100 MB of memory and increases the CPU load by 5%.
Today there’s no explicit support for APM monitoring of SharePoint 2010 although that is coming and there’s no way to put Advisor reports into a dashboard as there’s no widget for it yet. What’s more concerning is that there won’t be built in support to use APM to monitor cloud applications in Azure at RTM, although this support is “on the roadmap”.
In the next part of this series we’ll examine what’s been improved in the native Unix/Linux monitoring that debuted in SCOM 2007 R2 as well as the brand new Java Application Server monitoring.