Modélisation de l’intégrité et observabilité des charges de travail stratégiques sur Azure

La modélisation et l’observabilité de l’intégrité sont des concepts essentiels pour optimiser la fiabilité, qui se concentre sur une instrumentation et une surveillance robustes et contextualisées. Ces concepts fournissent des informations essentielles sur l’intégrité de l’application, favorisant l’identification et la résolution rapides des problèmes.

La plupart des applications stratégiques sont importantes en termes d’échelle et de complexité et génèrent donc des volumes élevés de données opérationnelles, ce qui rend difficile l’évaluation et la détermination de l’action opérationnelle optimale. La modélisation d’intégrité s’efforce en fin de compte d’optimiser l’observabilité en augmentant les journaux et les métriques de surveillance bruts avec des exigences métier clés pour quantifier l’intégrité des applications, ce qui conduit à l’évaluation automatisée des états d’intégrité pour obtenir 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 d’intégrité robuste, en mappant les états d’intégrité quantifiés des applications par le biais de l’observabilité et des constructions opérationnelles pour atteindre la maturité opérationnelle.

Important

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

Il existe trois main niveaux de maturité opérationnelle pour optimiser la fiabilité.

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

Vidéo : Définir un modèle d’intégrité pour votre charge de travail stratégique

Intégrité de l’application en couches

Pour créer un modèle d’intégrité, définissez d’abord l’intégrité de l’application dans le contexte des exigences métier clés en quantifiant les états « sains » et « non sains » dans un format en couches et mesurable. Ensuite, pour chaque composant d’application, affinez la définition dans le contexte d’un état d’exécution stable et agrégée en fonction des flux utilisateur de l’application. Superposez à des exigences métier non fonctionnelles clés pour les performances et la disponibilité. Enfin, agrégez les états d’intégrité de chaque flux d’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 couche doivent être utilisées pour informer les métriques de surveillance critiques sur tous les composants du système et valider la composition du sous-système opérationnel.

Important

Lorsque vous définissez les états « non sains », représentez 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é.

Remarques relatives à la conception

• Le processus de modélisation de l’intégrité est une activité de conception descendante qui commence par un exercice d’architecture pour définir tous les flux utilisateur et mapper les dépendances entre les composants fonctionnels et logiques, ce qui permet de mapper implicitement les dépendances entre les ressources Azure.

• Un modèle d’intégrité dépend entièrement du contexte de la solution qu’il représente et ne peut donc pas être résolu « out-of-the-box », car « une taille ne convient pas à tous ».

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

• Un modèle d’intégrité en couche permet de retracer l’intégrité de l’application vers des dépendances de niveau inférieur, ce qui contribue à causer rapidement la dégradation du service à la racine.

• 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. Le test des performances est donc une fonctionnalité clé pour définir et évaluer en permanence l’intégrité de l’application.

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

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

Recommandations de conception

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

  • Le modèle d’intégrité doit être en couches 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 composants fondamentaux doivent être agrégés en même temps que les exigences non fonctionnelles clés pour créer une perspective contextualisée métier dans l’intégrité des flux système.
  • Les flux système doivent être agrégés avec des pondérations appropriées basées sur la criticité métier pour créer une définition significative de l’intégrité globale de l’application. Les flux d’utilisateurs significatifs sur le plan financier ou orientés client doivent être hiérarchisés.
  • Chaque couche du modèle d’intégrité doit capturer ce que représentent les états « sains » et « non sains ».
  • Assurez-vous que le modèle de santé peut faire la distinction entre les états non sains temporaires et non temporaires 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, en considérant les exigences non fonctionnelles clés comme coefficients.

  • Le score d’intégrité d’un flux utilisateur doit être représenté par le score le plus bas de tous les composants mappés, en prenant en compte la réalisation 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 de manière cohérente l’intégrité opérationnelle 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 d’intégrité pour refléter les status d’intégrité.

• Le score d’intégrité doit être calculé automatiquement en fonction des métriques sous-jacentes, qui peuvent être visualisées à l’aide de modèles d’observabilité et mises en œuvre par le biais de procédures opérationnelles automatisées.

  • Le score d’intégrité doit devenir le cœur de 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 d’intégrité pour calculer l’atteinte de l’objectif de niveau de service (SLO) de disponibilité au lieu de la disponibilité brute, en veillant à ce que la démarcation entre la dégradation du service et l’indisponibilité soit reflétée sous forme de SLO distincts.

