Modélisation et observabilité de l'intégrité des charges de travail critiques sur Azure

La modélisation de la santé et l'observabilité sont des concepts essentiels pour optimiser la fiabilité, qui se concentre sur une instrumentation et une surveillance robustes et contextualisées. Ces concepts fournissent un aperçu critique de l’intégrité des applications, en favorisant l’identification et la résolution rapides des problèmes.

La plupart des applications stratégiques sont importantes en termes de mise à l’échelle et de complexité et génèrent donc des volumes élevés de données opérationnelles, ce qui rend difficile d’évaluer et de déterminer une action opérationnelle optimale. La modélisation de la santé vise finalement à maximiser la visibilité et l'observabilité en augmentant les journaux et métriques de surveillance bruts avec des exigences métier clés pour évaluer la santé des applications, ce qui conduit à une évaluation automatisée des états de santé afin d'assurer des opérations cohérentes et accélérées.

Ce domaine de conception se concentre sur le processus de définition d’un modèle de santé robuste, en mappant les états d’intégrité des applications quantifiés par l’observabilité et les constructions opérationnelles pour atteindre la maturité opérationnelle.

Important

Cet article fait partie de la série sur les charges de travail critiques Azure Well-Architected. Si vous n’êtes pas familiarisé avec cette série, nous vous recommandons de commencer par ce qu’est une charge de travail stratégique ?

Il existe trois niveaux principaux de maturité opérationnelle lorsqu’il s’efforce d’optimiser la fiabilité.

1. Détectez et répondez aux problèmes au fur et à mesure qu’ils se produisent.
2. Diagnostiquer les problèmes qui se produisent ou qui se sont déjà produits.
3. Prédire et empêcher les problèmes avant qu’ils ne se produisent.

Vidéo : Définir un modèle de santé pour votre charge de travail essentielle à la mission

Système de santé applicatif en couches

Pour créer un modèle d’intégrité, commencez par définir l’intégrité de l’application dans le contexte des principales exigences métier en quantifient les états « sains » et « non sains » dans un format en couches et mesurables. Ensuite, pour chaque composant d’application, affinez la définition dans le contexte d’un état d’exécution stable et agrégé en fonction des flux utilisateur de l’application. Superposer les principales exigences non fonctionnelles en termes de performances et de disponibilité. Enfin, agréger les états d’intégrité de chaque flux utilisateur individuel pour former une représentation acceptable de l’intégrité globale de l’application. Une fois établies, ces définitions d’intégrité en couches doivent être utilisées pour informer les métriques de surveillance critiques sur tous les composants système et valider la composition du sous-système opérationnel.

Important

Lors de la définition des états « à risque » pour tous les niveaux de l'application. Il est important de faire la distinction entre les états d’échec temporaires et non temporaires pour qualifier la dégradation du service par rapport à l’indisponibilité.

Considérations relatives à la conception

• Le processus de modélisation de la santé est une activité de conception de haut en bas qui commence par un exercice architectural pour définir tous les flux utilisateur et mapper les dépendances entre les composants fonctionnels et logiques, et donc mappe implicitement les dépendances entre les ressources Azure.

• Un modèle de santé dépend entièrement du contexte de la solution qu'il représente et ne peut donc pas être résolu « prêt à l'emploi », car « une seule solution ne convient pas à tous ».

  • Les applications diffèrent dans la composition et les dépendances
  • Les métriques et les seuils de métriques pour les ressources doivent également être affinés en termes de valeurs qui représentent des états sains et non sains, qui sont fortement influencés par les fonctionnalités d’application incluses et ciblent des exigences non fonctionnelles.

• Un modèle de santé en couches permet de remonter à des dépendances de niveau inférieur pour tracer la santé de l'application, ce qui aide à identifier rapidement la cause d'une dégradation du service.

• Pour capturer les états d’intégrité d’un composant individuel, les caractéristiques opérationnelles distinctes de ce composant doivent être comprises sous un état stable qui reflète la charge de production. Les tests de performances sont donc une fonctionnalité clé permettant de définir et d’évaluer continuellement l’intégrité de l’application.

• Les défaillances au sein d’une solution cloud peuvent ne pas se produire en isolation. Une panne dans un composant unique peut entraîner l’indisponibilité de plusieurs fonctionnalités ou composants supplémentaires.

  • Ces erreurs peuvent ne pas être immédiatement observables.

Recommandations en matière de conception

• Définissez un modèle de santé mesurable comme une priorité pour garantir une compréhension opérationnelle claire de l’ensemble de l’application.

  • Le modèle de santé doit être stratifié et refléter la structure de l'application.
  • La couche de base doit prendre en compte les composants d’application individuels, tels que les ressources Azure.
  • Les éléments fondamentaux doivent être agrégés en même temps que les exigences non fonctionnelles clés pour créer une perspective contextuelle métier sur l’état des flux du système.
  • Les flux système doivent être agrégés avec des pondérations appropriées en fonction de la criticité métier pour créer une définition significative de l’intégrité globale des applications. Les flux d’utilisateurs financièrement significatifs ou orientés client doivent être hiérarchisés.
  • Chaque couche du modèle de santé doit capturer ce que signifient les états de « bonne santé » et « mauvaise santé ».
  • Assurez-vous que le modèle de santé peut faire la distinction entre les états temporaires et non temporaires de santé dégradée pour isoler la dégradation du service de l’indisponibilité.

