From 1bfe0f0a850367d0db601ac02b71254f7b716df1 Mon Sep 17 00:00:00 2001 From: deploy Date: Mon, 21 Sep 2026 13:56:19 +0000 Subject: [PATCH] chore(platform): sincroniza platform/ com o monorepo --- platform/monitoring/athleticmap-rules.yaml | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/platform/monitoring/athleticmap-rules.yaml b/platform/monitoring/athleticmap-rules.yaml index fa94cdf..7df48b5 100644 --- a/platform/monitoring/athleticmap-rules.yaml +++ b/platform/monitoring/athleticmap-rules.yaml @@ -76,6 +76,7 @@ spec: severity: warning annotations: summary: "Pod {{ $labels.pod }} em {{ $labels.namespace }} nao-Ready ha mais de 10m" + description: "Comece pelo motivo, que costuma estar no evento e nao no log: kubectl -n {{ $labels.namespace }} describe pod {{ $labels.pod }} | tail -20. CrashLoop com imagem recem-trocada e quase sempre a subida do Spring — veja kubectl logs --previous." # O no e UNICO e tem limite de 110 pods. Em 2026-09-19 a consolidacao # parou porque nao havia vaga ("Too many pods"), e o sintoma so aparecia @@ -106,6 +107,36 @@ spec: summary: "O teto de provisionamentos por hora segurou pedidos" description: "Ou entraram muitos clientes de uma vez, ou ha um laco. Veja provisionamento/execucao no banco do plataforma." + # P5.8 — o pedido que FALHOU. Esta e a regra que faltava, e a que a tela + # de espera pressupoe: ela diz ao cliente "nossa equipe ja foi avisada", e + # ate 2026-09-21 ninguem era avisado de nada. + # + # `> 0` e nao um patamar: cada falha e um cliente que pagou e esta olhando + # a tela de espera. Nao existe volume aceitavel disto. + # + # 10m (e nao 15m como as de cima) porque aqui alguem espera do outro lado. + - alert: AthleticMapProvisionamentoFalhou + expr: increase(atm_provisionamento_falhou_total[10m]) > 0 + for: 0m + labels: + severity: critical + annotations: + summary: "Provisionamento falhou — ha cliente pago esperando tenant" + description: "Veja a execucao e a etapa: kubectl -n plataforma-prod exec deploy/pg-compartilhado -- psql -U postgres -d athleticmap -c \"select * from captacao.execucao_provisionamento where situacao='FALHOU' order by criado_em desc limit 5\"" + + # Execucao que EXPIROU e diferente de falhar: ninguem devolveu a posse — + # tipicamente o pod morreu no meio. O pedido volta para a fila sozinho, e + # por isso e warning; mas expiracao repetida quer dizer que algo mata o pod + # sempre no mesmo ponto, e ai a fila anda para tras. + - alert: AthleticMapProvisionamentoExpirou + expr: increase(atm_provisionamento_expirou_total[1h]) > 2 + for: 0m + labels: + severity: warning + annotations: + summary: "Tres ou mais execucoes de provisionamento expiraram em 1h" + description: "A posse venceu sem o dono devolver: o pod morreu no meio da etapa. Veja restarts em kubectl -n plataforma-prod get pods -l app=servico-captacao." + # Webhook recusado e evento que o Asaas mandou e nos rejeitamos: token # errado (configuracao) ou alguem batendo na rota (tentativa). Um ou outro # acontece; uma rajada, nao. @@ -130,3 +161,4 @@ spec: severity: critical annotations: summary: "{{ $labels.deployment }} sem replica disponivel — demo, piloto e acme dependem dele" + description: "Os tres tenants migrados param juntos. kubectl -n plataforma-prod get pods -l app={{ $labels.deployment }} e, se for o PgBouncer, lembre que a userlist e montada por subPath e so entra em vigor com restart."