APPLICATION INSIGHTS : UTILISATION ET PERSONNALISATION DU MONITORING

Application Insights est un outil puissant et extensible qui permet de surveiller vos applications. Le but de cet article est de voir comment on peut facilement étendre les possibilités offertes par cet outil dans le cadre du monitoring d’une application ASP.NET hébergée sur un App Service Azure.
Pour une liste détaillée des possibilités déjà offertes, consultez la documentation officielle.

Configuration

Pour commencer, vous devez déjà avoir une application ayant Application Insights configuré, si ce n’est pas le cas la documentation officielle vous y aidera.

Cette configuration active par défaut la collecte des informations suivantes :

• Requêtes
• Dépendances
• Exceptions

Pour certains types d’applications ASP.NET, une configuration supplémentaire sera nécessaire pour collecter toutes ces informations.

Cas des applications ASP.NET OWIN

Dans le cas d’une application ASP.NET utilisant l’abstraction OWIN, l’utilisation d’Application Insights nécessite un peu de configuration.

Il est possible d’effectuer cette configuration rapidement en installant le package Nuget ApplicationInsights.OwinExtensions.

Pensez à suivre les instructions d’installations pour que cela fonctionne correctement !

Extensibilité

Une des forces d’Application Insights est son extensibilité (en image ici en bas du paragraphe SDK Layering). Elle est possible via plusieurs concepts :

• Modules
• Processeurs
• Initialiseurs

Le fichier de configuration ApplicationInsights.config installé par défaut est déjà préconfiguré avec beaucoup de ces modules, processeurs et initialiseurs. Une liste exhaustive et une description exhaustive de ces éléments est disponible dans la documentation officielle.

Passons en revue brièvement ces concepts avant de passer à la personnalisation.

Modules

Les modules permettent de choisir quelles informations vous souhaitez collecter depuis votre application. Leurs noms sont plutôt explicites et la documentation officielle explique bien à quoi ils servent.
A noter que certains modules ne sont pas utilisables dans tous les contextes. Exemple avec celui qui collecte les données des compteurs de performances, il n’est pas disponible pour les applications hébergées sur les App Services Azure.

Initialiseurs et Processeurs

Ces éléments sont complémentaires aux modules, ils permettent d’enrichir les données collectées avec de nouvelles informations. Chaque initialiseur à la responsabilité d’ajouter ou modifier une donnée précise.
Les processeurs sont appelés après les initialiseurs et peuvent aussi ajouter/modifier ou filtrer les données. C’est par exemple le parfait moyen pour filtrer des données confidentielles avant envoi, avec la RGPD qui arrive cela peut être utile !

Création d’un processeur

Voyons maintenant comment implémenter un nouveau processeur sur un cas concret.

Présentation du cas

Chez Younited Credit, nous utilisons beaucoup les App Services Azure. Sur ces App Services, nous utilisons le Always On pour nous assurer que les sites hébergés soient toujours prêts et accessibles. Nous utilisons également Application Insights pour surveiller nos applications.

Nuisance

Nous avons constaté une nuisance liée à l’utilisation du Always On : les statistiques d’Application Insights sont « polluées » par les hits effectués toutes les 5 minutes destinés à garder l’App Service accessible.

Solution

En travaillant sur l’amélioration de notre politique de log, nous avons eu l’idée d’éliminer cette nuisance en créant un processeur qui aura pour rôle de filtrer cette télémétrie qui ne nous intéresse pas.

Utiliser un processeur pour cela a plusieurs avantages :

• Cela est géré de manière centralisée dans notre configuration Application Insights que nous partageons entre toutes nos applications.
• Nous économisons de l’argent en n’enregistrant pas de la télémétrie dont nous ne nous servons pas (rappel : vous payez au volume au-delà d’1 Go par mois !).
• Azure utilise un user agent explicite pour les appels effectués par le Always On. Ils sont donc facilement identifiables.

Implémentation

Voici l’implémentation de ce processeur :

/// <summary>
/// Exclude from logs request done by Azure AppServices AlwaysOn UserAgent.
/// </summary>
public class AlwaysOnFilterProcessor : ITelemetryProcessor
{
private const string AzureAlwaysOnUserAgentName = "AlwaysOn";
private ITelemetryProcessor Next { get; }
/// <summary>
/// Constructor taking next processor to run.
/// </summary>
/// <param name="next"></param>
public AlwaysOnFilterProcessor(ITelemetryProcessor next)
{
this.Next = next;
}
/// <summary>
/// Process item only if it doesn't come from AlwaysOn.
/// </summary>
/// <param name="item"></param>
public void Process(ITelemetry item)
{
var context = HttpContext.Current;
if (context == null)
{
return;
}
if (context.Request.UserAgent?.IndexOf(AzureAlwaysOnUserAgentName, StringComparison.OrdinalIgnoreCase) >= 0)
return;
this.Next.Process(item);
}
}

Ensuite, il ne reste plus qu’a ajouter le processeur dans votre configuration.

Vous pouvez le faire de manière statique en l’ajoutant directement dans le fichier de configuration ApplicationInsights.config. Il faut ajouter la ligne de configuration dans la section TelemetryProcessors en utilisant le nom complet du type et l’assembly du processeur :

<TelemetryProcessors>
<!-- Autres processeurs existants présents ici -->
<Add Type="Yuc.Logging.Web.AlwaysOnFilterProcessor, Yuc.Logging.Web"/>
</TelemetryProcessors>

Vous pouvez aussi faire cette configuration par code, dans le startup de votre application. Elle doit être faite avant de déclarer un TelemetryClient :

// Uniquement si votre fichier ApplicationInsights.config ne contient pas déjà la clé
TelemetryConfiguration.Active.InstrumentationKey = "VOTRE_CLE_APPLICATION_INSIGHTS_ICI";
var builder = TelemetryConfiguration.Active.TelemetryProcessorChainBuilder;
builder.Use((next) => new AlwaysOnFilterProcessor(next));
builder.Build();

Et voilà, l’Application Insights de votre application n’enregistrera plus les hits effectués par le Always On Azure.

On peut voir le résultat en image en consultant les requêtes serveurs sur la blade Application Insights :

Le flux continu de requêtes a disparu. Il ne reste que les requêtes liées aux utilisateurs. Les erreurs serveurs que vous pouvez voir étaient liées également au Always On. La présence d’un filtrage IP au niveau du fichier de configuration du site avait pour effet d’enregistrer des 404.

Conclusion

Le but de cet article était de vous présenter comment il est possible d’étendre facilement le comportement d’Application Insights.
Comme vous avez pu le voir, il est très simple d’étendre le comportement du SDK, celui-ci étant très générique.

Attention tout de même à garder vos processeurs et initialiseurs simples et chacun avec une responsabilité unique et bien définie. Il faut garder à l’esprit qu’ils vont potentiellement être appelés (en fonction de comment ils sont configurés) pour chaque télémétrie qui est enregistrée par votre application ! Cela peut avoir un impact non négligeable sur votre application si leur exécution est coûteuse.

Avant de développer un nouveau composant, pensez à vérifier s’il n’est pas déjà couvert par un des nombreux éléments déjà fournis. Le mieux est de consulter la documentation officielle ou le code source directement, il est disponible sur Github :

• SDK : https://github.com/Microsoft/ApplicationInsights-dotnet
• Initialiseurs, processeurs existants : https://github.com/Microsoft/ApplicationInsights-dotnet-server