Dans la continuité des articles précédents sur la Kubernetes Gateway API, nous explorons aujourd’hui un aspect plus opérationnel de ce...
18 juin 2025
Introduction à Azure Monitor Logs Ingestion API – Troisième partie
C’est le dernier article de cette série sur l’introduction à Azure Monitor Logs Ingestion API. Les métriques sont désormais disponibles, il ne reste plus qu’à mettre en place des alertes et représenter le tout. Pour rappel, les deux précédents articles sont disponibles ici :
Azure Alert
La production d’alertes pour les métriques présents dans la table constitue la première étape. Techniquement, nous allons mettre en œuvre une « Scheduled Query Rule » qui va exploiter un « scope » qui est notre instance Log Analytics Workspace. Le signal sera issu de notre table « MyTable_CL » que l’on va traiter au travers d’une requête KQL. L’objectif est de ne retenir que les valeurs de notre métrique qui dépasseront la valeur de 50. Une contrainte de temporalité (dans les cinq dernières minutes) sera ajoutée à la requête. L’alerte devra ainsi se déclencher si la métrique est supérieure à 50 dans ce laps de temps. Si ce n’est plus le cas, alors l’alerte doit être close.
Action Group
Lorsque cette alerte se déclenche, la réaction prend la forme d’un Action group qui va utiliser un type de notification : « Email Azure Resource Manager Role » qui présente quelques limitations à connaître :
- C’est un service comme un autre, avec des limitations. Il y a donc un risque que nous ne recevions pas de mails.
- Le service ne supporte qu’un sous ensemble des rôles Azure Builtin : « Owner », « Contributor », « Reader », « Monitoring Contributor », « Monitoring Reader ». Conclusion, pas possible d’utiliser des rôles « Custom ».
- L’assignation du rôle doit nécessairement être réalisée au niveau de la souscription.
- Enfin, nous n’allons recevoir les premiers mails de notification que 24 heures après l’assignation du rôle
Si ces limitations sont bloquantes pour vous, il faudra alors considérer une solution alternative pour envoyer des mails de notifications. Une solution peut être d’utiliser une Azure Function pour récupérer le payload de l’alerte, construire un message qui sera envoyé à l’aide d’Azure Communication Services.
Sources :
Dans le cadre de cet article, l’alerte n’a pas été configurée pour utiliser une « User-Assigned Managed Identity ». C’est une nouvelle fonctionnalité (Azure Monitor log search support managed idenities) qui peut être exploiter pour appliquer le principe du « Least Privilège » auxalertes lorsqu’elles interrogent l’instance Log Analytics Workspaces.
Représentation
Azure Workbook est un moyen simple et efficace pour représenter nos métriques. Nous n’allons pas rentrer dans le détail de ce sujet dans cet article car il a déjà été abordé par un autre Cellenzan : Workbooks Azure : comment réaliser ses propres dashboards.
J’ai mis à disposition dans le template ARM un Workbook minimaliste pour illustrer le cas d’usage. Sans rentrer dans tous les détails, un Workbook exploite différentes data sources. Celle qui va nous intéresser, c’est log.
Après, c’est votre créativité en KQL qui fera le reste. Pour la réalisation, un seul conseil : Pour être efficient dans le Cloud Computing, il faut apprendre à être fainéant : ARM template for deploying a workbook instance. Conclusion, utilisez le designer mis à disposition pour construire votre Workbook puis exportez le en tant que template ARM pour le déployer. C’est ce que j’ai fait pour le template ARM mis à disposition.
Dans le contexte de cet article, notre Workbook est volontairement élémentaire. Il présente proposer d’utiliser un certain nombre de filtres pour interroger notre « Custom Table » :
Coût de la solution
Selon la formule consacrée « All magic comes with a price ». Premier réflexe, aller consulter le modèle de facturation d’Azure Monitor. Le service est effectivement payant mais l’unité de mesure utilisée indique qu’il faudra réellement produire beaucoup de métriques, pour que son coût devienne réellement prohibitif.
En fait, le danger peut venir des conséquences liées à la métrique associée à des alertes. Selon la fréquence d’évaluation que nous avons retenue, le coût peut rapidement augmenter. Il est donc nécessaire de déterminer si toutes les métriques ont la même valeur pour prendre une décision. Une évaluation toutes les quinze minutes peut, dans certains cas, s’avérer amplement suffisante, tout dépend de vos engagements définis (SLO, SLI, SLA).
Si une alerte est déclenchée, une notification est alors émise. Il est essentiel de calibrer correctement les seuils de déclenchement afin de tirer parti des alertes gratuites chaque mois. À noter que les Secure Web Hooks présentent un tarif totalement prohibitif.
Un dernier point d’attention concernera les Data Collection Rules (DCR) et plus particulièrement les transformations opérées lors de l’ingestion. Dès lors que le processus va réduire la volumétrie de données de plus de 50%, alors nous seront facturés (Cost for transformations) pour ces opérations.
La seule exception, c’est pour les instances Log Analytics Workspaces auxquelles on a lié une instance d’Azure Sentinel. A noter qu’au moment de l’écriture de cet article, la facturation des Data Collection Rules (DCR) ne semble pas encore effective.
Maintenant qu’on comprend un peu mieux le modèle de facturation, le plus simple est de prendre un cas concret et extrapoler. À titre de cela, un projet personnel qui produit entre 10 et 14 métriques toutes les 3 minutes, soit un peu plus de 3500 métriques produites par jour, soit un total de 100 000 métriques par mois. Cette mesure a été réalisée au niveau de la Data Collection Rule (DCR) en observant le métrique « Log Ingestion Request » comme illustré ci-dessous :
Ci-dessous le détail d’un Workbook permettant d’exploiter les métriques de Log Analytics. Il apparaît que la volumétrie stockée dans la « Custom table » ne représente rien par rapport aux autres tables, en particulier si on compare avec la table « AppTraces ». Ce n’est donc pas la rétention de nos métriques qui va peser dans la facture.
Pour finir, voilà un extrait de la facturation de la souscription Azure sur une période de 24 heures pour chaque classe de service consommé. L’analyse montre que l’usage de la Logs Ingestion API d’Azure Monitor génère des coûts minimes.
Dans le contexte, le coût est très maîtrisé car :
- L’instance Log Analytics utilise une durée de rétention de 30 jours uniquement
- La transformation opérée par la Data Collection Rule (DCR) ne déclenche pas le seuil de facturation
- Le poids de la table « MyTable_CL » est presque insignifiante par rapport aux autres.
- A ce jour, l’utilisation du service Azure Monitor Logs Ingestion API ne semble pas encore facturé
On peut donc conclure que l’utilisation de la Logs Ingestion API n’aura pas un impact significatif sur notre facture globale.
Conclusion
C’est la fin de l’introduction à l’Azure Monitor Logs Ingestion API. Techniquement, il y aurait de nombreux éléments à approfondir, mais avec ce que nous venons de détailler dans cette série d’articles offrent désormais toutes les clés pour produire des métriques adaptées aux applications.
Pour compléter, voilà quelques lectures complémentaires qui m’ont bien aidé :
