Every exceptional situation has it's own aspect. It can be incorrect workflow into business logic, problem with configuration files, incorrect versioning, messy deployment, wrong usage of third-party components. Typically only developer understand which of these aspect every exception belongs to.

Other story with infrastructure problems. It's relatively simple to distinguish infrastructure problems from other exceptions. They usually represents by SecurityException or XXXNotFoundException exception that logically can be named as security and connectivity aspect of infrastructure problems. Having these two types named it's natural to call regular exceptions as application failures and performance violations as performance problem.

And all these aspects we have in APM for Operations Manager. And you can find them in AppDiagnostics console in filtering pane for events:


It's pretty simple to test connectivity problem. Just stop SQL server you are using for your application.

If it's too aggressive for you to shut down database you can try approach I usually use for this. Just put dummy aspx file into virtual directory of application you've configured for monitoring with pretty simple content:

<%@ Page language="c#" %>
<%@ Assembly Name="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<form id="Form1" action="Default.aspx" method="post" runat="server">
using (SqlConnection connection = new SqlConnection("Server=server;Database=database;User ID=user;Password=password;"))

This aspx will work for all frameworks and you shouldn't compile anything to run it.

Running this aspx you'll get alert with following description into Operations Manager Active Alerts view:

Connectivity failure has been detected in the application 'TestConnectionString' on computer 'sergkanz-opsmgr.testdomain.com'. An exception of type 'System.Data.SqlClient.SqlException' with a message of 'A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections....' was thrown in '/TestConnectionString/Default.aspx'. For additional details see the Alert Context.

Alert details lead to the AppDiagnostics event that says we really failed in the the method "ASP.default_aspx.__Render__control2" that definitely makes sense to developer.


So we have this connectivity failure in the Operations Manager as Alert that IT can respond as well as exception event in AppDiagnostics console that gives all runtime details to developers. And it makes sense to have this even be shown in both consoles since we can’t understand whether this problem was caused by real connectivity problem or just because connection string was formed incorrectly in code.

We have completely different situation with application failure aspect. This typically interesting for developers only if the issue escalation procedure doesn't suppose deep involvement of operations personnel as for instance TFS Connector supposes (https://connect.microsoft.com/OpsMgr/program7044).

So in Operations Manager 2012 you will be able to filter alerts by aspect specifying whether you want to see "application failure" alerts for your application or you just want to have it as event for developer's investigations in AppDiagnostics console.