Um livro-razão que conta antes do preço

A monitorização não tem preço. Nem valor, nem moeda, nem plano, nem linha de fatura. O que existe desde esta ronda de trabalho é um livro-razão que regista cada verificação realmente enviada pela plataforma, a guarda durante treze meses e fecha cada hora num balde que nunca mais é alterado.

Construir a contagem antes da cobrança parece a ordem errada até se ter feito o contrário uma vez. Um contador que nasce ao lado de uma fatura herda todas as comodidades que essa fatura deseja: uma nova tentativa contada em silêncio porque de outro modo o total parecia estranho, uma correção aplicada editando a linha. São decisões, e tomam-se melhor quando nenhum total depende delas.

O livro-razão existe, portanto, não contém dinheiro, e uma das suas colunas está deliberadamente vazia.

Conta o que realmente saiu

Uma verificação agendada atravessa poucos estados, e o livro-razão faz uma única pergunta por estado: saiu tráfego do edifício. Isso está escrito como tabela sobre todos os desfechos e não como uma bifurcação com ramo por omissão, porque um ramo por omissão é justamente o caminho pelo qual um sétimo desfecho passa a «não conta» em silêncio e falta um mês.

Duas destas linhas merecem uma frase própria.

Uma verificação que alcança uma máquina morta conta na mesma. Houve tráfego e houve medição; que a resposta seja «inacessível» é o resultado e não a pergunta. Uma regra que contasse apenas verificações bem-sucedidas cobraria menos precisamente aos clientes por quem mais se trabalha.

E «expirado» é mais subtil do que parece, porque um pedido pode expirar depois de enviado. Não se conta duas vezes, e não por sorte: um tique só chega a esse estado pela varredura que toca os tiques que nunca passaram do envio, e o que saiu já constava como enviado e tem a sua linha desde então.

A classe de origem, a nossa sonda ou o agente do cliente, consta da linha e da assinatura da função que decide. Hoje ambas contam do mesmo modo, e é precisamente por isso que a classe fica escrita em vez de suposta.

Um tique, uma linha

A comutação por falha é o caso que inflaciona em silêncio um número de utilização. Uma verificação parte de uma origem, essa origem não responde, outra assume, e agora há duas tentativas para uma só medição.

Aqui isso é um índice único sobre uma chave da forma tick:<identificador do tique>. Repetições e comutações dentro do mesmo tique produzem a mesma chave, pelo que a segunda inserção colide e não devolve nada. Ambos os caminhos de escrita fazem assim; nenhum consulta antes, porque entre uma consulta e uma inserção cabe um segundo gateway.

A chave é uma coluna de texto e não a referência ao tique, e é aí que está o interessante. Os tiques vivem sete dias, a utilização treze meses. Quando a varredura remove o tique essa referência fica vazia, e no Postgres um valor vazio nunca é igual a outro valor vazio: um índice único sobre essa coluna passaria assim a tolerar duplicados uma semana depois, sem dizer nada.

Um teste manual também é tráfego

Existe um botão que executa uma verificação de imediato. Não conta, e é registado na mesma.

Ambas as metades importam. Não conta porque uma pessoa a carregar num botão não é o serviço agendado. É registado porque continua a ser tráfego para a máquina de alguém, e mil toques por hora são exatamente aquilo que um sistema de utilização deve conseguir mostrar. Uma segunda tabela que nenhum resumo consulta esconderia justamente o caso em que o número é interessante.

O que separa os dois não é uma convenção mas uma restrição na base de dados: uma linha do tipo manual não pode contar nem levar tique. «Manual e contabilizado» não pode existir, e isso importa porque uma linha assim parece perfeitamente normal em qualquer resumo.

Uma hora fecha tarde, e depois nunca mais muda

Os baldes vão por organização, hora, classe de origem e tipo de verificação. Uma hora só é fechada quando passaram quinze minutos da hora seguinte.

O motivo evidente, um resultado de medição tardio, não é o verdadeiro; os resultados não tocam no total. O que pode realmente chegar tarde é a própria linha: uma transação confirmada às 10:59:59 torna-se visível às 11:00:00, vários gateways leem cada um o seu relógio, e um que esteve ausente por pouco tempo recupera depois o atraso. Quinze minutos são uma ordem de grandeza mais do que tudo o que uma verificação pode durar, onde o tempo máximo de espera é de 120 segundos e a reserva de 45.

Depois de fechada, uma hora não se edita. Um evento tardio produz uma linha nova que aponta para a linha base com um motivo legível por máquina, nunca uma atualização. É a forma que o impõe e não a disciplina: o índice único sobre organização, hora, classe de origem e tipo é parcial e cobre apenas as linhas que não são correções, de modo que uma segunda correção sobre a mesma hora não colide com a primeira nem desaparece. Se as correções partilhassem esse índice, perder-se-ia exatamente a prova útil numa disputa. O motivo em si é uma palavra e não uma frase livre, porque o painel traduz-o em nove línguas e uma exportação agrupa por ele.

