Soluções para problemas comuns no Azure IoT Edge

Aplica-se a: IoT Edge 1.5

Use este artigo para identificar e resolver problemas comuns ao utilizar soluções IoT Edge. Para informações sobre como encontrar logs e erros do seu dispositivo IoT Edge, veja Resolva problemas do seu dispositivo IoT Edge.

Aprovisionamento e implantação

O módulo IoT Edge é implementado com sucesso e depois desaparece do dispositivo

Sintomas

Depois de definir módulos para um dispositivo IoT Edge, os módulos são implementados com sucesso, mas passados alguns minutos desaparecem do dispositivo e dos detalhes do dispositivo no portal Azure. Outros módulos além dos definidos também podem aparecer no dispositivo.

Causa

Se uma implantação automática tiver como alvo um dispositivo, ela terá prioridade sobre a configuração manual dos módulos para um único dispositivo. A funcionalidade de módulos Set no portal do Azure ou Create deployment for single device em Visual Studio Code tem um efeito temporário. Você vê os módulos que você definiu iniciar no dispositivo. Em seguida, a prioridade de implantação automática inicia-se e substitui as propriedades desejadas do dispositivo.

Solução

Utilize apenas um tipo de mecanismo de implementação por dispositivo, seja uma implementação automática ou implementações individuais de dispositivos. Se você tiver várias implantações automáticas direcionadas a um dispositivo, poderá alterar as descrições de prioridade ou destino para garantir que a correta se aplique a um determinado dispositivo. Você também pode atualizar o dispositivo gêmeo para não corresponder mais à descrição de destino da implantação automática.

Para mais informações, consulte Compreender as distribuições automáticas do IoT Edge em escala ou para dispositivos individuais.

Runtime do IoT Edge

O agente IoT Edge para ao fim de um minuto

Sintomas

O módulo edgeAgent é iniciado e executado com êxito por cerca de um minuto e, em seguida, para. Os registos mostram que o agente IoT Edge tenta ligar-se ao IoT Hub via AMQP, e depois tenta ligar-se usando AMQP via WebSocket. Quando essa ligação falha, o agente IoT Edge sai.

Exemplo de logs do edgeAgent:

2017-11-28 18:46:19 [INF] - Starting module management agent.
2017-11-28 18:46:19 [INF] - Version - 1.0.7516610 (03c94f85d0833a861a43c669842f0817924911d5)
2017-11-28 18:46:19 [INF] - Edge agent attempting to connect to IoT Hub via AMQP...
2017-11-28 18:46:49 [INF] - Edge agent attempting to connect to IoT Hub via AMQP over WebSocket...

Causa

Uma configuração de rede na rede anfitriã impede que o agente IoT Edge chegue à rede. O agente primeiro tenta ligar através de AMQP (porta 5671). Se a conexão falhar, ele tenta WebSockets (porta 443).

O runtime do IoT Edge estabelece uma rede para cada módulo se comunicar. No Linux, esta rede é uma rede de ponte. No sistema operativo Windows, utiliza NAT. Este problema é mais comum em dispositivos Windows que usam containers Windows que utilizam a rede NAT.

Solução

Certifique-se de que existe uma rota para a internet para os endereços IP atribuídos a esta bridge ou rede NAT. Por vezes, uma configuração de VPN no host sobrepõe-se à rede IoT Edge.

O módulo do Agente do Edge indica "ficheiro de configuração vazio" e nenhum módulo é iniciado no dispositivo

Sintomas

• O dispositivo tem problemas para iniciar os módulos definidos na implantação. Só o edgeAgent está a correr, mas reporta ficheiro de configuração vazio....

• Quando executa sudo iotedge check num dispositivo, ele reporta O motor Container não está configurado com as definições do servidor DNS, o que pode afetar a conectividade com o IoT Hub. Consulte https://aka.ms/iotedge-prod-checklist-dns para as melhores práticas.

Causa

• Por padrão, o IoT Edge inicia módulos na sua própria rede de contentores isolados. O dispositivo pode ter problemas com a resolução de nomes DNS dentro desta rede privada.
• Se usar uma instalação rápida do IoT Edge, o ficheiro de configuração do Docker está noutro local. Consulte a opção 3 da solução.

Solução

Opção 1: Definir o servidor DNS nas configurações do mecanismo de contêiner

