For the complete documentation index, see llms.txt. This page is also available as Markdown.

Como interpretar alertas de publicação e entrega de eventos

Saiba como interpretar os logs e alertas relacionados à publicação e entrega de eventos na Digibee Integration Platform, e o que fazer em cada caso.

Visão geral

Pipelines que usam Event Publisher e Event Trigger se comunicam por meio da camada de mensageria da plataforma. Para ajudar você a identificar problemas de configuração antes que afetem a produção, a plataforma exibe dois tipos de sinais:

  • Logs em tempo de execução, registrados quando um pipeline publica um evento durante a execução.

  • Alertas em tempo de deploy, exibidos quando você faz o deploy de um pipeline, antes de o evento ser publicado.

Nenhum desses sinais indica, por si só, uma falha de entrega. Eles são diagnósticos: use-os para confirmar que um Publisher e seu Subscriber correspondente estão corretamente pareados e implantados.

Log

Evento publicado sem subscriber

Quando um pipeline publica um evento e nenhum pipeline está inscrito para consumi-lo, a plataforma registra uma entrada de log indicando que o evento foi publicado sem subscriber.

Event pipeline-name was published but reached no consumer. 

Esse log não indica uma falha: o evento é publicado normalmente. Ele serve para ajudar você a identificar casos em que uma inscrição está faltando ou em que o pipeline Subscriber ainda não foi publicado.

O que verificar

  • Confirme que existe um pipeline com Event Trigger configurado para consumir o evento, e que a propriedade Event Name corresponde exatamente ao nome do evento definido no Event Publisher.

  • Confirme que o pipeline Subscriber está publicado e em execução.

  • Faça o redeploy do pipeline Publisher caso o pipeline Subscriber tenha sido reimplantado recentemente.

Alertas em tempo de deploy

Ao fazer o deploy de um pipeline com Event Publisher ou Event Trigger, a plataforma pode exibir um dos alertas a seguir. Nenhum deles bloqueia o deploy, e você ainda pode fazer o deploy após revisar o aviso.

"Este evento não possui consumidores implantados ativos no momento"

Esse alerta aparece quando o parâmetro Event usa um nome de evento estático (fixo) e nenhum pipeline com um Event Trigger correspondente está atualmente implantado e ativo para esse evento.

O que verificar

  • Confirme que existe um pipeline com Event Trigger para esse evento, e que sua propriedade Event Name corresponde exatamente.

  • Confirme que o pipeline Subscriber está implantado e ativo, não apenas salvo como rascunho.

"O nome do evento não pôde ser determinado no momento do deploy e não foi verificado"

Esse alerta aparece quando o parâmetro Event usa uma expressão Double Braces em vez de um nome estático, por exemplo:

Como o nome do evento depende de dados em tempo de execução, a plataforma não consegue verificar no momento do deploy se existe um Subscriber ativo para ele. Isso é esperado para nomes de evento dinâmicos e não indica necessariamente a ausência de um Subscriber.

O que verificar

  • Como nomes de evento dinâmicos não podem ser verificados no momento do deploy, a plataforma também não consegue confirmar se algum Subscriber deste evento ainda está no fluxo de eventos legado. Como precaução, faça o redeploy de qualquer pipeline que você sabe que consome este evento para garantir que ele esteja no novo fluxo de eventos.

"Existem consumidores deste evento ainda executando no fluxo de eventos legado"

Esse alerta aparece quando um ou mais pipelines ainda consomem este evento no fluxo de eventos legado. O alerta lista cada evento e pipeline Subscriber afetado, por exemplo:

Um mesmo evento pode ter múltiplos pipelines Subscriber listados caso mais de um deles ainda esteja no fluxo de eventos legado.

O que verificar

  • Identifique o pipeline Subscriber (ou pipelines) mostrado no alerta e faça o redeploy deles para que recebam este evento no novo fluxo de eventos.

Se os dois lados estiverem temporariamente desalinhados, a entrega de eventos continua funcionando, mas as configurações de timeout e reentrega (Allow Redelivery Of Messages) podem não se aplicar até que os dois pipelines sejam reimplantados.

Atualizado

Isto foi útil?