Azure Monitoring : hub Metrics, Logs, Activity Logs et Alerts

À la fin de ce hub, vous saurez situer Azure Monitoring dans un parcours DevOps Azure : ouvrir le service Monitor, lire des Metrics, consulter l’Activity Log, créer une Alert avec Action group, et enchaîner vers les quatre leçons sœurs — sans secrets en clair, lab en canadacentral.

Niveau : Débutant · Temps estimé : 45–60 min · Versions testées : Azure Monitor (portail 2026), Azure CLI · Dernière vérification : 2026-09-12

Slug : azure-monitoring · Série : Azure DevOps (mega-menu) · WP post #1074 · Région lab : canadacentral

Azure Monitoring

Parcours officiel (conservé) :

1. Azure – Monitoring Overview

2. Azure – Monitor Metrics

3. Azure Activity Logs

4. Azure Alerts

Prérequis

Compte Azure avec un abonnement lab (Contributor sur un resource group)
Navigateur récent ; MFA activé sur le compte admin lab
Optionnel : Azure CLI (az login) pour lire métriques / activity log
Une ressource à observer (VM, App Service ou Storage) en canadacentral — ou suivez en lecture seule sur une ressource existante
Hub série : Azure DevOps · outils : Azure DevOps Tools

Coût estimé : 0 € pour ouvrir Monitor / Metrics / Activity Log. Les alertes SMS / webhook partenaires peuvent être facturées ; préférez email sur Action group en lab. Application Insights / Log Analytics facturent à l’ingestion — volume lab faible, rétention courte, delete RG en fin de session.

Ce que nous allons construire


