Monitorer le SLA applicatif avec Application Insights

Aujourd’hui, je reviens vers vous avec un petit retour d’expérience sur l’utilisation de Azure Application Insights pour monitorer la disponibilité de services hébergés ou non sur Azure.

SLA Report

Application Insights

A l’instar de Google Analytics, Application Insights vous permet d’instrumenter votre application et de bénéficier d’informations pertinentes sur le fonctionnement de votre application ainsi que des usages qu’en font vos utilisateurs. Vous pourrez ainsi facilement ajouter les agents de télémétrie dans vos applications (Backend et Frontend).

Une fois votre application instrumentée, et votre télémétrie disponible dans Application Insights, vous bénéficier alors de Dashboard et d’une interface utilisateur adaptée au diagnostique de votre application :

Overview

Application Insights Overview

Cette page d’overview de Application Insights vous permet alors d’accéder aux différents écrans de monitoring et de diagnostique de votre application comme par exemple Failed Requests

Failed Requests

Failed Requests

A partir de cet écran il est alors possible d’analyser en profondeur les différentes erreurs rencontrées dans votre application, en effectuant un drill down depuis votre opération (requête Http par exemple), jusqu’à l’accès à votre base de données et la requête SQL qui a été générée…

Disponibilité et SLA

Dans cet article, je ne vais pas détailler chacune des fonctionnalités de Azure Application Insights, mais je vais m’attarder à la mise en œuvre de tests de disponibilité de votre application et/ou de vos dépendances afin d’être alerté en cas d’indisponibilité et/ou de récupérer un rapport de disponibilité de votre application au global.

Pour pouvoir alimenter la disponibilité de votre application dans Application Insights, vous devrez créer des tests de disponibilité. Plusieurs types de tests sont présents :

  • Test classiques
    • URL Ping
    • Multi-Step
  • Test Standard

Locations

Pour chacun de ces tests, vous pouvez demander à Azure de les déclencher depuis plusieurs localisations. Il s’agit des datacenters de Microsoft Azure. Cette option est très intéressante puisqu’avec ceci vous pouvez faire en sorte que votre mesure de disponibilité ne soit affectée que si plusieurs origines ne peuvent pas effectuer le test. De cette manière vous pourrez exclure les erreurs liées à un datacenter en particulier (si votre application est géo-redondée).

L’alerte sur la disponibilité pourra alors être déclenchée si plusieurs localisations indiquent en même temps un résultat négatif …

Alertes

Les alertes sont gérées par Azure Monitor, vous aurez alors le même type de fonctionnalité que pour les autres alertes que vous gérez avec Azure Monitor (Email, SMS, Web Hook, ITSM, …).

Fréquence

Les tests déclenchés par Azure Application Insights seront déclenchés sur la base d’un choix que vous aurez fait entre plusieurs valeurs possibles (5min, 10min ou 15min). Cette fréquence est souvent largement suffisante, mais il faudra garder en tête que la mesure de la disponibilité et de l’indisponibilité ne pourra pas être faite avec une granularité inférieure à 5min.

Tests Classiques

Deux possibilités s’offrent à vous pour les tests classiques, URL Ping et Multi-Step.

Le URL ping est tout aussi simple que son nom l’indique, il s’agit d’un simple test de ping sur une URL. Vous aurez ainsi la possibilité valider qu’un endpoint est bien disponible (en spécifiant le HTTP Method qu’il convient et un body dans le cadre d’une POST), qu’il vous renvoit une réponse attendue (Status Code, et un content match basé sur la présence simple d’un texte dans le corps de la réponse). Il s’agit bien là d’un test très basique, mais efficace dans de nombreux cas.

Le Multi-Step est un test basé sur un WebTest edité par Visual Studio. Ce type de test permet d’effectuer des actions de test plus pointues avec un enchaînement de requêtes par exemple, des contrôles sur les headers, des contrôles plus poussés sur le body, …. Cependant c’est une fonctionnalité amenée à disparaitre, Microsoft a en effet annoncé une fin programmée de ce type de test et vous propose alors de réaliser des tests de disponibilité personnalisés déclenchés par Azure Function (nous allons voir cela plus bas dans cet article).

