Dans la continuité des articles précédents sur la Kubernetes Gateway API, nous explorons aujourd’hui un aspect plus opérationnel de ce...
17 avril 2025
Introduction à Azure Monitor Logs Ingestion API – première partie
Cet article est le premier d’une série sur Azure Monitor Logs Ingestion API. En rédigeant cette introduction, il est rapidement apparu qu’un seul article ne suffirait pas à couvrir l’ensemble du sujet. C’est pourquoi cette série sera découpée en trois volets :
- Introduction à Azure Monitor Logs Ingestion API – Première partie
- Introduction à Azure Monitor Logs Ingestion API – Seconde partie
- Introduction à Azure Monitor Logs Ingestion API – Troisième partie
Comme pour tout nouveau service Azure, quelques éléments essentiels doivent être examinés :
- La documentation du service que nous allons consommer (Logs Ingestion API)
- Les limites du service que nous allons consommer (Logs Ingestion API)
- Les limites des services adjacents que nous allons aussi consommer (Data Collection Rule)
- La grille tarifaire dont il dépend (Azure Monitor)
Cette préparation permet d’anticiper les éventuelles surprises. Ceci, posé, rentrons dans le vif du sujet.
Objectif de cette première partie
Pour rendre son application « observable », il est nécessaire qu’elle produise des logs, des métriques et des traces. Pour les ressources Azure, cela est facilité via les Diagnostic Settings. Mais comment instrumentaliser notre code pour produire des logs et des métriques ? Réponse : Avec Azure Monitor Logs Ingestion API, à ne pas confondre avec la Azure Monitor HTTP Data Collector API qui sera elle dépréciée en 2026.
Dans cet article, nous allons aborder la mise en œuvre de l’infrastructure sous-jacente. Pour simplifier la mise en œuvre, le code nécessaire est mis à disposition dans ce Repository GitHub DemoAMLIAPI. Le template ARM mis à disposition assure le déploiement de toute l’infrastructure nécessaire. Pour le contexte de cet article, le template ARM sera déployé dans un groupe de ressources nommé « demologingestion ». Le template n’a besoin que d’un seul paramètre : Un préfixe pour toutes les ressources que nous allons créer. Une fois déployées, voici le détail des ressources dans notre groupe de ressources :
Le template ARM met à disposition :
- Une instance Azure Log Analytics Workspace
- Une « Custom Table » pour stocker notre métrique
- Un Action Group pour réaliser la notification des alertes
- Une alerte qui va exploiter une requête KQL pour interroger notre « Custom Table »
- Une Data Collection Rule (DCR) pour opérer la transformation de notre métrique et son ingestion
- Une Data Collection Endpoint (DCE) pour nous permettre de joindre la Data Collection Rule (DCR)
- Un Workbook pour interroger la « Custom Table » en fonction de différents critères
Au terme du déploiement, un certain nombre d’informations sont mises à disposition, dont nous allons avoir besoin dans la partie code de l’implémentation.
La documentation Microsoft constitue une base solide pour implémenter Azure Monitor Logs Ingestion API. Voici un aperçu de l’architecture cible : 
Un peu de terminologie
Pour produire notre métrique, il est nécessaire de mettre en œuvre une « Custom Table » dans Azure Log Analytics Workspace. Ce sera la destination de notre métrique. L’alimentation de cette table passera par un autre objet Azure nommé « Azure Data Collection Rule (DCR) » qui décrira comment traiter un « Stream » de données entrant, le transformer et l’insérer dans notre « Custom Table ».
Enfin, un dernier objet Azure nommé « Azure Data Collection Endpoint (DCE) » sera mis en œuvre pour exposer notre « Data Collection Rule (DCR) » à notre application. On peut le voir comme un endpoint d’API qui sera visible par notre application.
Log Analytics & Custom Table
La création de l’instance Log Analytics ne présente pas de complexité. En revanche, la définition de la Custom Table nécessite de l’attention. La table doit préalablement exister avant de pouvoir y faire référence dans notre Data Collection Rule (DCR).
Ci-dessous, l’exemple fourni dans le template ARM montre une structure composée de cinq colonnes.
En fait, il y a une astuce car nous allons exploiter le mécanisme de transformation (KQL) dans notre Data Collection Rule (DCR) pour peupler dynamiquement de nouveaux attributs. D’où le type « Dynamique » pour l’attribut « AdditionalContext ».
Points de vigilance :
- Le nom de la « Custom Table » doit impérativement contenir l’extension « _CL »
- Certains attributs sont obligatoires comme « TimeGenerated »
Data Collection Endpoint (DCE)
Voilà un objet très simple. Comme indiqué, le DCE expose la Data Collection Rule sous forme d’URL, permettant à l’application d’y accéder comme à une API. La configuration est minimale. En sortie, ce qui va nous intéresser, c’est cette fameuse URL d’exposition que l’on retrouvera dans le portail Azure comme illustré ci-dessous :
Cette même information est mise à disposition en sortie de notre template ARM.
Data Collection Rule (DCR)
La Data Collection Rule (DCR) est un composant central. C’est un objet Azure pour lequel nous allons fournir une « Data Source » pour réaliser la transformation. Elle peut être représentée ainsi :
Comme l’illustre le schéma, la mise en place d’un « streamDeclaration » permet de formaliser la structure des données manipulées. Ce flux est ensuite traité par un « DataFlow », au sein duquel une transformation est opérée via une requête KQL. Enfin, le flux est envoyé vers une destination : le Log Analytics Workspace.
La requête KQL présente une caractéristique pour construire notre attribut « AdditionalContext ». Pour rappel, il est de type dynamique : chaque entrée dans la table peut avoir une structure qui lui est propre. De cette manière nous allons pouvoir définir des sous-attributs pour ajouter du contexte sans jamais devoir reconfigurer l’infrastructure.
Il est essentiel de conserver l’attribut ImmutableID généré par le template ARM, également visible dans le portail Azure comme illustré ci-dessous :
À propos de Azure Monitor Private LinkScope (AMPLS)
Bien que Azure Monitor Private Link Scope (AMPLS) mériterait un article à part entière, il est volontairement exclu de cette première partie. Il est simplement utile de noter que ce service permet de privatiser l’ensemble des composants Azure Monitor, via des « Access Modes » pour l’ingestion et l’interrogation des données. En l’absence de configuration, ce sera donc une implémentation publique que nous allons réalise
Role assignments
Tous les composants sont en place, il ne nous reste que le sujet des « roles assignments ». Pour produire des métriques, il est nécessaire que notre identité soit associée au rôle « Monitoring Metrics Publisher ». Ce rôle, comme indiqué ci-dessous, se concentre principalement sur des dataActions. Dans le cas de la création d’un rôle personnalisé, seule l’action Microsoft.Insights/Metrics/Write est réellement nécessaire.
Source : Monitoring Metrics Publisher
Pour que le script mis à disposition puisse fonctionner, il faudra que l’identité qui va l’exécuter dispose de ce rôle sur le scope de la Data Collection Rule (DCR), sinon, cela produira une erreur comme celle-ci :
Point d’attention, la propagation des permissions au niveau du data plane peut-être longue. Une liste des différents codes erreurs est disponible ici : Troubleshooting. La première réaction sera donc d’attendre.
Le second « Rôle Assignment » est lui nécessaire pour nous permettre de recevoir les mails de notifications émis lors du déclenchement de l’alerte. Dans le contexte de cet article, il a été retenu d’utiliser le mécanisme de notification « Email Azure Resource Manager Rôle » qui implique que notre identité soit associée à un rôle. La fonctionnalité a quelques contraintes au niveau du « Rôle Assignment » :
- Est nécessairement mis en œuvre au niveau de la souscription Azure
- Doit référencer notre identité ou un groupe de sécurité Azure AD Entra dont nous sommes membres
- Utiliser uniquement un des rôles Builtin suivants : « Owner », « Contributor », « Reader », « Monitoring Contributor », « Monitoring Reader ».
Le troisième « Role assignment » n’est pas obligatoire mais doit être considéré dans le futur, si nous voulions appliquer des principes de « Least Privilege ». Il faudrait :
- Associer une User-Assigned identity à nos alertes (Azure Monitor log search support managed idenities)
- Accorder le rôle « Monitoring Metrics Publisher » à notre « User-Assigned Managed Identity » sur le Data Collection Rule (DCR) pour publier des métriques.
Toujours dans une approche « Least Privilege », nous devrions mettre en place un « Role Assignment » pour notre identité avec le rôle « Log Analytics Reader » sur l’instance Log Analytics pour interroger notre nouvelle « Custom Table ».
Conclusion – Infrastructure prête pour Logs Ingestion API
L’infrastructure de base est désormais opérationnelle. La seconde partie de cette série se concentrera sur la génération de métriques avec PowerShell. Le template ARM utilisé ici est disponible dans le GitHub DemoAMLIAPI et constitue un prérequis pour les prochaines étapes de mise en œuvre d’Azure Monitor Logs Ingestion API.
Vous avez envie de rejoindre Cellenza ?
Vous souhaitez rejoindre un cabinet de conseil engagé dans la RSE, reconnu pour son très haut niveau d’expertise ? Retrouvez tous nos postes ouverts sur notre site Carrière et n’hésitez pas à contacter notre équipe Recrutement !