Especifique o servidor DNS para seu ambiente nas configurações do mecanismo de contêiner. Estas definições aplicam-se a todos os módulos de contentores que o motor inicia. Crie um ficheiro chamado daemon.json, e especifique o servidor DNS a usar. Por exemplo:

{
    "dns": ["1.1.1.1"]
}

Este servidor DNS está definido como um serviço DNS acessível publicamente. No entanto, algumas redes, como as redes corporativas, têm os seus próprios servidores DNS e não permitem o acesso a servidores DNS públicos. Portanto, se o dispositivo de borda não puder acessar um servidor DNS público, substitua-o por um endereço de servidor DNS acessível.

Coloque daemon.json no diretório /etc/docker do seu dispositivo.

Se o local já contiver um daemon.json arquivo, adicione a chave dns a ele e salve o arquivo.

Reinicie o motor de contentor para que as atualizações entrem em vigor.

sudo systemctl restart docker

Opção 2: Definir o servidor DNS em IoT Edge implementação por módulo

Pode definir o servidor DNS para a secção createOptions de cada módulo na implementação IoT Edge. Por exemplo:

"createOptions": {
  "HostConfig": {
    "Dns": [
      "x.x.x.x"
    ]
  }
}

Certifique-se de definir essa configuração para os módulos edgeAgent e edgeHub também.

Opção 3: Passe o local do arquivo de configuração do docker para verificar o comando

Se instalares IoT Edge como snap, usa o parâmetro --container-engine-config-file para especificar a localização do ficheiro de configuração do Docker. Por exemplo, se o arquivo de configuração do Docker estiver localizado em /var/snap/docker/current/config/daemon.json, execute o seguinte comando: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'.

Atualmente, a mensagem de aviso continua a aparecer na saída da verificação do iotedge mesmo depois de definir a localização do ficheiro de configuração. O Check reporta o erro porque o snap do IoT Edge não tem acesso de leitura ao snap do Docker. Se você usar iotedge check em seu processo de liberação, poderá suprimir a mensagem de aviso usando o --ignore container-engine-dns container-engine-logrotate parâmetro.

O módulo do Edge Agent com conexão LTE relata 'configuração vazia do Edge Agent' e causa 'erro de rede transitório'

Sintomas

Um dispositivo configurado com uma ligação LTE apresenta problemas ao iniciar módulos definidos na implementação. O edgeAgent não consegue ligar-se ao IoT Hub e reporta "configuração vazia do edge agent" e "ocorreu um erro transitório de rede".

Causa

Algumas redes têm overhead de pacotes, o que torna a MTU padrão da rede docker (1500) demasiado alta e causa fragmentação de pacotes. Esta fragmentação impede o acesso a recursos externos.

Solução

1. Verifique a configuração de MTU para sua rede docker.

   docker network inspect <network name>

2. Verifica as definições MTU para o adaptador físico de rede do teu dispositivo.

   ip addr show eth0

Se você vir um tamanho de MTU diferente para sua rede docker e o dispositivo, tente a seguinte solução alternativa:

1. Crie uma nova rede. Por exemplo,

   docker network create --opt com.docker.network.driver.mtu=1430 test-mtu

   No exemplo, a configuração de MTU para o dispositivo é 1430. Defina a MTU da rede Docker para 1430.

2. Pare e remova a rede Azure.

   docker network rm azure-iot-edge

3. Recriar a rede Azure.

   docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge

4. Remova todos os contêineres e reinicie o serviço aziot-edged .

   sudo iotedge system stop && sudo docker rm -f $(docker ps -aq -f "label=net.azure-devices.edge.owner=Microsoft.Azure.Devices.Edge.Agent") && sudo iotedge config apply

O agente IoT Edge não consegue aceder à imagem de um módulo (403)

Sintomas

Um contêiner não é executado e os logs do edgeAgent relatam um erro 403.

Causa

O módulo IoT Edge agent não tem permissões para aceder à imagem de um módulo.

Solução

Verifique se as credenciais do registo de contentores estão corretas no manifesto de implementação do dispositivo.

O agente IoT Edge faz chamadas excessivas de verificação de identidade.

Sintomas

O agente IoT Edge faz chamadas de identidade excessivas para o Azure IoT Hub.

Causa

A configuração incorreta do manifesto de implantação do dispositivo causa uma implantação malsucedida no dispositivo. A lógica de retry do IoT Edge Agent continua a tentar a implementação repetidamente. Cada nova tentativa faz chamadas de identidade até que a implantação seja bem-sucedida. Por exemplo, se o manifesto de implementação especificar um URI de módulo que não existe no registo do contentor ou está mal digitado, o agente IoT Edge tenta novamente a implementação até que o manifesto de implementação seja corrigido.