• Représentez les états d’intégrité à l’aide d’un score d’intégrité granulaire pour chaque composant d’application distinct et chaque flux utilisateur en agrégeant les scores d’intégrité pour les composants dépendants mappés, compte tenu des principales exigences non fonctionnelles en tant que coefficients.

  • Le score d’intégrité d’un flux utilisateur doit être représenté par le score le plus bas sur tous les composants mappés, en factorisant l’atteinte relative par rapport aux exigences non fonctionnelles pour le flux utilisateur.
  • Le modèle utilisé pour calculer les scores d’intégrité doit refléter constamment l’intégrité de l’exploitation et, si ce n’est pas le cas, le modèle doit être ajusté et redéployé pour refléter les nouveaux apprentissages.
  • Définissez des seuils de score de santé pour refléter l’état de santé.

• Le score d’intégrité doit être calculé automatiquement en fonction des métriques sous-jacentes, qui peuvent être visualisées via des schémas d’observabilité et permettre des actions à travers des procédures opérationnelles automatisées.

  • Le score d’intégrité doit devenir essentiel à la solution de supervision, afin que les équipes d’exploitation n’aient plus à interpréter et mapper les données opérationnelles à l’intégrité de l’application.

• Utilisez le modèle de santé pour calculer l'atteinte de l'objectif de niveau de service (SLO) de disponibilité au lieu de la disponibilité brute, garantissant que la démarcation entre la dégradation du service et l'indisponibilité soit reflétée en tant que SLO distincts.

• Utilisez le modèle d’intégrité dans les pipelines CI/CD et les cycles de test pour valider que l’intégrité de l’application est conservée après les mises à jour du code et de la configuration.

  • Le modèle d’intégrité doit être utilisé pour observer et valider l’intégrité pendant les tests de charge et de chaos dans le cadre des processus CI/CD.

• La création et la maintenance d’un modèle de santé sont un processus itératif et un investissement d’ingénierie doit être aligné afin de promouvoir des améliorations continues.

  • Définissez un processus pour évaluer et affiner continuellement la précision du modèle, et envisagez d’investir dans des modèles Machine Learning pour entraîner davantage le modèle.

Exemple : modèle de santé en couches

Il s’agit d’une représentation simplifiée d’un modèle d’intégrité d’application en couches à des fins d’illustration. Un modèle de santé exhaustif et contextualisé est fourni dans les implémentations de référence Mission-Critical :

• Mission-Critical Online
• Connexion d'importance cruciale

Lors de l’implémentation d’un modèle de santé, il est important de définir la santé des composants individuels par le biais de l’agrégation et de l’interprétation des métriques de niveau ressources. Voici un exemple de la façon dont les métriques de ressource peuvent être utilisées :

Cette définition de l’intégrité peut par la suite être représentée par une requête KQL, comme illustré par l’exemple de requête ci-dessous qui agrège InsightsMetrics (Container Insights) et AzureMetrics (paramètre de diagnostic pour le cluster AKS) et compare (jointure interne) aux seuils d’intégrité modélisés.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

La sortie de table résultante peut ensuite être transformée en score de santé pour faciliter l’agrégation à des niveaux plus élevés du modèle de santé.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Ces scores agrégés peuvent ensuite être représentés en tant que graphique de dépendances à l’aide d’outils de visualisation tels que Grafana pour illustrer le modèle de santé.

Cette image montre un exemple de modèle d’intégrité en couches à partir de l’implémentation de référence en ligne Azure Mission-Critical, et montre comment un changement d’état d’intégrité pour un composant fondamental peut avoir un impact en cascade sur les flux utilisateur et l’intégrité globale de l’application (les exemples de valeurs correspondent à la table de l’image précédente).

Vidéo de démonstration : Surveillance et modélisation de l'état de santé

Récepteur de données unifié pour l’analyse corrélée

De nombreux jeux de données opérationnels doivent être collectés à partir de tous les composants système pour représenter avec précision un modèle thermique défini, en tenant compte des journaux et des métriques des composants d’application et des ressources Azure sous-jacentes. Cette grande quantité de données doit finalement être stockée dans un format qui permet une interprétation quasi-en temps réel pour faciliter l’action opérationnelle rapide. De plus, la corrélation entre tous les ensembles de données englobés est nécessaire pour garantir que l’analyse efficace soit sans restriction, ce qui permet une représentation en couches de la santé.

Un récepteur de données unifié est nécessaire pour garantir que toutes les données opérationnelles sont rapidement stockées et mises à disposition pour l’analyse corrélée afin de créer une représentation « volet unique » de l’intégrité de l’application. Azure fournit plusieurs technologies opérationnelles différentes sous l’parapluie d’Azure Monitor, et l’espace de travail Log Analytics sert de récepteur de données natif Azure principal pour stocker et analyser les données opérationnelles.

Considérations relatives à la conception

Azure Monitor.

• Azure Monitor est activé par défaut pour tous les abonnements Azure, mais les journaux Azure Monitor (espace de travail Log Analytics) et les ressources Application Insights doivent être déployés et configurés pour incorporer des fonctionnalités de collecte et d’interrogation de données.

