Collecter, interroger et visualiser les états d’intégrité
Pour représenter avec exactitude un modèle d’intégrité, vous devez collecter différents jeux de données dans le système. Les jeux de données comprennent les journaux et les métriques de performances des composants d’application et des ressources Azure sous-jacentes. L’idée est de mettre en corrélation les données entre jeux de données pour créer une représentation en couches de l’intégrité du système.
Instrumentation du code et de l’infrastructure
Un récepteur de données unifié est nécessaire pour que toutes les données opérationnelles soient stockées et disponibles à l’endroit où toutes les données de télémétrie sont collectées. Par exemple, quand un employé crée un commentaire dans son navigateur web, vous pouvez suivre cette opération et voir que la demande a transité par l’API du catalogue vers Azure Event Hubs. À partir de là, le processeur en arrière-plan a récupéré le commentaire et le stocke dans Azure Cosmos DB.
Azure Monitor Log Analytics sert de récepteur de données unifié Azure natif principal pour stocker et analyser les données opérationnelles :
Application Insights est l’outil APM (Application Performance Monitoring) recommandé pour tous les composants d’application afin de collecter les journaux, les métriques et les traces des applications. Application Insights est déployé dans une configuration basée sur un espace de travail dans chaque région.
Dans l’exemple d’application, Azure Functions est utilisé sur Microsoft .NET 6 pour ses services de back-end en raison de l’intégration native. Comme les applications de back-end existent déjà, Contoso Shoes crée uniquement une ressource Application Insights dans Azure et configure le paramètre
APPLICATIONINSIGHTS_CONNECTION_STRINGsur les deux applications de fonction. Le runtime Azure Functions inscrit automatiquement le fournisseur de journalisation Application Insights, pour que la télémétrie s’affiche dans Azure sans effort supplémentaire. Pour une journalisation plus personnalisée, vous pouvez utiliser l’interfaceILogger.Le jeu de données centralisé est un antimodèle pour les charges de travail stratégiques. Chaque région doit avoir son espace de travail Log Analytics dédié et une instance Application Insights. Pour les ressources globales, des instances distinctes sont recommandées. Pour voir le modèle d’architecture de base, consultez Modèle d’architecture pour les charges de travail stratégiques sur Azure.
Chaque couche doit envoyer des données au même espace de travail Log Analytics pour faciliter l’analyse et les calculs d’intégrité.
Requêtes de monitoring de l’intégrité
Log Analytics, Application Insights et Azure Data Explorer utilisent tous le Langage de requête Kusto (KQL) pour leurs requêtes. Vous pouvez utiliser KQL pour générer des requêtes, et utiliser des fonctions pour récupérer les métriques et calculer les scores d’intégrité.
Pour connaître les services individuels qui calculent l’état d’intégrité, consultez les exemples de requêtes suivants.
API Catalogue
L’exemple suivant illustre une requête d’API du catalogue :
let _maxAge = 2d; // Include data only from the last two days
let _timespanStart = ago(_maxAge); // Start time for the time span
let _timespanEnd = now(-2m); // Account for ingestion lag by stripping the last 2m
// For time frame, compare the averages to the following threshold values
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
"failureCount", 10, 50, // Failed requests, anything non-200, allow a few more than 0 for user-caused errors like 404s
"avgProcessingTime", 150, 500 // Average duration of the request, in ms
];
// Calculate average processing time for each request
let avgProcessingTime = AppRequests
| where AppRoleName startswith "CatalogService"
| where OperationName != "GET /health/liveness" // Liveness requests don't do any processing, including them would skew the results
| make-series Value = avg(DurationMs) default=0 on TimeGenerated from _timespanStart to _timespanEnd step 1m
| mv-expand TimeGenerated, Value
| extend TimeGenerated = todatetime(TimeGenerated), Value=toreal(Value), MetricName= 'avgProcessingTime';
// Calculate failed requests
let failureCount = AppRequests
| where AppRoleName startswith "CatalogService" // Liveness requests don't do any processing, including them would skew the results
| where OperationName != "GET /health/liveness"
| make-series Value=countif(Success != true) default=0 on TimeGenerated from _timespanStart to _timespanEnd step 1m
| mv-expand TimeGenerated, Value
| extend TimeGenerated = todatetime(TimeGenerated), Value=toreal(Value), MetricName= 'failureCount';
// Union all together and join with the thresholds
avgProcessingTime
| union failureCount
| lookup kind = inner Thresholds on MetricName
| extend IsYellow = iff(todouble(Value) > YellowThreshold and todouble(Value) < RedThreshold, 1, 0)
| extend IsRed = iff(todouble(Value) > RedThreshold, 1, 0)
| project-reorder TimeGenerated, MetricName, Value, IsYellow, IsRed, YellowThreshold, RedThreshold
| extend ComponentName="CatalogService"
Azure Key Vault
L’exemple suivant illustre une requête Azure Key Vault :
let _maxAge = 2d; // Include data only from the last two days
let _timespanStart = ago(_maxAge); // Start time for the time span
let _timespanEnd = now(-2m); // Account for ingestion lag by stripping the last 2m
// For time frame, compare the averages to the following threshold values
let Thresholds = datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
"failureCount", 3, 10 // Failure count on key vault requests
];
let failureStats = AzureDiagnostics
| where TimeGenerated > _timespanStart
| where ResourceProvider == "MICROSOFT.KEYVAULT"
// Ignore authentication operations that have a 401. This is normal when using Key Vault SDK. First an unauthenticated request is made, then the response is used for authentication
| where Category=="AuditEvent" and not (OperationName == "Authentication" and httpStatusCode_d == 401)
| where OperationName in ('SecretGet','SecretList','VaultGet') or '*' in ('SecretGet','SecretList','VaultGet')
// Exclude Not Found responses because these happen regularly during 'Terraform plan' operations, when Terraform checks for the existence of secrets
| where ResultSignature != "Not Found"
// Create ResultStatus with all the 'success' results bucketed as 'Success'
// Certain operations like StorageAccountAutoSyncKey have no ResultSignature; for now, also set to 'Success'
| extend ResultStatus = case ( ResultSignature == "", "Success",
ResultSignature == "OK", "Success",
ResultSignature == "Accepted", "Success",
ResultSignature);
failureStats
| make-series Value=countif(ResultStatus != "Success") default=0 on TimeGenerated from _timespanStart to _timespanEnd step 1m
| mv-expand TimeGenerated, Value
| extend TimeGenerated = todatetime(TimeGenerated), Value=toreal(Value), MetricName="failureCount", ComponentName="Keyvault"
| lookup kind = inner Thresholds on MetricName
| extend IsYellow = iff(todouble(Value) > YellowThreshold and todouble(Value) < RedThreshold, 1, 0)
| extend IsRed = iff(todouble(Value) > RedThreshold, 1, 0)
Score d’intégrité du service de catalogue
Finalement, vous pouvez lier différentes requêtes d’état d’intégrité pour calculer le score d’intégrité d’un composant. L’exemple de requête suivant montre comment calculer le score d’intégrité d’un service de catalogue :
CatalogServiceHealthStatus()
| union AksClusterHealthStatus()
| union KeyvaultHealthStatus()
| union EventHubHealthStatus()
| where TimeGenerated < ago(2m)
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed) by bin(TimeGenerated, 2m)
| extend HealthScore = 1 - (YellowScore * 0.25) - (RedScore * 0.5)
| extend ComponentName = "CatalogService", Dependencies="AKSCluster,Keyvault,EventHub" // These values are added to build the dependency visualization
| order by TimeGenerated desc
Conseil
Consultez d’autres exemples de requêtes dans le dépôt GitHub Azure Mission-Critical Online.
Configurer des alertes basées sur une requête
Les alertes déclenchent une attention immédiate sur les problèmes qui reflètent ou affectent l’état d’intégrité. Chaque fois qu’il y a un changement d’état d’intégrité, que ce soit un état dégradé (jaune) ou un état non sain (rouge), des notifications doivent être envoyées à l’équipe responsable. Définissez des alertes au niveau du nœud racine du modèle d’intégrité pour être averti immédiatement de tout changement de l’état d’intégrité de la solution au niveau de l’entreprise. Ensuite, vous pouvez observer les visualisations du modèle d’intégrité pour avoir plus d’informations et résoudre les problèmes.
L’exemple utilise des alertes Azure Monitor pour générer des actions automatiques en réponse aux changements de l’état d’intégrité d’application.
Utiliser des tableaux de bord pour la visualisation
La visualisation de votre modèle d’intégrité permet de comprendre rapidement l’effet d’une panne de composant sur l’ensemble du système. L’objectif final d’un modèle d’intégrité est de faciliter un diagnostic rapide en fournissant une vue informée des écarts par rapport à l’état stable.
Une façon courante de visualiser les informations d’intégrité du système est de combiner une vue en couches du modèle d’intégrité avec des fonctionnalités d’exploration de la télémétrie dans un tableau de bord.
La technologie de tableau de bord doit être en mesure de représenter le modèle d’intégrité. Les options les plus courantes sont les tableaux de bord Azure, Power BI et Azure Managed Grafana.