Observabilité sur Azure : Azure Monitor, Log Analytics, Application Insights, Prometheus et Grafana managés

1. Vue d'ensemble #

Azure Monitor et ses magasins de données.

Une plateforme unique : Azure Monitor #

Sur Azure, toute l'observabilité passe par Azure Monitor. Il repose sur deux magasins principaux : Azure Monitor Metrics (séries temporelles légères, conservées 93 jours) et les journaux Azure Monitor stockés dans des espaces de travail Log Analytics et interrogés en KQL (Kusto Query Language). Application Insights apporte l'APM et stocke ses données (requêtes, dépendances, traces, exceptions) dans Log Analytics. Pour Kubernetes et les métriques Prometheus, Azure propose Azure Monitor managed service for Prometheus et Azure Managed Grafana.

Piliers pris en charge #

À savoir : Le Snapshot Debugger d'Application Insights capture l'état des variables au moment d'une exception en production (.NET) : un complément utile aux profils.

2. Les composants en détail #

Rôle de chaque brique d'Azure Monitor.

Métriques de plateforme et paramètres de diagnostic #

Chaque ressource Azure publie gratuitement ses métriques de plateforme. Les journaux de ressources (requêtes d'une passerelle d'application, journaux d'audit d'une base, etc.) ne sont collectés que si l'on crée un paramètre de diagnostic qui les envoie vers Log Analytics, un compte de stockage, Event Hubs ou une solution partenaire. Le journal d'activité trace les opérations de gestion (création, suppression, modifications de la configuration).

az monitor diagnostic-settings create --name vers-law \
  --resource /subscriptions/<abonnement>/resourceGroups/rg-prod/providers/Microsoft.Web/sites/api-boutique \
  --workspace /subscriptions/<abonnement>/resourceGroups/rg-obs/providers/Microsoft.OperationalInsights/workspaces/law-prod \
  --logs '[{"category":"AppServiceHTTPLogs","enabled":true}]' --metrics '[{"category":"AllMetrics","enabled":true}]'

Log Analytics et KQL #

Un espace de travail Log Analytics contient des tables (Syslog, Perf, ContainerLogV2, AppRequests…). Chaque table peut utiliser le plan Analytics (requêtes complètes, alertes), Basic ou Auxiliary (moins chers, requêtes limitées) selon l'usage. La rétention interactive et l'archivage longue durée se règlent par table.

AppRequests
| where TimeGenerated > ago(1h)
| summarize requetes = count(), erreurs = countif(Success == false),
            p95 = percentile(DurationMs, 95) by bin(TimeGenerated, 5m), Name
| order by TimeGenerated desc

Azure Monitor Agent et règles de collecte (DCR) #

L'Azure Monitor Agent (AMA) remplace les anciens agents Log Analytics (MMA/OMS). Il collecte journaux système, compteurs de performance et fichiers texte sur les VM Windows et Linux, y compris hors Azure via Azure Arc. Ce qu'il collecte et où il l'envoie est décrit dans des règles de collecte de données (DCR), qui peuvent aussi filtrer et transformer les données en KQL avant ingestion pour réduire les coûts.

Application Insights #

Application Insights est la brique APM : requêtes entrantes, dépendances sortantes, exceptions, traces, carte de l'application, analyse des défaillances et des performances, recherche de transactions de bout en bout, métriques en direct, tests de disponibilité et expérience des utilisateurs (SDK JavaScript). Une ressource Application Insights est rattachée à un espace Log Analytics.

Kubernetes : Container Insights, Prometheus et Grafana managés #

Sur AKS, Container Insights collecte journaux et inventaire des conteneurs, tandis que Managed Prometheus collecte les métriques (cibles par défaut, ServiceMonitor et PodMonitor) dans un espace de travail Azure Monitor. Azure Managed Grafana s'y connecte avec des tableaux de bord prêts à l'emploi.

az aks update --resource-group rg-prod --name aks-prod \
  --enable-azure-monitor-metrics \
  --azure-monitor-workspace-resource-id <id-espace-azure-monitor> \
  --grafana-resource-id <id-grafana-manage>

Alertes, groupes d'actions et classeurs #

