Application Insights suite… mais pas encore fin ! Dans cet article je vais vous expliquer comment gérer les exceptions de votre application. Je vais surtout me concentrer dans les explications sur les applications web MVC mais vous pouvez tout à fait utiliser cela pour d’autres types d’application (voir la documentation).

Exceptions non gérées

Application Insights vous propose 2 possibilités de suivi des erreurs. Ces deux possibilités sont disponibles dans le dashboard des Echecs.

Il s’agit des requêtes ayant échouées (failed requests) et les exceptions. Le graphique « Failed requests » regroupe toutes les requêtes ayant échouées, qu’il s’agisse d’une erreur serveur non catchée (erreur 5xx) ou autre (par ex : erreur 404). En cliquant sur le graphique, la liste des requêtes s’affiche.

Vous pouvez ensuite sélectionner une requête pour avoir son détail.

On peut remarquer sur l’image précédente, détaillant une erreur 500, que la section Exception est vide. Cette erreur est une exception non gérée qui est remontée. Pour qu’elle soit récupérée automatiquement par Application Insights et visible en détail dans la section Exception, 2 possibilités :

• Avoir la configuration de CustomError à Off

<customErrors mode="Off"/>

• Surcharger l’attribut de gestion d’erreur par défaut System.Web.Mvc.HandleErrorAttribute

La 1^ère possibilité n’étant pas valable en production, voici le détail du code (ce code est disponible sur le GitHub d’Application Insights)

using System;
using System.Web.Mvc;
using Microsoft.ApplicationInsights;
namespace MVC2App.Controllers
{
    [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)] 
    public class AiHandleErrorAttribute : HandleErrorAttribute
    {
        public override void OnException(ExceptionContext filterContext)
        {
            if (filterContext != null && filterContext.HttpContext != null && filterContext.Exception != null)
            {
                //If customError is Off, then AI HTTPModule will report the exception
                if (filterContext.HttpContext.IsCustomErrorEnabled)
                {
                    var ai = new TelemetryClient();
                    ai.TrackException(filterContext.Exception);
                }                
            }
            base.OnException(filterContext);
        }
    }
}

Il faut ensuite enregistrer la classe dans les Global Filters (pour MVC 5)

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    // Default replaced with the override to track unhandled exceptions
    filters.Add(new AiHandleErrorAttribute());
}

Maintenant, vos exceptions non gérées seront disponibles dans les détails

Exceptions gérées

Bon, c’est bien de pouvoir avoir des infos sur les exceptions non gérées, c’est quand même mieux qu’elles soient catchées avant d’exploser votre application. Un peu de la même manière que les événements personnalisés (l’article à relire ici), il existe une méthode pour envoyer des informations sur une exception : TrackException

Ces exceptions seront visibles dans le graphique « Exceptions »

Vous pouvez accéder à leur détail de la même manière que vu précédemment

L’avantage de la méthode TrackException est que vous pouvez, comme pour les évènements personnalisés, envoyer des données supplémentaires qui seront visibles dans le détail.

try
{
    //....
}
catch (Exception ex)
{
    var properties = new Dictionary<string, string> { { "User", Guid.NewGuid().ToString() } };
    var measurements = new Dictionary<string, double> { { "Valeur", GetRandomMetric() } };
    tc.TrackException(ex, properties, measurements);
}

Conclusion

Vous êtes maintenant parés pour faire face aux erreurs de votre application. Vous pourrez découvrir rapidement les exceptions qui vous ont échappées, les problèmes de liens cassés qui provoquent des erreurs 404, etc.