Situação de produção
Clique no cartão para abrir os pods.
Rotinas automáticas
Lidas do log do cortex-cron e guardadas pelo monitor por 7 dias, mesmo quando o pod é recriado. Horários no seu relógio.
Como esta aba decide cada situação
em dia: concluiu no horário esperado, sem linha de erro.
rodando: começou e ainda não concluiu.
travado?: rodando há mais de 20 minutos. A fila é serial, então nada mais roda enquanto ele não termina.
atrasado: o faturamento sem concluir há mais de 25 minutos, ou um diário sem concluir 30 minutos depois do horário.
com erro: a última execução teve linha de nível ERROR entre o início e a conclusão.
erro conhecido: só o Mercado Livre, que falha de propósito para empresa sem conexão desde 02/10. Abra as linhas de vez em quando: um erro diferente cairia aqui também.
aguardando: o horário chegou há menos de 30 minutos.
não observado: o horário foi antes de o monitor começar a guardar o histórico.
desligado: a variável CRON_*_ENABLED não está true.
espera na fila: tempo entre enfileirar e começar. Cresce quando um job longo segura os outros.
Como o cronQueue.js roda um job por vez, toda linha de erro entre o início e a conclusão de um job pertence a ele. O que fica fora da tela: empresas com falha e a tabela cron_sync_execucoes, que estão no banco. O monitor não acessa banco, por decisão.
Pods cortex-prd
| Nome | Ready | Status | Restarts | Idade | Node | IP |
|---|
Agora, contra o configurado
No Autopilot o request é o que se paga, não o uso real.
| Pod | CPU | Memória | Node |
|---|
Picos de memória guardados pelo monitor
O monitor lê o consumo a cada 60s, mesmo sem ninguém olhando, e guarda o maior valor. É o número que falta para decidir se a memória de produção fica em 2Gi: o pico durante importação de planilha, porque o multer carrega o arquivo inteiro na RAM. Limite: o metrics-server tira média em janelas curtas, então um pico de poucos segundos pode não aparecer.
Rotinas automáticas (cortex-cron)
O normal aqui é ligado. É o contrário do beat do Sinapse. Desligar para o faturamento das empresas e os outros seis jobs, e nada religa sozinho. Nunca passa de 1 réplica: dois pods sincronizam o faturamento duas vezes.
Processamento em fila (cortex-worker)
O worker consome a fila background_jobs. O normal é 1. O monitor não enxerga essa fila: ela fica no banco, e o monitor não acessa banco. Antes de parar, confira a fila com o dev. cortex-api e cortex-front não aparecem aqui: zerar derruba o sistema, e a restrição está no RBAC.
Desligar uma rotina específica
Muda a variável CRON_*_ENABLED do deployment. Tem dois efeitos colaterais: reinicia o pod do cron (cerca de 1 minuto em que nenhuma rotina roda) e diverge do repositório: o próximo deploy:prod religa sem avisar. Enquanto durar, a visão geral mostra quem desligou e por quê. Para parar todas, use o cartão de cima.
Reiniciar ou voltar versão
Reiniciar recria os pods. Um por vez, esperando ficar Running. O cortex-cron usa Recreate: reiniciar no meio de um job interrompe o job.
Voltar versão troca a imagem por uma anterior. No Cortex a ConfigMap e o Secret são aplicados à mão e nunca entram na revisão: se a causa estava neles, voltar versão não resolve.
Últimas ações
Console
somente leituraget, describe, logs, top e events. Contexto e namespace são do monitor. Secret e ConfigMap ficam fora: get -o yaml imprimiria configuração sensível.