Ir para o conteúdo

Erros de conexão, websocket e E/S em agentes privados Jitterbit usando VMs do Azure

Visão geral

Esta página fornece instruções sobre como solucionar problemas de um agente privado Linux ou Windows instalado em uma máquina virtual (VM) do Microsoft Azure. (Consulte Ajuste de desempenho do agente privado para informações gerais sobre ajuste de desempenho.)

Solucionar problemas de conexões perdidas

Ao usar um agente privado instalado em uma VM do Microsoft Azure, você pode ter conexões perdidas. O Azure define o tempo limite de inatividade do WebSocket para 4 minutos, enquanto o padrão do agente privado para ping Harmony é definido para 5 minutos. Para resolver esse problema, reduza o intervalo para o heartbeat do agente:

  1. Abra o jitterbit-agent-config.properties arquivo em um editor de texto. Este arquivo pode ser encontrado nestes diretórios:

    • Linux: <JITTERBIT_HOME>/Resources/

    • Windows: C:\Program Files\Jitterbit Agent\Resources

  2. Encontre o agent.heart.beat.interval configuração:

    #Agent heart beat interval (IN MINUTES)
    agent.heart.beat.interval=5
    
  3. Altere a configuração para agent.heart.beat.interval=3.

  4. Salve as alterações e reinicie o agente.

Solucionar problemas de websocket e erros de E/S

Importante

Planeje para que as etapas a seguir levem mais de 30 minutos para serem concluídas.

Erros relacionados a WebSocket e E/S podem ser resolvidos com atualizações nas configurações de tempo limite de inatividade de IP associado à VM, tempo limite de inatividade de TCP do gateway de tradução de endereço de rede (NAT) e tempo limite de fluxo de rede virtual (VNET).

Os valores de tempo limite de inatividade de IP, tempo limite de inatividade de TCP do gateway NAT e tempo limite de fluxo de VNET devem ser definidos como 15 minutos.

Identificar erros relevantes

Erros de WebSocket e E/S podem ser identificados referenciando os logs de operação e o jitterbit-agent.log arquivo. Este arquivo de log pode ser encontrado em um dos seguintes locais:

  • Para Windows: C:\Program Files (x86)\Jitterbit Agent\log\jitterbit-agent.log.

  • Para Linux: /opt/jitterbit/log/jitterbit-agent.log.

Erros de log de operação

Se presente, qualquer uma das seguintes mensagens nos detalhes do log de operação para uma operação com status Erro pode ser indicativa de um erro de WebSocket ou de E/S:

The operation "Example Operation" completed successfully.
No message found while removing message in cache for: Message Info: AgentId: 000001 AgentGroupId: 000001 MessageId: XXX Message Version (Agent): XXXX Message Version (Harmony): XXX Counter (Harmony): 1 Submitted Timestamp (Harmony):2024-01-20 11:55:00.700, message will be retried later OperationInstanceGUID: XXX
Run message could not reach the agent.

Erros no arquivo de log do Agente

Se presente, qualquer uma das seguintes mensagens no jitterbit-agent.log arquivo pode ser indicativo de um erro de WebSocket ou de E/S:

2024-01-20 12:00:00 request handler thread #10642  INFO org.jitterbit.integration.server.api.util.AgentRetryExecutor:53 - Agent Message Receipt (OperationInstanceGUID: XXX) failed. Retrying....
2024-01-20 12:00:00 request handler thread #10642 ERROR org.jitterbit.integration.server.api.util.AgentRetryExecutor:55 - org.springframework.web.client.ResourceAccessException: I/O error on PUT request for "https://na-east.jitterbit.com/jitterbit-cloud-restful-service/agent/ackmsgreceipt": Read timed out; nested exception is java.net.SocketTimeoutException: Read timed out
E:2024-01-20 12:00:00 request handler thread #884 ERROR org.jitterbit.integration.server.messaging.agent.listener.AgentMessageListener:231 - No message found while removing message in cache for: Message Info: AgentId: 000001 AgentGroupId: 000001 MessageId: XXX Message Version (Agent): XXXX Message Version (Harmony): XXX Counter (Harmony): 1 Submitted Timestamp (Harmony):2024-01-20 11:55:00.700, message will be retried later OperationInstanceGUID: XXX

Importante

Continue somente se um erro de WebSocket ou de E/S foi identificado nos logs de operação ou nos logs do agente com base nos critérios acima.

Drenar o agente de parada

Parada de drenagem o agente antes de atualizar quaisquer configurações de tempo limite. Se você tiver mais de um agente no grupo de agentes afetado, faça o mesmo para todos eles.

Isolar recursos do agente

É recomendável que a VM do agente e seus recursos associados sejam separados em seu próprio grupo de recursos no Azure. Isso inclui sua VNET, IP, gateway NAT, interface de rede (NIC) e grupo de segurança de rede (NSG), se presente.

Atualizar o tempo limite de inatividade do IP

  1. No portal do Azure, navegue até o grupo de recursos associado à VM do agente.

  2. Identifique e clique no item IP associado à VM:

    Tempo limite do Azure 1

  3. Clique em Configuração e altere o valor Tempo limite de inatividade (minutos) para 15 minutos:

    Tempo limite do Azure 2

Atualizar o tempo limite de inatividade do TCP do gateway NAT

  1. No portal do Azure, navegue até o grupo de recursos associado à VM do agente.

  2. Identifique e clique no item NAT gateway associado à VM e ao IP, se presente. Um gateway NAT associado também será listado na Visão geral do item IP ao lado do campo Associado a.

  3. Clique em Configuração e altere o valor Tempo limite de inatividade do TCP (minutos) para 15 minutos.

Atualizar o tempo limite do fluxo da VNET

  1. No portal do Azure, navegue até o grupo de recursos associado à VM do agente.

  2. Identifique e clique no item VNET associado à VM:

    Tempo limite do Azure 3

  3. Em Visão geral, clique em Configurar ao lado de Tempo limite de fluxo:

    Tempo limite do Azure 4

  4. No painel Tempo limite de fluxo, ative a configuração Ativar tempo limite de fluxo e altere o valor Tempo limite de fluxo (minutos) para 15 minutos:

    Tempo limite do Azure 5

  5. Clique em Salvar.

Reinicie o agente

  1. No portal do Azure, reinicie a VM do agente.

  2. Reinicie o agente parado. Veja Reiniciar um agente do Windows ou Reiniciar um agente Linux para informações detalhadas.