Documentação

Monitores

Um monitor é uma coisa que você quer vigiada, e a regra que decide se ela está saudável. Existem trinta tipos. A maioria faz uma requisição a partir da nossa rede e julga a resposta; dois esperam que algo chegue da sua, e quatro coletam o que seus roteadores exportam para a sua própria sonda privada.

Os tipos

Web e rede

Certificados e domínios

E-mail

Protocolos de infraestrutura

Eles existem porque uma verificação tcp na porta não prova quase nada sobre eles. Um SMSC aceita TCP muito depois de parar de registrar qualquer cliente; uma pilha SIP pode travar com o socket aberto; um servidor XMPP com o certificado vencido ainda completa um handshake TCP.

Bancos de dados

Pro e superiores. Uma verificação tcp na 5432 comprova que algo aceitou um socket, e todas as falhas interessantes de um banco de dados mantêm o socket aberto: Postgres em recuperação, um limite de conexões esgotado por uma aplicação com vazamento, um papel cuja senha expirou, um banco renomeado, um diretório de dados que não montou. Então estas verificações abrem uma conexão, autenticam e fazem ao servidor uma pergunta trivial.

Nenhuma delas lê ou escreve nada. Esta é uma verificação de disponibilidade, não uma transação sintética: dê a ela uma conta que não consiga fazer nada além de conectar.

A credencial é armazenada sem criptografia, porque a sonda que executa a verificação recebe a configuração como está. Por isso estas cinco só rodam em uma sonda liberada para dados pessoais, que é a mesma restrição que snmp e smpp carregam.

Isso significa um de dois lugares. A sua própria sonda privada, que é para o que estas verificações foram desenhadas: ela roda no seu hardware, dentro da sua rede, então a configuração nunca sai da sua infraestrutura — e normalmente é a única coisa capaz de alcançar um banco de dados que valha a pena monitorar, já que um banco atrás de uma VPC, de um link privado ou de uma lista de permissões não é acessível de rede alguma de terceiros, inclusive a nossa. Na falta dela, os nossos próprios pontos de observação na UE, para um banco que seja realmente acessível publicamente.

Contêineres

Pro e acima. Uma verificação na porta publicada de um contêiner responde pelo proxy que está na frente dele. Um contêiner que cai em loop atrás de uma política de reinício fica no ar alguns segundos por vez, um HEALTHCHECK falhando deixa a porta aberta, e um encerramento por falta de memória seguido de reinício parece uma única requisição lenta. O mecanismo Docker sabe dos três.

Acesso à API do mecanismo é root naquele host, então o endpoint e seus certificados de cliente são credenciais, e este tipo só roda a partir de uma sonda liberada para dados pessoais. Um socket unix só é aberto por uma sonda iniciada com DOCKER_SOCKET_ENABLED=true, algo que você configura na sua própria sonda privada ao lado do seu próprio mecanismo e que nunca configuramos nas nossas; em qualquer outro lugar a verificação se abstém em vez de dar seu contêiner como fora do ar. Um endpoint tcp:// ou https:// com certificados de cliente funciona a partir de ambos.

Tráfego de rede

Business e superiores. Uma verificação de disponibilidade diz que um link responde; ela não consegue dizer que o link está saturado, que um backup o inunda ao meio-dia ou que o tráfego para a sua camada web caiu a zero em silêncio. Seus roteadores e switches já contam tudo isso e conseguem exportar. Estes tipos coletam essa exportação e a transformam em taxas, uma divisão por protocolo e as portas e endereços mais movimentados.

Todo limite é opcional — uma taxa de bits máxima, uma taxa de bits mínima, uma taxa de pacotes máxima. Acima ou abaixo de um deles é degradado. Sem nenhum, o monitor registra o tráfego e o mostra em gráfico sem alertar por um valor. Um exportador que para de enviar por mais tempo do que você permite está fora do ar, e um que envia o protocolo errado — sFlow para um monitor NetFlow — está fora do ar com uma mensagem que diz exatamente isso.

Estes tipos só rodam na sua própria sonda privada. A exportação de fluxos é UDP, que não tem autenticação: um coletor na nossa rede compartilhada teria de confiar no endereço do remetente, que qualquer um pode falsificar ou reivindicar. Numa sonda dentro da sua rede, só os seus roteadores conseguem alcançá-la. Além disso, seus registros de tráfego ficam em casa — eles trazem os endereços das pessoas da sua rede, então a sonda os agrega onde chegam e nos envia apenas as taxas e as tabelas dos dez principais. Inicie a sonda com FLOW_COLLECTOR_ENABLED=true, publique as portas UDP, aponte seus roteadores para ela e escolha essa sonda ao criar o monitor.

Coisas que avisam a gente

Com que frequência ele roda