• Azure Monitor prend en charge trois types de données d’observabilité : les journaux, les métriques et les traces distribuées.

  • Les journaux sont stockés dans des espaces de travail Log Analytics, qui sont basés sur Azure Data Explorer. Les requêtes de journal sont stockées dans des packs de requêtes qui peuvent être partagés entre les abonnements et sont utilisées pour piloter des composants d’observabilité tels que des tableaux de bord, des classeurs ou d’autres outils de création de rapports et de visualisation.
  • Les métriques sont stockées dans une base de données de série chronologique interne. Pour la plupart des ressources Azure, les métriques sont automatiquement collectées et conservées pendant 93 jours. Les données de métrique peuvent également être envoyées à l’espace de travail Log Analytics à l’aide d’un paramètre de diagnostic pour la ressource.

• Toutes les ressources Azure exposent des journaux et des métriques, mais les ressources doivent être correctement configurées pour acheminer les données de diagnostic vers votre récepteur de données souhaité.

Conseil / Astuce

Azure fournit différentes stratégies intégrées qui peuvent être appliquées pour garantir que les ressources déployées sont configurées pour envoyer des journaux et des métriques à un espace de travail Log Analytics.

• Il n’est pas rare que les contrôles réglementaires exigent que les données opérationnelles restent dans des zones géographiques ou des pays/régions d’origine. Les exigences réglementaires peuvent stipuler la conservation des types de données critiques pendant une période prolongée. Par exemple, dans les banques réglementées, les données d’audit doivent être conservées pendant au moins sept ans.

• Différents types de données opérationnelles peuvent nécessiter des périodes de rétention différentes. Par exemple, les journaux de sécurité doivent être conservés pendant une longue période, tandis que les données de performances ne nécessitent pas de rétention à long terme en dehors du contexte d’AIOps.

• Les données peuvent être archivées ou exportées à partir d’espaces de travail Log Analytics à des fins de rétention et/ou d’audit à long terme.

• Les clusters dédiés offrent une option de déploiement qui active les zones de disponibilité pour la protection contre les défaillances zonales dans les régions Azure prises en charge. Les clusters dédiés nécessitent un engagement minimal d’ingestion de données quotidiennes.

• Les espaces de travail Log Analytics sont déployés dans une région Azure spécifiée.

• Pour se protéger contre la perte de données en raison de l’indisponibilité d’un espace de travail Log Analytics, les ressources peuvent être configurées en utilisant plusieurs paramètres de diagnostic. Chaque paramètre de diagnostic peut envoyer des métriques et des journaux à un espace de travail Log Analytics distinct.

  • Les données envoyées à chaque espace de travail Log Analytics supplémentaire entraînent des coûts supplémentaires.
  • L’espace de travail Log Analytics redondant peut être déployé dans la même région Azure ou dans des régions Azure distinctes pour une redondance régionale supplémentaire.
  • L’envoi de journaux et de métriques d’une ressource Azure vers un espace de travail Log Analytics situé dans une autre région entraîne des coûts de transfert de données entre régions.
  • Certaines ressources Azure nécessitent un espace de travail Log Analytics dans la même région que la ressource elle-même.
  • Consultez les pratiques recommandées pour Azure Monitor Logs pour obtenir d'autres options de disponibilité pour Log Analytics workspace.

• Les données de l’espace de travail Log Analytics peuvent être exportées vers stockage Azure ou Azure Event Hubs sur une base continue, planifiée ou ponctuelle.

  • L’exportation de données permet l’archivage des données à long terme et protège contre les pertes de données opérationnelles possibles en raison d’une indisponibilité.
  • Les destinations d’exportation disponibles sont Stockage Azure ou Azure Event Hubs. Stockage Azure peut être configuré pour différents niveaux de redondance , y compris zonaux ou régionaux. L’exportation de données vers Stockage Azure stocke les données dans .json fichiers.
  • Les destinations d’exportation de données doivent se trouver dans la même région Azure que l’espace de travail Log Analytics. Destination d’exportation de données du hub d’événements dans la même région que l’espace de travail Log Analytics. La géorécupération d’urgence Azure Event Hubs n’est pas applicable pour ce scénario.
  • Il existe plusieurs limitations d’exportation de données. Seules les tables spécifiques de l’espace de travail sont prises en charge pour l’exportation de données.
  • L’archivage peut être utilisé pour stocker des données dans un espace de travail Log Analytics pour une conservation à long terme à un coût réduit sans l’exporter.

• Les journaux Azure Monitor ont des limites de restriction des requêtes utilisateur, ce qui peut être perçu comme une disponibilité réduite pour les clients, tels que les tableaux de bord d’observabilité.

  • Cinq requêtes simultanées par utilisateur : si cinq requêtes sont déjà en cours d’exécution, des requêtes supplémentaires sont placées dans une file d’attente de concurrence par utilisateur jusqu’à ce qu’une requête en cours d’exécution se termine.
  • Durée de la file d’attente d’accès concurrentiel : si une requête se trouve dans la file d’attente d’accès concurrentiel pendant plus de trois minutes, elle est arrêtée et un code d’erreur 429 retourné.
  • Limite de profondeur de la file d’attente d’accès concurrentiel : la file d’attente d’accès concurrentiel est limitée à 200 requêtes, et des requêtes supplémentaires sont rejetées avec un code d’erreur 429.
  • Limite du taux de requêtes : il existe une limite par utilisateur de 200 requêtes par 30 secondes sur tous les espaces de travail.

