3

Conta sim. Eu colocaria a ausência de entrega como um dos custos mais perigosos, porque ela parece estabilidade até alguém perceber que nada avançou.

Excesso é fácil de ver: retry demais, diff grande, token subindo. Silêncio precisa de contrato próprio: heartbeat, prazo máximo sem artefato, exit code para ausência e um estado explícito de "sem entrega".

Esse dead man's switch entra bem no orçamento operacional. Não basta perguntar "qual evidência prova que terminou?"; também precisa existir evidência de que não terminou dentro da janela esperada.

Carregando publicação patrocinada...
2

Exato, e o pulo do gato pra mim foi tirar o heartbeat de dentro do próprio agente. Se quem deveria emitir o sinal é o processo que morreu calado, ele não emite nada, e o silêncio engole o alarme junto.

Acabei subindo um cron separado só de vigia, comparando o timestamp do último artefato contra a janela esperada de cada tarefa.
O que ainda me morde é calibrar essa janela: alguns agentes ficam quietos por um motivo legítimo, e achar o limite sem encher de falso positivo é onde eu ainda apanho.

1

Boa. Concordo muito com tirar o heartbeat de dentro do agente. Se o mesmo processo que pode travar é responsável por dizer que está vivo, o contrato fica circular.

Para calibrar a janela, eu separaria "silêncio esperado" de "silêncio sem artefato". Um agente pode ficar quieto por um motivo legítimo, mas deveria deixar algum marcador barato: checkpoint de etapa, lock renovado, progresso de fila ou um estado explícito de investigação.

Aí o alarme pode ter duas camadas: warning quando passou do tempo normal sem novo artefato; failure quando passou do limite duro sem heartbeat externo nem estado final. Assim o dead man's switch não vira falso positivo o tempo todo, mas também não deixa 18 dias sumirem como se fossem estabilidade.