Oi pessoal
Estou escalando uma plataforma n8n multi-tenant e começando a perceber que logs básicos não são mais suficientes.
Arquitetura atual:Load Balancer
↓
Vários Workers n8n
↓
PostgreSQL + Redis + APIs Externas
Com o crescimento do número de tenants e workflows, estou achando difícil responder perguntas como:
• Qual tenant está gerando mais carga?
• Por que um workflow específico falhou?
• Onde estão os gargalos do sistema?
• Quais APIs externas estão causando latência?
• Como faço para detectar problemas antes dos clientes perceberem?
Estou considerando adicionar:
• Log centralizado
• Coleta de métricas
• Rastreamento distribuído
• Dashboards por tenant
• Alertas e detecção de anomalias
Exemplo de métricas:tenant_id
workflow_id
execution_time
error_rate
queue_depth
API_latency
Qual stack de observabilidade vocês estão usando?
Quais métricas foram mais valiosas?
Descrever o problema/erro/pergunta
Qual é a mensagem de erro (se houver)?
Por favor, compartilhe seu workflow
(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)
Ei @Greg_John Conforme sua plataforma cresce, fica mais difícil entender o que está acontecendo apenas olhando para os logs. É por isso que ter uma boa observabilidade é tão importante.
Uma configuração típica de produção inclui:
Registro centralizado
Coleta de métricas
Alertas
Rastreamento (se necessário)
As coisas mais úteis para monitorar são:
• tenant_id
• workflow_id
• Tempo de execução
• Taxa de erro
• Profundidade da fila
• Tempo de resposta da API externa
Adicionar tenant_id e workflow_id aos seus logs e métricas torna muito mais fácil encontrar e solucionar problemas para um cliente ou fluxo de trabalho específico.
Também é uma boa ideia configurar alertas para:
Altas taxas de erro
Acúmulo de filas
Falhas de workers
APIs externas lentas
Picos inesperados de tráfego
Um erro a evitar é confiar apenas em logs de aplicação ou monitorar apenas sua infraestrutura. Você precisa de visibilidade tanto nos seus fluxos de trabalho quanto nos sistemas que os executam.
Em resumo, centralizar seus logs e métricas, etiquetá-los adequadamente e configurar dashboards e alertas ajudarão você a identificar problemas cedo e manter sua plataforma funcionando tranquilamente conforme cresce.
Oi @Greg_John
n8n possui seu próprio endpoint Prometheus, então a camada de coleta é apenas uma mudança de configuração, não algo que você constrói. Defina isso nos mains e nos workers:
A profundidade da fila vem de n8n_scaling_mode_queue_jobs_waiting e n8n_scaling_mode_queue_jobs_active. n8n lê essas métricas do Bull e as expõe apenas nos mains, então aponte o job de scrape para os mains para o estado da fila e para os workers para execução e timings de nós. Workflow ID é a label mais granular que n8n emite, não há dimensão de tenant, então faça o join workflow-para-tenant na relabelagem do Prometheus ou em uma regra de gravação e construa as visualizações de tenant sobre essa série. Mantenha /metrics na rede interna, pois expõe detalhes operacionais da instância.
Obrigado, isso é realmente útil. Gosto do ponto sobre marcar tudo com tenant_id e workflow_id—isso tornaria a resolução de problemas muito mais fácil em uma configuração multi-tenant. Também concordo que monitorar workflows é tão importante quanto monitorar a infraestrutura. Agradeço você compartilhar isso.
Obrigado pela perspectiva! Isso é um ponto de vista útil e me dá algumas ideias para melhorar minha configuração. Vou investigar essa abordagem e ver como ela se adequa à minha arquitetura.
A maior parte deste tópico é um conselho genérico de observabilidade. As partes específicas do n8n são onde as respostas às suas cinco perguntas realmente estão, então:
Profundidade da fila e carga por tenant já estão expostas — você não precisa construí-las. O n8n envia um endpoint Prometheus que está desativado por padrão: N8N_METRICS=true oferece /metrics no principal. Os sinalizadores que importam para seu caso são N8N_METRICS_INCLUDE_QUEUE_METRICS (essa é sua queue_depth), N8N_METRICS_INCLUDE_WORKFLOW_ID_LABEL e N8N_METRICS_INCLUDE_NODE_TYPE_LABEL (séries por workflow e por tipo de nó, que é como “qual tenant está gerando mais carga” e “qual API externa está lenta” se tornam uma consulta PromQL em vez de um projeto de logging). Coloque-o em qualquer lugar que você já execute. Observe a cardinalidade se você tiver muitos workflows — o rótulo workflow-id é o que o torna útil e também o que o torna caro.
Sua métrica error_rate mentirá para você, e essa é a que morde em escala multi-tenant. Uma execução n8n termina com status success em muitos casos onde nada realmente aconteceu: um nó que retorna zero itens apenas passa zero itens para baixo e tudo depois disso silenciosamente não faz nada; um IF sem ramo correspondente; a saída done de um Split In Batches que ninguém conectou. A execução está verde, a taxa de erro fica plana, e os dados do tenant simplesmente não se movem. Então não monitore apenas erros — faça asserções sobre resultados. Emita uma contagem de itens no final de cada workflow do tenant e alerte quando processed == 0 quando zero não é um resultado legítimo. Sucesso silencioso é o modo de falha que chega aos seus clientes antes de chegar ao seu painel.
“Detectar problemas antes que os clientes notem” precisa de um dead-man’s switch, não de um alerta. O Error Trigger / Error Workflow é o gancho de alerta correto por tenant — configure-o por workflow e coloque o suficiente no payload para ser acionável ($execution.id, o nome do workflow, o nó falhando e os dados do último nó; um alerta que apenas diz “workflow falhou” consome uma sessão de debugging toda vez). Mas observe o que estruturalmente ele não consegue fazer: o Error Trigger nunca dispara para uma execução que nunca começou. Um gatilho agendado travado, um worker preso, um workflow que alguém desativou — todos produzem silêncio, e silêncio parece exatamente com “tudo está bem.” A solução é invertida: faça cada workflow do tenant enviar um ping a um watchdog na conclusão e alerte quando o ping está ausente. Essa verificação única captura toda a classe de falha que seus logs não conseguem ver por construção.
Seu gargalo é provavelmente execution_entity. Em volume multi-tenant, a tabela de dados de execução é o que torna o Postgres lento, e cresce silenciosamente. EXECUTIONS_DATA_PRUNE=true com um EXECUTIONS_DATA_MAX_AGE real e EXECUTIONS_DATA_PRUNE_MAX_COUNT, e para tenants de alto volume considere EXECUTIONS_DATA_SAVE_ON_SUCCESS=none — manter payloads de sucesso completos para cada execução é um custo grande para dados que você nunca abrirá. Faça limpeza antes de otimizar consultas; muito de “n8n é lento” acaba sendo isso.
Uma coisa que vale a pena decidir cedo, já que você é multi-tenant: essa tabela de execução contém os payloads reais dos seus tenants. Se algum deles estiver na UE, o execution DB é uma location de processamento, e a retenção lá é uma questão de compliance, não apenas de disco. Muito mais barato estabelecer a política agora do que explicá-la depois.