Solução

Verifique o manifesto de implementação no portal do Azure. Corrija quaisquer erros e reimplante o manifesto no dispositivo.

Hub IoT Edge falha em arrancar

Sintomas

O módulo edgeHub falha ao iniciar. Pode ver uma mensagem semelhante a um dos seguintes erros nos registos:

One or more errors occurred.
(Docker API responded with status code=InternalServerError, response=
{\"message\":\"driver failed programming external connectivity on endpoint edgeHub (6a82e5e994bab5187939049684fb64efe07606d2bb8a4cc5655b2a9bad5f8c80):
Error starting userland proxy: Bind for 0.0.0.0:443 failed: port is already allocated\"}\n)

Ou

info: edgelet_docker::runtime -- Starting module edgeHub...
warn: edgelet_utils::logging -- Could not start module edgeHub
warn: edgelet_utils::logging --     caused by: failed to create endpoint edgeHub on network nat: hnsCall failed in Win32:
        The process cannot access the file because it is being used by another process. (0x20)

Causa

Algum outro processo na máquina anfitriã ligou uma porta que o módulo edgeHub tenta ligar. O hub IoT Edge mapeia as portas 443, 5671 e 8883 para utilização em cenários de gateway. O módulo falha ao iniciar se outro processo já tiver ligado uma dessas portas.

Solução

Resolva este problema de duas formas:

Se o dispositivo IoT Edge funcionar como um dispositivo gateway, encontre e pare o processo que utiliza a porta 443, 5671 ou 8883. Um erro para a porta 443 geralmente significa que o outro processo é um servidor web.

Se não precisares de usar o dispositivo IoT Edge como gateway, remove as ligações de portas das opções de criação de módulos do edgeHub. Pode alterar as opções de criação no portal Azure ou diretamente no ficheiro deployment.json.

No portal do Azure:

1. Vai ao teu hub IoT e seleciona Dispositivos no menu de gestão de dispositivos .

2. Selecione o dispositivo IoT Edge que pretende atualizar.

3. Selecione Definir Módulos.

4. Selecione Configurações de tempo de execução.

5. Nas configurações do módulo Edge Hub, exclua tudo da caixa de texto Opções de Criação do Contêiner.

6. Selecione Aplicar para salvar as alterações e criar a implantação.

No ficheiro "deployment.json":

1. Abre o ficheiro deployment.json que aplicaste ao teu dispositivo IoT Edge.

2. Encontre as edgeHub configurações na seção de propriedades desejadas do edgeAgent:

     "edgeHub": {
         "restartPolicy": "always",
         "settings": {
            "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
            "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"443/tcp\":[{\"HostPort\":\"443\"}],\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
         },
         "status": "running",
         "type": "docker"
      }
   

3. Remova a linha createOptions e a vírgula no final da linha image antes dela.

     "edgeHub": {
         "restartPolicy": "always",
         "settings": {
         "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
         "status": "running",
         "type": "docker"
   }
   

4. Selecione Create para o aplicar novamente ao seu dispositivo IoT Edge.

O módulo IoT Edge não consegue enviar uma mensagem para o edgeHub e devolve o erro 404

Sintomas

Um módulo de IoT Edge personalizado não consegue enviar uma mensagem para o hub IoT Edge e devolve um erro 404 Module not found. O runtime do IoT Edge imprime a seguinte mensagem nos registos:

Error: Time:Thu Jun  4 19:44:58 2018 File:/usr/sdk/src/c/provisioning_client/adapters/hsm_client_http_edge.c Func:on_edge_hsm_http_recv Line:364 executing HTTP request fails, status=404, response_buffer={"message":"Module not found"}u, 04 )

Causa

Por razões de segurança, o runtime do IoT Edge impõe a identificação de processos para todos os módulos que se ligam ao edgeHub. Verifica se todas as mensagens enviadas por um módulo vêm do ID principal do processo do módulo. Se um módulo tentar enviar uma mensagem a partir de um ID de processo diferente, o runtime rejeita a mensagem e devolve uma mensagem de erro 404.

Solução

A partir da versão 1.0.7, todos os processos do módulo podem ligar-se. Para mais informações, consulte o registo de alterações de lançamento 1.0.7.

Se não conseguires atualizar para a versão 1.0.7, segue estes passos. Certifique-se de que o módulo personalizado IoT Edge usa sempre o mesmo ID de processo para enviar mensagens ao edgeHub. Por exemplo, usa o ENTRYPOINT comando em vez do CMD comando no teu ficheiro Docker. O CMD comando resulta num ID de processo para o módulo e outro ID de processo para o comando bash que executa o programa principal. O ENTRYPOINT comando resulta num único ID de processo.

Problemas de estabilidade em dispositivos mais pequenos

Sintomas

Pode ter problemas de estabilidade em dispositivos com recursos limitados como o Raspberry Pi, especialmente quando usado como gateway. Os sintomas incluem exceções por falta de memória no módulo hub IoT Edge, dispositivos a jusante falharem a ligar, ou o dispositivo falhar em enviar mensagens de telemetria após algumas horas.

Causa

O hub IoT Edge, que faz parte do ambiente de execução do IoT Edge, está otimizado para desempenho por padrão e tenta alocar grandes blocos de memória. Essa otimização não é ideal para dispositivos de borda restrita e pode causar problemas de estabilidade.

Solução

Para o hub IoT Edge, defina uma variável de ambiente OptimizeForPerformance para false. Pode definir variáveis de ambiente de duas formas:

No portal do Azure:

1. No seu IoT Hub, selecione o seu dispositivo IoT Edge. Na página de detalhes do dispositivo, selecione Definir Definições de Tempo de Execução dos Módulos>.

2. Crie uma variável de ambiente para o módulo hub IoT Edge chamada OptimizeForPerformance com o tipo True/False e defina-a para False.

3. Selecione Aplicar para guardar as suas alterações e depois selecione Analisar + criar.

   A variável de ambiente agora está na edgeHub propriedade do manifesto de implantação:

      "edgeHub": {
         "env": {
               "OptimizeForPerformance": {
                  "value": false
               }
         },
         "restartPolicy": "always",
         "settings": {
               "image": "mcr.microsoft.com/azureiotedge-hub:1.5",
               "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"443/tcp\":[{\"HostPort\":\"443\"}],\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
         },
         "status": "running",
         "type": "docker"
      }
   

4. Selecione Criar para salvar as alterações e implantar o módulo.

O serviço de segurança não consegue arrancar

Sintomas

O daemon de segurança não consegue arrancar e os contentores de módulos não são criados. O serviço IoT Edge não inicia edgeAgent, edgeHub ou outros módulos personalizados. Nos aziot-edged logs, você vê esta mensagem de erro:

• O daemon não pôde ser iniciado com êxito: Não foi possível iniciar o serviço de gerenciamento
• causado por: Ocorreu um erro para o caminho /var/run/iotedge/mgmt.sock
• causado por: Permissão negada (erro OS 13)

Causa

Para todas as distribuições Linux, exceto o CentOS 7, o IoT Edge usa ativação de socket systemd por predefinição. Se alterar o ficheiro de configuração para desativar a ativação de sockets mas manter os URLs como /var/run/iotedge/*.sock, recebe um erro de permissões. O iotedge utilizador não pode escrever em /var/run/iotedge, por isso não pode desbloquear nem montar os soquetes. CentOS chegou ao fim da vida útil (EOL). Para obter mais informações, consulte o CentOS End Of Life guidance.

Solução

Não desative a ativação de soquetes numa distribuição que suporta ativação de soquetes. No entanto, se não quiseres usar ativação por soquete, coloca os soquetes em /var/lib/iotedge/.

1. Executa systemctl disable iotedge.socket iotedge.mgmt.socket para desativar as unidades de soquete para que o systemd não as inicie.
2. Alterar a configuração iotedge para usar /var/lib/iotedge/*.sock em ambas as seções connect e listen
3. Se já tens módulos, eles têm os antigos suportes /var/run/iotedge/*.sock, então executa docker rm -f para os remover.

A limpeza da fila de mensagens é lenta

Sintomas

A fila de mensagens não realiza a limpeza após as mensagens serem processadas. A fila de mensagens cresce ao longo do tempo e eventualmente faz com que o runtime do IoT Edge fique sem memória.

Causa

O TTL da mensagem do cliente (time to live) e a variável de ambiente do EdgeHubMessageCleanupIntervalSecs controlam o intervalo de limpeza das mensagens. O valor TTL da mensagem predefinido é de duas horas e o valor predefinido MessageCleanupIntervalSecs é de 30 minutos. Se a tua aplicação usar um valor TTL mais curto do que o padrão e não ajustares esse MessageCleanupIntervalSecs valor, as mensagens expiradas só são limpas no intervalo de limpeza seguinte.

Solução

Se mudares o valor TTL da tua aplicação para um valor mais curto do que o padrão, também ajusta esse MessageCleanupIntervalSecs valor. O MessageCleanupIntervalSecs valor deve ser significativamente menor do que o menor valor TTL que o cliente utiliza. Por exemplo, se a aplicação cliente definir um TTL de cinco minutos no cabeçalho da mensagem, defina o MessageCleanupIntervalSecs valor para um minuto. Essas configurações garantem que as mensagens sejam limpas em seis (5 + 1) minutos.

Para configurar o valor MessageCleanupIntervalSecs, defina a variável de ambiente no manifesto de implementação para o módulo hub IoT Edge. Para mais informações sobre a definição de variáveis do ambiente em tempo de execução, consulte Edge Agent e Edge Hub Environment Variables.

IoT Edge Hub reporta erro System.FormatException ao utilizar o protocolo AMQP

Sintomas

Quando encaminha mensagens de um dispositivo IoT Edge para um IoT Hub usando o protocolo AMQP e define a propriedade iothub-creation-time-utc nas mensagens de dispositivo de saída, o IoT Edge Hub reporta um erro System.FormatException. A mensagem de erro é semelhante à seguinte:

System.FormatException: String '2024-12-01T00:00:0.000Z' was not recognized as a valid DateTime.

Causa

O iot-hub-creation-time-utc valor não atende a critérios de formato restritos. O formato que o Edge Hub requer é um subconjunto da ISO 8601.

Solução

Este problema é conhecido no IoT Edge Hub para o protocolo AMQP. Atualmente, a equipa de produto está a investigar uma solução. O protocolo MQTT não tem esse problema.

Rede

Daemon de segurança IoT Edge falha com um nome de host inválido

Sintomas

Tentar verificar os registos do gestor de segurança IoT Edge falha e imprime a seguinte mensagem:

Error parsing user input data: invalid hostname. Hostname cannot be empty or greater than 64 characters

Causa

O runtime do IoT Edge suporta nomes de host com menos de 64 caracteres. As máquinas físicas geralmente não têm nomes de host longos, mas o problema é mais comum em uma máquina virtual. Os nomes de host gerados automaticamente para máquinas virtuais Windows alojadas no Azure, em particular, tendem a ser longos.

Solução

Quando vires este erro, resolve-o configurando o nome DNS da tua máquina virtual e depois define o nome DNS como nome do host no comando de configuração.

1. No portal Azure, aceda à página de visão geral da sua máquina virtual.

2. Abra o painel de configuração selecionando o link Não configurado (se a sua máquina virtual for nova) ou selecione o seu nome DNS existente em Essentials>Nome DNS. Se sua máquina virtual já tiver um nome DNS configurado, não será necessário configurar um novo.

3. Introduz um valor para o nome DNS, se ainda não tiver um, e selecione Guardar.

4. Copie o novo nome DNS, que deve estar no formato:
   <DNSnamelabel>.<vmlocation.cloudapp.azure.com>.

5. No dispositivo IoT Edge, abra o ficheiro de configuração.

   sudo nano /etc/aziot/config.toml
   

6. Substitua o valor de hostname pelo seu nome DNS.

7. Guarde e feche o ficheiro, depois aplique as alterações ao IoT Edge.

   sudo iotedge config apply
   

O módulo IoT Edge reporta erros de conectividade

Sintomas

Os módulos IoT Edge que se ligam diretamente a serviços cloud, incluindo os módulos de execução, deixam de funcionar como esperado e devolvem erros relacionados com falhas de ligação ou rede.

Causa

Os contentores dependem do encaminhamento de pacotes IP para se ligarem à internet, de modo a poderem comunicar com serviços na cloud. O Docker ativa o encaminhamento de pacotes IP por defeito, mas se o desativares, quaisquer módulos que se liguem a serviços cloud não funcionam como esperado. Para obter mais informações, consulte Compreender a comunicação de contêiner na documentação do Docker.

Solução

Use as etapas a seguir para habilitar o encaminhamento de pacotes IP.

1. Abra o arquivo sysctl.conf .

   sudo nano /etc/sysctl.conf
   

2. Adicione a seguinte linha ao ficheiro.

   net.ipv4.ip_forward=1
   

3. Guarde e feche o ficheiro.

4. Reinicie o serviço de rede e o serviço docker para aplicar as alterações.

Um dispositivo IoT Edge atrás de um gateway não consegue realizar pedidos HTTP nem iniciar o módulo edgeAgent

Sintomas

O tempo de execução IoT Edge está ativo com um ficheiro de configuração válido, mas não consegue iniciar o módulo edgeAgent. O comando iotedge list retorna uma lista vazia. O tempo de execução IoT Edge reporta Could not perform HTTP request nos registos.

Causa

Os dispositivos IoT Edge por detrás de um gateway obtêm as imagens dos módulos do dispositivo IoT Edge pai especificado no campo parent_hostname do ficheiro de configuração. O Could not perform HTTP request erro significa que o dispositivo a jusante não consegue aceder ao seu dispositivo pai via HTTP.

Solução

Certifique-se de que o dispositivo IoT Edge-mãe pode receber pedidos recebidos do dispositivo IoT Edge a jusante. Abra o tráfego de rede nas portas 443 e 6617 para pedidos provenientes do dispositivo a jusante.

O IoT Edge atrás de um gateway não consegue ligar-se ao migrar de um hub IoT para outro

Sintomas

Quando migra uma hierarquia de dispositivos IoT Edge de um IoT hub para outro, o dispositivo IoT Edge principal de topo liga-se ao IoT Hub, mas os dispositivos IoT Edge posteriores não conseguem. Os registos relatam Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Causa

A migração não atualizou corretamente as credenciais dos dispositivos a jusante. Por causa deste problema, os módulos edgeAgent e edgeHub têm um tipo de autenticação ( none o padrão se não o definires explicitamente). Durante a conexão, os módulos nos dispositivos downstream usam credenciais antigas, fazendo com que a autenticação falhe.

Solução

Quando migrar para o novo hub IoT (assumindo que não está a usar DPS), siga estes passos por ordem:

1. Siga este guia para exportar e, em seguida, importar identidades de dispositivo do antigo hub IoT para o novo
2. Reconfigure todas as implementações e configurações do IoT Edge no novo hub IoT
3. Reconfigurar todas as relações de dispositivo pai-filho no novo hub IoT
4. Atualize cada dispositivo para apontar para o novo nome de host do hub IoT (iothub_hostname sob [provisioning] em config.toml)
5. Se você optar por excluir chaves de autenticação durante a exportação do dispositivo, reconfigure cada dispositivo com as novas chaves fornecidas pelo novo hub IoT (device_id_pk em [provisioning.authentication]config.toml)
6. Reinicie primeiro o dispositivo Edge principal de nível superior, certifique-se de que está operacional e a funcionar.
7. Reinicie cada dispositivo em nível hierárquico por nível, de cima para baixo

O IoT Edge tem baixo fluxo de mensagens quando está geograficamente distante do IoT Hub

Sintomas

Os dispositivos Azure IoT Edge que estão geograficamente distantes do Azure IoT Hub têm menor taxa de transferência de mensagens.

Causa

A alta latência entre o dispositivo e o IoT Hub provoca uma redução no fluxo de mensagens. O IoT Edge utiliza um tamanho padrão de lote de mensagens de 10. Este tamanho de lote limita o número de mensagens enviadas num único lote, o que aumenta o número de viagens de ida e volta entre o dispositivo e o IoT Hub.

Solução

Tente aumentar a variável de ambiente do IoT Edge Hub MaxUpstreamBatchSize. Esta alteração envia mais mensagens num único lote, o que reduz o número de viagens de ida e volta entre o dispositivo e o IoT Hub.

Para definir variáveis de ambiente do Azure Edge Hub no portal Azure:

1. Navegue até à sua IoT Hub e selecione Dispositivos no menu Gestão de dispositivos.
2. Selecione o dispositivo IoT Edge que pretende atualizar.
3. Selecione Definir Módulos.
4. Selecione Configurações de tempo de execução.
5. Na guia Configurações do módulo Edge Hub, adicione a variável de ambiente MaxUpstreamBatchSize como tipo Número com um valor de 20.
6. Selecione Aplicar.

Próximos passos

Acha que encontrou algum erro na plataforma IoT Edge? Submeter um problema para que a equipa de produto possa continuar a melhorar a plataforma.

Se você tiver mais perguntas, crie uma solicitação de suporte para obter ajuda.