Monitoring sur Azure : automatiser l’exploitation des logs et mettre en place les alertes

Généralement, quand on développe une fonction ou une web API, on rajoute des logs qui nous permettent d’analyser les erreurs de nos lignes de code ou tout simplement suivre l’exécution de la fonction et mesurer les actions des utilisateurs (connexion, inscription, désinscription, etc.).
Ces logs sont souvent réservés aux développeurs et ne sont pas exploitables par les experts métiers.
Dans cet article, nous allons détailler une méthode simple pour automatiser l’exploitation des logs et de notifier les responsables selon les cas d’usages.
Les puits de Logs sur Azure
Il existe deux puits de logs sur Azure qui permettent de collecter les logs des applications dans Azure ou en dehors, ainsi que la télémétrie des composants Azure tels que les machines virtuelles, Logic Apps, Data factory, Container, etc. :
- Log Analytics
- Application Insights
Log Analytics
Azure Log Analytics Workspace est le stockage logique des logs sur Azure. Il est utilisé par Azure Monitor pour collecter et stocker les logs, et par différents autres services Azure notamment, Azure Sentinel, Machine Virtuelle, Logic Apps, etc.
Application Insights
Application Insights est une feature d’Azure Monitor qui permet de collecter les logs de vos applications comme les applications mobiles, les Web Apps, les Azure fonctions, ainsi que les applications hébergées sur d’autres Clouds ou même on-premises.
Application Insights s’intègre facilement avec les différents frameworks de développement tels que .NET, Java, Node.js et Python.
On peut associer Application Insights au Log Analytics Workspace et bénéficier de toutes les fonctionnalités de ce dernier.
Comment envoyer les Logs ?
Chaque composant a une méthode de configuration et d’envoi de logs. Je vous propose ici de détailler le cas d’une Azure Function et d’une Logic Apps.
Cas de Web App ou d’Azure Fonction
Avant de commencer à surveiller votre code, la première étape consiste à lier sa fonction à Application Insights. Pour cela, il faut rajouter dans la configuration la variable APPINSIGHTS_INSTRUMENTATIONKEY avec comme valeur la clé d’instrumentation de votre application insights :
"APPINSIGHTS_INSTRUMENTATIONKEY" : "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
La prochaine étape consiste à installer le package Microsoft.ApplicationInsights et importer les Namespaces suivants dans votre classe :
using Microsoft.ApplicationInsights; using Microsoft.ApplicationInsights.Extensibility;
Vous devrez ensuite initialiser le client qui va envoyer les logs :
Vous pouvez maintenant commencer à envoyer les évènements de logs selon le cas d’usage : les Traces, les Exceptions ainsi que les CustomEvents de vos fonctions.
Pour les Traces:
_telemetryClient.TrackTrace($"Demo trace:function executed at: {DateTime.Now}") ;
Pour les Exceptions:
_telemetryClient.TrackException(new Exception($"Demo trace : Timer trigger function executed at: {DateTime.Now}"));
Pour les CustomEvents:
Cas d’une Logic Apps
Pour les Logic Apps et d’autres services Azure, il suffit de les associer au Log Analytics Workspace. Je vous invite à consulter l’article de Microsoft sur les Log Analytics pour plus de détails.
Si vous déployez vos Logic Apps avec un ARM Template, vous n’aurez qu’à ajouter la ressource DiagnosticSettings et activer les catégories que vous souhaitez surveiller comme dans l’exemple suivant :
Pour envoyer des custom logs à Log Analytics, vous pouvez utiliser le connecteur Azure Log Analytics Data Collector qui fournit deux paramètres :
- JSON Request body: permet de passer les données sous forme d’un objet JSON.
- Custom Log Name: permet de définir le nom de la table qui va stocker les logs. Si la table n’existe pas, elle sera créée avec un préfixe _CL (par exemple pour la valeur « Bootcamp » la table créée sera « Bootcamp_CL »).
Pour récupérer ces logs, il suffit de requêter avec le nom de la table dans l’éditeur Log Analytics Workspace.
Comment implémenter l’Alerting sur Azure ?
Maintenant que les logs sont remontés dans Azure, nous pouvons implémenter nos alertes.
Préparation de la requête
Tout d’abord, il faut préparer la requête qui va nous retourner le résultat pour le type de logs qu’on souhaite surveiller (par exemple les Exceptions, les Warnings ou une donnée fonctionnelle stockée dans un customEvent).
Sur le portail Azure, naviguez vers l’onglet Logs de Application Insights ou Logs Analytics. Dans l’éditeur de requête, vous pouvez exécuter les requêtes. Par exemple, pour sélectionner les Exceptions générées depuis 24h, vous pouvez utiliser :
exceptions | order by timestamp desc | count
Action group et Webhook
Quand toutes les conditions pour lever une alerte sont réunies, Azure utilise le composant action groups pour notifier les utilisateurs par email, SMS, et/ou pousser une notification à un autre composant comme une Azure Function ou une Logic Apps via un Webhook.
Si vous choisissez une Azure Function pour recevoir la notification et personnaliser le message, alors il suffit de passer le message en se basant sur le schéma fourni par Microsoft (alerts-common-schema-test-action-definitions) et d’envoyer une requête HTTP à la cible (Teams, Slack, Jira, etc.).
Le code suivant nous donne un exemple pour le cas de l’envoi à Teams :
Si vous préférez moins de code, vous pouvez utiliser une Logic Apps, comme dans l’exemple suivant :
Création de l’Alerte
Sur le portail Azure, naviguez vers l’onglet Logs de Application Insights puis créez Alert Rule :
Dans la liste des signaux, choisissez Custom Log Search, puis insérez votre requête et validez.
Vous pouvez ensuite configurer la fenêtre de recherche ainsi que la fréquence d’évaluation d’alerte.
Par exemple : évaluer la requête tous les jours et récupérer les logs des 24 dernières heures.
Dans l’onglet « Action », choisissez l’action préalablement créée : AG-bootcamp-01.
Enfin, dans l’onglet « Details », choisissez la Resource Group, le nom de l’alerte, la description et la sévérité.
Résultat de la création de l’alerte
Maintenant que notre alerte est créée, dès que les conditions définies dans la requête sont vérifiées, on devrait recevoir une alerte sur Teams avec un lien pour voir les logs :
Aller plus loin sur le monitoring Azure
Dans cet article, nous avons présenté une méthode simple et peu coûteuse pour surveiller les fonctions et autres composants sur Azure sans inonder les boites mail de messages souvent ignorés ou filtrés.
Si vous préférez utiliser des tableaux de reporting, je vous invite à lire notre précédent article sur les workbooks.
Très bien expliqué, bravo! 👍🏽