Você escolhe um intervalo; o seu plano define o piso. Free verifica a cada minuto, Starter a cada 45 segundos, Pro a cada 30, Business a cada 15, Enterprise a cada 5.

Quatro tipos têm o próprio piso, independentemente do plano, porque a resposta não muda de um minuto para o outro e perguntar com mais frequência seria ruído e carga no servidor de outra pessoa:

Um intervalo não é a rapidez com que você fica sabendo de uma queda

Esta é a parte que vale ler duas vezes. Uma única verificação com falha não abre um incidente. Um monitor tem que falhar três vezes seguidas — essa é a configuração confirmations, e três é o padrão — antes que alguém seja avisado.

Só que não são três vezes o intervalo. Quando uma verificação falha, a próxima é antecipada em vez de esperar o intervalo inteiro, então um monitor de cinco minutos confirma uma queda em bem menos de quinze minutos. Um resultado só pode tornar a próxima verificação mais cedo, nunca mais tarde.

Diminua confirmations se você preferir ser acordado cedo e, de vez em quando, à toa. Aumente para algo que você sabe que oscila.

As verificações rodam em rodízio entre localidades

Verificamos a partir de vários lugares, um por intervalo, em rodízio. Três pontos de observação em um monitor de cinco minutos significam que cada um o vê a cada quinze minutos, enquanto o monitor continua sendo verificado a cada cinco.

É isso que dá sentido à confirmação: três falhas seguidas são três falhas vistas de três lugares diferentes, então uma sonda que simplesmente não alcança o seu servidor é inofensiva — a região seguinte tem sucesso e a sequência é zerada.

Uma falha enquanto outra localidade está bem é degradado, e não fora do ar. Fora do ar deve significar que o seu site está inacessível, não que um ponto de observação não consegue enxergá-lo. Ainda conta como falha e um incidente ainda é aberto, com severidade degradado.

Um firewall não é uma queda

Um site bloqueado em uma localidade falha todas as verificações feitas de lá, enquanto funciona em todo o resto. Contar isso como indisponibilidade tornaria o seu número de disponibilidade uma afirmação sobre o nosso roteamento, e não sobre o seu serviço.

Por isso uma região que nunca alcançou um monitor é excluída dele depois de três falhas. Uma região que já o alcançava e não alcança mais continua contando, permanentemente — porque de lá aquilo é uma queda de verdade, e escondê-la seria pior.

Se o mundo mudou ao redor de um site — um bloqueio governamental, uma rota perdida, uma restrição geográfica adicionada depois — você pode recalibrar um monitor a partir da página dele. Isso descarta o histórico de todas as regiões para aquele único monitor, de modo que o comportamento atual passa a ser a nova referência. É por monitor e é deliberado, porque só a medição não distingue um bloqueio permanente de uma queda permanente.

Onde as verificações rodam, e o que enviamos para lá

Alguns pontos de observação ficam fora do EEE. Uma verificação cuja configuração possa conter dados pessoais — um cabeçalho de requisição, um corpo de requisição — só roda de dentro dele. Isso é imposto pelo agendador, e não por política, e é testado contra um banco de dados real a cada build. snmp e smpp e os cinco tipos de banco de dados são confinados do mesmo jeito, porque em todos eles a credencial é o protocolo.

Não testado não é aprovado

Para tls_audit, cada sondagem tem três resultados, e não dois: suportado, recusado ou não testado. O OpenSSL 3 do Node não compila nem RC4 nem 3DES, então essas duas famílias nunca podem ser oferecidas pela nossa frota — e o silêncio sob esses títulos seria lido como “nós olhamos e elas estão desligadas”, o que é um falso sinal de tudo certo justamente sobre as constatações pelas quais uma auditoria TLS é aberta.

Dependências

Diga a um monitor do que ele depende — um banco de dados, um gateway, uma API upstream — e, quando a dependência estiver fora do ar, o que está atrás dela é marcado como consequência em vez de abrir incidentes próprios. Um incidente, não quarenta, e a página nomeia a causa raiz em vez dos sintomas.

Janelas de manutenção

Agende uma janela e, enquanto ela estiver aberta, nada aciona ninguém. Use para um deploy que você sabe que vai derrubar a coisa. Por padrão as verificações continuam rodando e continuam registrando, então esses minutos contam para o número de disponibilidade como quaisquer outros — a janela tira o alerta, não o histórico. Desligue “continuar verificando” e nada é verificado enquanto a janela está aberta, o que deixa uma lacuna no histórico em vez de uma queda. Uma janela pode se repetir diariamente, semanalmente ou mensalmente, e cada ocorrência segura os alertas, não apenas a primeira.

Pausar

Um monitor pausado não é verificado e não conta contra nada. Ele mantém o histórico, então pausar e retomar não perde o registro.