• Packs de requêtes sont des ressources Azure Resource Manager, utilisables pour protéger et récupérer les requêtes de journal si l’espace de travail Log Analytics n’est pas disponible.

  • Les packs de requêtes contiennent des requêtes au format JSON et peuvent être stockés en externe à Azure comme d’autres ressources d’infrastructure en tant que code.
    • Déployable via l’API REST Microsoft.Insights.
    • Si un espace de travail Log Analytics doit être recréé, le pack de requêtes peut être redéployé à partir d’une définition stockée en externe.

• Application Insights peut être déployé dans un modèle de déploiement basé sur un espace de travail, sous-jacent par un espace de travail Log Analytics où toutes les données sont stockées.

• L’échantillonnage peut être activé dans Application Insights pour réduire la quantité de données de télémétrie envoyées et optimiser les coûts d’ingestion des données.

• Toutes les données collectées par Azure Monitor, y compris Application Insights, sont facturées en fonction du volume de données ingérées et de la durée de conservation des données.

  • Les données ingérées dans un espace de travail Log Analytics peuvent être conservées sans frais supplémentaires jusqu’à 31 premiers jours (90 jours si Sentinel est activé)
  • Les données ingérées dans une application Insights basée sur un espace de travail sont conservées pendant les 90 premiers jours sans frais supplémentaires.

• Le modèle de tarification du niveau d’engagement Log Analytics offre un coût réduit et une approche prévisible des frais d’ingestion des données.

  • Toute utilisation au-dessus du niveau de réservation est facturée au même prix que le niveau actuel.

• Log Analytics, Application Insights et Azure Data Explorer utilisent le langage de requête Kusto (KQL).

• Les requêtes Log Analytics sont enregistrées en tant que fonctions dans l’espace de travail Log Analytics (savedSearches).

Recommandations en matière de conception

• Utilisez l’espace de travail Log Analytics comme récepteur de données unifié pour fournir un « volet unique » dans tous les jeux de données opérationnels.

  • Décentralisez les espaces de travail Log Analytics dans toutes les régions de déploiement utilisées. Chaque région Azure avec un déploiement d’application doit prendre en compte un espace de travail Log Analytics pour collecter toutes les données opérationnelles provenant de cette région. Toutes les ressources globales doivent utiliser un espace de travail Log Analytics dédié distinct, qui doit être déployé dans une région de déploiement principale.
    • L’envoi de toutes les données opérationnelles à un seul espace de travail Log Analytics créerait un point de défaillance unique.
    • Les exigences en matière de résidence des données peuvent interdire les données quittant la région d’origine et les espaces de travail fédérés résolvent par défaut cette exigence.
    • Il existe un coût de sortie important associé au transfert des journaux et des métriques entre les régions.
  • Tous les tampons de déploiement au sein de la même région peuvent utiliser le même espace de travail Log Analytics régional.

• Envisagez de configurer des ressources avec plusieurs paramètres de diagnostic pointant vers différents espaces de travail Log Analytics pour vous protéger contre l’indisponibilité d’Azure Monitor pour les applications avec moins de tampons de déploiement régionaux.

• Utilisez Application Insights comme outil APM (Application Performance Monitoring) cohérent sur tous les composants d’application pour collecter les journaux d’application, les métriques et les traces d’application.

  • Déployez Application Insights dans une configuration basée sur un espace de travail pour vous assurer que chaque espace de travail Log Analytics régional contient des journaux et des métriques à partir des composants d’application et des ressources Azure sous-jacentes.

• Utilisez des requêtes inter-espaces de travail pour gérer un « volet unique » unifié sur les différents espaces de travail.

• Utilisez des packs de requêtes pour protéger les requêtes de journal en cas d’indisponibilité de l’espace de travail.

  • Stockez les packs de requêtes dans le référentiel d'application Git en tant que ressources Infrastructure as Code.

• Tous les espaces de travail Log Analytics doivent être traités comme des ressources de longue durée avec un cycle de vie différent par rapport aux ressources d’application au sein d’une empreinte de déploiement régional.

• Exportez des données opérationnelles critiques depuis l’espace de travail Log Analytics pour la rétention et l’analyse à long terme afin de faciliter les AIOps et les analyses avancées, visant à affiner le modèle de santé sous-jacent et à informer des actions prédictives.

• Évaluez soigneusement le magasin de données à utiliser pour la rétention à long terme ; toutes les données ne doivent pas être stockées dans un magasin de données chaud et interrogeable.

  • Il est vivement recommandé d’utiliser stockage Azure dans une configuration GRS pour le stockage de données opérationnelles à long terme.
    • Utilisez la fonctionnalité d’exportation de l’espace de travail Log Analytics pour exporter toutes les sources de données disponibles vers stockage Azure.

• Sélectionnez les périodes de rétention appropriées pour les types de données opérationnels dans Log Analytics, en configurant des périodes de rétention plus longues dans l’espace de travail où des exigences d’observabilité « chaudes » existent.

• Utilisez Azure Policy pour garantir que toutes les ressources régionales routent les données opérationnelles vers l’espace de travail Log Analytics approprié.

Note

Lors du déploiement dans une zone de réception Azure, s'il existe une exigence pour le stockage centralisé des données opérationnelles, vous pouvez répliquer les données lors de l'instanciation afin qu'elles soient ingérées à la fois dans des outils centralisés et dans des espaces de travail Log Analytics dédiés à l'application. Vous pouvez également exposer l’accès aux espaces de travail Log Analytics d’application afin que les équipes centrales puissent interroger les données d’application. Il est finalement essentiel que les données opérationnelles provenant de la solution soient disponibles dans les espaces de travail Log Analytics dédiés à l’application.

