Vigilância própria ou serviço externo: como escolher

Um script de vigilância são vinte linhas. É precisamente por isso que a pergunta merece uma resposta honesta em vez de um argumentário: para um site único e com pouco em jogo, escrever o seu é muitas vezes a decisão certa, e ninguém tem interesse em dizer-lho.

A comparação, nos critérios que decidem

Só uma linha desta tabela é eliminatória, e é a quarta. Todo o resto se recupera com tempo; uma sonda que morre com a máquina que vigia, não. Essa linha é afastada na fase de desenho e recordada às três da manhã: o cenário para o qual a sua vigilância existe é exatamente aquele em que uma sonda alojada na mesma máquina já parou.

Escrevê-lo você mesmo: quando é a boa escolha

Um site, um servidor, uma pessoa. Uma tarefa cron que consulta a sua página inicial e lhe envia um email se o código não for 200 funciona. Custa uma noite e nada por mês.

Uma necessidade particular. Verificar algo dentro da sua aplicação, o tamanho de uma fila, um número de negócio, o estado preciso de uma base: nenhum serviço externo o pode fazer sem um acesso que não deveria ser dado.

O gosto de o fazer. Uma razão legítima, e muitas vezes a mais forte. Um script que escreveu é um script que saberá reparar.

Uma condição, nos três casos: a sonda deve correr noutro sítio que não a máquina vigiada. Uma máquina de cinco euros por mês noutro fornecedor, ou uma execução agendada num terceiro, chega. Sem isso, escreveu uma ferramenta que se cala exatamente quando devia falar.

Os três muros com que se acaba por esbarrar

A verificação corre na máquina vigiada. Se o servidor cair, o script cai com ele. A falha que ninguém deteta é justamente aquela em que está tudo no chão ao mesmo tempo, e foi para essa que o escreveu.

O histórico desaparece. Saber que o site está em baixo agora é a metade fácil. Responder a «que disponibilidade teve no mês passado» pressupõe guardar cada verificação, gerir a retenção e saber recalcular uma taxa quando havia uma janela de manutenção prevista. É aí que um projeto de fim de semana se torna uma pequena base de dados para manter.

Escala mal. Um site, vinte linhas. Vinte sites, uma rotação de intervalos, falsos alarmes para afinar, alertas que param sem que ninguém dê por isso, e um cliente que reclama um relatório mensal. Organizar um parque é um ofício em si, e não é aquele para o qual o script foi escrito. A transição raramente é uma decisão; acontece pouco a pouco, um site de cada vez, até que uma tarde desaparece a manter algo que devia custar uma noite.

As quatro armadilhas do script próprio, pela ordem em que aparecem

Nenhuma é intransponível. Todas se descobrem depois, e é esse o problema.

O email de alerta não chega. Um servidor que envia correio a partir do seu próprio endereço IP acaba no spam, ou em lado nenhum. Damos por isso no dia em que esperávamos o alerta, ou seja tarde demais. A correção é simples, um serviço de envio transaccional, e acrescenta mais uma dependência para vigiar.

O script pára sem o dizer. Uma atualização de linguagem, um caminho que muda, uma quota atingida: a tarefa agendada falha em silêncio. Um script de vigilância precisa de ser vigiado, o que é logicamente incómodo e praticamente verdadeiro. A defesa cabe numa linha: faça-o enviar um sinal de vida semanal, cuja ausência o alerta.

Os falsos positivos acabam por ganhar. Sem confirmação nem memória de estado, um script envia um email a cada soluço de rede. Ao fim de três semanas ninguém os abre, e a vigilância continua a existir sem servir para nada.

Mais ninguém sabe repará-lo. No dia em que estiver de férias, o script é uma caixa negra escrita num estilo pessoal, sem documentação. É aceitável para um site pessoal, muito menos assim que um cliente depende da resposta.

O custo real, em tempo

É o único argumento sério, e aquele que as comparações evitam porque não cabe numa tabela de preços.

Escrevê-lo custa uma noite. O resto chega às fatias: uma hora quando o fornecedor de email muda as regras, duas horas no dia em que expira o certificado da sua própria sonda, meio dia para acrescentar o histórico quando um cliente o pede, e uma tarde na primeira vez que descobre que o script não corria há seis semanas.

Conte um a dois dias por ano, distribuídos pelo pior momento, sempre enquanto fazia outra coisa. A comparar com uma subscrição, tendo presente que o seu dia vale provavelmente mais do que custa um ano dela.

O que um serviço externo compra realmente

Não a verificação em si: essa sabe escrevê-la. Compra o ponto de vista exterior, o histórico que não teve de guardar, e o facto de a coisa continuar a correr quando a sua infraestrutura já não corre.

E a parte em que ninguém pensa no início: mais alguém a mantém. Um script de vigilância que deixou de funcionar há três meses é pior do que vigilância nenhuma, porque continua a julgar-se coberto. É a falha silenciosa mais comum deste domínio, e a única que a sua vítima não pode detetar por definição.

A montagem híbrida, que é o que fazem as equipas sérias

Não é um compromisso mole, é a resposta certa assim que o sistema passa de um site.

A vigilância de infraestrutura fica consigo: disco, memória, filas, números de negócio. Vê o que um exterior não consegue ver, e tem o direito de cair com a máquina, já que é a máquina que descreve.

A vigilância de site parte do exterior: o código de resposta, o tempo de resposta, o certificado, o conteúdo esperado na página. Vê o que os seus visitantes vêem, e é o único ponto de vista que continua válido quando tudo o resto está no chão. É também o único que responde à pergunta a que o seu alojamento nunca responderá.

Os dois não se substituem. Respondem a duas perguntas diferentes, e confundi-los é a causa mais frequente de uma vigilância que tranquiliza sem proteger.

Uma regra de decisão honesta

Parta do que perderia durante três horas de falha, e do número de sites de que trata. O primeiro número calcula-se em cinco minutos, o segundo já o conhece.

• Um site, pouco em jogo → escreva-o você mesmo, ponha-o a correr noutro sítio, e verifique uma vez por trimestre que ainda dispara.
• Vários sites, ou um cliente envolvido → um serviço externo paga-se no tempo que deixa de gastar a mantê-lo.
• Necessidades profundas dentro da aplicação → os dois, em postos diferentes.

O mesmo juízo repete-se, idêntico, sobre outro objeto: seguir os seus backlinks numa folha de cálculo mantida à mão aguenta muito tempo, e depois deixa de aguentar exatamente pelas mesmas razões. A folha, as suas sete colunas e o seu prazo de validade contam a mesma história com outras linhas.

E seja qual for a sua escolha, a questão do intervalo fica inteira: resolve-se a partir do custo, não da técnica. A primeira coisa a fazer depois, no dia em que algo cai, é a mesma nos dois casos: os primeiros quinze minutos não dependem da ferramenta.