Tests Standard

Au moment où j’écris cet article, le test de disponibilité « Standard » est encore en public preview, c’est-à-dire que tout le monde peut bénéficier de cette fonctionnalité, mais que celle-ci ne fait pas partie des garanties de Microsoft Azure et que donc vous pourriez ne pas avoir de support sur cette fonctionnalité.

En revanche, c’est une fonctionnalité sur laquelle Microsoft va très certainement rapidement passer en GA et donc où le support et les garanties seront complètement remplies.

Il reste cependant assez proche du test classique en URL Ping, mais ajoute un test proactif de la validité de votre certificat SSL avec l’affichage d’une alerte si votre certificat expire dans quelques jours (1, 7, 30, 90, 365).

Test de disponibilité personnalisé

Vous pouvez également réaliser des tests de disponibilité personnalisés au travers du SDK de Application Insights. Cette méthode est extrêmement utile pour par exemple :

  • Réaliser des tests plus complexes que ceux présents en URL ping ou même Standard,
  • Augmenter la fréquence (granularité) de vos tests.

A noter cependant que la fonctionnalité nous permettant d’émettre les informations de disponibilité n’est disponible uniquement dans la version .NET du SDK de Application Insights.

La réalisation est assez simple : on ajoute le package Microsoft.ApplicationInsights à notre projet et nous utilisons la méthode TrackAvailability de TelemetryClient. Regardons maintenant cela de plus près…

Démonstration

Dans cette démonstration, je vais utiliser et déployer une Function App, mais notez que cela peut s’exécuter par n’importe quel moyen du moment où l’on exécute du .NET…

Nous allons ensemble créer une fonction d’orchestration durable nous permettant de piloter le déclenchement de plusieurs activités en asynchrone avant de terminer l’exécution. (Pour plus d’informations sur sur les fonctions durables : Durable Functions Overview – Azure | Microsoft Docs)

Commençons donc par créer une nouvelle Application de Fonction Azure avec Visual Studio Code.

Dans le choix du template de votre fonction, choisissez l’option « Timer Trigger« , cela nous permettra d’avoir alors une fonction qui se déclenchera à la fréquence que vous aurez choisie.

Vous pourrez retrouver l’intégralité de ce code source sur mon repository github : kbeaugrand/custom-availability (github.com).

TestUri Activity

Puis nous allons commencer par créer l’activité qui nous intéresse :

        [FunctionName("TestUri")]
        public static async Task TestUri([ActivityTrigger] Uri test, ILogger log)
        {
            var telemetryClient = new TelemetryClient(new TelemetryConfiguration(Environment.GetEnvironmentVariable("APPINSIGHTS_INSTRUMENTATIONKEY")));
            var telemetry = new AvailabilityTelemetry();
            telemetry.Name = test.Host;
            var watch = new Stopwatch();

            try
            {
                HttpClient client = HttpClientFactory.Create();

                watch.Start();
                var responseMessage = await client.GetAsync(test);

                responseMessage.EnsureSuccessStatusCode();
                telemetry.Success = true;
            }
            catch (Exception e)
            {
                telemetry.Message = e.ToString();
            }
            finally
            {
                watch.Stop();
                telemetry.Duration = watch.Elapsed;
                telemetryClient.TrackAvailability(telemetry);
                telemetryClient.Flush();
            }
        }

Comme vous le constatez, cette activité déclenche un appel HTTP Get sur l’URL en paramètre et demande au client de télémétrie Application Insights d’envoyer une mesure de disponibilité avec la mesure du temps d’exécution et le message d’erreur s’il y en a une.

Orchestration