Si l’intégration SIEM est requise, n’envoyez pas d’entrées de journal brutes, mais envoyez plutôt des alertes critiques.

• Configurez uniquement l’échantillonnage dans Application Insights s’il est nécessaire d’optimiser les performances ou si l’échantillonnage n’est pas coûteux.

  • L’échantillonnage excessif peut entraîner des signaux opérationnels manqués ou incorrects.

• Utilisez des ID de corrélation pour tous les événements de trace et les messages de journalisation pour les lier à une demande donnée.

  • Retournez les ID de corrélation à l’appelant pour tous les appels, pas seulement les demandes ayant échoué.

• Assurez-vous que le code de l'application intègre l'instrumentation et l'enregistrement appropriés pour informer le modèle de santé et, si nécessaire, faciliter la résolution des problèmes ou l'analyse des causes profondes ultérieures.

  • Le code d’application doit utiliser Application Insights pour faciliter le suivi distribué, en fournissant à l’appelant un message d’erreur complet qui inclut un ID de corrélation lorsqu’un échec se produit.

• Utilisez la journalisation structurée pour tous les messages de journal.

• Ajoutez des sondes de santé significatives à tous les composants de l’application.

  • Lors de l’utilisation d’AKS, configurez les points de terminaison d’intégrité pour chaque déploiement (pod) afin que Kubernetes puisse déterminer correctement quand un pod est sain ou malsain.
  • Lors de l’utilisation d’Azure App Service, configurez les contrôles d’intégrité afin que les opérations de scale-out ne provoquent pas d’erreurs en envoyant du trafic à des instances qui ne sont pas encore prêtes et en veillant à ce que les instances non saines soient recyclées rapidement.

Si l’application est abonnée au support Microsoft Mission-Critical, envisagez d’exposer les sondes d’intégrité clés au support Microsoft, afin que l’intégrité de l’application puisse être modélisée plus précisément par le Support Microsoft.

• Consignez les demandes de contrôle d’intégrité réussies, sauf si des volumes de données accrus ne peuvent pas être tolérés dans le contexte des performances de l’application, car ils fournissent des insights supplémentaires pour la modélisation analytique.

• Ne configurez pas les espaces de travail Log Analytics de production pour appliquer une limite quotidienne, ce qui limite l’ingestion quotidienne des données opérationnelles, car cela peut entraîner la perte de données opérationnelles critiques.

  • Dans des environnements inférieurs, tels que le développement et le test, une limite quotidienne peut être considérée comme un mécanisme facultatif d’économie de coûts.

• À condition que les volumes d’ingestion de données opérationnelles fournis atteignent le seuil minimal de niveau, configurez les espaces de travail Log Analytics pour utiliser une tarification selon un niveau d’engagement, afin d’accroître l’efficacité des coûts par rapport au modèle de tarification « paiement à l’utilisation ».

• Il est fortement recommandé de stocker des requêtes Log Analytics à l’aide du contrôle de code source et d’utiliser l’automatisation CI/CD pour les déployer sur des instances d’espace de travail Log Analytics pertinentes.

Visualisation

Représenter visuellement le modèle de santé avec des données opérationnelles critiques est essentiel pour réaliser des opérations efficaces et optimiser la fiabilité. Les tableaux de bord doivent finalement être utilisés pour fournir des insights quasiment en temps réel sur l’intégrité des applications pour les équipes DevOps, ce qui facilite le diagnostic rapide des écarts par rapport à l’état stable.

Microsoft fournit plusieurs technologies de visualisation des données, notamment les tableaux de bord Azure, Power BI et Azure Managed Grafana (actuellement en préversion). Les tableaux de bord Azure sont positionnés pour fournir une solution de visualisation prête à l’emploi étroitement intégrée pour les données opérationnelles dans Azure Monitor. Il a donc un rôle fondamental à jouer dans la représentation visuelle des données opérationnelles et de l’intégrité des applications pour une charge de travail stratégique. Toutefois, il existe plusieurs limitations en termes de positionnement des tableaux de bord Azure en tant que plateforme d’observabilité holistique et, par conséquent, il convient de tenir compte de l’utilisation supplémentaire de solutions d’observabilité leader sur le marché, telles que Grafana, qui est également fournie en tant que solution gérée dans Azure.

Cette section se concentre sur l’utilisation de Tableaux de bord Azure et de Grafana pour créer une expérience de tableau de bord robuste capable d’offrir une perspective technique et commerciale sur la santé des applications, permettant ainsi aux équipes DevOps de fonctionner de manière efficace. Un tableau de bord robuste est essentiel pour diagnostiquer les problèmes qui se sont déjà produits et prendre en charge les équipes opérationnelles dans la détection et la réponse aux problèmes au fur et à mesure qu’elles se produisent.

Considérations relatives à la conception

• Lors de la visualisation du modèle de santé à l’aide de requêtes de journal, notez qu’il existe des limites Log Analytics sur les requêtes simultanées et mises en file d’attente, ainsi que le taux de requêtes global, les requêtes suivantes étant mises en file d’attente et ralenties.

• Les requêtes permettant de récupérer des données opérationnelles utilisées pour calculer et représenter des scores d’intégrité peuvent être écrites et exécutées dans Log Analytics ou Azure Data Explorer.

  • Des exemples de requêtes sont disponibles ici.

• Log Analytics impose plusieurs limites de requête, qui doivent être conçues pour la conception de tableaux de bord opérationnels.