3. Fiche détaillée de chaque composant #

Rôle, contenu, types de données, rétention et interactions internes et externes de chaque brique du schéma.

Vue récapitulative #

Le tableau suivant résume chaque composant du schéma d'architecture ; les fiches qui suivent les détaillent une par une.

Valeurs indicatives : Les durées de rétention, limites et modèles de prix évoluent régulièrement : vérifiez-les dans la documentation officielle avant de dimensionner une architecture.

Paramètres de diagnostic (diagnostic settings) #

Le mécanisme qui active la collecte des journaux de ressources d'un service Azure et choisit leur destination.

Azure Monitor Agent (AMA) et règles de collecte (DCR) #

L'agent unique de collecte d'Azure Monitor, piloté par des règles de collecte de données.

Azure Monitor Metrics #

Le magasin de métriques léger et rapide d'Azure Monitor.

Azure Monitor managed service for Prometheus #

Le service Prometheus managé d'Azure, adossé à un espace de travail Azure Monitor.

Log Analytics #

Le cœur des journaux Azure Monitor : un espace de travail contenant des tables interrogées en KQL.

Application Insights #

La brique APM d'Azure Monitor.

Azure Managed Grafana #

Une instance Grafana gérée par Microsoft, intégrée à Entra ID.

API de requête (Azure Monitor, Log Analytics, Prometheus) #

Les points de terminaison qui exposent les données d'Azure Monitor en lecture.

Alertes et groupes d'actions #

Le moteur d'alerte d'Azure Monitor et ses canaux de notification et d'action.

Azure Event Hubs #

La plateforme de diffusion en continu d'Azure, utilisée comme passerelle d'export de la télémétrie.

4. Compatibilité OpenTelemetry #

Distro Azure Monitor OpenTelemetry et collecteur.

Instrumenter avec la distro Azure Monitor OpenTelemetry #

Microsoft recommande désormais OpenTelemetry pour Application Insights : la distro Azure Monitor OpenTelemetry (.NET, Java, Node.js, Python) regroupe le SDK, l'instrumentation automatique des bibliothèques courantes et l'exportateur Azure Monitor. Les traces, métriques et journaux OpenTelemetry deviennent des requêtes, dépendances, traces et métriques personnalisées dans Application Insights.

pip install azure-monitor-opentelemetry

# app.py
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()   # lit APPLICATIONINSIGHTS_CONNECTION_STRING

Avec un collecteur OpenTelemetry, l'exportateur azuremonitor de la distribution contrib envoie traces, métriques et journaux vers Application Insights ; les métriques peuvent aussi partir en remote write vers Managed Prometheus. Azure Monitor propose par ailleurs l'ingestion OTLP native, en cours de déploiement : vérifiez sa disponibilité dans votre région avant de vous y appuyer.

À savoir : Pour Java, l'agent Application Insights 3.x est lui-même construit sur OpenTelemetry : il instrumente sans modification de code et accepte les API OpenTelemetry pour la télémétrie personnalisée.

5. Interconnexions avec les produits externes #

Exporter et intégrer.

Envoyer les données Azure ailleurs #

Bonne Pratique : Pour un outil tiers, passez par Event Hubs plutôt que par l'interrogation des API : le flux est continu, scalable et indépendant du nombre de ressources.

6. Coûts et bonnes pratiques #

Maîtriser l'ingestion.

Bonnes pratiques #

• Centraliser les journaux dans peu d'espaces Log Analytics (par environnement ou par région), avec un contrôle d'accès par ressource.
• Choisir le plan de table adapté (Analytics, Basic, Auxiliary) et filtrer avec des transformations DCR.
• Déployer paramètres de diagnostic et règles DCR par Azure Policy pour couvrir automatiquement les nouvelles ressources.
• Instrumenter avec la distro OpenTelemetry pour rester portable.
• Échantillonner la télémétrie d'Application Insights sur les applications à fort trafic.
• Fixer un plafond journalier et des alertes de coût sur l'ingestion.

Erreur courante : Collecter « tous les journaux » de toutes les ressources dans le plan Analytics fait exploser la facture : commencez par les catégories utiles.