• Utilisez le modèle d’intégrité dans les pipelines CI/CD et les cycles de test pour vérifier 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 les tests de chaos dans le cadre des processus CI/CD.

• La création et la maintenance d’un modèle d’intégrité sont un processus itératif et les investissements en ingénierie doivent être alignés pour favoriser des améliorations continues.

  • Définissez un processus pour évaluer et affiner en permanence la précision du modèle, et envisagez d’investir dans des modèles Machine Learning pour poursuivre l’apprentissage du modèle.

Exemple - Modèle d’intégrité 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 d’intégrité complet et contextualisé est fourni dans les implémentations de référence Mission-Critical :

• Stratégique en ligne
• Connecté critique à la mission

Lors de l’implémentation d’un modèle d’intégrité, il est important de définir l’intégrité des composants individuels par le biais de l’agrégation et de l’interprétation de métriques clés au niveau des ressources. L’image ci-dessous illustre la façon dont les métriques de ressources peuvent être utilisées :

Cette définition de l’intégrité peut ensuite être représentée par une requête KQL, comme le montre l’exemple de requête ci-dessous qui agrège InsightsMetrics (Container Insights) et AzureMetrics (diagnostics paramètre 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 un score d’intégrité pour faciliter l’agrégation à des niveaux plus élevés du modèle d’intégrité.

// 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 sous forme de graphique de dépendances à l’aide d’outils de visualisation tels que Grafana pour illustrer le modèle d’intégrité.

Cette image montre un exemple de modèle d’intégrité en couche de l’implémentation de référence en ligne Azure Mission-Critical, et montre comment une modification de l’état d’intégrité d’un composant de base 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 : Démonstration de modélisation de la surveillance et de l’intégrité

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 de santé 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 une action opérationnelle rapide. En outre, la corrélation entre tous les jeux de données inclus est nécessaire pour garantir une analyse efficace sans limite, ce qui permet la représentation en couches de l’intégrité.

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

Remarques 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 les espaces de travail Log Analytics, 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 configurées de manière appropriée pour acheminer les données de diagnostic vers le récepteur de données souhaité.

Conseil

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 prévoir la conservation des types de données critiques pendant une période prolongée. Par exemple, dans le secteur bancaire réglementé, 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é peuvent devoir être conservés pendant une longue période, alors qu’il est peu probable que les données de performances nécessitent une 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 fournissent une option de déploiement qui permet Zones de disponibilité de protection contre les défaillances zonales dans les régions Azure prises en charge. Les clusters dédiés nécessitent un engagement quotidien minimal d’ingestion de données.

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

• Pour vous protéger contre la perte de données en cas d’indisponibilité d’un espace de travail Log Analytics, les ressources peuvent être configurées avec 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 à partir d’une ressource Azure vers un espace de travail Log Analytics dans une autre région entraîne des coûts de sortie des données interré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 Meilleures pratiques pour les journaux Azure Monitor pour obtenir d’autres options de disponibilité pour l’espace de travail Log Analytics.

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

  • L’exportation de données permet l’archivage des données à long terme et protège contre une éventuelle perte de données opérationnelles due à l’indisponibilité.
  • Les destinations d’exportation disponibles sont Stockage Azure ou Azure Event Hubs. Le 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 des fichiers .json.
  • Les destinations d’exportation de données doivent se trouver dans la même région Azure que l’espace de travail Log Analytics. Une destination d’exportation de données du hub d’événements doit se trouver dans la même région que l’espace de travail Log Analytics. Azure Event Hubs géo-récupération d’urgence ne s’applique pas à 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 les exporter.

• Les journaux Azure Monitor ont des limites de limitation des requêtes utilisateur, qui peuvent apparaître comme une disponibilité réduite pour les clients, comme 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 d’accès concurrentiel par utilisateur jusqu’à ce qu’une requête en cours d’exécution se termine.
  • Temps dans 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 est retourné.
  • Limite de profondeur de file d’attente d’accès concurrentiel : la file d’attente d’accès concurrentiel est limitée à 200 requêtes, et les requêtes supplémentaires sont rejetées avec un code d’erreur 429.
  • Limite de débit de requêtes : il existe une limite par utilisateur de 200 requêtes par 30 secondes dans tous les espaces de travail.

• Les packs de requêtes sont des ressources Azure Resource Manager, qui peuvent être utilisées pour protéger et récupérer des 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, soutenu 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’aux 31 premiers jours (90 jours si Sentinel est activé)
  • Les données ingérées dans un application Insights basé 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 de 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 de conception

• Utilisez l’espace de travail Log Analytics comme récepteur de données unifié pour fournir un « volet unique » sur 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 envisager 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 conditions requises pour la résidence des données peuvent empêcher les données de quitter la région d’origine, et les espaces de travail fédérés résolvent cette exigence par défaut.
    • 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 dans 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égional.

• Utilisez Application Insights en tant qu’outil APM (Application Performance Monitoring) compatible avec tous les composants d’application afin de collecter les journaux, les métriques et les traces de l’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 provenant des composants d’application et des ressources Azure sous-jacentes.

• Utilisez des requêtes inter-espaces de travail pour conserver un « volet unique » unifié dans 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 Git de l’application en tant que ressources d’infrastructure en tant que 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 des ressources d’application dans un tampon de déploiement régional.

• Exportez des données opérationnelles critiques à partir de l’espace de travail Log Analytics pour la rétention et l’analytique à long terme afin de faciliter l’intelligence artificielle et l’analytique avancée afin d’affiner le modèle d’intégrité sous-jacent et d’informer l’action prédictive.

• Évaluez soigneusement le magasin de données qui doit être utilisé pour la conservation à 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érationnelles dans Log Analytics, en configurant des périodes de rétention plus longues dans l’espace de travail où des exigences d’observabilité « à chaud » existent.

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

Notes

Lors du déploiement dans une zone d’atterrissage Azure, s’il est nécessaire d’utiliser un stockage centralisé des données opérationnelles, vous pouvez dupliquer les données au moment de l’instanciation afin qu’elles soient ingérées à la fois dans les outils centralisés et les 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. Au final, il est 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 l’échantillonnage dans Application Insights uniquement s’il est nécessaire pour optimiser les performances ou si l’échantillonnage ne devient pas prohibitif.

  • Un échantillonnage excessif peut entraîner des signaux opérationnels manqués ou inexacts.

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

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

• Vérifiez que le code d’application intègre une instrumentation et une journalisation appropriées pour informer le modèle d’intégrité et faciliter la résolution des problèmes ou l’analyse de la cause racine si nécessaire.

  • 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 en cas de défaillance.

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

• Ajoutez des sondes d’intégrité significatives à tous les composants de l’application.

  • Lorsque vous utilisez 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 non sain.
  • Lorsque vous utilisez 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 vers des instances qui ne sont pas encore prêtes et en vous assurant que les instances non saines sont recyclées rapidement.

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

• Journaliser les requêtes de case activée d’intégrité réussies, sauf si l’augmentation des volumes de données ne peut pas être tolérée dans le contexte des performances de l’application, car elles fournissent des insights supplémentaires pour la modélisation analytique.

• Ne configurez pas les espaces de travail Log Analytics de production pour appliquer un plafond quotidien, 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 les environnements inférieurs, tels que le développement et le test, un plafond quotidien peut être considéré comme un mécanisme facultatif d’économie de coûts.

• Si les volumes d’ingestion de données opérationnelles atteignent le seuil de niveau minimal, configurez les espaces de travail Log Analytics pour utiliser la tarification basée sur le niveau d’engagement afin d’optimiser les coûts par rapport au modèle tarifaire de paiement à l’utilisation.

• Il est fortement recommandé de stocker les 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

Il est essentiel de représenter visuellement le modèle d’intégrité avec des données opérationnelles critiques pour obtenir des opérations efficaces et optimiser la fiabilité. Les tableaux de bord doivent finalement être utilisés pour fournir des insights en quasi-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. Elle 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. Par conséquent, il convient de tenir compte de l’utilisation supplémentaire de solutions d’observabilité de pointe, telles que Grafana, qui est également fournie en tant que solution managée dans Azure.

Cette section se concentre sur l’utilisation des tableaux de bord Azure et de Grafana pour créer une expérience de tableaux de bord robuste capable de fournir des objectifs techniques et métier sur l’intégrité des applications, ce qui permet aux équipes DevOps de fonctionner efficacement. Un tableau de bord robuste est essentiel pour diagnostiquer les problèmes qui se sont déjà produits et aider les équipes opérationnelles à détecter et à répondre aux problèmes au fur et à mesure qu’ils se produisent.

Remarques relatives à la conception

• Lors de la visualisation du modèle d’intégrité à 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ête global, avec les requêtes suivantes mises en file d’attente et limitées.

• Les requêtes permettant de récupérer des données opérationnelles utilisées pour calculer et représenter les 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 d’exploitation pour déterminer l’impact sur l’intégrité status, ce qui peut être difficile lors d’un incident actif.

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

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

Recommandations relatives à la 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.

Notes

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 la plateforme existent, telles qu’ExpressRoute pour la communication locale.

• Un modèle de « feu tricolore » doit être utilisé pour représenter visuellement les états « sain » et « non sain », le vert étant utilisé pour indiquer que les exigences non fonctionnelles clés sont entièrement satisfaites et que les ressources sont utilisées de manière optimale. Utilisez « Vert », « Orange et Rouge » 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 empreintes 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 et les états d’utilisation du processeur ou de déploiement pour AKS. Les tableaux de bord doivent être conçus pour favoriser l’efficacité opérationnelle, en infusant les enseignements tirés des scénarios d’échec pour que les équipes DevOps aient 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 une solution de visualisation alternative, fournissant des fonctionnalités de pointe sur le marché et un écosystème de plug-ins open source étendu. Évaluez l’offre de préversion Grafana managée pour éviter les complexités opérationnelles de la gestion de l’infrastructure Grafana.

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

  • Séparez l’état de configuration dans un magasin de données externe, tel qu’Azure Database pour Postgres ou MySQL, pour garantir que les nœuds d’application Grafana restent sans état.

    • 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 au sein d’une région, à l’aide de déploiements basés sur des conteneurs.

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

    App Services fournit une plateforme de conteneurs à faible friction, qui est idéale pour les scénarios à faible échelle, tels que les tableaux de bord opérationnels, et l’isolement de Grafana 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. Reportez-vous à la zone Deign platform d’application 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 app service et la lecture de base de données réplica composants Grafana dans un minimum de deux régions de déploiement, et envisagez d’utiliser un modèle où Grafana est déployé dans toutes les régions de déploiement considérées.

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

• Limitez les limites des requêtes Log Analytics en agrégeant les requêtes en un seul ou un petit nombre de requêtes, par exemple à l’aide de l’opérateur « union » KQL, 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 que Azure SQL.

Réponse automatisée aux incidents

Bien que les représentations visuelles de l’intégrité d’application fournissent des insights opérationnels et métier précieux pour permettre la détection et le diagnostic des problèmes, elles reposent 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 l’homme. 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’alertes complète pour détecter, classer et répondre aux signaux opérationnels par le biais de groupes d’actions. Cette section se concentre donc sur l’utilisation des alertes Azure Monitor pour générer des actions automatisées en réponse à des écarts actuels ou potentiels par rapport à un état d’application sain.

Important

L’alerte et l’action automatisée sont essentielles pour détecter efficacement les problèmes et y répondre rapidement à mesure qu’ils se produisent, avant qu’un impact négatif plus important ne se produise. L’alerte fournit également un mécanisme pour interpréter les signaux entrants et répondre afin d’éviter les problèmes avant qu’ils ne se produisent.

Remarques 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 interrogeables dans Azure Monitor, car tous les points de données de diagnostic ne sont pas 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 groupes d’alertes et d’actions, qui doivent être conçues pour :

  • Il existe des limites pour le nombre de règles d’alerte configurables.
  • L’API Alerts 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 matérielles pour le nombre de réponses configurables, qui doivent être conçues pour.
    • Chaque type de réponse a une limite de 10 actions, à l’exception de la messagerie électronique, qui a une limite de 1 000 actions.

• Les alertes peuvent être intégrées dans un modèle d’intégrité en couches en créant une règle d’alerte pour une requête de recherche dans les journaux enregistrée à partir de la fonction de scoring « racine » du modèle. Par exemple, l’utilisation de « WebsiteHealthScore » et l’alerte sur une valeur numérique qui représente un état « Non sain ».

Recommandations 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.

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

• Répondez aux signaux d’utilisation excessive des ressources par des opérations de mise à l’échelle automatisées, en utilisant des fonctionnalités de mise à l’échelle automatique Azure natives dans la mesure du possible. Quand la fonctionnalité de mise à l’échelle automatique intégrée n’est pas applicable, utilisez le score d’intégrité du composant pour modéliser les signaux et déterminer le meilleur moment pour répondre avec des opérations de mise à l’échelle automatisées. Vérifiez 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 de mise à l’échelle englobent les composants qui doivent être mis à l’échelle par rapport à d’autres composants.

• Actions de modèle pour prendre en charge un ordre hiérarchisé, qui doit être déterminé par l’impact sur l’entreprise.

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

• Pour les scénarios d’échec critiques, qui ne peuvent pas être satisfaits par une réponse automatisée, assurez-vous que l’automatisation des runbooks opérationnels est en place pour générer une action rapide et cohérente une fois l’interprétation et la déconnexion manuelles fournies. Utiliser les notifications d’alerte pour permettre une identification rapide des problèmes nécessitant une interprétation manuelle

• Créez des allocations dans les sprints d’ingénierie pour apporter des améliorations incrémentielles aux alertes afin de garantir que de nouveaux scénarios d’échec qui n’ont pas encore été pris en compte peuvent être entièrement pris en charge dans de nouvelles actions automatisées.

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

Opérations d’action prédictive et d’IA (AIOps)

Les modèles Machine Learning peuvent être appliqués pour mettre en corrélation et hiérarchiser les données opérationnelles, ce qui permet de recueillir des informations critiques relatives au filtrage du « bruit » des alertes excessives et à la prédiction des problèmes avant qu’ils n’entraînent un impact, ainsi qu’à accélérer la réponse aux incidents quand c’est le cas.

Plus spécifiquement, 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 actuellement (détecter), la quantification de la raison pour laquelle le problème se produit (diagnostic) ou la signalisation de 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é système et de métriques de productivité DevOps, afin de hiérarchiser en fonction de l’impact sur l’entreprise. Les actions effectuées peuvent elles-mêmes être infusées dans le système par le biais d’une boucle de rétroaction qui entraîne davantage le modèle sous-jacent pour améliorer l’efficacité.

Il existe plusieurs technologies analytiques dans Azure, telles que Azure Synapse et Azure Databricks, qui peuvent être utilisées pour créer 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 mener des actions prédictives, en se concentrant sur Azure Synapse qui réduit les frictions en réunissant le meilleur des services de données d’Azure et de nouvelles fonctionnalités puissantes.

AIOps est utilisé pour générer des actions prédictives, interpréter et corrélater des signaux opérationnels complexes observés sur une période prolongée afin de mieux répondre aux problèmes et de les prévenir avant qu’ils ne se produisent.

Remarques 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 Spark Synapse avec des bibliothèques telles que 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 entraîné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 à Azure Data Factory outils pour extraire, transformer et charger (ETL) ou ingérer des données dans des pipelines d’orchestration.

• Azure Synapse active 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’analyse des données du pool Synapse Spark.

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

  • Synapse orchestre la lecture des données et leur envoi à 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 propose différents outils pour faciliter la préparation des données, notamment Apache Spark, Synapse Notebooks et pools SQL serverless avec T-SQL et des visualisations intégrées.

• Les modèles ML qui ont été entraînés, opérationnels et déployés peuvent être utilisés pour le scoring 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 d’alimenter en continu des données d’observabilité quasiment en temps réel dans des modèles d’inférence ML en temps réel.

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

Recommandations de conception

• Assurez-vous que toutes les ressources Azure et les composants d’application 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 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 des alertes historiques et les stocker dans le stockage froid pour que les données opérationnelles les utilisent ensuite dans des 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 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’apprentissage 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 à des fins d’entraînement, d’opérationnalisation, de scoring et d’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 administrative et d’intégration. Envisagez la détection des anomalies pour signaler rapidement les écarts inattendus dans les flux de données d’observabilité.

Étape suivante

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

Déploiement et test