Estratégias de reverificação: confirmando um status novo antes de alertar

Por que uma verificação falhada não é uma indisponibilidade

Um resultado de verificação descreve uma requisição, de um lugar, em um momento. Qualquer um desses três pode estar errado sobre o site como um todo. A rede entre um único ponto de verificação e o seu servidor pode estar quebrada enquanto toda outra rota está bem. Um registro DNS pode ainda estar se propagando em uma região e já estar correto na próxima. O próprio ambiente de um ponto de verificação pode ser incompatível com algo que o seu servidor faz.

Se um sistema de monitoramento agisse em todo primeiro resultado, ele acionaria você para tudo isso e também corromperia as suas estatísticas de uptime, já que a indisponibilidade que ele registrou nunca aconteceu para os seus usuários. Então o status detectado, No Ar ou Fora do Ar, é mantido como não verificado até ser confirmado, e só então algo mais adiante acontece: um alerta sendo enviado, um episódio abrindo, o número de uptime se movendo.

O que uma reverificação pega

Reverificar a partir de outras localidades é o que separa uma mudança real e no site inteiro de um artefato local. Os casos que ela mais frequentemente filtra são:

• Indisponibilidade curta durante uma implantação nova, onde o site volta antes de uma segunda verificação rodar
• Indisponibilidade de DNS enquanto uma mudança de configuração se propaga, então alguns resolvedores respondem e outros não
• Uma listagem em blacklist local do site ou do endereço do ponto de verificação, visível a partir de uma única rede
• Um agente de verificação cujo ambiente é incompatível com as tecnologias que o servidor usa
• Problemas de roteamento ou peering no caminho entre um único ponto de verificação e o servidor

As verificações de confirmação são tiradas da região geográfica configurada para a tarefa de monitoramento, então a segunda opinião vem da mesma parte do mundo em que os seus usuários estão, em vez de de onde quer que esteja disponível.

As três estratégias de reverificação

A HostTracker suporta três formas de decidir se um status novo é real.

1. Votação por maioria. Quando uma verificação devolve um status novo, o sistema aloca até 7 localidades novas da região geográfica da tarefa de monitoramento para confirmá-lo. Os resultados devolvidos são agrupados por status, e o grupo maior vence. Digamos que uma verificação de Miami reporte Fora do Ar, e reverificações de Nova York, Boston e Chicago voltem No Ar, Fora do Ar, No Ar. O Fora do Ar não é confirmado e é descartado, e Miami é penalizada: não vai ser usada para verificações daquele site. Rode o mesmo exemplo ao contrário, com Miami reportando No Ar depois de um Fora do Ar e Nova York e Chicago confirmando No Ar, e a transição Fora do Ar-No Ar é registrada.

2. Um número definido de localidades confirmando Fora do Ar. Aqui você configura o número mínimo de reverificações necessárias para confirmar um Fora do Ar, enquanto um No Ar ainda exige a votação por maioria. Com esse número definido como 1, no mesmo exemplo, só Boston devolvendo Fora do Ar já é suficiente para confirmar o Fora do Ar de Miami, mesmo que Nova York e Chicago tenham discordado.

3. Sem reverificação. O status novo é sempre confirmado assim que é detectado. Isso presume confiança completa no servidor e nos ambientes das localidades de monitoramento. Serve para algumas necessidades específicas de monitoramento, e deveria ser escolhido com cuidado, porque todo problema de rede transitório em um único ponto de verificação vira um alerta falso e um dano na cifra de uptime.

Escolhendo uma estratégia

1. Comece pela votação por maioria. É o padrão equilibrado: custa alguns segundos de tempo de confirmação extra e remove quase todo o ruído de ponto único.
2. Diminua o limite de confirmação de Fora do Ar quando um alerta rápido vale mais do que uma caixa de entrada silenciosa. Uma indisponibilidade regional que só duas localidades conseguem ver ainda chega até você, ao custo de mais falsos positivos.
3. Mantenha a votação por maioria para transições de No Ar seja qual for a forma que você definir o Fora do Ar. Um No Ar prematuro fecha um incidente que ainda está rodando e esconde a cauda da indisponibilidade das suas estatísticas.
4. Reserve o sem-reverificação para alvos que você controla de ponta a ponta, onde você prefere investigar um alerta espúrio a esperar por confirmação.

Qual estratégia você escolher, você consegue reproduzir uma discordância você mesmo a partir de duas redes diferentes e comparar o que cada uma vê:

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/

Um 503 de uma rede e um 200 de outra é o mesmo padrão que a reverificação foi projetada para resolver. Se o status que está falhando é um 5xx em vez de um timeout, o servidor respondeu, o que é um problema diferente: veja 503 Service Unavailable.

O que a confirmação dá a você

Reverificações são o que permite que um sistema de monitoramento rode verificações frequentes a partir de muitos lugares sem transformar essa sensibilidade em ruído. A HostTracker verifica a partir de mais de 300 pontos de verificação em 158 cidades, então sempre há localidades independentes disponíveis para a segunda opinião, e só uma transição confirmada dispara um alerta por e-mail, SMS, chamada de voz, Slack, Telegram e mais. As estratégias acima não são o conjunto inteiro possível, e o suporte pode considerar uma nova para uma versão futura se o seu monitoramento tiver uma demanda que nenhuma delas cobre. Veja monitoramento de disponibilidade distribuído para como a rede de pontos de verificação é usada, e o restante da seção de conceitos de monitoramento para os termos por trás dela.