O n8n agora oferece suporte nativo ao OpenTelemetry, permitindo que cada execução de fluxo de trabalho seja emitida como um rastreamento, de modo que o n8n apareça dentro da mesma pilha de observabilidade que sua equipe já usa para o restante da produção.
Não há sidecar para executar e nenhum patch para manter, e como tudo é construído no padrão OTLP, também não há dependência de fornecedor. Aponte n8n para qualquer coletor ou back-end compatível com OTLP, seja Jaeger, Tempo, Datadog, Honeycomb, New Relic ou Grafana Cloud, e você começará a ver o que seus fluxos de trabalho realmente fazem em tempo de execução.
Por que isso é importante
Os fluxos de trabalho tornaram-se sistemas de produção. Eles processam pagamentos, encaminham tickets de suporte, sincronizam dados de CRM, orientam agentes de IA e mantêm as operações internas em andamento. Assim, quando algo dá errado dentro de um deles, as perguntas são as mesmas que você faria em qualquer outro serviço. Qual etapa falhou, quanto tempo demorou, como foi chamada e o que voltou?
Até agora, responder a essas perguntas no n8n significava viver dentro da visão de execução. Isso é bom para um fluxo de trabalho em uma única instância, mas tende a falhar nas situações mais importantes. Imagine um webhook de seu aplicativo atingindo n8n, n8n chamando três serviços downstream, um desses serviços lento e o engenheiro de suporte de plantão sentado no Datadog sem ter ideia de que n8n está no caminho.
Com o suporte OpenTelemetry, o n8n se torna um participante de primeira classe no rastreamento distribuído. Cada execução de fluxo de trabalho produz um intervalo raiz que contém informações de status, duração e erro, e você pode ativar um intervalo filho opcional para cada nó, para que seja fácil ver qual etapa está lenta ou com falha.
O que você pode fazer com isso
Considere um engenheiro de plantão em uma fintech que usa n8n para orquestrar a reconciliação de pagamentos. Um cliente relata que um reembolso demorou vinte minutos para chegar. No Datadog, o engenheiro obtém o rastreamento dessa solicitação de reembolso e vê o caminho completo, desde o gateway da API até o serviço de pagamentos, até o fluxo de trabalho n8n que se estende até uma verificação de fraude, o razão e uma etapa de notificação, e até a API bancária downstream. A lentidão está aí, uma chamada de verificação de fraude de terceiros que atingiu o tempo limite e foi repetida duas vezes. O engenheiro sabe exatamente qual nó, em qual fluxo de trabalho, em qual instância e com quais entradas, sem coleta de logs e sem suposições.
Ou considere uma equipe de plataforma lançando um novo agente de IA integrado ao n8n. O agente chama um LLM, acessa uma API de pesquisa interna, faz write-back em um banco de dados e publica uma atualização no Slack. Antes do OTel, a equipe podia ver a execução dentro do n8n e a chamada LLM dentro do painel do provedor de IA, mas unir os dois era um trabalho manual. Com o OTel habilitado, tudo se torna um rastreamento conectado, amostrado e armazenado no mesmo back-end que o restante de seus serviços.
E para uma equipe executando o n8n no modo de fila em vários trabalhadores, os rastreamentos desses trabalhadores direcionam corretamente para o processo principal. Contanto que as mesmas variáveis de ambiente do OTel sejam definidas em todas as instâncias, a imagem permanece coerente.
Como funciona
n8n emite spans sobre HTTP OTLP usando codificação Protobuf, então qualquer coisa que fale OTLP pode recebê-los. A parte que torna isso genuinamente ponta a ponta, em vez de apenas interno ao n8n, é a propagação do contexto de rastreamento.
No lado de entrada, se uma solicitação de webhook para n8n incluir um traceparent cabeçalho, o intervalo de execução do fluxo de trabalho é criado como filho desse rastreamento, de modo que o sistema que chamou n8n mantém uma visão contínua da solicitação. No lado de saída, os nós de solicitação HTTP podem injetar traceparent em chamadas de saída para que os serviços downstream continuem o rastreamento sob o mesmo ID de rastreamento. Os intervalos de subfluxos de trabalho são parentados do intervalo do fluxo de trabalho de chamada, o que preserva a hierarquia de chamadas, e quando um fluxo de trabalho é retomado após uma espera, o novo intervalo usa um link de intervalo para apontar de volta para o anterior, de modo que orquestrações de longa duração permaneçam rastreáveis durante as pausas. Esta é a parte que transforma o rastreamento de uma conveniência de depuração em algo em que uma equipe SRE realmente confiará.
Comece
A configuração mínima consiste em duas variáveis de ambiente definidas em cada instância n8n na qual você deseja que o rastreamento de fluxo de trabalho seja ativado:
export N8N_OTEL_ENABLED=true
export N8N_OTEL_EXPORTER_OTLP_ENDPOINT=http://:4318
A referência completa de configuração e um passo a passo local do Jaeger estão no Documentos do OpenTelemetry.
O que vem a seguir
Esta versão cobre o rastreamento de execução do fluxo de trabalho, que é a base, e já há mais em andamento. Estamos trabalhando em rastreamentos de agentes mais profundos, com extensões mais ricas dentro de nós de agentes de IA para chamadas LLM, chamadas de ferramentas e etapas de avaliação, para que as plataformas de rastreamento e avaliação obtenham o sinal de que precisam. Estamos criando rastreamento de aplicativos que revelará rastreamentos de dentro do próprio n8n, incluindo consultas de banco de dados, tempo de endpoint de API e erros internos. E planejamos adicionar métricas de instância, para que sinais operacionais como profundidade de fila, fluxos de trabalho ativos e medidores de recursos possam ser exportados da mesma maneira.
A direção é consistente por toda parte. Qualquer sinal que um operador ou desenvolvedor esperaria de um serviço de produção deve ser emitido por meio de padrões abertos, no backend de sua escolha.
