Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Osservabilità Multi-AZ
Per poter evacuare una zona di disponibilità durante un evento isolato in una singola zona di disponibilità, è necessario innanzitutto essere in grado di rilevare che l'errore è, di fatto, isolato in una singola zona di disponibilità. Ciò richiede una visibilità ad alta fedeltà sul comportamento del sistema in ciascuna zona di disponibilità. Molti AWS servizi forniscono out-of-the-box metriche che forniscono informazioni operative sulle risorse. Ad esempio, Amazon EC2 fornisce numerose metriche come l'CPUutilizzo, le letture e le scritture del disco e il traffico di rete in entrata e in uscita.
Tuttavia, quando crei carichi di lavoro che utilizzano questi servizi, hai bisogno di maggiore visibilità rispetto ai soli parametri standard. Desideri avere visibilità sull'esperienza del cliente fornita dal tuo carico di lavoro. Inoltre, è necessario che le metriche siano allineate alle zone di disponibilità in cui vengono prodotte. Queste sono le informazioni necessarie per rilevare i guasti grigi osservabili in modo differenziale. Questo livello di visibilità richiede strumentazione.
La strumentazione richiede la scrittura di codice esplicito. Questo codice dovrebbe eseguire operazioni come registrare la durata delle attività, contare il numero di elementi riusciti o non riusciti, raccogliere metadati sulle richieste e così via. È inoltre necessario definire delle soglie in anticipo per definire cosa è considerato normale e cosa no. È necessario definire obiettivi e diverse soglie di gravità per la latenza, la disponibilità e il conteggio degli errori nel carico di lavoro. L'articolo di Amazon Builders' Library sulla [strumentazione dei sistemi distribuiti per la visibilità operativa](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) fornisce una serie di best practice.
Le metriche devono essere generate sia dal lato server che dal lato client. Una best practice per generare metriche lato client e comprendere l'esperienza del cliente consiste nell'utilizzare [Canaries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), un software che analizza regolarmente il carico di lavoro e registra i parametri.
Oltre a produrre queste metriche, devi anche comprenderne il contesto. Un modo per farlo consiste nell'utilizzare le [dimensioni](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension). Le dimensioni conferiscono a una metrica un'identità unica e aiutano a spiegare cosa ti dicono le metriche. [Per le metriche utilizzate per identificare gli errori nel carico di lavoro (ad esempio, latenza, disponibilità o conteggio degli errori), è necessario utilizzare dimensioni che si allineino ai limiti di isolamento degli errori.](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)
Ad esempio, se si esegue un servizio Web in una regione, in più zone di disponibilità, utilizzando un framework web [M odel-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC), è necessario utilizzare`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`, e `InstanceId` come dimensioni per i set di dimensioni (se si utilizzavano microservizi, è possibile utilizzare il nome e il HTTP metodo del servizio anziché i nomi del controller e delle azioni). Questo perché ci si aspetta che diversi tipi di errori vengano isolati entro questi limiti. Non ti aspetteresti che un bug nel codice del tuo servizio web che influisca sulla sua capacità di elencare i prodotti influisca anche sulla home page. Analogamente, non ci si aspetterebbe che un EBS volume completo su una singola EC2 istanza influisca sulla pubblicazione dei contenuti web da parte di altre EC2 istanze. La dimensione ID della zona di disponibilità è ciò che consente di identificare gli impatti relativi alla zona di disponibilità in modo coerente su tutto il territorio. Account AWS Puoi trovare l'ID della zona di disponibilità nei tuoi carichi di lavoro in diversi modi. [Appendice A — Ottenere l'ID della zona di disponibilità](appendix-a-getting-the-availability-zone-id.md)Per alcuni esempi, fare riferimento a.
Sebbene questo documento utilizzi principalmente Amazon EC2 come risorsa di calcolo negli esempi, `InstanceId` potrebbe essere sostituito con un ID contenitore per le risorse di calcolo [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AmazonECS) e [Amazon Elastic Kubernetes](https://aws.amazon.com/eks/) Service EKS (Amazon) come componenti delle tue dimensioni.
I vostri canarini possono anche utilizzare `Controller` `Action``AZ-ID`, e `Region` come dimensioni nelle loro metriche se disponete di endpoint zonali per il vostro carico di lavoro. In questo caso, allinea i canarini in modo che funzionino nella zona di disponibilità che stanno testando. In questo modo, se un evento isolato relativo alla zona di disponibilità ha un impatto sulla zona di disponibilità in cui si trova il canarino, non registri parametri che facciano apparire inadeguata una zona di disponibilità diversa da quella testata. [Ad esempio, il tuo canary può testare ogni endpoint zonale per un servizio basato su Network Load Balancer () o Application Load Balancer NLB () utilizzando i relativi nomi di zonaALB. DNS](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#dns-name)
![\[Diagramma che mostra un canarino in esecuzione su CloudWatch Synthetics o una AWS Lambda funzione che verifica ogni endpoint zonale di un NLB\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/canary-testing-for-zonal-impact.png)
Producendo metriche con queste dimensioni, puoi stabilire [ CloudWatch allarmi Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) che ti avvisano quando si verificano cambiamenti di disponibilità o latenza entro tali limiti. [Puoi anche analizzare rapidamente tali dati utilizzando i dashboard.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html) Per utilizzare sia le metriche che i log in modo efficiente, Amazon CloudWatch offre il [formato metrico incorporato](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) (EMF) che consente di incorporare metriche personalizzate nei dati di registro. CloudWatchestrae automaticamente le metriche personalizzate in modo da poterle visualizzare e generare allarmi in base ad esse. AWS fornisce diverse [librerie client](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) per diversi linguaggi di programmazione che semplificano l'avvio. EMF Possono essere utilizzati con AmazonEC2, Amazon ECS EKS [AWS Lambda](https://aws.amazon.com/lambda/), Amazon e ambienti locali. Con le metriche integrate nei tuoi log, puoi anche utilizzare [Amazon CloudWatch Contributor Insights per creare grafici di serie temporali che mostrano i dati dei contributori](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html). In questo scenario, potremmo visualizzare i dati raggruppati per dimensioni come `AZ-ID``InstanceId`, o insieme a qualsiasi altro campo del registro `Controller` come o. `SuccessLatency` `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
}
```
Questo registro ha tre set di dimensioni. Procedono in ordine di granularità, da un'istanza alla zona di disponibilità all'altra (`Controller`e `Action` sono sempre inclusi in questo esempio). Supportano la creazione di allarmi per tutto il carico di lavoro che indicano quando c'è un impatto su un'azione specifica del controller in una singola istanza, in una singola zona di disponibilità o all'interno di un insieme. Regione AWS Queste dimensioni vengono utilizzate per il conteggio delle metriche di HTTP risposta 2xx, 3xx, 4xx e 5xx, nonché per la latenza per le metriche delle richieste riuscite (se la richiesta fallisce, viene registrata anche una metrica per la latenza delle richieste non riuscite). Il registro registra anche altre informazioni come il HTTP percorso, l'IP di origine del richiedente e se questa richiesta ha richiesto l'aggiornamento della cache locale. Questi punti dati possono quindi essere utilizzati per calcolare la disponibilità e la latenza di ogni elemento fornito API dal carico di lavoro.
**Una nota sull'utilizzo dei codici di HTTP risposta per le metriche di disponibilità**
In genere, puoi considerare le risposte 2xx e 3xx come riuscite e 5xx come errori. I codici di risposta 4xx si collocano da qualche parte nel mezzo. Di solito vengono prodotti a causa di un errore del client. Forse un parametro non è compreso nell'intervallo e porta a una [risposta 400](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes), oppure stanno richiedendo qualcosa che non esiste, con il risultato di una risposta 404. Queste risposte non verranno conteggiate in base alla disponibilità del carico di lavoro. Tuttavia, questo potrebbe anche essere il risultato di un bug nel software.
Ad esempio, se hai introdotto una convalida degli input più rigorosa che rifiuta una richiesta che prima avrebbe avuto successo, la risposta 400 potrebbe essere considerata un calo della disponibilità. O forse stai limitando il cliente e restituendo una risposta 429. La limitazione di un cliente protegge il servizio e ne mantiene la disponibilità, ma dal punto di vista del cliente il servizio non è disponibile per elaborare la sua richiesta. Dovrai decidere se i codici di risposta 4xx rientrano o meno nel calcolo della disponibilità.
Sebbene in questa sezione sia stato descritto l'utilizzo CloudWatch come metodo per raccogliere e analizzare le metriche, non è l'unica soluzione che puoi utilizzare. Puoi anche scegliere di inviare i parametri ad Amazon Managed Service for Prometheus e Amazon Managed Grafana, a una tabella Amazon DynamoDB o utilizzare una soluzione di monitoraggio di terze parti. La chiave è che le metriche prodotte dal carico di lavoro devono contenere un contesto relativo ai limiti di isolamento dei guasti del carico di lavoro.
Con carichi di lavoro che producono metriche con dimensioni allineate ai limiti di isolamento dei guasti, è possibile creare un'osservabilità che rilevi i guasti isolati nelle zone di disponibilità. Le sezioni seguenti descrivono tre approcci complementari per rilevare i guasti derivanti dal danneggiamento di una singola zona di disponibilità.
**Topics**
+ [Rilevamento dei guasti con allarmi compositi CloudWatch](failure-detection-with-cloudwatch-composite-alarms.md)
+ [Rilevamento dei guasti mediante rilevamento dei valori anomali](failure-detection-using-outlier-detection.md)
+ [Rilevamento dei guasti delle risorse zonali a istanza singola](failure-detection-of-single-instance-zonal-resources.md)
+ [Riepilogo](summary.md)
# Rilevamento dei guasti con allarmi compositi CloudWatch
Nelle CloudWatch metriche, ogni set di dimensioni è una metrica unica e puoi creare un allarme su ognuna CloudWatch di esse. Puoi quindi creare [allarmi CloudWatch compositi Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) per aggregare questi parametri.
Per rilevare con precisione l'impatto, gli esempi di questo paper utilizzeranno due diverse strutture di CloudWatch allarme per ogni dimensione su cui viene impostato l'allarme. Ogni allarme utilizzerà un **periodo** di un minuto, il che significa che la metrica viene valutata una volta al minuto. Il primo approccio prevede l'utilizzo di tre punti dati consecutivi di violazione impostando i **periodi di valutazione** e i **datapoint su Allarme su tre, ovvero un impatto per un totale** di tre minuti. **Il secondo approccio prevede l'utilizzo di un valore «M su N» in caso di violazione di 3 punti dati qualsiasi in una finestra di cinque minuti, impostando i **periodi di valutazione** su cinque e i datapoints su Alarm su tre.** Ciò offre la capacità di rilevare un segnale costante, oltre a uno che oscilla per un breve periodo. Le durate temporali e il numero di punti dati qui contenuti sono solo un suggerimento. Utilizzate valori adatti ai vostri carichi di lavoro.
## Rileva l'impatto in una singola zona di disponibilità
Utilizzando questo costrutto, considera un carico di lavoro che utilizza`Controller`, `Action` `InstanceId``AZ-ID`, e `Region` come dimensioni. Il carico di lavoro ha due controller, Products e Home, e un'azione per controller, rispettivamente List e Index. Funziona in tre zone di disponibilità nella `us-east-1` regione. È possibile creare due allarmi di disponibilità per ciascuno `Controller` e `Action` una combinazione in ciascuna zona di disponibilità, nonché due allarmi di latenza per ciascuno. Quindi, puoi facoltativamente scegliere di creare un allarme composito per la disponibilità per ciascuna combinazione. `Controller` `Action` Infine, crei un allarme composito che aggrega tutti gli allarmi di disponibilità per la zona di disponibilità. Questo è illustrato nella figura seguente per una singola zona di disponibilità`use1-az1`, utilizzando l'allarme composito opzionale per ogni `Controller` `Action` combinazione (esisterebbero allarmi simili anche per le zone di `use1-az3` disponibilità `use1-az2` e, ma non sono mostrati per semplicità).
![\[Diagramma che mostra una struttura composita di allarmi per la disponibilità in use1-az1\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-availability.png)
È inoltre necessario creare una struttura di allarme simile anche per quanto riguarda la latenza, illustrata nella figura riportata di seguito.
![\[Un diagramma che mostra una struttura di allarme composita per la latenza in use1-az1\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-latency.png)
Per il resto delle figure di questa sezione, al `az1-availability` livello superiore verranno mostrati solo gli allarmi `az1-latency` compositi. Questi allarmi compositi, `az1-availability` e`az1-latency`, ti diranno se la disponibilità scende al di sotto o la latenza supera le soglie definite in una particolare zona di disponibilità per qualsiasi parte del tuo carico di lavoro. Potresti anche prendere in considerazione la possibilità di misurare la velocità effettiva per rilevare l'impatto che impedisce al carico di lavoro in una singola zona di disponibilità di ricevere lavoro. Puoi integrare anche gli allarmi prodotti dalle metriche emesse dai canarini in questi allarmi compositi. In questo modo, se il lato server o il lato client riscontrano un impatto sulla disponibilità o sulla latenza, l'allarme creerà un avviso.
## Assicurati che l'impatto non sia regionale
È possibile utilizzare un altro set di allarmi compositi per garantire che solo un evento isolato della zona di disponibilità provochi l'attivazione dell'allarme. Ciò viene eseguito assicurando che un allarme composito della zona di disponibilità sia nello `ALARM` stato mentre gli allarmi compositi per le altre zone di disponibilità siano nello `OK` stato. Ciò si tradurrà in un allarme composito per ogni zona di disponibilità utilizzata. Un esempio è illustrato nella figura seguente (ricordate che ci sono allarmi per la latenza e la disponibilità in `use1-az2` and`use1-az3`,`az2-latency`,`az2-availability`, e `az3-latency``az3-availability`, che non sono illustrati per semplicità).
![\[Un diagramma che mostra una struttura composita di allarme per rilevare l'impatto isolato in una singola AZ\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-impact.png)
## Assicurati che l'impatto non sia causato da una singola istanza
Una singola istanza (o una piccola percentuale del parco macchine complessivo) può avere un impatto sproporzionato sulle metriche di disponibilità e latenza, tale da far sembrare che l'intera zona di disponibilità ne risenta, mentre in realtà non lo è. Rimuovere una singola istanza problematica è più veloce ed efficace che evacuare una zona di disponibilità.
Le istanze e i contenitori vengono in genere trattati come risorse effimere, spesso sostituiti da servizi come. [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) È difficile creare un nuovo CloudWatch allarme ogni volta che viene creata una nuova istanza (ma sicuramente possibile utilizzando gli hook del [ciclo di vita di [Amazon EventBridge](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)). Puoi invece utilizzare [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) per identificare la quantità di persone che contribuiscono alle metriche di disponibilità e latenza.
Ad esempio, per un'applicazione HTTP Web, è possibile creare una regola per identificare i principali contributori per 5xx HTTP risposte in ogni zona di disponibilità. Questo identificherà quali istanze stanno contribuendo a un calo della disponibilità (la nostra metrica di disponibilità definita sopra è determinata dalla presenza di errori 5xx). Utilizzando l'esempio del EMF log, create una regola utilizzando una chiave di. `InstanceId` Quindi, filtra il registro in base al `HttpResponseCode` campo. Questo esempio è una regola per la zona di `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 gli allarmi possono essere creati anche in base a queste regole. Puoi creare allarmi in base alle regole di Contributor Insights utilizzando la [matematica metrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) e la funzione con la `INSIGHT_RULE_METRIC` metrica. `UniqueContributors` Puoi anche creare regole di Contributor Insights aggiuntive con CloudWatch allarmi per metriche come la latenza o il conteggio degli errori oltre a quelli relativi alla disponibilità. Questi allarmi possono essere utilizzati con gli allarmi compositi isolati di Availability Zone Impact per garantire che le singole istanze non attivino l'allarme. La metrica per la regola Insights `use1-az1` potrebbe essere simile alla seguente:
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
È possibile definire un allarme quando questa metrica è superiore a una soglia; per questo esempio, due. Viene attivato quando i contributori unici delle risposte 5xx superano tale soglia, a indicare che l'impatto proviene da più di due istanze. Il motivo per cui questo allarme utilizza un confronto maggiore anziché minore di è per assicurarsi che un valore zero per i contributori unici non faccia scattare l'allarme. *Ciò indica che l'impatto non proviene da una singola istanza.* Modifica questa soglia per il tuo carico di lavoro individuale. Una guida generale prevede che questo numero sia pari o superiore al 5% delle risorse totali nella zona di disponibilità. Oltre il 5% delle risorse interessate mostra una rilevanza statistica, se il campione è sufficientemente ampio.
## Mettere tutto insieme
La figura seguente mostra la struttura composita completa degli allarmi per una singola zona di disponibilità:
![\[Un diagramma che mostra una struttura di allarme composita completa per determinare l'impatto Single-AZ\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-complete.png)
L'allarme composito finale,`use1-az1-isolated-impact`, viene attivato quando l'allarme composito che indica l'impatto isolato della zona di disponibilità dalla latenza o dalla disponibilità è attivo e quando anche l'allarme basato sulla regola Contributor Insights per la stessa zona di disponibilità è attivo (vale a `ALARM` dire che l'impatto riguarda più di una singola istanza). `use1-az1-aggregate-alarm` `ALARM` `not-single-instance-use1-az1` Dovresti creare questa pila di allarmi per ogni zona di disponibilità utilizzata dal tuo carico di lavoro.
Puoi allegare un avviso [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (AmazonSNS) a questo allarme finale. Tutti gli allarmi precedenti sono configurati senza alcuna azione. L'avviso potrebbe avvisare un operatore via e-mail di avviare un'indagine manuale. Potrebbe anche avviare l'automazione per evacuare la zona di disponibilità. Tuttavia, un avvertimento sull'automazione degli edifici per rispondere a questi avvisi. Dopo l'evacuazione di una zona di disponibilità, il risultato dovrebbe essere che l'aumento dei tassi di errore venga mitigato e l'allarme ritorni a uno stato. `OK` Se si verifica un impatto in un'altra zona di disponibilità, è possibile che l'automazione riesca a evacuare una seconda o terza zona di disponibilità, rimuovendo potenzialmente tutta la capacità disponibile del carico di lavoro. L'automazione dovrebbe verificare se è già stata eseguita un'evacuazione prima di intraprendere qualsiasi azione. Potrebbe inoltre essere necessario scalare le risorse in altre zone di disponibilità prima che l'evacuazione abbia successo.
Quando aggiungi nuovi controller o azioni alla tua app MVC web, o un nuovo microservizio o, in generale, qualsiasi funzionalità aggiuntiva che desideri monitorare separatamente, devi solo modificare alcuni allarmi in questa configurazione. Creerai nuovi allarmi di disponibilità e latenza per quella nuova funzionalità e poi li aggiungerai agli allarmi compositi di disponibilità e latenza allineati alla zona di disponibilità e latenza appropriati, come `az1-availability` nell'esempio che abbiamo `az1-latency` usato qui. Gli allarmi compositi rimanenti rimangono statici dopo essere stati configurati. Ciò semplifica l'integrazione di nuove funzionalità con questo approccio.
# Rilevamento dei guasti mediante rilevamento dei valori anomali
*Una lacuna rispetto all'approccio precedente potrebbe verificarsi quando si riscontrano tassi di errore elevati in più zone di disponibilità che si verificano per un motivo non correlato.* Immagina uno scenario in cui EC2 le istanze siano distribuite in tre zone di disponibilità e la soglia di allarme di disponibilità sia del 99%. Quindi, si verifica un danno a una singola zona di disponibilità, che isola molte istanze e fa scendere la disponibilità in quella zona al 55%. Allo stesso tempo, ma in una zona di disponibilità diversa, una singola EC2 istanza esaurisce tutto lo storage del EBS volume e non è più in grado di scrivere file di log. Ciò fa sì che inizi a restituire errori, ma supera comunque i controlli di integrità del load balancer perché questi non attivano la scrittura di un file di registro. Ciò si traduce in una riduzione della disponibilità al 98% in quella zona di disponibilità. In questo caso, l'allarme di impatto di una singola zona di disponibilità non si attiverebbe perché si riscontra un impatto sulla disponibilità in più zone di disponibilità. Tuttavia, è comunque possibile mitigare quasi tutto l'impatto evacuando la zona di disponibilità compromessa.
In alcuni tipi di carichi di lavoro, è possibile che si verifichino errori coerenti in tutte le zone di disponibilità, per cui la precedente metrica di disponibilità potrebbe non essere utile. Prendiamo ad AWS Lambda esempio. AWS consente ai clienti di creare il proprio codice da eseguire nella funzione Lambda. Per utilizzare il servizio, è necessario caricare il codice in un ZIP file, comprese le dipendenze, e definire il punto di ingresso alla funzione. Ma a volte i clienti sbagliano questa parte, ad esempio potrebbero dimenticare una dipendenza critica nel ZIP file o digitare erroneamente il nome del metodo nella definizione della funzione Lambda. Ciò fa sì che la funzione non venga richiamata e genera un errore. AWS Lambda vede continuamente questo tipo di errori, ma non è indicativo che qualcosa sia necessariamente malsano. Tuttavia, anche qualcosa come una compromissione della zona di disponibilità potrebbe causare la comparsa di questi errori.
Per individuare il segnale in presenza di questo tipo di rumore, è possibile utilizzare il rilevamento dei valori anomali per determinare se esiste una differenza statisticamente significativa nel numero di errori tra le zone di disponibilità. Sebbene riscontriamo errori in più zone di disponibilità, se si verificasse davvero un errore in una di esse, ci aspetteremmo di vedere un tasso di errore molto più elevato in quella zona di disponibilità rispetto alle altre, o potenzialmente molto inferiore. Ma quanto più alto o più basso?
Un modo per eseguire questa analisi consiste nell'utilizzare un test [chi-squared](https://en.wikipedia.org/wiki/Chi-squared_test) (*χ* 2) per rilevare differenze statisticamente significative nei tassi di errore tra le zone di disponibilità (esistono [molti algoritmi diversi per](https://dataprocessing.aixcape.org/DataPreprocessing/DataCleaning/OutlierDetection/index.html) eseguire il rilevamento dei valori anomali). Diamo un'occhiata a come funziona il test chi-squared.
Un test chi-squared valuta la probabilità che si verifichi una certa distribuzione dei risultati. In questo caso, siamo interessati alla distribuzione degli errori in un insieme definito di. AZs Per questo esempio, per semplificare i calcoli, considera quattro zone di disponibilità.
Innanzitutto, stabilite l'*ipotesi nulla*, che definisce quello che ritenete sia il risultato predefinito. In questo test, l'ipotesi nulla è che ci si aspetti che gli errori vengano distribuiti uniformemente in ogni zona di disponibilità. Quindi, genera l'*ipotesi alternativa*, ovvero che gli errori non siano distribuiti in modo uniforme, il che indica una compromissione della zona di disponibilità. Ora puoi testare queste ipotesi utilizzando i dati delle tue metriche. A tal fine, campionerai le tue metriche in una finestra di cinque minuti. Supponiamo di ottenere 1000 punti dati pubblicati in quella finestra, in cui vengono visualizzati 100 errori totali. Ti aspetti che con una distribuzione uniforme gli errori si verifichino il 25% delle volte in ciascuna delle quattro zone di disponibilità. Supponiamo che la tabella seguente mostri ciò che ti aspettavi rispetto a ciò che hai effettivamente visto.
*Tabella 1: Errori previsti e errori effettivi rilevati*
| AZ | Expected (Atteso) | Effettivo |
| --- | --- | --- |
| use1-az1 | 25 | 20 |
| use1-az2 | 25 | 20 |
| use1-az3 | 25 | 25 |
| use1-az4 | 25 | 35 |
Quindi, vedete che la distribuzione in realtà non è uniforme. Tuttavia, potresti credere che ciò sia avvenuto a causa di un certo livello di casualità nei punti dati che hai campionato. Esiste un certo livello di probabilità che questo tipo di distribuzione si verifichi nel set di campioni e si presume comunque che l'ipotesi nulla sia vera. Ciò porta alla seguente domanda: qual è la probabilità di ottenere un risultato almeno così estremo? Se tale probabilità è inferiore a una soglia definita, si rifiuta l'ipotesi nulla. Per essere [https://en.wikipedia.org/wiki/Statistical_significance](https://en.wikipedia.org/wiki/Statistical_significance), questa probabilità deve essere pari o inferiore al 5%. 1
1 Craparo, Robert M. (2007). «Livello di significatività». In Salkind, Neil J. Enciclopedia della misurazione e della statistica 3. Thousand Oaks, CA: Pubblicazioni. pp. 889—891. SAGE ISBN1-412-91611-9.
Come si calcola la probabilità di questo risultato? Si utilizza la statistica *χ 2* che fornisce distribuzioni molto ben studiate e può essere utilizzata per determinare la probabilità di ottenere un risultato così estremo o più estremo utilizzando questa formula.
![\[Formule per Ei, O i e X 2\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas1.png)
Nel nostro esempio, ciò si traduce in:
![\[Formule per E ii, O e X 2 utilizzando il nostro esempio, ottenendo una risposta di 6.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas2.png)
Quindi, cosa `6` significa in termini di probabilità? È necessario considerare una distribuzione chi-quadrata con il giusto grado di libertà. La figura seguente mostra diverse distribuzioni chi-squared per diversi gradi di libertà.
![\[Grafico che mostra le distribuzioni chi-squared per diversi gradi di libertà\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/chi-squared-distributions.png)
Il grado di libertà viene calcolato come uno in meno rispetto al numero di scelte del test. In questo caso, poiché vi sono quattro zone di disponibilità, il grado di libertà è tre. Quindi, vuoi conoscere l'area sotto la curva (l'integrale) per *x ≥ 6* sul grafico *k = 3*. È inoltre possibile utilizzare una tabella precalcolata con valori di uso comune per approssimare tale valore.
*Tabella 2: Valori critici al quadrato di Chi*
| Gradi di libertà | Probabilità inferiore al valore critico | | **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 |
Per tre gradi di libertà, il valore chi-quadrato di sei rientra tra le colonne di probabilità 0,75 e 0,9. Ciò significa che esiste una probabilità superiore al 10% che si verifichi questa distribuzione, che non è inferiore alla soglia del 5%. Pertanto, si accetta l'*ipotesi nulla* e si stabilisce che *non* vi è una differenza statisticamente significativa nei tassi di errore tra le zone di disponibilità.
L'esecuzione di un test di statistica chi-squared non è supportata nativamente nella matematica CloudWatch metrica, quindi dovrai raccogliere le metriche di errore applicabili CloudWatch ed eseguire il test in un ambiente di calcolo come Lambda. Puoi decidere di eseguire questo test a livello di MVC Controller/Action o di microservizio individuale oppure a livello di zona di disponibilità. Dovrai valutare se una compromissione della zona di disponibilità influirebbe allo stesso modo su ogni controller/azione o microservizio o se qualcosa come un DNS guasto potrebbe avere un impatto su un servizio a basso throughput e non su un servizio a throughput elevato, che potrebbe mascherare l'impatto se aggregato. In entrambi i casi, selezionate le dimensioni appropriate per creare la query. Il livello di granularità influirà anche sugli CloudWatch allarmi risultanti che creerai.
Raccogli la metrica del conteggio degli errori per ogni AZ e Controller/Action in una finestra temporale specificata. Innanzitutto, calcola il risultato del test chi-squared come vero (c'era un'inclinazione statisticamente significativa) o falso (non c'era, cioè vale l'ipotesi nulla). Se il risultato è falso, pubblica un punto di dati pari a 0 nel flusso di metriche per i risultati chi-squared per ogni zona di disponibilità. Se il risultato è vero, pubblica un punto dati 1 per la zona di disponibilità con gli errori più lontani dal valore previsto e uno 0 per gli altri (fare riferimento a [Appendice B — Esempio di calcolo al quadrato](appendix-b-example-chi-squared-calculation.md) per un codice di esempio che può essere utilizzato in una funzione Lambda). È possibile seguire lo stesso approccio dei precedenti allarmi di disponibilità utilizzando la creazione di un allarme CloudWatch metrico a 3 righe e un allarme CloudWatch metrico a 3 su 5 in base ai punti dati prodotti dalla funzione Lambda. Come negli esempi precedenti, questo approccio può essere modificato per utilizzare più o meno punti dati in una finestra più o meno lunga.
Quindi, aggiungete questi allarmi all'allarme di disponibilità esistente della zona di disponibilità per la combinazione Controller e Azione, mostrata nella figura seguente.
![\[Diagramma che mostra l'integrazione del test statistico chi-squared con allarmi compositi\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/statistics-test-with-composite-alarms.png)
Come accennato in precedenza, quando si incorporano nuove funzionalità nel carico di lavoro, è sufficiente creare gli allarmi CloudWatch metrici appropriati specifici per quella nuova funzionalità e aggiornare il livello successivo nella gerarchia composita degli allarmi per includere tali allarmi. Il resto della struttura degli allarmi rimane statico.
# Rilevamento dei guasti delle risorse zonali a istanza singola
In alcuni casi, potresti avere una singola istanza attiva di una risorsa zonale, in genere sistemi che richiedono un componente a scrittura singola come un database relazionale (come AmazonRDS) o una cache distribuita (come [Amazon ElastiCache (Redis OSS](https://aws.amazon.com/elasticache/redis/))). Se una singola violazione della zona di disponibilità influisce sulla zona di disponibilità in cui si trova la risorsa principale, può avere un impatto su ogni zona di disponibilità che accede alla risorsa. Ciò potrebbe causare il superamento delle soglie di disponibilità in ogni zona di disponibilità, il che significa che il primo approccio non identificherebbe correttamente la singola fonte di impatto della zona di disponibilità. Inoltre, è probabile che si verifichino tassi di errore simili in ogni zona di disponibilità, il che significa che anche l'analisi dei valori anomali non rileverebbe il problema. Ciò significa che è necessario implementare un'osservabilità aggiuntiva per rilevare in modo specifico questo scenario.
È probabile che la risorsa che ti preoccupa produca le proprie metriche sullo stato di salute, ma durante un danneggiamento della zona di disponibilità quella risorsa potrebbe non essere in grado di fornire tali metriche. *In questo scenario, è necessario creare o aggiornare gli allarmi per sapere quando si vola alla cieca.* Se ci sono metriche importanti che stai già monitorando e che attivano l'allarme, puoi configurare l'allarme in modo da considerare i [dati mancanti come violazioni](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data). Questo ti aiuterà a sapere se la risorsa smette di riportare i dati e può essere inclusa nella stessa *in una riga* e tra *gli allarmi utilizzati in* precedenza.
È anche possibile che, in alcune metriche che indicano lo stato della risorsa, questa pubblichi un punto dati a valore zero in assenza di attività. Se la compromissione impedisce le interazioni con la risorsa, non è possibile utilizzare l'approccio basato sui dati mancanti per questo tipo di metriche. Inoltre, probabilmente non vorrai allarmarti se il valore è pari a zero, poiché potrebbero esserci scenari legittimi in cui tale valore rientri nelle soglie normali. L'approccio migliore per rilevare questo tipo di problema consiste nell'utilizzare le metriche prodotte dalle risorse che utilizzano questa dipendenza. In questo caso vogliamo rilevare l'impatto in *più* zone di disponibilità utilizzando allarmi compositi. Questi allarmi dovrebbero utilizzare una manciata di categorie di metriche critiche relative alla risorsa. Di seguito sono elencati alcuni esempi:
+ **Produttività**: la velocità delle unità di lavoro in entrata. Potrebbero trattarsi di transazioni, letture, scritture e così via.
+ **Disponibilità**: misura il numero di unità di lavoro riuscite rispetto a quelle fallite.
+ **Latenza**: misura più percentili di latenza per eseguire con successo il lavoro svolto in operazioni critiche.
Ancora una volta, puoi creare allarmi metrici *consecutivi* e *m su n* per ogni metrica in ogni categoria metrica che desideri misurare. Come in precedenza, questi possono essere combinati in un allarme composito per determinare che questa risorsa condivisa è la fonte dell'impatto sulle zone di disponibilità. Si desidera essere in grado di identificare l'impatto su più di una zona di disponibilità con gli allarmi compositi, ma l'impatto non deve necessariamente riguardare *tutte le* zone di disponibilità. La struttura di allarme composita di alto livello per questo tipo di approccio è illustrata nella figura seguente.
![\[Diagramma che mostra un esempio di creazione di allarmi per rilevare l'impatto su più zone di disponibilità causato da una singola risorsa\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)
Noterai che questo diagramma è meno prescrittivo sul tipo di allarmi metrici da utilizzare e sulla gerarchia degli allarmi compositi. Questo perché scoprire questo tipo di problema può essere difficile e richiederà un'attenzione particolare ai segnali giusti per la risorsa condivisa. Potrebbe essere necessario valutare tali segnali anche in modi specifici.
Inoltre, dovresti notare che l'`primary-database-impact`allarme non è associato a una zona di disponibilità specifica. Questo perché l'istanza del database principale può trovarsi in qualsiasi zona di disponibilità per cui è configurata e non esiste una CloudWatch metrica che specifichi dove si trova. Quando vedi questo allarme attivarsi, dovresti usarlo come segnale che potrebbe esserci un problema con la risorsa e avviare un failover verso un'altra zona di disponibilità, se non è stato eseguito automaticamente. Dopo aver spostato la risorsa in un'altra zona di disponibilità, puoi aspettare e vedere se l'allarme isolato della zona di disponibilità è attivato oppure puoi scegliere di richiamare preventivamente il tuo piano di evacuazione della zona di disponibilità.
# Riepilogo
Questa sezione descrive tre approcci per aiutare a identificare i problemi legati a una singola zona di disponibilità. Ciascun approccio deve essere utilizzato congiuntamente per fornire una visione olistica dello stato del carico di lavoro.
L'approccio CloudWatch composito agli allarmi consente di individuare problemi in cui la disparità di disponibilità non è statisticamente significativa, ad esempio disponibilità del 98% (la zona di disponibilità compromessa), del 100% e del 99,99%, il che non è causata da un'unica risorsa condivisa.
Il rilevamento dei valori anomali aiuta a rilevare i problemi relativi a una singola zona di disponibilità in cui si verificano errori non correlati in più zone di disponibilità e tutte superano la soglia di allarme.
Infine, l'identificazione del degrado di una risorsa zonale a istanza singola aiuta a scoprire quando una violazione della zona di disponibilità influisce su una risorsa condivisa tra le zone di disponibilità.
Gli allarmi risultanti da ciascuno di questi schemi possono essere combinati in una gerarchia CloudWatch composita di allarmi per scoprire quando si verificano problemi in una singola zona di disponibilità e hanno un impatto sulla disponibilità o sulla latenza del carico di lavoro.