Introduction : le défi de la supervision applicative moderne
Une application cloud moderne est rarement monolithique. Elle repose sur une constellation de ressources Azure interconnectées — services managés, conteneurs, bases de données, caches, API tierces — chacune générant ses propres métriques, logs et traces. Lorsque l'on additionne ces signaux à l'échelle d'une application complète, on peut rapidement se retrouver face à des milliers d'indicateurs à analyser simultanément.
Cette complexité rend la détection et le diagnostic des incidents particulièrement difficiles : un opérateur confronté à une alerte doit reconstituer mentalement la chaîne de dépendances avant même de pouvoir identifier la cause racine. C'est précisément pour répondre à cette problématique qu'Azure Health Models a été conçu.
Qu'est-ce qu'Azure Health Models ?
Azure Health Models est une fonctionnalité d'Azure Monitor qui permet de modéliser la santé d'une application sous forme de hiérarchie, en agrégeant des signaux provenant de multiples sources (métriques Azure Monitor, Log Analytics, Application Insights, Prometheus) en un indicateur d'état unique et contextualisé.
Les sources de signaux supportées par Azure Health Models
Avant d'aborder la modélisation elle-même, il est important de comprendre la richesse des sources de données exploitables. Azure Health Models ne se limite pas aux métriques natives Azure Monitor ; il agrège des signaux provenant de :
- Azure Monitor Metrics : métriques time-series natives pour chaque ressource Azure (CPU, mémoire, latence, disponibilité…)
- Log Analytics Workspaces : requêtes KQL (Kusto Query Language) personnalisées pour extraire des états de santé depuis vos logs
- Application Insights : télémétrie applicative (taux d'erreurs, temps de réponse, disponibilité des dépendances)
- Azure Monitor Managed Service for Prometheus : métriques issues de clusters Kubernetes, qu'ils soient hébergés sur Azure ou non
- Sources externes : tout service pouvant envoyer des données vers Log Analytics peut potentiellement être intégré au modèle
Cette ouverture est fondamentale : elle signifie qu'un health model peut couvrir des architectures hybrides ou multi-cloud, pas uniquement des ressources Azure pures.
Astuce KQL
Si vous maîtrisez déjà les requêtes KQL dans Log Analytics ou Application Insights, vous pouvez les réutiliser directement pour définir les signaux de santé de vos composants. Pas besoin de recréer des requêtes from scratch.
Architecture hiérarchique : le cœur du modèle de santé
Le principe de cascade de santé
La valeur fondamentale d'Azure Health Models repose sur sa structure hiérarchique. La santé d'un élément parent est dérivée de la santé de ses dépendances enfants. Si un composant de bas niveau devient défaillant, l'impact se propage automatiquement vers les niveaux supérieurs de la hiérarchie.
Cette propagation permet à une équipe d'exploitation de comprendre en un coup d'œil :
- Quel est l'état global de l'application ?
- Quelle fonction métier est impactée ?
- Quel composant technique est à l'origine du problème ?
Les quatre niveaux de la hiérarchie
| Niveau | Description | Exemple |
|---|---|---|
| Modèle (entité métier) | Représente l'application ou le service dans sa globalité | Application e-commerce |
| Fonctions métier | Grandes capacités fonctionnelles de l'application | Boutique, Gestion utilisateurs, Administration |
| Composants applicatifs | Sous-systèmes techniques servant les fonctions métier | Navigation, Panier, Paiement, Recherche |
| Ressources plateforme | Ressources Azure sous-jacentes et services d'infrastructure | Azure Cache for Redis, Key Vault, App Service |
Exemple concret : une application e-commerce
Prenons l'exemple d'une application de vente en ligne pour illustrer la structuration d'un health model :
- Niveau 1 (Modèle) : L'application e-commerce dans son ensemble
- Niveau 2 (Fonctions métier) : Boutique, Gestion des utilisateurs, Administration de la boutique
- Niveau 3 (Composants applicatifs) : Navigation produits, Ajout au panier, Processus de paiement, Moteur de recherche
- Niveau 4 (Ressources plateforme) : Instances App Service, Azure Cache for Redis, Azure Key Vault, bases de données
Notez qu'un même composant applicatif peut être partagé entre plusieurs fonctions métier. Par exemple, le frontend peut être une dépendance à la fois de la navigation et du processus de paiement.
Configurer les règles d'agrégation de santé
Un des points de flexibilité clés d'Azure Health Models concerne la logique d'agrégation de la santé entre les dépendances. Deux modes principaux sont disponibles :
Mode « Worst-of » (le plus défavorable)
C'est le comportement par défaut. Si une seule dépendance est en état Unhealthy, le composant parent est également considéré comme Unhealthy. Ce mode est adapté aux architectures sans redondance, où chaque composant est critique.
Mode « Fleet » (seuil de disponibilité)
Pour les architectures redondantes (clusters, pools de ressources, groupes de disponibilité), vous pouvez définir :
- Un nombre minimum de dépendances saines requis pour que le parent reste sain
- Un nombre maximum de dépendances défaillantes tolérées avant de déclarer un état Degraded ou Unhealthy
Choisissez le bon mode d'agrégation
Un mauvais choix de mode d'agrégation peut générer des faux positifs (alertes inutiles) ou des faux négatifs (incidents non détectés). Alignez toujours le mode d'agrégation avec l'architecture réelle de redondance de vos composants.
Démonstration : navigation dans le tableau de bord
Le tableau de bord d'Azure Health Models offre une vue graphique interactive de votre hiérarchie. Voici ce que vous y trouverez en pratique :
- Vue d'ensemble : représentation visuelle de tous les nœuds de la hiérarchie, colorés selon leur état (vert = Healthy, orange = Degraded, rouge = Unhealthy)
- Timeline de santé : historique de l'état de chaque nœud dans le temps, permettant d'analyser la durée et la progression des incidents
- Détail des signaux : pour chaque ressource, liste des métriques et requêtes KQL utilisées pour évaluer l'état, avec la possibilité de les explorer
- Propagation visuelle : identification immédiate de l'élément à l'origine d'une dégradation et de son impact sur les niveaux supérieurs
Dans l'exemple d'une application e-commerce, si le cache (Azure Cache for Redis) devient défaillant, le tableau de bord affichera immédiatement l'impact sur la fonction de recherche, puis sur la boutique dans son ensemble — tout en indiquant que le paiement et la gestion des utilisateurs restent opérationnels.
Configurer un Azure Health Model : guide étape par étape
Accéder au designer Azure Health Models
Dans le portail Azure, naviguez vers Azure Monitor puis accédez à la section Health Models. Cliquez sur Create pour ouvrir l'interface de conception visuelle (le Designer).
Référence officielle : Azure Monitor Health Models - Documentation Microsoft
Ajouter les entités et les ressources
Dans le Designer, commencez par définir les entités de haut niveau (modèle, fonctions métier), puis ajoutez les composants applicatifs et enfin les ressources Azure sous-jacentes. Vous pouvez :
- Utiliser Add Entity pour créer des nœuds logiques (fonctions, composants)
- Utiliser Add Azure Resource pour lier des ressources Azure existantes (App Service, Redis Cache, Key Vault…)
Définir les relations de dépendance
Une fois les entités créées, établissez les relations parent-enfant par glisser-déposer dans l'interface graphique. Chaque lien de dépendance définit comment la santé se propage vers le haut de la hiérarchie.
Configurer les signaux de santé
Pour chaque ressource ou composant, définissez les signaux utilisés pour évaluer l'état de santé. Exemples de configuration :
1// Exemple de requête KQL pour détecter un taux d'erreur élevé2requests3| where timestamp > ago(5m)4| summarize errorRate = countif(success == false) * 100.0 / count()5| where errorRate > 5Vous pouvez combiner des métriques Azure Monitor natives et des requêtes KQL personnalisées pour chaque signal.
Configurer le mode d'agrégation
Pour chaque nœud parent, sélectionnez le mode d'agrégation adapté à votre architecture :
- Worst-of : un seul enfant défaillant suffit à dégrader le parent
- Fleet : définissez un seuil minimum de dépendances saines
Configurer les alertes et Action Groups
Définissez des alertes sur les états Degraded et Unhealthy pour les nœuds critiques de votre hiérarchie. Associez chaque alerte à un Action Group Azure Monitor pour déclencher les actions appropriées :
- Envoi d'e-mail ou SMS
- Appel d'un webhook (intégration ITSM, PagerDuty, Slack…)
- Déclenchement d'une Azure Function pour une remédiation automatisée
- Notification via Azure Logic Apps
Référence : Action Groups dans Azure Monitor
Composition et réutilisation des modèles
Azure Health Models supporte la composition de modèles. Un modèle existant peut être référencé comme dépendance dans un autre modèle. Cette approche permet de :
- Réutiliser des modèles de services partagés (par exemple, un modèle de service d'authentification utilisé par plusieurs applications)
- Déléguer la responsabilité de certains modèles à différentes équipes
- Réduire la complexité en décomposant un système large en sous-modèles cohérents
Bonne pratique d'organisation
Pour les organisations disposant de nombreuses applications, envisagez de créer des modèles dédiés pour les services d'infrastructure partagée (couche réseau, services d'identité, observabilité) que vous pouvez ensuite référencer dans les modèles applicatifs.
Bénéfices opérationnels pour les équipes IT
L'adoption d'Azure Health Models apporte des avantages concrets pour les équipes d'exploitation et de développement :
- Réduction du MTTR (Mean Time To Resolve) : la hiérarchie visuelle accélère l'identification de la cause racine
- Meilleure communication métier : l'état de santé est exprimé en termes de fonctionnalités (« le paiement est indisponible ») plutôt qu'en métriques techniques
- Alerting contextualisé : les alertes sont émises au niveau fonctionnel pertinent, réduisant le bruit et les faux positifs
- Réutilisation des investissements existants : les requêtes KQL, les métriques et les workspaces Log Analytics déjà en place sont directement exploitables
- Visibilité end-to-end : une seule vue couvre l'ensemble de la chaîne, des ressources infrastructure jusqu'aux fonctions métier
Ressources et références complémentaires
Pour approfondir votre maîtrise d'Azure Health Models et de l'écosystème Azure Monitor :
- Documentation officielle Azure Monitor Health Models
- Référence KQL pour Azure Monitor
- Action Groups Azure Monitor
- Azure Managed Prometheus
- Application Insights - Vue d'ensemble
Disponibilité
Azure Health Models est disponible dans le portail Azure via Azure Monitor. Vérifiez la disponibilité dans votre région et les éventuels prérequis en termes d'abonnement sur la page officielle Microsoft Learn.
Conclusion
Azure Health Models représente une évolution significative dans la supervision applicative sur Azure. En transformant des milliers de signaux bruts en une hiérarchie de santé lisible et actionnée, il permet aux équipes IT de passer d'une supervision réactive basée sur des métriques isolées à une observabilité orientée services et fonctions métier.
Que vous gériez une application e-commerce, un système ERP ou une plateforme SaaS, la modélisation de santé vous aide à répondre rapidement à la question essentielle : qu'est-ce qui ne fonctionne pas, et quel impact cela a-t-il sur mes utilisateurs ?