• La visualisation des métriques de ressources brutes, telles que l’utilisation du processeur ou le débit réseau, nécessite une évaluation manuelle par les équipes des opérations pour déterminer les impacts sur l’état d’intégrité et cela peut être difficile pendant un incident actif.

• Si plusieurs utilisateurs utilisent des tableaux de bord au sein d’un outil comme Grafana, le nombre de requêtes envoyées à Log Analytics se multiplie rapidement.

  • Atteindre la limite de requête simultanée sur Log Analytics met en file d’attente les requêtes suivantes, ce qui rend l’expérience du tableau de bord « lente ».

Recommandations de conception

• Collectez et présentez les sorties interrogées de tous les espaces de travail Log Analytics régionaux et de l’espace de travail Log Analytics global pour créer une vue unifiée de l’intégrité des applications.

Note

Si vous effectuez un déploiement dans une zone d’atterrissage Azure, envisagez d’interroger l’espace de travail Log Analytics de la plateforme centrale si des dépendances clés sur les ressources de plateforme existent, telles qu’ExpressRoute pour la communication locale.

• Un modèle « feu de trafic » doit être utilisé pour représenter visuellement les états « sains » et « non sains », avec un vert utilisé pour illustrer quand les exigences non fonctionnelles clés sont entièrement satisfaites et que les ressources sont utilisées de manière optimale. Utilisez « Green », « Amber et « Red » pour représenter les états « Sain », « Détérioré » et « Non disponible ».

• Utilisez les tableaux de bord Azure pour créer des objectifs opérationnels pour les ressources globales et les tampons de déploiement régional, représentant des métriques clés telles que le nombre de demandes pour Azure Front Door, la latence côté serveur pour Azure Cosmos DB, les messages entrants/sortants pour Event Hubs, ainsi que l’utilisation du processeur ou les états de déploiement pour AKS. Les tableaux de bord doivent être adaptés pour favoriser l’efficacité opérationnelle, infusant les apprentissages des scénarios d’échec afin de garantir que les équipes DevOps disposent d’une visibilité directe sur les métriques clés.

• Si les tableaux de bord Azure ne peuvent pas être utilisés pour représenter avec précision le modèle d’intégrité et les exigences métier requises, il est vivement recommandé de considérer Grafana comme solution de visualisation alternative, offrant des fonctionnalités de pointe sur le marché et un vaste écosystème de plug-in open source. Évaluez l’offre de prévisualisation Grafana gérée pour éviter les complexités opérationnelles liées à la gestion de l’infrastructure Grafana.

• Lors du déploiement de Grafana auto-hébergé, utilisez une conception hautement disponible et géodistribuable pour garantir que les tableaux de bord opérationnels critiques peuvent être résilients aux défaillances de plateforme régionale et aux scénarios d’erreur en cascade.

  • Externalisez l'état de configuration vers une base de données externe, telle qu'Azure Database pour Postgres ou MySQL, afin d'assurer que les nœuds d'application de Grafana demeurent stateless.

    • Configurez la réplication de base de données entre les régions de déploiement.

  • Déployez des nœuds Grafana sur App Services dans une configuration hautement disponible dans une région, à l’aide de déploiements basés sur des conteneurs.

    • Déployez des instances App Service dans des régions de déploiement considérées.

    App Services fournit une plateforme conteneur à faible friction, qui est idéale pour les scénarios à faible échelle, tels que les tableaux de bord opérationnels, et l’isolation de Grafana à partir d’AKS offre une séparation claire des préoccupations entre la plateforme d’application principale et les représentations opérationnelles pour cette plateforme. Consultez la section de conception de la plateforme d’applications pour obtenir d’autres recommandations de configuration.

  • Utilisez Stockage Azure dans une configuration GRS pour héberger et gérer des visuels et des plug-ins personnalisés.

  • Déployez les composants de service d'application et de duplication en lecture de base de données avec Grafana dans au moins deux régions de déploiement. Envisagez d’adopter un modèle où Grafana est déployé dans toutes les régions de déploiement envisagées.

Pour les scénarios ciblant un >= 99,99% SLO, Grafana doit être déployé dans un minimum de 3 régions de déploiement pour optimiser la fiabilité globale pour les tableaux de bord opérationnels clés.

• Limitez les requêtes Log Analytics en agrégeant des requêtes en un ou petit nombre de requêtes, telles que l’utilisation de l’opérateur KQL « union » et définissez un taux d’actualisation approprié sur le tableau de bord.

  • Un taux d’actualisation maximal approprié dépend du nombre et de la complexité des requêtes de tableau de bord ; l’analyse des requêtes implémentées est requise.

• Si la limite de requête simultanée de Log Analytics est atteinte, envisagez d’optimiser le modèle de récupération en stockant (temporairement) les données requises pour le tableau de bord dans un magasin de données hautes performances tel qu’Azure SQL.

Réponse automatisée aux incidents

Bien que les représentations visuelles de la santé des applications fournissent des insights opérationnels et métier inestimables pour soutenir la détection et le diagnostic des problèmes, elles s’appuient sur la préparation et les interprétations des équipes opérationnelles, ainsi que sur l’efficacité des réponses ultérieures déclenchées par des humains. Par conséquent, pour optimiser la fiabilité, il est nécessaire d’implémenter des alertes étendues pour détecter de manière proactive et répondre aux problèmes en quasi-temps réel.

