Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Observabilité multi-AZ
Pour pouvoir évacuer une zone de disponibilité lors d'un événement isolé dans une seule zone de disponibilité, vous devez d'abord être en mesure de détecter que la panne est, en fait, isolée dans une seule zone de disponibilité. Cela nécessite une visibilité très fidèle du comportement du système dans chaque zone de disponibilité. De nombreux AWS services fournissent out-of-the-box des indicateurs qui fournissent des informations opérationnelles sur vos ressources. Par exemple, Amazon EC2 fournit de nombreux indicateurs tels que CPU l'utilisation, les lectures et écritures sur disque, ainsi que le trafic réseau entrant et sortant.
Toutefois, lorsque vous créez des charges de travail qui utilisent ces services, vous avez besoin de plus de visibilité que ces indicateurs standard. Vous souhaitez avoir une visibilité sur l'expérience client fournie par votre charge de travail. En outre, vos indicateurs doivent être alignés sur les zones de disponibilité dans lesquelles ils sont produits. C'est l'information dont vous avez besoin pour détecter les défaillances de gris observables de manière différentielle. Ce niveau de visibilité nécessite des instruments.
L'instrumentation nécessite l'écriture d'un code explicite. Ce code doit notamment enregistrer la durée des tâches, compter le nombre d'éléments réussis ou échoués, collecter des métadonnées sur les demandes, etc. Vous devez également définir des seuils à l'avance pour définir ce qui est considéré comme normal et ce qui ne l'est pas. Vous devez définir les objectifs et les différents seuils de gravité relatifs à la latence, à la disponibilité et au nombre d'erreurs dans votre charge de travail. L'article de la bibliothèque Amazon Builders' [Instrumenting distributed systems for operational visibility](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) fournit un certain nombre de bonnes pratiques.
Les métriques doivent être générées à la fois du côté serveur et du côté client. L'une des meilleures pratiques pour générer des indicateurs côté client et comprendre l'expérience client consiste à utiliser [des canaries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), un logiciel qui analyse régulièrement votre charge de travail et enregistre les indicateurs.
En plus de produire ces indicateurs, vous devez également comprendre leur contexte. Pour ce faire, vous pouvez utiliser des [dimensions](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension). Les dimensions confèrent à une métrique une identité unique et aident à expliquer ce que les métriques vous indiquent. Pour les métriques utilisées pour identifier les défaillances de votre charge de travail (par exemple, latence, disponibilité ou nombre d'erreurs), vous devez utiliser des dimensions alignées sur vos [limites d'isolation des pannes](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html).
Par exemple, si vous exécutez un service Web dans une région, dans plusieurs zones de disponibilité, à l'aide d'un framework Web [M odel-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC), vous devez utiliser`Region`,, [https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)`Controller``Action`, et `InstanceId` comme dimensions pour vos ensembles de dimensions (si vous utilisiez des microservices, vous pouvez utiliser le nom du service et la HTTP méthode au lieu du contrôleur et des noms d'action). Cela est dû au fait que vous vous attendez à ce que les différents types de défaillances soient isolés par ces limites. Vous ne vous attendriez pas à ce qu'un bogue dans le code de votre service Web affectant sa capacité à répertorier des produits ait également un impact sur la page d'accueil. De même, vous ne vous attendez pas à ce qu'un EBS volume complet sur une seule EC2 instance empêche EC2 les autres instances de diffuser votre contenu Web. La dimension ID de zone de disponibilité vous permet d'identifier de manière cohérente les impacts liés à la zone de disponibilité. Comptes AWS Vous pouvez trouver l'ID de zone de disponibilité dans vos charges de travail de différentes manières. Reportez-vous à [Annexe A — Obtenir l'ID de la zone de disponibilité](appendix-a-getting-the-availability-zone-id.md) pour quelques exemples.
Bien que ce document utilise principalement Amazon EC2 comme ressource de calcul dans les exemples, il `InstanceId` pourrait être remplacé par un ID de conteneur pour les ressources de calcul [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AmazonECS) et [Amazon Elastic Kubernetes](https://aws.amazon.com/eks/) Service (EKSAmazon) en tant que composants de vos dimensions.
Vos canaris peuvent également utiliser`Controller`, `Action``AZ-ID`, et `Region` comme dimensions dans leurs métriques si vous disposez de points de terminaison zonaux pour votre charge de travail. Dans ce cas, alignez vos canaris pour qu'ils s'exécutent dans la zone de disponibilité qu'ils testent. Cela garantit que si un événement de zone de disponibilité isolé a un impact sur la zone de disponibilité dans laquelle votre Canary fonctionne, il n'enregistre pas de statistiques indiquant qu'une autre zone de disponibilité testée ne semble pas saine. [Par exemple, votre Canary peut tester chaque point de terminaison zonal pour un service situé derrière un Network Load Balancer NLB () ou un Application Load Balancer () en utilisant ALB ses noms de zone. DNS](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#dns-name)
![\[Schéma montrant un canari utilisant des CloudWatch Synthetics ou AWS Lambda une fonction testant chaque extrémité zonale d'un NLB\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/canary-testing-for-zonal-impact.png)
En produisant des métriques avec ces dimensions, vous pouvez établir des [ CloudWatch alarmes Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) qui vous avertissent lorsque des changements de disponibilité ou de latence surviennent dans ces limites. Vous pouvez également analyser rapidement ces données à l'aide de [tableaux de bord](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). Pour utiliser efficacement les métriques et les journaux, Amazon CloudWatch propose le [format de métrique intégré](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) (EMF) qui vous permet d'intégrer des métriques personnalisées aux données des journaux. CloudWatchextrait automatiquement les métriques personnalisées afin que vous puissiez les visualiser et les analyser. AWS fournit plusieurs [bibliothèques clientes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) pour différents langages de programmation, ce qui facilite la prise en mainEMF. Ils peuvent être utilisés avec AmazonEC2, Amazon ECS EKS [AWS Lambda](https://aws.amazon.com/lambda/), Amazon et dans des environnements sur site. Grâce aux statistiques intégrées à vos journaux, vous pouvez également utiliser [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) pour créer des graphiques de séries chronologiques présentant les données des contributeurs. Dans ce scénario, nous pourrions afficher des données groupées par dimensions telles que `AZ-ID``InstanceId`, ou `Controller` ainsi que tout autre champ du journal tel que `SuccessLatency` ou`HttpResponseCode`.
```
{
"_aws": {
"Timestamp": 1634319245221,
"CloudWatchMetrics": [
{
"Namespace": "workloadname/frontend",
"Metrics": [
{ "Name": "2xx", "Unit": "Count" },
{ "Name": "3xx", "Unit": "Count" },
{ "Name": "4xx", "Unit": "Count" },
{ "Name": "5xx", "Unit": "Count" },
{ "Name": "SuccessLatency", "Unit": "Milliseconds" }
],
"Dimensions": [
[ "Controller", "Action", "Region", "AZ-ID", "InstanceId"],
[ "Controller", "Action", "Region", "AZ-ID"],
[ "Controller", "Action", "Region"]
]
}
],
"LogGroupName": "/loggroupname"
},
"CacheRefresh": false,
"Host": "use1-az2-name.example.com",
"SourceIp": "34.230.82.196",
"TraceId": "|e3628548-42e164ee4d1379bf.",
"Path": "/home",
"OneBox": false,
"Controller": "Home",
"Action": "Index",
"Region": "us-east-1",
"AZ-ID": "use1-az2",
"InstanceId": "i-01ab0b7241214d494",
"LogGroupName": "/loggroupname",
"HttpResponseCode": 200,
"2xx": 1,
"3xx": 0,
"4xx": 0,
"5xx": 0,
"SuccessLatency": 20
}
```
Ce journal comporte trois ensembles de dimensions. Ils progressent par ordre de granularité, de l'instance à la zone de disponibilité puis à la région (`Controller`et `Action` sont toujours inclus dans cet exemple). Ils permettent de créer des alarmes sur l'ensemble de votre charge de travail qui indiquent quand une action spécifique du contrôleur a un impact sur une seule instance, dans une seule zone de disponibilité ou dans un ensemble Région AWS. Ces dimensions sont utilisées pour le nombre de mesures de HTTP réponse 2xx, 3xx, 4xx et 5xx, ainsi que pour la latence des mesures de demande réussies (si la demande échoue, elle enregistre également une métrique de latence de demande échouée). Le journal enregistre également d'autres informations telles que le HTTP chemin, l'adresse IP source du demandeur et indique si cette demande a nécessité l'actualisation du cache local. Ces points de données peuvent ensuite être utilisés pour calculer la disponibilité et la latence de chaque charge API de travail fournie.
**Remarque sur l'utilisation des codes de HTTP réponse pour les mesures de disponibilité**
En général, vous pouvez considérer les réponses 2xx et 3xx comme des réussites, et les réponses 5xx comme des échecs. Les codes de réponse 4xx se situent quelque part entre les deux. Ils sont généralement produits en raison d'une erreur du client. Peut-être qu'un paramètre est hors de portée, ce qui entraîne une [réponse 400](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes), ou qu'il demande quelque chose qui n'existe pas, ce qui entraîne une réponse 404. Vous ne compteriez pas ces réponses par rapport à la disponibilité de votre charge de travail. Cependant, cela peut également être le résultat d'un bogue dans le logiciel.
Par exemple, si vous avez introduit une validation des entrées plus stricte qui rejette une demande qui aurait abouti auparavant, la réponse 400 peut être considérée comme une baisse de disponibilité. Ou peut-être que vous limitez le client et que vous renvoyez une réponse 429. Bien que la limitation d'un client protège votre service afin de maintenir sa disponibilité, du point de vue du client, le service n'est pas disponible pour traiter sa demande. Vous devrez décider si les codes de réponse 4xx font partie de votre calcul de disponibilité.
Bien que cette section ait décrit l'utilisation CloudWatch comme moyen de collecter et d'analyser des métriques, ce n'est pas la seule solution que vous pouvez utiliser. Vous pouvez également choisir d'envoyer des métriques vers Amazon Managed Service for Prometheus et Amazon Managed Grafana, une table Amazon DynamoDB, ou d'utiliser une solution de surveillance tierce. L'essentiel est que les métriques produites par votre charge de travail doivent contenir le contexte des limites d'isolation des pannes de votre charge de travail.
Avec des charges de travail qui produisent des métriques dont les dimensions sont alignées sur les limites d'isolation des pannes, vous pouvez créer une observabilité qui détecte les défaillances isolées dans les zones de disponibilité. Les sections suivantes décrivent trois approches complémentaires permettant de détecter les défaillances résultant de la détérioration d'une seule zone de disponibilité.
**Topics**
+ [Détection des défaillances à l'aide d'alarmes CloudWatch composites](failure-detection-with-cloudwatch-composite-alarms.md)
+ [Détection des défaillances grâce à la détection des valeurs aberrantes](failure-detection-using-outlier-detection.md)
+ [Détection des défaillances des ressources zonales à instance unique](failure-detection-of-single-instance-zonal-resources.md)
+ [Récapitulatif](summary.md)
# Détection des défaillances à l'aide d'alarmes CloudWatch composites
Dans CloudWatch les métriques, chaque ensemble de dimensions est une métrique unique, et vous pouvez créer une CloudWatch alarme pour chacune d'elles. Vous pouvez ensuite créer des [alarmes CloudWatch composites Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) pour agréger ces métriques.
Afin de détecter un impact avec précision, les exemples présentés dans ce paper utiliseront deux structures CloudWatch d'alarme différentes pour chaque dimension sur laquelle l'alarme est réglée. Chaque alarme utilisera une **période** d'une minute, ce qui signifie que la métrique est évaluée une fois par minute. La première approche consiste à utiliser trois points de données violés consécutifs en réglant les **périodes d'évaluation** et les points de **données d'alarme à** trois, ce qui signifie un impact pendant trois minutes au total. La deuxième approche consiste à utiliser un « M sur N » lorsque 3 points de données dans une fenêtre de cinq minutes sont violés en réglant les **périodes d'évaluation** à cinq et les **points de données à alarme à** trois. Cela permet de détecter un signal constant, ainsi qu'un signal qui fluctue sur une courte période. Les durées et le nombre de points de données contenus ici sont des suggestions. Utilisez des valeurs adaptées à vos charges de travail.
## Détectez l'impact dans une seule zone de disponibilité
À l'aide de cette construction, considérez une charge de travail qui utilise `Controller``Action`,`InstanceId`,`AZ-ID`, et `Region` en tant que dimensions. La charge de travail comporte deux contrôleurs, Products et Home, et une action par contrôleur, List et Index respectivement. Il opère dans trois zones de disponibilité de la `us-east-1` région. Vous devez créer deux alarmes de disponibilité pour chacune `Controller` et `Action` une combinaison dans chaque zone de disponibilité, ainsi que deux alarmes de latence pour chacune d'entre elles. Ensuite, vous pouvez éventuellement choisir de créer une alarme composite pour vérifier la disponibilité de chaque alarme `Controller` et d'`Action`une combinaison. Enfin, vous créez une alarme composite qui regroupe toutes les alarmes de disponibilité pour la zone de disponibilité. Cela est illustré dans la figure suivante pour une seule zone de disponibilité`use1-az1`, en utilisant l'alarme composite optionnelle pour chaque zone `Controller` et une `Action` combinaison (des alarmes similaires existeraient également pour les zones de `use1-az3` disponibilité `use1-az2` et, pour des raisons de simplicité, elles ne sont pas affichées).
![\[Schéma illustrant une structure d'alarme composite pour la disponibilité dans use1-az1\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-availability.png)
Vous pouvez également créer une structure d'alarme similaire pour la latence, comme indiqué dans la figure suivante.
![\[Schéma illustrant une structure d'alarme composite pour la latence dans use1-az1\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-latency.png)
Pour les autres figures de cette section, seules les alarmes `az1-latency` composites `az1-availability` et les alarmes seront affichées au niveau supérieur. Ces alarmes composites vous indiqueront si la disponibilité tombe en dessous ou si la latence augmente au-dessus des seuils définis dans une zone de disponibilité donnée pour une partie quelconque de votre charge de travail. `az1-availability` `az1-latency` Vous pouvez également envisager de mesurer le débit pour détecter l'impact qui empêche votre charge de travail dans une seule zone de disponibilité de recevoir du travail. Vous pouvez également intégrer les alarmes produites à partir des métriques émises par vos canaris dans ces alarmes composites. Ainsi, si le côté serveur ou le côté client constatent des impacts sur la disponibilité ou la latence, l'alarme créera une alerte.
## Assurez-vous que l'impact n'est pas régional
Un autre ensemble d'alarmes composites peut être utilisé pour garantir que seul un événement de zone de disponibilité isolé provoque l'activation de l'alarme. Pour ce faire, il faut s'assurer qu'une alarme composite de zone de disponibilité est dans l'`ALARM`état alors que les alarmes composites des autres zones de disponibilité sont dans `OK` cet état. Cela se traduira par une alarme composite par zone de disponibilité que vous utilisez. Un exemple est illustré dans la figure suivante (n'oubliez pas qu'il existe des alarmes de latence et de disponibilité dans `use1-az2` et`use1-az3`,`az2-latency`, et `az2-availability` `az3-latency``az3-availability`, qui ne sont pas illustrées pour des raisons de simplicité).
![\[Schéma illustrant une structure d'alarme composite pour détecter un impact isolé à un seul AZ\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-impact.png)
## Assurez-vous que l'impact n'est pas causé par une seule instance
Une seule instance (ou un faible pourcentage de votre parc global) peut avoir un impact disproportionné sur les indicateurs de disponibilité et de latence, ce qui pourrait donner l'impression que l'ensemble de la zone de disponibilité est affectée, alors qu'en fait ce n'est pas le cas. Il est plus rapide et tout aussi efficace de supprimer une seule instance problématique que d'évacuer une zone de disponibilité.
Les instances et les conteneurs sont généralement traités comme des ressources éphémères, fréquemment remplacés par des services tels que. [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) Il est difficile de créer une nouvelle CloudWatch alarme à chaque fois qu'une nouvelle instance est créée (mais cela est certainement possible en utilisant les [hooks de cycle de vie d'[Amazon EventBridge](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) ou d'Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)). Vous pouvez plutôt utiliser [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) pour identifier le nombre de contributeurs aux métriques de disponibilité et de latence.
Par exemple, pour une application HTTP Web, vous pouvez créer une règle pour identifier les principaux contributeurs pour 5 x HTTP réponses dans chaque zone de disponibilité. Cela permettra d'identifier les instances qui contribuent à une baisse de disponibilité (notre indicateur de disponibilité défini ci-dessus est déterminé par la présence d'erreurs 5xx). À l'aide de l'exemple du EMF journal, créez une règle à l'aide de la clé de`InstanceId`. Filtrez ensuite le journal en fonction du `HttpResponseCode` champ. Cet exemple est une règle pour la zone de `use1-az1` disponibilité.
```
{
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.InstanceId",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"GreaterThan": 499
},
{
"Match": "$.HttpStatusCode",
"LessThan": 600
},
{
"Match": "$.AZ-ID",
"In": ["use1-az1"]
},
],
"Keys": [
"$.InstanceId"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
"/loggroupname"
],
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
}
}
```
CloudWatch des alarmes peuvent également être créées en fonction de ces règles. Vous pouvez créer des alarmes en fonction des règles de Contributor Insights à l'aide des [mathématiques métriques](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) et de la `INSIGHT_RULE_METRIC` fonction associée à la `UniqueContributors` métrique. Vous pouvez également créer des règles supplémentaires pour Contributor Insights avec des CloudWatch alarmes pour des indicateurs tels que la latence ou le nombre d'erreurs, en plus de celles relatives à la disponibilité. Ces alarmes peuvent être utilisées avec les alarmes composites d'impact de zone de disponibilité isolées afin de garantir que des instances uniques n'activent pas l'alarme. La métrique de la règle d'analyse pour `use1-az1` peut ressembler à ce qui suit :
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
Vous pouvez définir une alarme lorsque cette métrique est supérieure à un seuil ; dans cet exemple, deux. Il est activé lorsque le nombre de contributeurs uniques aux réponses 5xx dépasse ce seuil, ce qui indique que l'impact provient de plus de deux instances. La raison pour laquelle cette alarme utilise une comparaison supérieure à plutôt qu'inférieure à est de s'assurer qu'une valeur nulle pour les contributeurs uniques ne déclenche pas l'alarme. Cela indique que l'impact *ne provient pas* d'une seule instance. Ajustez ce seuil en fonction de votre charge de travail individuelle. Un guide général consiste à faire de ce chiffre 5 % ou plus du total des ressources de la zone de disponibilité. Plus de 5 % de vos ressources touchées présentent une signification statistique, compte tenu de la taille de l'échantillon suffisante.
## Tout assembler
La figure suivante montre la structure d'alarme composite complète pour une seule zone de disponibilité :
![\[Schéma illustrant une structure d'alarme composite complète pour déterminer l'impact mono-AZ\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-complete.png)
L'alarme composite finale est activée lorsque l'alarme composite indiquant un impact de zone de disponibilité isolé lié à la latence ou à `ALARM` la disponibilité est activée et lorsque l'alarme basée sur la règle Contributor Insights pour cette même zone de disponibilité est également active `ALARM` (ce qui signifie que l'impact est supérieur à une seule instance). `use1-az1-isolated-impact` `use1-az1-aggregate-alarm` `not-single-instance-use1-az1` Vous devez créer cette pile d'alarmes pour chaque zone de disponibilité utilisée par votre charge de travail.
Vous pouvez joindre une alerte [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (AmazonSNS) à cette dernière alarme. Toutes les alarmes précédentes sont configurées sans action. L'alerte pourrait informer un opérateur par e-mail pour qu'il lance une enquête manuelle. Cela pourrait également initier l'automatisation pour évacuer la zone de disponibilité. Cependant, attention à l'automatisation des bâtiments pour répondre à ces alertes. Après l'évacuation d'une zone de disponibilité, les taux d'erreur accrus devraient être atténués et l'alarme devrait revenir à son `OK` état normal. Si un impact se produit dans une autre zone de disponibilité, il est possible que l'automatisation évacue une deuxième ou une troisième zone de disponibilité, supprimant ainsi toute la capacité disponible de la charge de travail. L'automatisation doit vérifier si une évacuation a déjà été effectuée avant de prendre des mesures. Vous devrez peut-être également augmenter les ressources dans d'autres zones de disponibilité pour qu'une évacuation soit réussie.
Lorsque vous ajoutez de nouveaux contrôleurs ou actions à votre application MVC Web, à un nouveau microservice ou, en général, à toute fonctionnalité supplémentaire que vous souhaitez surveiller séparément, il vous suffit de modifier quelques alarmes dans cette configuration. Vous allez créer de nouvelles alarmes de disponibilité et de latence pour cette nouvelle fonctionnalité, puis les ajouter aux alarmes composites de disponibilité et de latence alignées sur la zone de disponibilité appropriée, `az1-latency` comme `az1-availability` dans l'exemple que nous avons utilisé ici. Les autres alarmes composites restent statiques une fois configurées. Cela simplifie le processus d'intégration de nouvelles fonctionnalités avec cette approche.
# Détection des défaillances grâce à la détection des valeurs aberrantes
Une lacune par rapport à l'approche précédente peut survenir lorsque vous constatez des taux d'erreur élevés dans plusieurs zones de disponibilité pour une raison *non corrélée*. Imaginez un scénario dans lequel des EC2 instances sont déployées dans trois zones de disponibilité et où votre seuil d'alarme de disponibilité est de 99 %. Ensuite, une défaillance d'une seule zone de disponibilité se produit, isolant de nombreuses instances et faisant chuter la disponibilité dans cette zone à 55 %. Dans le même temps, mais dans une autre zone de disponibilité, une EC2 instance unique épuise tout le stockage de son EBS volume et ne peut plus écrire de fichiers journaux. Cela l'amène à renvoyer des erreurs, mais il passe tout de même les tests de santé de l'équilibreur de charge, car ceux-ci ne déclenchent pas l'écriture d'un fichier journal. Cela se traduit par une baisse de la disponibilité à 98 % dans cette zone de disponibilité. Dans ce cas, votre seule alarme d'impact de zone de disponibilité ne s'activera pas car vous constatez un impact sur la disponibilité dans plusieurs zones de disponibilité. Cependant, vous pouvez tout de même atténuer la quasi-totalité de l'impact en évacuant la zone de disponibilité altérée.
Dans certains types de charges de travail, il est possible que vous rencontriez régulièrement des erreurs dans toutes les zones de disponibilité où l'indicateur de disponibilité précédent peut ne pas être utile. Prenons par AWS Lambda exemple. AWS permet aux clients de créer leur propre code à exécuter dans la fonction Lambda. Pour utiliser le service, vous devez télécharger votre code dans un ZIP fichier, y compris les dépendances, et définir le point d'entrée de la fonction. Mais parfois, les clients se trompent sur cette partie. Par exemple, ils peuvent oublier une dépendance critique dans le ZIP fichier ou mal saisir le nom de la méthode dans la définition de la fonction Lambda. Cela empêche l'invocation de la fonction et entraîne une erreur. AWS Lambda voit ce genre d'erreurs tout le temps, mais cela n'indique pas que quelque chose ne va pas nécessairement mal. Cependant, un problème tel qu'une altération de la zone de disponibilité peut également provoquer l'apparition de ces erreurs.
Pour détecter un signal dans ce type de bruit, vous pouvez utiliser la détection des valeurs aberrantes afin de déterminer s'il existe un écart statistiquement significatif dans le nombre d'erreurs entre les zones de disponibilité. Bien que nous constations des erreurs dans plusieurs zones de disponibilité, en cas de défaillance réelle de l'une d'entre elles, nous pouvons nous attendre à un taux d'erreur beaucoup plus élevé dans cette zone de disponibilité par rapport aux autres, voire à un taux potentiellement bien inférieur. Mais combien plus haut ou plus bas ?
L'une des méthodes de cette analyse consiste à utiliser un test du [Khi carré](https://en.wikipedia.org/wiki/Chi-squared_test) (*x* 2) pour détecter les différences statistiquement significatives dans les taux d'erreur entre les zones de disponibilité (il existe de [nombreux algorithmes différents pour effectuer la détection des valeurs aberrantes](https://dataprocessing.aixcape.org/DataPreprocessing/DataCleaning/OutlierDetection/index.html)). Voyons comment fonctionne le test du chi carré.
Un test du Khi deux évalue la probabilité qu'une certaine distribution des résultats se produise. Dans ce cas, nous nous intéressons à la distribution des erreurs sur un ensemble défini deAZs. Pour cet exemple, pour faciliter les calculs, considérez quatre zones de disponibilité.
Établissez d'abord l'*hypothèse nulle*, qui définit ce que vous pensez être le résultat par défaut. Dans ce test, l'hypothèse nulle est que vous vous attendez à ce que les erreurs soient réparties uniformément dans chaque zone de disponibilité. Générez ensuite l'*hypothèse alternative, selon* laquelle les erreurs ne sont pas réparties uniformément, ce qui indique une altération de la zone de disponibilité. Vous pouvez désormais tester ces hypothèses à l'aide des données de vos indicateurs. À cette fin, vous allez échantillonner vos statistiques sur une fenêtre de cinq minutes. Supposons que vous obteniez 1 000 points de données publiés dans cette fenêtre, dans lesquels vous voyez 100 erreurs au total. Vous vous attendez à ce qu'avec une distribution uniforme, les erreurs se produisent 25 % du temps dans chacune des quatre zones de disponibilité. Supposons que le tableau suivant montre ce que vous attendiez par rapport à ce que vous avez réellement vu.
*Tableau 1 : Erreurs attendues et réelles observées*
| AZ | Expected | Réel |
| --- | --- | --- |
| use1-az1 | 25 | 20 |
| use1-az2 | 25 | 20 |
| use1-az3 | 25 | 25 |
| use1-az4 | 25 | 35 |
Donc, vous voyez qu'en réalité, la distribution n'est pas uniforme. Cependant, vous pourriez penser que cela s'est produit en raison d'un certain degré de hasard dans les points de données que vous avez échantillonnés. Il existe un certain niveau de probabilité que ce type de distribution se produise dans l'échantillon tout en supposant que l'hypothèse nulle est vraie. Cela amène à la question suivante : Quelle est la probabilité d'obtenir un résultat au moins aussi extrême ? Si cette probabilité est inférieure à un seuil défini, vous rejetez l'hypothèse nulle. Pour être [https://en.wikipedia.org/wiki/Statistical_significance](https://en.wikipedia.org/wiki/Statistical_significance), cette probabilité doit être de 5 % ou moins. 1
1 Craparo, Robert M. (2007). « Niveau de signification ». Dans Salkind, Neil J. Encyclopedia of Measurement and Statistics 3. Thousand Oaks, CA : SAGE Publications. pages 889 à 891. ISBN1-412-91611-9.
Comment calculez-vous la probabilité d'un tel résultat ? Vous utilisez la statistique *x 2* qui fournit des distributions très bien étudiées et qui peut être utilisée pour déterminer la probabilité d'obtenir un résultat aussi extrême ou plus extrême à l'aide de cette formule.
![\[Formules pour E ii, O et X 2\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas1.png)
Dans notre exemple, cela se traduit par :
![\[Formules pour E ii, O et X 2 utilisant notre exemple, pour obtenir une réponse de 6.\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas2.png)
Alors, qu'est-ce `6` que cela signifie en termes de probabilité ? Vous devez examiner une distribution du chi carré avec le degré de liberté approprié. La figure suivante montre plusieurs distributions du Khi carré pour différents degrés de liberté.
![\[Graphique montrant les distributions du Khi carré pour différents degrés de liberté\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/chi-squared-distributions.png)
Le degré de liberté est calculé comme étant inférieur d'un au nombre de choix du test. Dans ce cas, étant donné qu'il existe quatre zones de disponibilité, le degré de liberté est de trois. Ensuite, vous voulez connaître l'aire sous la courbe (l'intégrale) pour *x ≥ 6* sur le diagramme *k = 3*. Vous pouvez également utiliser un tableau précalculé avec les valeurs couramment utilisées pour obtenir une approximation de cette valeur.
*Tableau 2 : Valeurs critiques du Khi au carré*
| Degrés de liberté | Probabilité inférieure à la valeur critique | | **0,75** | **0,90** | **0,95** | **0,99** | **0,999** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 1,323 | 2,706 | 3,841 | 6,635 | 10,828 |
| 2 | 2,773 | 4,605 | 5,991 | 9,210 | 13,816 |
| 3 | 4,108 | 6,251 | 7,815 | 11,345 | 16,266 |
| 4 | 5,385 | 7,779 | 9,488 | 13,277 | 18,467 |
Pour trois degrés de liberté, la valeur du Khi carré de six se situe entre les colonnes de probabilité de 0,75 et 0,9. Cela signifie qu'il y a plus de 10 % de chances que cette distribution se produise, ce qui n'est pas inférieur au seuil de 5 %. Par conséquent, vous acceptez l'*hypothèse nulle* et déterminez qu'il *n'y a pas* de différence statistiquement significative dans les taux d'erreur entre les zones de disponibilité.
L'exécution d'un test de statistiques du Khi carré n'est pas prise en charge de manière native dans les mathématiques CloudWatch métriques. Vous devrez donc collecter les mesures d'erreur applicables CloudWatch et exécuter le test dans un environnement informatique tel que Lambda. Vous pouvez décider d'effectuer ce test au niveau d'un MVC contrôleur/action ou d'un microservice individuel, ou au niveau de la zone de disponibilité. Vous devez déterminer si une altération de la zone de disponibilité affecterait de la même manière chaque contrôleur/action ou microservice, ou si une DNS défaillance peut avoir un impact sur un service à faible débit et non sur un service à haut débit, ce qui pourrait masquer l'impact une fois agrégé. Dans les deux cas, sélectionnez les dimensions appropriées pour créer la requête. Le niveau de granularité aura également un impact sur les CloudWatch alarmes que vous créez.
Collectez la métrique du nombre d'erreurs pour chaque AZ et contrôleur/action dans une fenêtre temporelle spécifiée. Tout d'abord, calculez le résultat du test du Khi deux comme étant vrai (il y avait un biais statistiquement significatif) ou faux (il n'y en avait pas, c'est-à-dire que l'hypothèse nulle est valable). Si le résultat est faux, publiez un point de données égal à 0 dans votre flux de mesures pour obtenir des résultats au chi-carré pour chaque zone de disponibilité. Si le résultat est vrai, publiez un point de données de 1 pour la zone de disponibilité avec les erreurs les plus éloignées de la valeur attendue et un 0 pour les autres (voir un [Annexe B — Exemple de calcul du Khi deux](appendix-b-example-chi-squared-calculation.md) exemple de code pouvant être utilisé dans une fonction Lambda). Vous pouvez suivre la même approche que les alarmes de disponibilité précédentes en créant une alarme CloudWatch métrique de 3 lignes et une alarme métrique de 3 sur 5 CloudWatch en fonction des points de données produits par la fonction Lambda. Comme dans les exemples précédents, cette approche peut être modifiée pour utiliser plus ou moins de points de données dans une fenêtre plus ou moins longue.
Ajoutez ensuite ces alarmes à votre alarme de disponibilité de zone de disponibilité existante pour la combinaison contrôleur/action, illustrée dans la figure suivante.
![\[Schéma illustrant l'intégration du test de statistiques du Khi deux avec des alarmes composites\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/statistics-test-with-composite-alarms.png)
Comme indiqué précédemment, lorsque vous intégrez une nouvelle fonctionnalité à votre charge de travail, il vous suffit de créer les alarmes CloudWatch métriques appropriées spécifiques à cette nouvelle fonctionnalité et de mettre à jour le niveau suivant de la hiérarchie composite des alarmes pour inclure ces alarmes. Le reste de la structure de l'alarme reste statique.
# Détection des défaillances des ressources zonales à instance unique
Dans certains cas, vous pouvez avoir une seule instance active d'une ressource zonale, le plus souvent des systèmes qui nécessitent un composant d'écriture unique tel qu'une base de données relationnelle (telle qu'AmazonRDS) ou un cache distribué (tel qu'[Amazon ElastiCache (Redis OSS](https://aws.amazon.com/elasticache/redis/))). Si une seule défaillance de la zone de disponibilité affecte la zone de disponibilité dans laquelle se trouve la ressource principale, elle peut avoir un impact sur chaque zone de disponibilité qui accède à la ressource. Cela pourrait entraîner le franchissement des seuils de disponibilité dans chaque zone de disponibilité, ce qui signifie que la première approche ne permettrait pas d'identifier correctement la source d'impact de la zone de disponibilité unique. En outre, vous constaterez probablement des taux d'erreur similaires dans chaque zone de disponibilité, ce qui signifie que l'analyse des valeurs aberrantes ne détectera pas non plus le problème. Cela signifie que vous devez implémenter une observabilité supplémentaire pour détecter spécifiquement ce scénario.
Il est probable que la ressource qui vous préoccupe produise ses propres indicateurs concernant son état de santé, mais lors d'une détérioration de la zone de disponibilité, il se peut que cette ressource ne soit pas en mesure de fournir ces indicateurs. Dans ce scénario, vous devez créer ou mettre à jour des alarmes pour savoir si vous *volez à l'aveugle*. S'il existe des métriques importantes que vous surveillez déjà et que vous déclenchez une alarme, vous pouvez configurer l'alarme pour traiter les [données manquantes comme des](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) violations. Cela vous aidera à savoir si la ressource cesse de communiquer des données et si elle peut être incluse dans la même ressource *d'affilée et si elle peut être utilisée dans* *les alarmes m sur n* utilisées précédemment.
Il est également possible que, dans certains indicateurs indiquant l'état de santé de la ressource, celle-ci publie un point de données de valeur nulle en l'absence d'activité. Si la déficience empêche les interactions avec la ressource, vous ne pouvez pas utiliser l'approche des données manquantes pour ce type de mesures. Vous ne voulez probablement pas non plus vous alarmer si la valeur est nulle, car il peut y avoir des scénarios légitimes où elle se situe dans les limites des seuils normaux. La meilleure approche pour détecter ce type de problème consiste à utiliser des métriques produites par les ressources utilisant cette dépendance. Dans ce cas, nous voulons détecter l'impact dans *plusieurs* zones de disponibilité à l'aide d'alarmes composites. Ces alarmes doivent utiliser une poignée de catégories de métriques critiques liées à la ressource. Voici quelques exemples :
+ **Débit** : taux d'unités de travail entrantes. Il peut s'agir de transactions, de lectures, d'écritures, etc.
+ **Disponibilité** — Mesurez le nombre d'unités de travail réussies par rapport à celles qui ont échoué.
+ **Latence** : mesurez plusieurs percentiles de latence pour garantir la réussite du travail effectué dans le cadre d'opérations critiques.
Une fois encore, vous pouvez créer les alarmes métriques *in a row* *et m sur n* pour chaque métrique de chaque catégorie de métrique que vous souhaitez mesurer. Comme auparavant, elles peuvent être combinées dans une alarme composite afin de déterminer que cette ressource partagée est la source d'impact sur l'ensemble des zones de disponibilité. Vous souhaitez être en mesure d'identifier l'impact sur plusieurs zones de disponibilité grâce aux alarmes composites, mais il n'est pas nécessaire que l'impact concerne *toutes les* zones de disponibilité. La structure d'alarme composite de haut niveau pour ce type d'approche est illustrée dans la figure suivante.
![\[Schéma illustrant un exemple de création d'alarmes pour détecter l'impact sur plusieurs zones de disponibilité causé par une seule ressource\]](http://docs.aws.amazon.com/fr_fr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)
Vous remarquerez que ce diagramme est moins prescriptif quant au type d'alarmes métriques à utiliser et à la hiérarchie des alarmes composites. En effet, la découverte de ce type de problème peut être difficile et nécessitera une attention particulière aux bons signaux pour la ressource partagée. Il peut également être nécessaire d'évaluer ces signaux de manière spécifique.
En outre, vous devez remarquer que l'`primary-database-impact`alarme n'est pas associée à une zone de disponibilité spécifique. Cela est dû au fait que l'instance de base de données principale peut être située dans n'importe quelle zone de disponibilité qu'elle est configurée pour utiliser, et aucune CloudWatch métrique ne précise son emplacement. Lorsque vous voyez cette alarme s'activer, vous devez l'utiliser pour signaler un problème éventuel avec la ressource et lancer un basculement vers une autre zone de disponibilité, si cela n'a pas été fait automatiquement. Après avoir déplacé la ressource vers une autre zone de disponibilité, vous pouvez attendre de voir si votre alarme de zone de disponibilité isolée est activée, ou vous pouvez choisir d'invoquer de manière préventive votre plan d'évacuation de zone de disponibilité.
# Récapitulatif
Cette section décrit trois approches permettant d'identifier les déficiences liées à une seule zone de disponibilité. Chaque approche doit être utilisée conjointement pour fournir une vision globale de l'état de votre charge de travail.
L'approche d'alarme CloudWatch composite vous permet de détecter les problèmes pour lesquels l'écart de disponibilité n'est pas statistiquement significatif, par exemple des disponibilités de 98 % (zone de disponibilité altérée), 100 % et 99,99 %, qui ne sont pas causés par une seule ressource partagée.
La détection des valeurs aberrantes permet de détecter les défaillances d'une seule zone de disponibilité lorsque des erreurs non corrélées se produisent dans plusieurs zones de disponibilité qui dépassent toutes votre seuil d'alarme.
Enfin, l'identification de la dégradation d'une ressource zonale d'une instance unique permet de découvrir quand une altération d'une zone de disponibilité affecte une ressource partagée entre les zones de disponibilité.
Les alarmes résultant de chacun de ces modèles peuvent être combinées dans une hiérarchie d'alarmes CloudWatch composite afin de détecter les défaillances d'une seule zone de disponibilité qui ont un impact sur la disponibilité ou la latence de votre charge de travail.