Olá a todos,
Estou executando múltiplas instâncias do n8n no Google Cloud Run usando uma única chave de licença.
Qual é a melhor maneira de rastrear o uso por implantação/tenant (execuções, fluxos de trabalho ativos, uso de API, etc.)?
Oi @rgrzesk
Acho que a melhor forma é usar o insights:
Mas se você quer múltiplas instâncias de dados em um único frame, então eu recomendaria isso:
Eu usei e funciona o tempo todo.
Além disso, você pode simplesmente chamar a API N8N:
GET /api/v1/executions?status=success&limit=250
Se você não está no n8n cloud, a opção Ud metrics é a melhor.
Isso ajuda, @rgrzesk ?
Para rastrear várias instâncias do Cloud Run em um único lugar, a abordagem de polling da API não escalará bem — cada instância tem seu próprio endpoint de API e não há uma visualização unificada. Um padrão mais limpo é adicionar um workflow dedicado de “execution logger” (logger de execução) a cada instância: ele é executado em um cronograma, acessa GET /api/v1/executions com uma janela de tempo, adiciona uma tag instance_id e publica os resultados em uma tabela Postgres compartilhada ou Google Sheet. Assim você tem um único lugar centralizado para consultar o uso em todas as instâncias. Você pode incluir o nome do serviço Cloud Run como identificador da instância por meio de uma variável de ambiente injetada no momento da implantação.
Isso soa muito bem, mas o problema é que não tenho e não terei acesso a todas as instâncias. Posso orquestrá-las, mas não posso ser um usuário.
Eu precisaria criar tal fluxo de trabalho predefinido ao fazer o deploy, mas acho que não é possível fazer isso facilmente. A única maneira é usar de alguma forma dados disponíveis publicamente. É possível usar o endpoint /metric? Vou obter dados suficientes que eu possa usar?
Se você não tem acesso via API/usuário em cada instância, eu trataria /metrics como um sinal parcial de infraestrutura, não como um modelo completo de uso.
Pode ajudar com perguntas como “essa instância está ativa, quão ocupada está, as execuções estão falhando mais do que o usual”, mas geralmente não vai lhe dar uma atribuição de negócio clara como uso de tenant, contagem de workflows ativos por cliente, ou chamadas de API faturáveis, a menos que você tenha projetado a implantação com esses rótulos desde o início.
Para seu caso, como você consegue orquestrar a implantação, eu moveria o limite de rastreamento para o template de implantação:
-
dê a cada serviço Cloud Run um rótulo
deployment_id/tenant_idestável -
ative a exportação de métricas/logs no momento da implantação, não depois que o cliente começar a usar
-
faça os logs do Cloud Run incluírem o mesmo rótulo de implantação
-
se possível, pré-instale um pequeno workflow de logging interno durante o provisionamento
-
se o acesso ao workflow não for possível, pelo menos colete saúde da instância, totais de execução, falhas, latência e sinais de reinicialização/erro centralizadamente
A parte importante é que o ID deve existir fora do n8n também. Se cada instância emite métricas mas elas chegam sem um rótulo de implantação estável, você ainda vai acabar com um monte global de números que é difícil de reconciliar.
Então eu usaria /metrics para monitoramento operacional, mas não dependeria apenas disso para relatórios de tenant/cliente. Para relatórios de uso eu gostaria de um workflow de logging predefinido, acesso via API, ou rótulos no nível de implantação que seu coletor adiciona antes dos dados chegarem no armazenamento central.
Obrigado, faz sentido.
E quanto a usar o BD como fonte de verdade para o histórico/uso de licenças? Faria sentido, mantém os dados que preciso?
Verificando por execution_entity e contando todos os que não estão marcados como manual?
Oi @rgrzesk
existe outra abordagem para sua configuração que é o rastreamento com OpenTelemetry. Como você controla a implantação, defina essas variáveis de ambiente durante o provisionamento:
N8N_OTEL_TRACE_ENABLED=true
N8N_OTEL_TRACE_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=https://your-central-collector:4318
Cada execução emite um span workflow.execute com o modo de execução, status, ID do fluxo de trabalho e o n8n.instance.id único da instância. Aponte todas as instâncias para um coletor (Jaeger, Grafana Tempo, etc.) e você obtém rastreamento por instância, por execução com filtragem de modo. Sem necessidade de acesso ao BD, sem risco de limpeza, protocolo padrão, e é configurado inteiramente no momento da implantação, o que se encaixa perfeitamente nas suas restrições.
Como alternativa pela rota do BD: sim, execution_entity com mode != 'manual' funciona, mas esteja ciente de que a limpeza deleta esses registros com base em EXECUTIONS_DATA_MAX_AGE. Agregue em seu próprio armazenamento em um cronograma mais curto do que a janela de limpeza.
Me avise se ajuda 
Ótimo!
OL é uma boa solução para instâncias já novas. Conseguimos de alguma forma obter dados históricos também?
OTel só captura a partir do momento em que é ativado, sem rastreamentos retroativos.
Para dados históricos em instâncias existentes, duas opções já que você tem acesso ao BD:
-
Tabela
execution_entity: consultemode != 'manual'para contagens de produção. Apenas tão longe quanto a limpeza permite. -
Tabelas Insights: n8n armazena dados de insights compactados separadamente da execution_entity, retidos por até 365 dias por padrão (
N8N_INSIGHTS_MAX_AGE_DAYS). Isso sobrevive à limpeza de execução. Verifique as tabelasinsight_*em seu schema Postgres para contagens históricas agregadas.
Para qualquer coisa mais antiga do que o que está no BD, é irreversível.
Oi!
Tive uma pausa bem vinda do assunto, mas estou voltando 
Que legal que a partir da versão 2.27.0 também consigo configurar OpenTelemetry na interface!
Porém tenho duas dúvidas:
- Consigo ocultar essas opções? Porque expõe a API key do sistema de opentelemetry.
- Em qual execution.mode devo procurar no OTL? Quer dizer - quais deles são faturáveis? Também os !manual?
EDIT - para a pergunta 2. - acabei de notar que já existe uma flag N8N_OTEL_TRACES_PRODUCTION_ONLY