Azure Monitor fournit une infrastructure d’alerte étendue pour détecter, catégoriser et répondre aux signaux opérationnels par le biais de groupes d’actions. Cette section se concentre donc sur l’utilisation d’alertes Azure Monitor pour générer des actions automatisées en réponse à des écarts actuels ou potentiels d’un état d’application sain.

Important

L’alerte et l’action automatisée sont essentielles pour détecter et répondre rapidement aux problèmes au fur et à mesure qu’ils se produisent, avant que l’impact négatif puisse se produire. L’alerte fournit également un mécanisme permettant d’interpréter les signaux entrants et de répondre aux problèmes avant qu’ils ne se produisent.

Considérations relatives à la conception

• Les règles d’alerte sont définies pour être déclenchées lorsqu’un critère conditionnel est satisfait pour les signaux entrants, qui peuvent inclure différentes sources de données, telles que des métriques, des requêtes de journal ou des tests de disponibilité.

• Les alertes peuvent être définies dans Log Analytics ou Azure Monitor sur la ressource spécifique.

• Certaines métriques sont uniquement consultables dans Azure Monitor, car pas tous les points de données de diagnostic ne sont disponibles dans Log Analytics.

• L’API Alertes Azure Monitor peut être utilisée pour récupérer des alertes actives et historiques.

• Il existe des limites d’abonnement liées aux alertes et aux groupes d’actions, qui doivent être conçus pour :

  • Les limites existent pour le nombre de règles d’alerte configurables.
  • L’API Alertes a des limites de limitation, qui doivent être prises en compte pour les scénarios d’utilisation extrême.
  • Les groupes d’actions ont plusieurs limites strictes pour le nombre de réponses configurables, qui doivent être conçues pour.
    • Chaque type de réponse a une limite de 10 actions, en dehors de l’e-mail, qui a une limite de 1 000 actions.

• Les alertes peuvent être intégrées dans un modèle de santé à plusieurs niveaux en créant une règle d’alerte pour une requête de recherche de journal enregistrée à partir de la fonction de score « racine » du modèle. Par exemple, en utilisant « WebsiteHealthScore » et en alertant sur une valeur numérique qui représente un état « Non sain ».

Recommandations en matière de conception

• Pour les alertes centrées sur les ressources, créez des règles d’alerte dans Azure Monitor pour vous assurer que toutes les données de diagnostic sont disponibles pour les critères de règle d’alerte.

• Consolider les actions automatisées dans un nombre minimal de groupes d’actions, alignées avec les équipes de service pour prendre en charge une approche DevOps.

• Répondez aux signaux d’utilisation excessive des ressources par le biais d’opérations de mise à l’échelle automatisées, à l’aide de fonctionnalités de mise à l’échelle automatique natives Azure, le cas échéant. Lorsque la fonctionnalité intégrée de mise à l’échelle automatique n’est pas applicable, utilisez le score d’intégrité du composant pour modéliser les signaux et déterminer quand répondre avec des opérations de mise à l’échelle automatisées. Assurez-vous que les opérations de mise à l’échelle automatisées sont définies en fonction d’un modèle de capacité, qui quantifie les relations d’échelle entre les composants, afin que les réponses à l’échelle englobent les composants qui doivent être mis à l’échelle par rapport à d’autres composants.

• Modèles d’actions pour prendre en charge un classement hiérarchisé, qui doit être déterminé par l’impact de l’entreprise.

• Utilisez l’API Alertes Azure Monitor pour collecter des alertes historiques à incorporer dans le stockage opérationnel « froid » pour des analyses avancées.

• Pour les scénarios d’échec critique, qui ne peuvent pas être traités avec une réponse automatisée, assurez-vous que l'automatisation des runbooks opérationnelle est en place pour déclencher une action rapide et cohérente une fois que l’interprétation manuelle et la validation sont fournies. Utiliser des notifications d’alerte pour identifier rapidement les problèmes nécessitant une interprétation manuelle

• Créez des allocations dans les sprints d’ingénierie pour améliorer l’amélioration incrémentielle des alertes afin de garantir que de nouveaux scénarios d’échec qui n’ont pas déjà été considérés peuvent être entièrement pris en charge dans les nouvelles actions automatisées.

• Effectuez des tests de préparation opérationnelle dans le cadre des processus CI/CD pour valider les règles d’alerte clés pour les mises à jour de déploiement.

Actions prédictives et opérations IA (AIOps)

Les modèles d'apprentissage automatique peuvent être appliqués pour mettre en corrélation et hiérarchiser les données opérationnelles, ce qui permet de recueillir des insights critiques liés au filtrage du 'bruit' des alertes excessives, de prédire les problèmes avant qu'ils n’entraînent un impact, ainsi que d'accélérer la réponse aux incidents lorsqu'ils surviennent.

Plus précisément, une méthodologie AIOps peut être appliquée à des insights critiques sur le comportement du système, des utilisateurs et des processus DevOps. Ces insights peuvent inclure l’identification d’un problème qui se produit maintenant (détecter), la quantifier pourquoi le problème se produit (diagnostiquer) ou signaler ce qui se passera à l’avenir (prédire). Ces insights peuvent être utilisés pour générer des actions qui ajustent et optimisent l’application pour atténuer les problèmes actifs ou potentiels, à l’aide de métriques métier clés, de métriques de qualité du système et de métriques de productivité DevOps, afin de hiérarchiser en fonction de l’impact de l’entreprise. Les actions menées peuvent elles-mêmes être fusionnées dans le système par le biais d’une boucle de rétroaction qui entraîne davantage le modèle sous-jacent pour accroître l’efficacité.

