As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Observabilidade de multi-ZD
Para poder evacuar uma Zona de Disponibilidade durante um evento isolado em uma única Zona, primeiro você deve conseguir detectar se a falha está, de fato, isolada. Isso requer uma visibilidade muito precisa do comportamento do sistema em cada Zona de Disponibilidade. Muitos AWS serviços fornecem out-of-the-box métricas que fornecem informações operacionais sobre seus recursos. Por exemplo, a Amazon EC2 fornece várias métricas, como CPU utilização, leituras e gravações de disco e entrada e saída de tráfego de rede.
No entanto, ao criar workloads que usam esses serviços, você precisa de mais visibilidade do que apenas essas métricas padrão. Você quer visibilidade da experiência do cliente fornecida pela sua workload. Além disso, você precisa que suas métricas estejam alinhadas às Zonas de Disponibilidade onde elas estão sendo produzidas. Esse é o insight de que você precisa para detectar falhas cinzentas observáveis de maneira diferente. Esse nível de visibilidade requer instrumentação.
A instrumentação requer escrever código explícito. Esse código deve realizar ações como registrar a duração das tarefas, contar quantos itens foram bem-sucedidos ou falharam, coletar metadados sobre as solicitações e assim por diante. Você também precisa definir limites com antecedência para configurar o que é considerado normal e o que não é. Você precisa delinear objetivos e diferentes limites de severidade para latência, disponibilidade e contagens de erros na sua workload. O artigo da Amazon Builders’ Library [Instrumentando sistemas distribuídos para visibilidade operacional](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) apresenta várias práticas recomendadas.
As métricas devem ser geradas tanto do lado do servidor quanto do lado do cliente. Uma prática recomendada para gerar métricas do lado do cliente e entender a experiência do cliente é usar o [Canário](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html), um software que examina regularmente sua workload e registra as métricas.
Além de produzir essas métricas, você também precisa entender o contexto delas. Para isso, você pode usar [dimensões](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension). As dimensões dão à métrica uma identidade única e ajudam a explicar o que as métricas estão dizendo a você. Para métricas usadas para identificar falhas na sua workload (por exemplo, latência, disponibilidade ou contagem de erros), você precisa usar dimensões que se alinhem aos [limites de isolamento de falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html).
Por exemplo, se você estiver executando um serviço web em uma região, em várias zonas de disponibilidade, usando uma estrutura web [M odel-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC), você deve usar`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` como dimensões para seus conjuntos de dimensões (se estiver usando microsserviços, você pode usar o nome e o HTTP método do serviço em vez dos nomes do controlador e da ação). Isso ocorre porque você espera que diferentes tipos de falhas sejam isolados por esses limites. Você não esperaria que um bug no código do seu serviço web que afetasse sua capacidade de listar produtos também afetasse a página inicial. Da mesma forma, você não esperaria que um EBS volume completo em uma única EC2 instância afetasse a veiculação de seu conteúdo da web por outras EC2 instâncias. A dimensão ID da Zona de Disponibilidade é o que permite identificar os impactos relacionados à Zona de Disponibilidade de forma consistente em todas as Contas da AWS. Você pode encontrar o ID da Zona de Disponibilidade nas suas workloads de várias maneiras diferentes. Consulte [Apêndice A — Obtendo o ID da zona de disponibilidade](appendix-a-getting-the-availability-zone-id.md) para ver alguns exemplos.
Embora este documento use principalmente a Amazon EC2 como recurso computacional nos exemplos, `InstanceId` pode ser substituído por um ID de contêiner para os recursos computacionais do [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (AmazonECS) e do [Amazon Elastic Kubernetes](https://aws.amazon.com/eks/) Service EKS (Amazon) como componentes de suas dimensões.
Seus canários também podem usar `Controller`, `Action`, `AZ-ID` e `Region` como dimensões em suas métricas se você tiver endpoints zonais para sua workload. Nesse caso, alinhe seus canários para que sejam executados na Zona de Disponibilidade que estão testando. Isso garante que, se um evento isolado da Zona de Disponibilidade estiver afetando a Zona na qual seu canário está sendo executado, ele não registre métricas que façam com que uma Zona de Disponibilidade diferente sendo testada pareça não estar íntegra. [Por exemplo, seu canário pode testar cada endpoint zonal para um serviço por trás de um Network Load Balancer () ou Application Load Balancer NLB () usando seus nomes de zona. ALB DNS](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#dns-name)
![\[Diagrama mostrando um canário em execução no CloudWatch Synthetics ou AWS Lambda uma função testando cada extremidade zonal de um NLB\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/canary-testing-for-zonal-impact.png)
Ao produzir métricas com essas dimensões, você pode estabelecer [ CloudWatch alarmes da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) que o notificam quando mudanças na disponibilidade ou na latência ocorrerem dentro desses limites. Você também pode analisar rapidamente esses dados usando [painéis](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). Para usar métricas e registros de forma eficiente, a Amazon CloudWatch oferece o [formato de métrica incorporada](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) (EMF) que permite incorporar métricas personalizadas aos dados de registro. CloudWatchextrai automaticamente as métricas personalizadas para que você possa visualizá-las e alertá-las. AWS fornece várias [bibliotecas de cliente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) para diferentes linguagens de programação que facilitam o inícioEMF. Eles podem ser usados com Amazon EC2ECS, Amazon EKS [AWS Lambda](https://aws.amazon.com/lambda/), Amazon e ambientes locais. Com métricas incorporadas aos seus registros, você também pode usar o [Amazon CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) para criar gráficos de séries temporais que exibem dados dos colaboradores. Nesse cenário, podemos exibir dados agrupados por dimensões como `AZ-ID`, `InstanceId` ou `Controller`, bem como qualquer outro campo no log, como `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
}
```
Esse log tem três conjuntos de dimensões. Eles progridem em ordem de granularidade, da instância, à Zona de Disponibilidade e depois à Região (`Controller` e `Action` estão sempre incluídos neste exemplo). Eles oferecem suporte à criação de alarmes em toda a sua workload, que indicam quando há impacto em uma ação específica do controlador em uma única instância, em uma única Zona de Disponibilidade ou em toda a Região da AWS. Essas dimensões são usadas para a contagem das métricas de HTTP resposta 2xx, 3xx, 4xx e 5xx, bem como para a latência das métricas de solicitação bem-sucedida (se a solicitação falhar, ela também registraria uma métrica para a latência da solicitação com falha). O registro também registra outras informações, como o HTTP caminho, o IP de origem do solicitante e se essa solicitação exigiu que o cache local fosse atualizado. Esses pontos de dados podem então ser usados para calcular a disponibilidade e a latência de cada um fornecido API pela carga de trabalho.
**Uma observação sobre o uso de códigos de HTTP resposta para métricas de disponibilidade**
Normalmente, é possível considerar respostas 2xx e 3xx como bem-sucedidas e 5xx como falhas. Os códigos de resposta 4xx ficam em algum lugar intermediário. Normalmente, elas são produzidas devido a um erro do cliente. Talvez um parâmetro esteja fora do alcance, levando a uma [resposta 400](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes), ou talvez o cliente esteja solicitando algo que não existe, resultando em uma resposta 404. Você não contaria essas respostas com base na disponibilidade da sua workload. No entanto, isso também pode ser resultado de um bug no software.
Por exemplo, se você introduziu uma validação de entrada mais rígida, que rejeita uma solicitação que teria sido bem-sucedida antes, a resposta 400 pode contar como uma queda na disponibilidade. Ou talvez você esteja realizando controle de utilização do cliente e retornando uma resposta 429. Embora o controle de utilização proteja seu serviço para manter a disponibilidade, do ponto de vista do cliente, o serviço não está disponível para o processamento da solicitação. Você precisará decidir se os códigos de resposta 4xx fazem parte do cálculo da disponibilidade.
Embora esta seção tenha descrito o uso CloudWatch como forma de coletar e analisar métricas, essa não é a única solução que você pode usar. Você também pode optar por enviar métricas para o Amazon Managed Service for Prometheus, Amazon Managed Grafana, para uma tabela do Amazon DynamoDB ou usar uma solução de monitoramento de terceiros. O principal é: as métricas que sua workload produz devem conter contexto sobre os limites de isolamento de falhas da workload.
Com workloads que produzem métricas com dimensões alinhadas aos limites de isolamento de falhas, você pode criar uma observabilidade que detecte falhas isoladas de Zona de Disponibilidade. As seções a seguir descrevem três abordagens complementares para detectar falhas decorrentes do comprometimento de uma única Zona de Disponibilidade.
**Topics**
+ [Detecção de falhas com CloudWatch alarmes compostos](failure-detection-with-cloudwatch-composite-alarms.md)
+ [Detecção de falhas usando detecção de discrepâncias](failure-detection-using-outlier-detection.md)
+ [Detecção de falhas de recursos zonais de instância única](failure-detection-of-single-instance-zonal-resources.md)
+ [Resumo](summary.md)
# Detecção de falhas com CloudWatch alarmes compostos
Nas CloudWatch métricas, cada conjunto de dimensões é uma métrica exclusiva, e você pode criar um CloudWatch alarme para cada uma. Em seguida, você pode criar [alarmes CloudWatch compostos da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) para agregar essas métricas.
Para detectar com precisão o impacto, os exemplos deste paper usarão duas estruturas de CloudWatch alarme diferentes para cada dimensão configurada para ativar o alarme. Cada alarme usará um **período** de um minuto, o que significa que a métrica é avaliada uma vez por minuto. A primeira abordagem usará três pontos de dados de violação consecutivos, definindo os **Períodos de Avaliação** e os **Pontos de Dados para Alarme** como três, o que significa impacto por um total de três minutos. A segunda abordagem usará um “M de N” quando quaisquer 3 pontos de dados em uma janela de cinco minutos forem violados, definindo os **Períodos de Avaliação** como cinco e os **Pontos de Dados para Alarme** como três. Isso permite a detecção de um sinal constante, bem como um que flutua em um curto espaço de tempo. As durações e o número de pontos de dados contidos aqui são uma sugestão. Use valores que façam sentido para suas workloads.
## Detectar impacto em uma única Zona de Disponibilidade
Usando essa estrutura, considere uma workload que usa `Controller`, `Action`, `InstanceId`, `AZ-ID` e `Region` como dimensões. A workload tem dois controladores, Products e Home, e uma ação por controlador, List e Index, respectivamente. Ela opera em três Zonas de Disponibilidade na Região `us-east-1`. Você criaria dois alarmes de disponibilidade para cada combinação de `Controller` e `Action` em cada Zona de Disponibilidade, bem como dois alarmes de latência para cada um. Em seguida, você pode optar por criar um alarme composto para verificar a disponibilidade de cada combinação de `Controller` e `Action`. Por fim, você cria um alarme composto que agrega todos os alarmes de disponibilidade da Zona de Disponibilidade. Isso é mostrado na figura a seguir para uma única Zona de disponibilidade, `use1-az1`, usando o alarme composto opcional para cada combinação de `Controller` e `Action` (alarmes semelhantes também existiriam para as Zonas de disponibilidade `use1-az2` e `use1-az3`, mas não são mostrados para simplificar).
![\[Diagrama mostrando uma estrutura de alarme composta para disponibilidade em use1-az1\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-availability.png)
Você também construiria uma estrutura de alarme semelhante para latência, mostrada na figura a seguir.
![\[Diagrama mostrando uma estrutura de alarme composta para latência em use1-az1\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-latency.png)
Para o restante das figuras desta seção, somente os alarmes compostos `az1-availability` e `az1-latency` serão mostrados no nível superior. Esses alarmes, `az1-availability` e `az1-latency`, dirão se a disponibilidade ficar abaixo ou se a latência ultrapassar os limites definidos em uma Zona de Disponibilidade específica, em qualquer parte da sua workload. Você também pode considerar a medição do throughput para detectar o impacto que impede que sua workload em uma única Zona de disponibilidade receba trabalho. Também é possível integrar alarmes produzidos a partir das métricas emitidas por seus canários nesses alarmes compostos. Dessa forma, se o lado do servidor ou o lado do cliente perceberem impactos na disponibilidade ou na latência, o alarme criará um alerta.
## Confira se o impacto não é regional
Outro conjunto de alarmes compostos pode ser usado para garantir que somente um evento isolado da Zona de Disponibilidade ative o alarme. Para isso acontecer, um alarme composto da Zona de Disponibilidade é colocado no estado `ALARM` enquanto os alarmes compostos das outras Zonas de Disponibilidade são colocados no estado `OK`. Isso resultará em um alarme composto por Zona de Disponibilidade usada. Um exemplo é mostrado na figura a seguir (lembre-se de que há alarmes de latência e disponibilidade em `use1-az2` e `use1-az3`, `az2-latency`, `az2-availability`, `az3-latency` e `az3-availability`, que não estão ilustrados para simplificar).
![\[Um diagrama mostrando uma estrutura de alarme composto para detectar impactos isolados em uma única ZD\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-impact.png)
## Garanta que o impacto não seja causado por uma única instância
Uma única instância (ou uma pequena porcentagem de sua frota geral) pode causar um impacto desproporcional nas métricas de disponibilidade e latência, o que pode fazer com que toda a Zona de Disponibilidade pareça estar afetada, quando na verdade não está. É mais rápido e eficaz remover uma única instância problemática do que evacuar uma Zona de disponibilidade.
As instâncias e os contêineres geralmente são tratados como recursos efêmeros, frequentemente substituídos por serviços como [AWS Auto Scaling](https://aws.amazon.com/autoscaling/). É difícil criar um novo CloudWatch alarme toda vez que uma nova instância é criada (mas certamente é possível usando ganchos de [ciclo de vida [da Amazon EventBridge](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) ou do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)). Em vez disso, você pode usar o [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) para identificar a quantidade de colaboradores nas métricas de disponibilidade e latência.
Como exemplo, para um aplicativo HTTP web, você pode criar uma regra para identificar os principais colaboradores para 5xx HTTP respostas em cada zona de disponibilidade. Isso identificará quais instâncias estão contribuindo para uma queda na disponibilidade (nossa métrica de disponibilidade definida acima é determinada pela presença de erros 5xx). Usando o exemplo de EMF log, crie uma regra usando uma chave de`InstanceId`. Em seguida, filtre o log usando o campo `HttpResponseCode`. Este exemplo é uma regra para a Zona de Disponibilidade `use1-az1`.
```
{
"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 alarmes também podem ser criados com base nessas regras. Você pode criar alarmes com base nas regras do Contributor Insights usando [matemática de métrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) e a função `INSIGHT_RULE_METRIC` com a métrica `UniqueContributors`. Você também pode criar regras adicionais do Contributor Insights com CloudWatch alarmes para métricas como latência ou contagens de erros, além de alarmes de disponibilidade. Esses alarmes podem ser usados com os alarmes compostos de para impacto em uma Zona de Disponibilidade isolada, de forma a garantir que instâncias únicas não ativem o alarme. A métrica da regra de insights para `use1-az1` pode ser assim:
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
Você pode definir um alarme quando essa métrica ultrapassar um limite; neste exemplo, dois. Ele é ativado quando os colaboradores exclusivos das respostas 5xx ultrapassam esse limite, indicando que o impacto está vindo de mais de duas instâncias. O motivo para esse alarme usar uma comparação “maior que” em vez de “menor que” é para garantir que um valor zero para colaboradores exclusivos não acione o alarme. Isso indica que o impacto *não* vem de uma única instância. Ajuste esse limite para sua workload individual. Indicamos que esse número seja 5% ou mais do total de recursos na Zona de Disponibilidade. Mais de 5% dos seus recursos sendo afetados mostra significância estatística, considerando um tamanho amostral suficiente.
## Juntando tudo isso
A figura a seguir mostra a estrutura de alarme composto completa para uma única Zona de Disponibilidade:
![\[Um diagrama mostrando uma estrutura de alarme composto completa para determinar o impacto em uma única ZD\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-complete.png)
O alarme composto final, `use1-az1-isolated-impact`, é ativado quando o alarme composto que indica o impacto isolado na Zona de Disponibilidade devido à latência ou disponibilidade, `use1-az1-aggregate-alarm`, estiver no estado `ALARM` e quando o alarme baseado na regra do Contributor Insights para a mesma ZD, `not-single-instance-use1-az1`, também estiver em estado `ALARM` (o que significa que o impacto é mais do que uma única instância). Você criaria essa pilha de alarmes para cada Zona de Disponibilidade usada pela workload.
Você pode anexar um alerta do [Amazon Simple Notification Service](https://aws.amazon.com/sns/) (AmazonSNS) a esse alarme final. Todos os alarmes anteriores são configurados sem uma ação. O alerta pode notificar um operador por e-mail para que ele de início a uma investigação manual. Ele também pode iniciar a automação para evacuar a Zona de Disponibilidade. No entanto, cuidado ao criar automações para responder a esses alertas. Após uma evacuação de Zona de Disponibilidade, o resultado deve ser a mitigação das taxas de erro crescentes e a volta do alarme a um estado `OK`. Se o impacto ocorrer em outra Zona de disponibilidade, é possível que a automação evacue uma segunda ou terceira Zona de disponibilidade, potencialmente removendo toda a capacidade disponível da workload. A automação deve verificar se uma evacuação já foi realizada antes de realizar qualquer ação. Você também pode precisar escalar recursos em outras Zonas de Disponibilidade antes que a evacuação seja bem-sucedida.
Ao adicionar novos controladores ou ações ao seu aplicativo MVC web, a um novo microsserviço ou, em geral, a qualquer funcionalidade adicional que você queira monitorar separadamente, você só precisa modificar alguns alarmes nessa configuração. Você criará novos alarmes de disponibilidade e latência para essa nova funcionalidade e, em seguida, os adicionará aos alarmes compostos de disponibilidade e latência adequados da Zona de Disponibilidade, `az1-latency` e `az1-availability` no exemplo que estamos usando aqui. Os alarmes compostos restantes permanecem estáticos após serem configurados. Isso torna a integração de novas funcionalidades um processo mais simples.
# Detecção de falhas usando detecção de discrepâncias
Uma lacuna na abordagem anterior pode surgir quando você vê taxas de erro elevadas em várias Zonas de Disponibilidade que estão ocorrendo por um motivo *não correlacionado*. Imagine um cenário em que você tenha EC2 instâncias implantadas em três zonas de disponibilidade e seu limite de alarme de disponibilidade seja de 99%. Em seguida, um problema ocorre em uma única Zona de disponibilidade, isolando muitas instâncias e fazendo com que a disponibilidade nessa zona caia para 55%. Ao mesmo tempo, mas em uma zona de disponibilidade diferente, uma única EC2 instância esgota todo o armazenamento em seu EBS volume e não pode mais gravar arquivos de registros. Ela comece a retornar erros, mas ainda passa pelas verificações de integridade do balanceador de carga, pois elas não acionam a gravação de um arquivo de log. Isso faz com que a disponibilidade caia para 98% nessa Zona de disponibilidade. Nesse caso, seu alarme de impacto em uma única Zona de Disponibilidade não seria ativado porque você está vendo impactos em várias ZD. No entanto, você ainda pode mitigar quase todo o impacto evacuando a Zona de Disponibilidade prejudicada.
Em alguns tipos de workload, você pode enfrentar erros de forma consistente em todas as Zonas de Disponibilidade nas quais a métrica de disponibilidade anterior pode não ser útil. Veja, AWS Lambda por exemplo. AWS permite que os clientes criem seu próprio código para execução na função Lambda. Para usar o serviço, você precisa carregar seu código em um ZIP arquivo, incluindo dependências, e definir o ponto de entrada para a função. Mas às vezes os clientes erram nessa parte, por exemplo, eles podem esquecer uma dependência crítica no ZIP arquivo ou digitar incorretamente o nome do método na definição da função Lambda. Isso faz com que a função não seja invocada e resulta em um erro. AWS Lambda vê esses tipos de erros o tempo todo, mas eles não são indicativos de que algo seja necessariamente prejudicial à saúde. No entanto, coisas como problemas na Zona de Disponibilidade também podem fazer com que esses erros apareçam.
Para encontrar sinal no meio desses ruídos, você pode usar a detecção de discrepâncias para determinar se há uma distorção estatisticamente significativa no número de erros entre as Zonas de Disponibilidade. Embora vejamos erros em várias Zonas de Disponibilidade, se realmente houvesse uma falha em uma delas, veríamos uma taxa de erro muito maior nessa ZD em comparação com as outras, ou potencialmente muito menor. Mas quanto maior ou menor?
Uma forma de fazer essa análise é usar um teste [qui-quadrado](https://en.wikipedia.org/wiki/Chi-squared_test) (*X* 2) para detectar diferenças estatisticamente significativas nas taxas de erro entre Zonas de disponibilidade ([há muitos algoritmos diferentes para realizar a detecção de discrepâncias](https://dataprocessing.aixcape.org/DataPreprocessing/DataCleaning/OutlierDetection/index.html)). Vamos ver como funciona o teste qui-quadrado.
Um teste qui-quadrado avalia a probabilidade de alguma distribuição de resultados ocorrer. Nesse caso, estamos interessados na distribuição de erros em algum conjunto definido deAZs. Neste exemplo, para facilitar a matemática, considere quatro Zonas de Disponibilidade.
Primeiro, estabeleça a *hipótese nula*, que define o que você acredita ser o resultado padrão. Nesse teste, você espera que os erros sejam distribuídos uniformemente em cada Zona de disponibilidade: essa é a hipótese nula. Em seguida, gere a *hipótese alternativa*: os erros não estão distribuídos uniformemente, indicando um problema em uma Zona de Disponibilidade. Agora você pode testar essas hipóteses usando dados de suas métricas. Para isso, você fará uma amostra de suas métricas em um período de cinco minutos. Suponha que você obtenha 1000 pontos de dados publicados nesse período, no qual você vê 100 erros no total. Você espera que, com uma distribuição uniforme, os erros ocorram 25% das vezes em cada uma das quatro Zonas de disponibilidade. Suponha que a tabela a seguir mostre o que você esperava em comparação com o que você realmente viu.
*Tabela 1: erros esperados versus erros reais observados*
| ZD | Esperados | Reais |
| --- | --- | --- |
| use1-az1 | 25 | 20 |
| use1-az2 | 25 | 20 |
| use1-az3 | 25 | 25 |
| use1-az4 | 25 | 35 |
Você vê que, na realidade, a distribuição não é uniforme. No entanto, você pode acreditar que isso ocorreu devido a algum nível de aleatoriedade nos pontos de dados coletados. Há probabilidade de que esse tipo de distribuição possa ocorrer no conjunto amostral e ainda supor que a hipótese nula seja verdadeira. Isso leva à seguinte pergunta: qual é a probabilidade de obter um resultado pelo menos nesse extremo? Se essa probabilidade estiver abaixo de um limite definido, você rejeita a hipótese nula. Para ser [https://en.wikipedia.org/wiki/Statistical_significance](https://en.wikipedia.org/wiki/Statistical_significance), essa probabilidade deve ser de 5% ou menos1
1 Craparo, Robert M. (2007). “Nível de significância”. Em Salkind, Neil J. Encyclopedia of Measurement and Statistics 3. Thousand Oaks, CA: SAGE Publicações. pp. 889—891. ISBN1-412-91611-9.
Como você calcula a probabilidade desse resultado? Você usa a estatística *X2*, que fornece distribuições muito bem estudadas e pode ser usada para determinar a probabilidade de obter um resultado tão extremo ou mais extremo usando essa fórmula.
![\[Fórmulas para Ei, Oi e X2\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas1.png)
Para nosso exemplo, isso resulta em:
![\[Fórmulas para Ei, Oi e X2 usando nosso exemplo, resultando em uma resposta igual a 6.\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas2.png)
Então, o que `6` significa em termos de probabilidade? Você precisa observar uma distribuição qui-quadrada com o grau apropriado de liberdade. A figura a seguir mostra várias distribuições de qui-quadrado para diferentes graus de liberdade.
![\[Gráfico mostrando distribuições de qui-quadrado para diferentes graus de liberdade\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/chi-squared-distributions.png)
O grau de liberdade é calculado como um a menos que o número de opções no teste. Nesse caso, como há quatro Zonas de Disponibilidade, o grau de liberdade é três. Então, você quer saber a área sob a curva (a integral) para *x ≥ 6* no gráfico *k = 3*. Você também pode usar uma tabela pré-calculada com valores comumente usados para aproximar esse valor.
*Tabela 2: valores críticos do qui-quadrado*
| Graus de liberdade | Probabilidade menor que o valor crítico | | **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 |
Para três graus de liberdade, o valor qui-quadrado de seis fica entre as colunas de probabilidade de 0,75 e 0,9. Ou seja, há mais de 10% de chance de que essa distribuição ocorra, o que não é inferior ao limite de 5%. Portanto, você aceita a *hipótese nula* e determina que *não* há uma diferença estatisticamente significativa nas taxas de erro entre as Zonas de Disponibilidade.
A realização de um teste estatístico qui-quadrado não tem suporte nativo na matemática CloudWatch métrica, então você precisará coletar as métricas de erro aplicáveis CloudWatch e executar o teste em um ambiente computacional como o Lambda. Você pode decidir realizar esse teste em algo como um nível de MVC controlador/ação ou microsserviço individual, ou no nível da zona de disponibilidade. Você precisará considerar se uma deficiência na zona de disponibilidade afetaria igualmente cada controlador/ação ou microsserviço, ou se algo como uma DNS falha poderia causar impacto em um serviço de baixo rendimento e não em um serviço de alto rendimento, o que poderia mascarar o impacto quando agregado. Em ambos os casos, selecione as dimensões apropriadas para criar a consulta. O nível de granularidade também afetará os CloudWatch alarmes resultantes que você criar.
Colete a métrica de contagem de erros para cada ZD e para cada Controlador/Ação em um período de tempo especificado. Primeiro, calcule o resultado do teste qui-quadrado como verdadeiro (houve uma distorção estatisticamente significativa) ou falso (não houve, ou seja, a hipótese nula é válida). Se o resultado for falso, publique um ponto de dados 0 em seu fluxo métrico de forma a obter resultados qui-quadrados para cada Zona de Disponibilidade. Se o resultado for verdadeiro, publique um ponto de dados 1 para a Zona de Disponibilidade com os erros mais distantes do valor esperado, e um 0 para os outros (consulte o [Apêndice B – Exemplo de cálculo do qui-quadrado](appendix-b-example-chi-squared-calculation.md) para ver um exemplo de código que pode ser usado em uma função do Lambda). Você pode seguir a mesma abordagem dos alarmes de disponibilidade anteriores usando a criação de um alarme métrico de 3 em uma linha e um alarme CloudWatch CloudWatch métrico de 3 em 5 com base nos pontos de dados produzidos pela função Lambda. Como nos exemplos anteriores, essa abordagem pode ser modificada para usar mais ou menos pontos de dados em um período menor ou mais longo.
Em seguida, adicione esses alarmes ao alarme de disponibilidade existente da Zona de disponibilidade na combinação de Controller e Action, mostrada na figura a seguir.
![\[Diagrama mostrando a integração do teste estatístico qui-quadrado com alarmes compostos\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/statistics-test-with-composite-alarms.png)
Conforme mencionado anteriormente, ao integrar uma nova funcionalidade em sua carga de trabalho, você só precisa criar os alarmes CloudWatch métricos apropriados que sejam específicos dessa nova funcionalidade e atualizar o próximo nível na hierarquia composta de alarmes para incluir esses alarmes. O resto da estrutura de alarmes permanece estática.
# Detecção de falhas de recursos zonais de instância única
Em alguns casos, você pode ter uma única instância ativa de um recurso zonal, geralmente sistemas que exigem um componente de gravação única, como um banco de dados relacional (como o AmazonRDS) ou um cache distribuído (como o [Amazon ElastiCache (Redis OSS](https://aws.amazon.com/elasticache/redis/))). Se um problema em uma única Zona de Disponibilidade afetar a Zona de Disponibilidade onde o recurso principal está, isso pode impactar todas as Zonas que acessam o recurso. Isso poderia fazer com que limites de disponibilidade fossem ultrapassados em todas as Zonas de dispobibilidade, ou seja, a primeira abordagem não identificaria corretamente a única Zona de disponibilidade sendo impactada. Além disso, você provavelmente veria taxas de erro semelhantes em cada Zona de disponibilidade, o que significa que a análise de discrepância também não detectaria o problema. Isso significa que você precisa implementar observabilidade adicional para detectar esse cenário.
É provável que o recurso que está gerando preocupação produza as próprias métricas sobre sua integridade. Porém, durante um problema de Zona de disponibilidade, esse recurso pode não ser capaz de fornecer essas métricas. Nesse cenário, você deve criar ou atualizar alarmes para saber quando está *voando às cegas*. Se houver métricas importantes que você já monitora e que possuem alarmes, você pode configurar o alarme para tratar os [dados ausentes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) como violação. Isso ajudará você a saber se o recurso para de reportar dados. Ele pode ser incluído no mesmos alarmes *em sequência* e *m de n* usados anteriormente.
Também é possível que, em algumas das métricas que indicam a integridade do recurso, ele publique um ponto de dados de valor zero quando não há atividade. Se o problema estiver impedindo interações com o recurso, não será possível usar a abordagem de dados ausentes para esses tipos de métricas. Você provavelmente também não quer colocar um alarme sobre o valor zero, pois pode haver cenários em que isso esteja dentro dos limites normais. A melhor abordagem para detectar esse tipo de problema é com métricas produzidas pelos recursos que usam essa dependência. Nesse caso, queremos detectar impacto em *várias* Zonas de Disponibilidade usando alarmes compostos. Esses alarmes precisam usar algumas categorias de métricas críticas relacionadas ao recurso. Alguns exemplos estão listados abaixo:
+ **Throughput** — A taxa de entrada de unidades de trabalho. Isso pode incluir transações, leituras, gravações e assim por diante.
+ **Disponibilidade**: mede o número de unidades de trabalho bem-sucedidas versus as unidades com falha.
+ **Latência**: mede vários percentis de latência para um trabalho bem-sucedido realizado em várias operações críticas.
Mais uma vez, você pode criar os alarmes métricos *em sequência* e *m de n* para cada métrica, em cada categoria a ser mensurada. Como antes, eles podem ser combinados em um alarme composto para determinar se esse recurso compartilhado é a fonte de impacto nas Zonas de disponibilidade. Você quer poder identificar impacto em mais de uma Zona de disponibilidade com os alarmes compostos, mas o impacto não precisa necessariamente ser em *todas* as Zonas de disponibilidade. A estrutura de alarme composto de alto nível para esse tipo de abordagem é mostrada na figura a seguir.
![\[Diagrama mostrando um exemplo de criação de alarmes para detectar impacto causado por um único recurso em várias Zonas de Disponibilidade\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)
Você notará que esse diagrama é menos prescritivo em relação a quais tipos de alarmes métricos devem ser usados e à hierarquia dos alarmes compostos. Isso ocorre porque descobrir esse tipo de problema pode ser difícil e exigirá atenção cuidadosa aos sinais certos para o recurso compartilhado. Esses sinais também podem precisar ser avaliados de maneiras específicas.
Além disso, observe que o alarme `primary-database-impact` não está associado a uma Zona de Disponibilidade específica. Isso ocorre porque a instância primária do banco de dados pode estar localizada em qualquer zona de disponibilidade configurada para uso, e não há uma CloudWatch métrica que especifique onde ela está. Quando esse alarme for ativado, veja isso como um sinal de que pode haver um problema com o recurso e inicie um failover para outra Zona de Disponibilidade, caso isso não tenha sido feito automaticamente. Depois de mover o recurso para outra Zona de Disponibilidade, você pode esperar e ver se o alarme para Zona de Disponibilidade isolada está ativado, ou pode optar por invocar preventivamente seu plano de evacuação da Zona.
# Resumo
Esta seção descreveu três abordagens para ajudar a identificar problemas em uma única Zona de Disponibilidade. Use as abordagens em conjunto para ter uma visão holística da integridade da sua workload.
A abordagem de alarme CloudWatch composto permite que você encontre problemas em que a distorção na disponibilidade não é estatisticamente significativa, digamos, disponibilidades de 98% (a zona de disponibilidade prejudicada), 100% e 99,99%, que não sejam causadas por um único recurso compartilhado.
A detecção de discrepâncias ajudará a detectar problemas em uma única Zona de Disponibilidade onde haja erros não correlacionados em várias ZDs, todos ultrapassando o limite de alarme.
Por fim, identificar degradação de um recurso zonal de única instância ajuda a descobrir quando um problema de Zona de Disponibilidade afeta um recurso compartilhado entre ZDs.
Os alarmes resultantes de cada um desses padrões podem ser combinados em uma hierarquia de alarmes CloudWatch composta para descobrir quando ocorrem deficiências em uma única zona de disponibilidade e têm impacto na disponibilidade ou latência de sua carga de trabalho.