Monitorização HTTP que verifica mais do que um 200

Um endpoint que devolve 200 não está por isso a funcionar

Um balanceador que serve uma página de erro em cache devolve 200. Uma API que responde em nove segundos devolve 200. Um deploy que substituiu o seu JSON por um formulário de login em HTML devolve 200. Assim, uma verificação que só lê a linha de estado dá conta de um serviço saudável enquanto os seus clientes não o conseguem usar.

Uma verificação HTTP do okokumo avalia todas as asserções que lhe der, e só conta como ativa quando todas se cumprem:

• Código de estado — exato, ou uma classe como qualquer 2xx.
• Latência — um limite em milissegundos, para que lento seja uma falha e não uma nota de pé de página.
• Conteúdo do corpo — uma cadeia que tem de estar presente, e é isso que apanha a página de erro em cache e o deploy errado.
• Cabeçalhos de resposta — presença e valor, para os cabeçalhos de cache, segurança e content-type que se avariam em silêncio.

Intervalo e método

De 30 segundos a 24 horas. O mínimo depende do plano — cinco minutos no Free, um minuto no Starter, trinta segundos no Pro e no Business — e o máximo existe porque algumas coisas vale a pena verificar diariamente em vez de constantemente, como um endpoint de relatórios ou o URL de callback de um parceiro.

Qualquer método HTTP, com um tempo limite que define por verificação. IPv6 e certificados autoassinados são tratados em vez de excluídos por omissão.

Duas regiões têm de concordar

As verificações correm a partir de duas regiões de sondagem da UE independentes. Uma falha só se torna alerta quando uma segunda sonda a confirma, e uma verificação só muda de estado depois de N falhas consecutivas — duas por omissão, configurável. Uma única região a perder a rota até si não o acorda às 3 da manhã.

A única exceção deliberada: se uma região de sondagem estiver ela própria em baixo, exigir confirmação significaria nunca alertar, pelo que o requisito se flexibiliza em vez de engolir em silêncio todas as falhas.

Como funciona a confirmação em duas regiões →

O que vê depois

app.okokumo.com/checks/api

Latência e disponibilidade por dia, semana e mês; cada transição entre ativo e em baixo com a respetiva hora; e um registo de entregas que indica que alerta foi para que canal — incluindo os que deliberadamente não foram enviados, com o motivo. Uma monitorização que falha em silêncio ao avisá-lo é pior do que nenhuma, pelo que esse registo é parte do produto e não uma vista de depuração.

De onde correm as verificações

França e uma segunda região da UE, na Scaleway. Os seus dados de monitorização não saem da UE, e está disponível um DPA estruturado no artigo 28 do RGPD antes de o pedir. Segurança e dados →