Introduction à Azure Monitor Logs Ingestion API – Seconde Partie

Nous voilà dans la seconde partie de la série d’article sur l’introduction à Azure Monitor Logs Ingestion API. L’infrastructure est en place, il ne reste plus qu’à produire des métriques. Pour rappel, le précédent article est ici : Introduction à Azure Monitor Logs Ingestion API – Première partie.

La partie code sera beaucoup plus simple et prendra la forme d’un script PowerShell pour usage de démonstration mis à disposition dans la Repository GitHub DemoAMLIAPI. Nous allons juste aborder quelques détails :

• Authentification
• Construction du Payload
• Production de la métrique

Authentification

Pour interagir avec la Data Collection Rule (DCR), il vaut présenter une identité disposant de notre « Role Assingment » pour le rôle « Monitoring Metrics Publisher ». La commande PowerShell Get-AzAccessToken fera le job. La seule subtilité, c’est la gestion d’un changement à venir avec cette commande :

Il faut un peu de travail et mieux gérer le stockage de notre jeton d’accès ainsi que son effacement :

Note : Rappel, pour que l’appel à l’API fonctionne, notre identité devra disposer d’un « Rôle Assignment » pour le rôle « Monitoring Metrics Publisher » sur l’objet « Data Collection Rule » comme illustré ci-dessous :

Construction du Payload 

Dans la construction du Payload, nous allons pouvoir passer un nombre dynamique de colonnes. De cette manière, on sera en mesure de produire des métriques dont la structure peut être différente sans devoir réécrire la DCR à chaque fois. La construction de notre Payload nous permet de structurer le contenu de l’attribut « AdditionalContext ». 

Production de la métrique 

Pour la fin, ne reste plus qu’à assembler le tout en invoquant le Data Collection Endpoint (DCE) avec notre Payload ainsi que notre identité avec un simple « Invoke-RestMethod ». C’est là que nous allons réutiliser les outputs de notre Template ARM.  

L’API que nous allons appeler est accessible via notre Data Collection Endpoint (DCE), qui dispose d’une « Log Ingestion URL » comme celle-ci : https://demo-dce-westeurope-8kjl.westeurope-1.ingest.monitor.azure.com. Derrière ce point d’entrée, nous avons notre Data Collection Rule (DCR) qui est représentée par son identifiant unique (Immutable ID). Il ne nous reste plus qu’à préciser quelle « Data Source » nous allons utiliser et donc la transformation à opérer. On peut retrouver cette information dans le portail Azure comme illustré ci-dessous :

Un point intéressant ici, c’est qu’une Data Collection Rule (DCR) peut référencer plusieurs « Data sources » et donc plusieurs règles de transformation pour un point d’exposition unique. Tout cela assemblé nous donne une URL pour produire notre métrique.

Si lors de l’exécution vous avez une erreur 403 comme celle illustrée ci-dessous, c’est que votre identité / Azure Function ne dispose pas du « Rôle Assignment » sur le scope attendu :  

Pour le prochain article, je vous conseille de produire quelques métriques à l’aide de la commande suivante : « demologingestion.ps1 –ResourceGroup_name DemoLogIngestion  –MetricValue (Get-Random -Minimum 0 -Maximum 100) » 

Dans notre instance de Log Analytics Workspace, la « Custom table » contient bien les métriques nouvellement publiées :  

Synthèse 

Nous sommes désormais capables de produire des métriques. L’intégralité du code PowerShell nécessaire à cette opération est disponible dans ce Repository GitHub DemoAMLIAPI. Pour la dernière partie, nous allons exploiter ces métriques pour produire des alertes et les représenter.