Azure Monitoring (hub menu #1074)
  ├── 1. Monitoring Overview     → /azure-monitoring-overview/
  ├── 2. Monitor Metrics         → /azure-monitor-metrics/
  ├── 3. Activity Logs           → /azure-activity-logs/
  └── 4. Azure Alerts            → /azure-monitor-alerts/
Lab canadacentral (option)
  └── rg-ado-lab-monitor → VM ou App Service → Metrics pin + Alert rule

Parcours officiel (fond conservé, jamais supprimé) :

Ce chapitre enrichit le post WordPress #1074 : on garde les quatre liens du mega-menu, puis on explique le « pourquoi », un lab portal minimal, les erreurs classiques et le maillage vers App Insights / DevOps.

Étape 1 — Pourquoi Azure Monitoring en DevOps

Sans observabilité, un pipeline vert ne prouve rien en production. Azure Monitor est la plateforme qui collecte, analyse et agit sur la télémétrie de vos apps et ressources Azure (et on‑premises via agents / Arc).

En pratique DevOps vous avez besoin de trois signaux complémentaires :

Signal	Question	Où le lire
Metrics	La ressource est-elle saine maintenant ?	Metrics explorer
Activity Log	Qui a changé quoi sur l’abonnement / la ressource ?	Activity Log
Alerts	Qui est prévenu quand un seuil casse ?	Alert rules + Action groups
Logs / App Insights	Pourquoi l’app échoue (traces, dépendances) ?	Log Analytics / Application Insights

Le hub menu Azure Monitoring oriente vers Overview → Metrics → Activity Logs → Alerts. Le deep-dive APM (workspace-based App Insights, KQL, Bicep) vit à part : Azure Monitor et Application Insights.

En 2026, le portail regroupe presque tout sous Monitor dans la barre de recherche Azure. Les insights (VM insights, Container insights, Application Insights) sont des expériences curatées *sur* la même plateforme — pas des produits isolés.

Étape 2 — Monitoring Overview : carte mentale

Fond leçon 28 conservé. L’overview décrit Azure Monitor comme solution pour maximiser disponibilité et performance : détecter avec Application Insights, corréler infra (VM / Container insights), requêter avec Log Analytics, automatiser, visualiser (dashboards / workbooks), collecter Metrics, et investiguer via Change Analysis.

Deux magasins fondamentaux :

Metrics — valeurs numériques légères, quasi temps réel (CPU, Network Out, requests/sec).
Logs — enregistrements structurés (événements, traces, diagnostics) interrogeables en KQL.

Sources typiques : code applicatif, guest OS, ressource Azure, subscription (Activity Log), tenant (Entra), changements (Change Analysis). Dès qu’une subscription existe, Activity Log et Metrics de plateforme commencent à arriver ; les diagnostics et agents étendent la profondeur.

Geste portal : portail Azure → cherchez Monitor → pinnez le service aux favoris. Parcourez Overview, Metrics, Activity log, Alerts, Workbooks, Logs. Détail : Monitoring Overview.

Étape 3 — Monitor Metrics : graphes et dashboards

Fond leçon 29 conservé. Pour une ressource (ex. VM) :

Ouvrez Monitor → Metrics (ou Metrics depuis la ressource).
Choisissez Subscription → Resource → Apply.
Sélectionnez une métrique (ex. Percentage CPU).
Lisez le graphe ; Pin to dashboard si utile.

Bonnes pratiques lab :

Commencez par les metrics platform (gratuites / incluses) avant custom metrics.
Agrégation : Avg / Max / Sum — documentez laquelle vous alertez.
Namespace et dimensions (Instance, Availability Zone) évitent les faux positifs.
Région lab canadacentral pour toute ressource créée pour ce parcours.


# Lecture métrique VM (illustratif — adaptez resourceId)
az monitor metrics list \
  --resource "/subscriptions/<sub>/resourceGroups/rg-ado-lab-monitor/providers/Microsoft.Compute/virtualMachines/vm-ado-lab" \
  --metric "Percentage CPU" \
  --interval PT1M \
  --aggregation Average \
  -o table

Suite pas-à-pas : Azure Monitor Metrics.

Étape 4 — Activity Logs : qui a changé quoi

Fond leçon 30 conservé. L’Activity Log est un *platform log* d’abonnement : création / modification de ressources, démarrage de VM, opérations de contrôle. Visible dans le portail ; exportable via PowerShell / CLI.

Pour aller plus loin, créez un Diagnostic setting vers :

Azure Monitor Logs (Log Analytics) — requêtes complexes, alertes, rétention jusqu’à ~2 ans selon plan
Event Hubs — SIEM / hors Azure
Storage — archive long terme moins chère

Gestes portal :

Monitor → Activity log.
Filtrez par Subscription, Timespan, Resource group, Operation.
Ouvrez une opération : Summary, Change history, JSON.
Export Activity Logs / Diagnostic settings → catégories (Administrative, Security, etc.) → destination (Storage / LAW / Event Hub).


az monitor activity-log list \
  --resource-group rg-ado-lab-monitor \
  --offset 24h \
  --query "[].{op:operationName.value, status:status.value, caller:caller, time:eventTimestamp}" \
  -o table

En incident DevOps : Metrics disent *symptôme* ; Activity Log dit souvent *cause* (déploiement, scale, delete accidentel). Suite : Azure Activity Logs.

Étape 5 — Azure Alerts : règles et Action groups

Fond leçon 31 conservé. Les alertes détectent un problème *avant* les utilisateurs. Une alert rule combine ressource(s) + signal (metric / log / activity) + condition. Si la condition est vraie, l’alerte passe à Fired et déclenche l’Action group.

Types utiles en 2026 :

Type	Usage lab / prod
Metric alerts	Seuils CPU, latence, Network Out — near real-time
Log alerts	KQL périodique sur LAW / App Insights
Activity log alerts	Ex. delete RG, role assignment, Service Health
Smart detection	Anomalies App Insights (migrer vers alert rules dédiées)

Lab portal (email only) :

Monitor → Alerts → Create → Alert rule.
Scope : votre VM / App Service lab canadacentral.
Condition : signal Metrics → ex. Percentage CPU > 80, granularité 1–5 min.
Actions : Create action group → notification Email (pas de SMS payant en lab).
Details : nom ag-ado-lab-email, severity Sev3/Sev4 pour lab.
Review + Create.


# Lister règles d'alerte (lecture)
az monitor metrics alert list -g rg-ado-lab-monitor -o table

Action groups partagés : un même groupe email/webhook pour plusieurs rules. Alert processing rules peuvent supprimer le bruit hors horaires. Détail : Azure Monitor Alerts.

Étape 6 — Mini-lab unifié (45 min)

Objectif : une boucle Metrics → Activity → Alert sur une ressource cheap.

az group create -n rg-ado-lab-monitor -l canadacentral (ou RG existant).
Déployez une VM B-series / App Service Free-F1 uniquement si vous n’avez rien à observer — sinon réutilisez.
Metrics : Percentage CPU ou Requests → pin dashboard « ado-lab-monitor ».
Activity log : filtrez le RG, ouvrez la dernière Write, notez caller + operation.
Alert rule + Action group email sur un seuil volontairement bas pour tester un Fired, puis remontez le seuil ou disable la rule.
Cleanup : disable/delete alert rule + action group ; az group delete -n rg-ado-lab-monitor --yes --no-wait si le RG est jetable.

Secrets : pas de connection string App Insights, pas de webhook signé, pas de PAT dans Git. Placeholders uniquement.

Étape 7 — Visualisations, export et intégration CI/CD

Azure Monitor ne s’arrête pas à la courbe rouge. Dashboards Azure pinnent metrics et résultats de requêtes pour un stand-up ops. Workbooks offrent un canvas interactif (souvent livré avec les Insights). Power BI peut importer des logs pour un public hors portail.

Côté export : Event Hubs alimente un SIEM ; Logic Apps orchestre des runbooks (ticket ITSM, message Teams). En CI/CD Azure DevOps, la tâche AzureMonitor@1 (gates de release) peut bloquer un déploiement si des alertes Sev0/Sev1 sont actives — utile en prod, excessif en lab tant que vous n’avez pas de baseline stable.

Pour une app web, branchez Application Insights workspace-based (LAW en canadacentral), stockez la connection string dans Key Vault / app settings, jamais dans le dépôt. Corrélez ensuite failed requests (App Insights) avec Percentage CPU (Metrics) et un éventuel déploiement visible dans l’Activity Log : c’est le réflexe SRE minimal avant d’ouvrir un postwar.

Checklist de fin de hub :

Favori Monitor dans le portail
Une métrique pinnée
Une entrée Activity Log lue (JSON + caller)
Une alert rule + Action group email créés *ou* documentés si droits insuffisants
Lien mental clair vers les quatre leçons enfants du mega-menu
Décision : ce hub vs le tuto App Insights pour le code

Si vous automatisez l’infra avec ARM Templates ou Bicep, versionnez diagnostic settings et alert rules comme du code : même revue PR, même canadacentral, mêmes tags env=lab. L’observabilité « après coup » dans le portail seul ne scale pas ; l’IaC d’alertes évite les environnements sourds après un redeploy.

Enfin, alignez les severities avec votre org : Sev0/Sev1 pour pages nocturnes, Sev3/Sev4 pour lab et non-prod. Documentez le runbook (disable rule, scale out, rollback pipeline) à côté de l’Action group — une alerte sans propriétaire est du bruit.

Bonnes pratiques et différenciation hub vs deep-dive

Ce hub Azure Monitoring reste volontairement transversal : il prépare le vocabulaire et les quatre clics portal du mega-menu Azure DevOps. Il ne remplace pas Monitoring Overview (plateforme complète), ni Metrics (explorer), ni Activity Logs (diagnostic settings), ni Alerts (création détaillée d’une rule). Il pointe aussi vers App Insights quand la question devient « mon code » plutôt que « ma VM ».

En entretien DevOps / SRE, sachez expliquer : métriques plateforme vs logs, Action group vs alert rule, pourquoi l’Activity Log est votre ami après un pipeline, et pourquoi canadacentral est la région lab du site. Montrez une alerte email de lab et un graphe pinné — c’est plus convaincant qu’un slide.

Quand plusieurs équipes partagent le même abonnement, convenez d’une convention de noms (ag-<app>-<env>, alert-<signal>-<env>) et d’un resource group dédié aux alertes partagées pour éviter les doublons. Vérifiez périodiquement les règles Disabled ou orphelines après un delete de ressource : Azure garde parfois des alertes qui ne peuvent plus évaluer leur scope.

Pour le coût, commencez sans diagnostic settings agressifs ni custom metrics haute fréquence. Activez l’export LAW seulement quand vous avez une question KQL précise. En lab, désactivez ou supprimez les alertes dès le cleanup — un Action group email oublié n’est pas grave, un webhook prod oublié l’est.

Erreurs fréquentes

Alerte qui ne fire jamais — mauvais scope (subscription vs ressource), agrégation Sum au lieu de Avg, ou ressource arrêtée (métriques plates).
Spam d’alertes — seuil trop bas + fréquence élevée ; ajoutez severity, processing rule, ou dynamic thresholds après baseline.
Activity Log vide « sur la ressource » — vous regardez un filtre trop étroit ; élargissez timespan / subscription.
Confusion Monitor vs App Insights — Monitor = plateforme ; App Insights = APM. Pour le code, suivez le tuto App Insights.
Diagnostic settings oubliés — sans export LAW, pas de KQL riche ni rétention longue sur Activity Log.
Coûts SMS / LAW — lab = email + rétention courte ; surveillez ingestion.

Mini-quiz

Metrics vs Activity Log : lequel répond à « qui a redémarré la VM » ?
Quels trois éléments compose une alert rule ?
Pourquoi préférer un Action group partagé ?
Où envoyer l’Activity Log pour du KQL long terme ?
Quelle région lab utilise ce parcours Azure du site ?

*Réponses :* (1) Activity Log · (2) scope + signal/condition + actions · (3) réutiliser destinataires / webhooks sans dupliquer · (4) Log Analytics via Diagnostic settings · (5) canadacentral.

Maillage

Monitoring Overview · Monitor Metrics · Activity Logs · Monitor Alerts
Azure DevOps · Azure DevOps Tools · ARM Templates
Deep-dive : Azure Monitor + Application Insights · Sécurité & gouvernance ADO

Retour parcours Azure DevOps — hub de la série et leçons sœurs.

#Tags

Azure Monitoring : hub Metrics, Logs, Activity Logs et Alerts