Il existe plusieurs technologies analytiques dans Azure, telles qu’Azure Synapse et Azure Databricks, qui peuvent être utilisées pour générer et entraîner des modèles analytiques pour AIOps. Cette section se concentre donc sur la façon dont ces technologies peuvent être positionnées au sein d’une conception d’application pour prendre en charge AIOps et générer une action prédictive, en mettant l’accent sur Azure Synapse qui réduit les frictions en regroupant le meilleur des services de données d’Azure, ainsi que de puissantes nouvelles fonctionnalités.

AIOps est utilisé pour favoriser l’action prédictive, l’interprétation et la corrélation des signaux opérationnels complexes observés sur une période prolongée afin de mieux répondre aux problèmes avant qu’ils ne se produisent.

Considérations relatives à la conception

• Azure Synapse Analytics offre plusieurs fonctionnalités Machine Learning (ML).

  • Les modèles ML peuvent être entraînés et exécutés sur des pools Synapse Spark avec des bibliothèques, notamment MLLib, SparkML et MMLSpark, ainsi que des bibliothèques open source populaires, telles que Scikit Learn.
  • Les modèles ML peuvent être entraînés avec des outils de science des données courants tels que PySpark/Python, Scala ou .NET.

• Synapse Analytics est intégré à Azure ML via Azure Synapse Notebooks, ce qui permet aux modèles ML d’être formés dans un espace de travail Azure ML à l’aide du ML automatisé.

• Synapse Analytics permet également aux fonctionnalités ML à l’aide d’Azure Cognitive Services de résoudre des problèmes généraux dans différents domaines, tels que la détection d’anomalies. Cognitive Services peut être utilisé dans Azure Synapse, Azure Databricks et via des SDK et des API REST dans les applications clientes.

• Azure Synapse s’intègre en mode natif avec les outils Azure Data Factory pour extraire, transformer et charger (ETL) ou ingérer des données dans des pipelines d’orchestration.

• Azure Synapse permet l’inscription de jeux de données externes aux données stockées dans stockage Blob Azure ou Azure Data Lake Storage.

  • Les jeux de données inscrits peuvent être utilisés dans les tâches d’analytique des données du pool Synapse Spark.

• Azure Databricks peut être intégré dans des pipelines Azure Synapse Analytics pour des fonctionnalités Spark supplémentaires.

  • Synapse orchestre la lecture des données et l’envoie à un cluster Databricks, où elles peuvent être transformées et préparées pour l’apprentissage du modèle ML.

• Les données sources doivent généralement être préparées pour l’analytique et le ML.

  • Synapse offre différents outils pour faciliter la préparation des données, notamment Apache Spark, les notebooks Synapse et les pools SQL serverless avec T-SQL et des visualisations intégrées.

• Les modèles ML qui ont été entraînés, mis en service et déployés peuvent être utilisés pour l'évaluation par lots dans Synapse.

  • Les scénarios AIOps, tels que l’exécution de prédictions de régression ou de dégradation dans le pipeline CI/CD, peuvent nécessiter un scoring en temps réel .

• Il existe des limites d’abonnement pour Azure Synapse, qui doivent être entièrement comprises dans le contexte d’une méthodologie AIOps.

• Pour incorporer entièrement AIOps, il est nécessaire de nourrir des données d’observabilité en quasi temps réel dans des modèles d’inférence ML en temps réel sur une base continue.

  • Les fonctionnalités telles que la détection d’anomalies doivent être évaluées dans le flux de données d’observabilité.

Recommandations en matière de conception

• Vérifiez que toutes les ressources et composants d’application Azure sont entièrement instrumentés afin qu’un jeu de données opérationnel complet soit disponible pour l’apprentissage du modèle AIOps.

• Ingérer des données opérationnelles Log Analytics à partir des comptes de stockage Azure globaux et régionaux dans Azure Synapse à des fins d’analyse.

• Utilisez l’API Alertes Azure Monitor pour récupérer les alertes historiques et les stocker dans le stockage à froid pour les données opérationnelles afin d’utiliser ultérieurement dans les modèles ML. Si l’exportation de données Log Analytics est utilisée, stockez les données d’alertes historiques dans les mêmes comptes de stockage Azure que les données Log Analytics exportées.

• Une fois les données ingérées préparées pour l’apprentissage ML, réécrivez-les dans stockage Azure afin qu’elles soient disponibles pour l’entraînement du modèle ML sans nécessiter l’exécution des ressources de calcul de préparation des données Synapse.

• Vérifiez que l’opérationnalisation du modèle ML prend en charge le scoring par lots et en temps réel.

• À mesure que des modèles AIOps sont créés, implémentez MLOps et appliquez des pratiques DevOps pour automatiser le cycle de vie ML, y compris l’entraînement, la mise en production, l’évaluation et l’amélioration continue. Créez un processus CI/CD itératif pour les modèles AIOps ML.

• Évaluez Azure Cognitive Services pour des scénarios prédictifs spécifiques en raison de leur faible surcharge d’administration et d’intégration. Envisagez la détection d’anomalies pour signaler rapidement des variances inattendues dans les flux de données d’observabilité.

Étape suivante

Passez en revue les considérations relatives au déploiement et aux tests.

Déploiement et tests