Limites que não são uma tabela de preços

Cada organização tem uma margem permitida, e cada número dentro dela foi escolhido para travar um acidente, não para descrever um pacote.

No máximo 200 regras, deliberadamente o mesmo número que a função de criação já impunha: um valor por omissão mais baixo teria empurrado contas existentes para além do seu limite logo no primeiro dia e teria disparado sem aviso a regra de suspensão abaixo. No máximo 9 origens por regra, ou seja as oito localizações alojadas mais um agente que o esquema já permitia. Todos os tipos de verificação conhecidos, derivados dessa lista em vez de escritos à mão, para que um sétimo tipo não fique proibido por omissão para toda a gente. Um mínimo de 60 segundos, que uma margem pode subir e nunca baixar; baixá-lo é um direito pago à parte que tem nome e não existe.

O número de revisão dessa linha é o que acaba no livro-razão, e zero significa «não há linha, isto é o valor por omissão». Sem essa distinção, uma linha de utilização do ano passado não se consegue ligar ao que então era permitido, e é exatamente para isso que se guarda uma revisão.

O que fica suspenso quando a margem encolhe

Se alguém baixar uma margem para menos do que uma conta utiliza, algumas regras param. Quais é uma decisão, e havia duas candidatas.

As mais caras primeiro não é viável, porque não há preço. Implicaria deduzir o custo do número de origens ou do intervalo, e então suspende-se precisamente a vigilância mais fina que o cliente tem. Quem reduz o seu plano prefere perder uma medição periférica a perder o aviso que o acorda de noite.

Assim, as regras mais antigas continuam e as mais recentes suspendem-se. As antigas carregam o historial de incidentes mais longo e os avisos em que as pessoas confiam, e «o último que se ligou é o primeiro a desligar-se» é a única ordem que um cliente consegue prever sem ler o nosso código. A ordenação é data de criação e depois identificador de regra, duas chaves porque aplicar um modelo cria várias regras no mesmo milissegundo; sem esse segundo critério a pré-visualização não coincidiria com o que acontece a seguir.

As regras que quebram um limite de forma, um tipo proibido, origens alojadas já não permitidas, origens a mais, são retiradas primeiro e depois contam no que sobra. Um intervalo agora demasiado rápido não suspende absolutamente nada: um mínimo elevado recusa uma regra nova ou alterada e deixa em paz as que já correm até alguém lhes tocar.

A coluna vazia

Os baldes têm uma coluna invoice_ref e está vazia. É uma costura com nome e não um esquecimento, no mesmo espírito do direito que tem nome e não tem implementação: quando a faturação chegar, a forma de que precisa já lá estará, e nada da contagem terá de ser repensado sob pressão de prazo.

Duas decisões aparentadas seguem o mesmo raciocínio. O livro-razão tem tabela própria em vez de derivar dos tiques, porque os tiques vivem sete dias e isto 395. E as linhas por verificação ficam fora da exportação de dados pessoais, com o motivo escrito ao lado: centenas de milhares por mês, uma exportação que corta cada secção em 25 000 linhas, e baldes horários que levam os mesmos totais. Os baldes e a linha de limites vão mesmo.

O que deixaríamos escrito

1. 01Construa o contador antes do preço. Toda a pergunta se responde com mais honestidade quando nenhum total depende da resposta.
2. 02Registe no momento em que o trabalho sai, não quando a resposta chega, e uma resposta tardia deixa de ser um problema de medição.
3. 03Faça a chave de idempotência sobreviver ao seu sujeito. Uma chave assente numa linha que será varrida começa a admitir duplicados conforme um calendário.
4. 04Enumere cada desfecho numa tabela. Um ramo por omissão transforma um estado novo num zero silencioso.
5. 05As correções são linhas, nunca edições, e a unicidade que protege o original não pode bloquear a correção.
6. 06Escolha a ordem que o seu cliente consegue prever, e deixe escrito qual descartou.

Para que fique claro o que isto é: a monitorização está por trás de um interruptor de lançamento desligado por omissão, não existe uma camada de direitos com dinheiro lá dentro, e nada disto é comprável hoje. Duas coisas ficam por provar. A varredura de retenção nunca correu contra uma linha realmente antiga, apenas contra o esquema. E o componente que fecha horas foi exercitado pela sua função e não por um processo de longa duração, pelo que um gateway ausente uma noite que depois recupera está raciocinado e não observado.

Do trabalho de monitorização em Provibr. Porque é que uma sonda não leva permissões de que não precisa está em uma sonda que não se deixa convencer de nada, e porque é que um incidente não se fecha porque as medições pararam está em um incidente que o silêncio nunca fecha.