Maintenant nous allons créer la logique d’orchestration. L’idée ici est de déclencher l’activité de test plusieurs fois sur des Urls différentes en parallèle et d’attendre le résultat de chacune de ces activités pour terminer :

        [FunctionName("RunOrchestrator")]
        public static async Task RunOrchestrator(
            [OrchestrationTrigger] IDurableOrchestrationContext context)
        {
            List<Task> activities = new List<Task>();

            activities.Add(context.CallActivityAsync("TestUri", "https://www.bing.com/"));
            activities.Add(context.CallActivityAsync("TestUri", "https://www.google.com/"));

            await Task.WhenAll(activities);
        }

L’orchestration effectuera donc les tests sur Bing.com et Google.com…

Timer Trigger

Enfin vient la partie de scheduling de ce monitoring. Comme nous avons utilisé le template « Timer Trigger », il nous faut maintenant modifier le corps de cette première fonction pour pouvoir appeler l’orchestration :

        [FunctionName("TimerOrchestrator")]
        public static async Task TimerOrchestrator([TimerTrigger("0 */1 * * * *")] TimerInfo timer, [DurableClient] IDurableOrchestrationClient starter)
        {
            await starter.StartNewAsync("RunOrchestrator", null);
        }

Configuration de Application Insights

Après avoir déployé l’application de fonction sur Azure, nous pouvons activer très rapidement l’envoi de la télémétrie de cette application dans Application Insights.

Configuration de la Function App

Il est maintenant temps de pouvoir consulter ces informations, rendez-vous dans la page « Disponibilité » de votre application Insights :

Vous pouvez alors depuis cet écran consulter les différents statuts de disponibilité pour chacun des tests et investiguer dans chacune des itérations les causes de l’indisponibilité. Passons maintenant au rapport de SLA de notre application.

Rapport de SLA

Depuis la page de disponibilité de votre application, cliquez sur « Rapport SLA ». La page suivante s’affiche alors :

Downtime & Outage

La première page est le rapport de Temps d’arrêts et de pannes de votre application. Cette page remontera alors les différents temps d’arrêts de votre application et les différentes occurrences de pannes rencontrées.

Au-dessus de cette page se trouve un ensemble de filtres et de contrôles vous permettant de paramétrer les objectifs de SLA que vous vous souhaitez :

Paramètres Downtime & Outages

On constate alors la possibilité de spécifier une période de maintenance autorisée de notre application qui exclut les pannes ayant eu lieu durant cette plage de maintenance de votre rapport de SLA rendant alors votre rapport plus spécifique aux erreurs non-planifiées.

Enfin, d’autres onglets sont présents sur le rapport de SLA permettant de diagnostiquer dans les pannes afin de faciliter la Root Cause Analysis en allant plus profondément dans les métriques et logs de votre application.

Conclusions

La mise en œuvre de Application Insights dans les applications Azure est extrêmement simple. Lorsque l’on utilise des applications déployées sur Azure WebApps ou Azure Function, Azure nous assure pour une bonne part l’auto-collection des métriques de notre application ainsi que des dépendances de notre application.

Son interface dédiée à l’analyse et les fonctions de Drill-Down permet rapidement de trouver les causes des erreurs rencontrées et de diagnostiquer des problématiques de performance.

Ajoutez à cela que Application Insights permet maintenant de déposer l’intégralité des métriques et logs dans votre Log Analytics Workspace, vous pouvez utiliser ces insights pendant toute leur durée de vie pour réaliser rapidement vos dashboards, requêtes et alerting au travers de Azure Monitor et de ses Action Groups.

Les tests de disponibilité de vos services permettent également de remplir votre rapport de SLA. Application Insights vous permet de déclarer basiquement un certain nombre de tests, mais dès que cela devient un peu plus complexe (ex: authentification sur un service, enchainement de requêtes, contrôle plus poussé dans le résultat de la réponse, …), je vous conseille de passer rapidement dans un test de disponibilité personnalisé avec l’utilisation du SDK de Azure Application Insights.

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s