Soluções para problemas comuns do Azure IoT Edge

Aplica-se a: IoT Edge 1.5 IoT Edge 1.4

Use este artigo para identificar e resolver problemas comuns ao usar soluções do IoT Edge. Se você precisar de informações sobre como localizar logs e erros do seu dispositivo IoT Edge, consulte Solucionar problemas do dispositivo IoT Edge.

Provisionamento e implantação

O módulo do IoT Edge foi implementado com êxito e desaparece do dispositivo

Sintomas

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

Motivo

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 Definir módulos no portal do Azure ou Criar implantação para funcionalidade de dispositivo único no Visual Studio Code entra em vigor por um momento. Você vê os módulos que você definiu iniciar no dispositivo. Em seguida, a prioridade da implantação automática é iniciada e substitui as propriedades desejadas do dispositivo.

Solução

Use apenas um tipo de mecanismo de implantação por dispositivo, seja uma implantação automática ou implantações de dispositivos individuais. 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 obter mais informações, consulte Compreender as implantações automáticas do IoT Edge para dispositivos únicos ou em escala.

Runtime do IoT Edge

O agente IoT Edge para após um minuto

Sintomas

O módulo edgeAgent é iniciado e executado com êxito por cerca de um minuto e, em seguida, para. Os logs indicam que o agente do IoT Edge tenta se conectar ao Hub IoT sobre AMQP e, em seguida, tenta se conectar usando AMQP sobre WebSocket. Quando isso falha, o agente do IoT Edge é encerrado.

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...

Motivo

Uma configuração de rede na rede host está impedindo que o agente IoT Edge alcance a 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 configura uma rede para comunicar em cada um dos módulos. No Linux, esta rede é uma rede de ponte. No Windows, utiliza NAT. Este problema é mais comum nos dispositivos Windows com contentores do 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 rede bridge/NAT. Por vezes, uma configuração de VPN no anfitrião sobrepõe-se à rede do 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. Somente o edgeAgent está em execução, mas e relata o arquivo de configuração vazio....

• Quando você executa sudo iotedge check em um dispositivo, ele informa que o mecanismo de contêiner não está configurado com a configuração do servidor DNS, o que pode afetar a conectividade com o Hub IoT. Consulte https://aka.ms/iotedge-prod-checklist-dns as melhores práticas.

Motivo

• Por padrão, o IoT Edge inicia módulos em sua própria rede de contêineres isolados. O dispositivo pode estar a ter problemas com a resolução de nomes DNS nesta rede privada.
• Se estiver usando uma instalação instantânea do IoT Edge, o arquivo de configuração do Docker será um local diferente. 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, que se aplicam a todos os módulos de contêiner iniciados pelo mecanismo. Crie um ficheiro com o nome daemon.jsone, em seguida, especifique o servidor DNS a utilizar. 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 redes corporativas, têm seus próprios servidores DNS instalados e não permitem 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 do /etc/docker seu dispositivo.

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

Reinicie o mecanismo de contêiner para que as atualizações entrem em vigor.

sudo systemctl restart docker

Opção 2: Definir o servidor DNS na implantação do IoT Edge por módulo

Você pode definir o servidor DNS para createOptions de cada módulo na implantação do 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 o IoT Edge for instalado em um piscar de olhos, use o --container-engine-config-file parâmetro para especificar o local do arquivo 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 iotedge mesmo depois de definir o local do arquivo de configuração. Check relata 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 Agente de Borda com conexão LTE relata 'configuração vazia do agente de borda' e causa 'erro de rede transitório'

Sintomas

Um dispositivo configurado com conexão LTE está tendo problemas para iniciar módulos definidos na implantação. O edgeAgent não consegue se conectar ao Hub IoT e relata a configuração vazia do agente de borda e ocorreu um erro transitório de rede.

Motivo

Algumas redes têm sobrecarga de pacotes, o que torna a MTU de rede docker padrão (1500) muito alta e causa fragmentação de pacotes impedindo o acesso a recursos externos.

Solução

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

   docker network inspect <network name>

2. Verifique a configuração de MTU para o adaptador de rede física no seu 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. Assim, o MTU para a rede Docker é definido como 1430.

2. Pare e remova a rede do Azure.

   docker network rm azure-iot-edge

3. Recrie a rede do 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 do IoT Edge não consegue aceder a uma imagem do módulo (403)

Sintomas

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

Motivo

O módulo do agente IoT Edge não tem permissões para acessar a imagem de um módulo.

Solução

Verifique se as credenciais do Registro do contêiner estão corretas no manifesto de implantação do dispositivo.

O agente do IoT Edge faz chamadas de identidade excessivas

Sintomas

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

Motivo

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

Solução

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

O hub do IoT Edge falha ao iniciar

Sintomas

O módulo edgeHub falha ao iniciar. Poderá ver uma mensagem como 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)

Motivo

Algum outro processo na máquina host vinculou uma porta que o módulo edgeHub está tentando vincular. O hub IoT Edge mapeia as portas 443, 5671 e 8883 para uso em cenários de gateway. O módulo não será iniciado se outro processo já tiver vinculado uma dessas portas.

Solução

Você pode resolver esse problema de duas maneiras:

Se o dispositivo IoT Edge estiver funcionando como um dispositivo de gateway, você precisará localizar e parar o processo que está usando a porta 443, 5671 ou 8883. Um erro para a porta 443 geralmente significa que o outro processo é um servidor web.

Se você não precisar usar o dispositivo IoT Edge como um gateway, poderá remover as ligações de porta das opções de criação de módulo do edgeHub. Você pode alterar as opções de criação no portal do Azure ou diretamente no arquivo deployment.json.

No portal do Azure:

1. Navegue até o hub IoT e selecione Dispositivos no menu Gerenciamento de dispositivos.

2. Selecione o dispositivo IoT Edge que você deseja atualizar.

3. Selecione Definir Módulos.

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

5. Nas configurações do módulo Hub de Borda , exclua tudo da caixa de texto Criar Opções de Contêiner.

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

No ficheiro deployment.json:

1. Abra o arquivo deployment.json que você aplicou ao seu 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 createOptions linha e a vírgula à direita no final da image linha antes dela:

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

4. Selecione Criar para aplicá-lo ao seu dispositivo IoT Edge novamente.

O módulo do IoT Edge não envia uma mensagem para o edgeHub com o erro 404

Sintomas

Um módulo personalizado do IoT Edge não consegue enviar uma mensagem para o hub do IoT Edge com um erro 404 Module not found . O tempo de execução do IoT Edge imprime a seguinte mensagem nos logs:

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 )

Motivo

O tempo de execução do IoT Edge impõe a identificação do processo para todos os módulos que se conectam ao edgeHub por motivos de segurança. Ele verifica se todas as mensagens enviadas por um módulo vêm do ID do processo principal do módulo. Se uma mensagem está sendo enviada por um módulo de um ID de processo diferente do estabelecido inicialmente, ele rejeita a mensagem com uma mensagem de erro 404.

Solução

A partir da versão 1.0.7, todos os processos do módulo estão autorizados a se conectar. Para obter mais informações, consulte o changelog de versão 1.0.7.

Se não for possível atualizar para a versão 1.0.7, conclua as etapas a seguir. Certifique-se de que o mesmo ID de processo seja sempre usado pelo módulo IoT Edge personalizado para enviar mensagens para o edgeHub. Por exemplo, certifique-se de que em ENTRYPOINT vez de comando no seu arquivo Docker CMD . O CMD comando leva a um ID de processo para o módulo e outro ID de processo para o comando bash executando o programa principal, mas ENTRYPOINT leva a um único ID de processo.

Problemas de estabilidade em dispositivos mais pequenos

Sintomas

Você pode ter problemas de estabilidade em dispositivos com restrição de recursos, como o Raspberry Pi, especialmente quando usado como um gateway. Os sintomas incluem exceções de falta de memória no módulo de hub IoT Edge, dispositivos downstream que não conseguem se conectar ou o dispositivo não consegue enviar mensagens de telemetria após algumas horas.

Motivo

O hub IoT Edge, que faz parte do tempo de execução do IoT Edge, é 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 como false. Há duas maneiras de definir variáveis de ambiente:

No portal do Azure:

1. No Hub IoT, selecione seu dispositivo IoT Edge e, na página de detalhes do dispositivo, selecione Definir configurações de tempo de execução de módulos>.

2. Crie uma variável de ambiente para o módulo de hub IoT Edge chamado OptimizeForPerformance com o tipo True/False definido como False.

3. Selecione Aplicar para guardar as alterações e, em seguida, selecione Rever + 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 daemon de segurança não pôde ser iniciado com êxito

Sintomas

O daemon de segurança falha ao iniciar e os contêineres de módulo não são criados. O edgeAgent, edgeHub e outros módulos personalizados não são iniciados pelo serviço IoT Edge. Nos aziot-edged logs, você vê este 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)

Motivo

Para todas as distribuições Linux, exceto o CentOS 7, a configuração padrão do IoT Edge é usar systemd a ativação de soquete. Um erro de permissão acontece se você alterar o arquivo de configuração para não usar a ativação de soquete, mas deixar as URLs como /var/run/iotedge/*.sock, já que o iotedge usuário não pode gravar para /var/run/iotedge o que significa que não pode desbloquear e montar os soquetes em si.

Solução

Não é necessário desativar a ativação de soquete em uma distribuição onde a ativação de soquete é suportada. No entanto, se você preferir não usar a ativação de soquete, coloque os soquetes em /var/lib/iotedge/.

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

A limpeza da fila de mensagens é lenta

Sintomas

A fila de mensagens não está sendo limpa depois que as mensagens são processadas. A fila de mensagens cresce com o tempo e, eventualmente, faz com que o tempo de execução do IoT Edge fique sem memória.

Motivo

O intervalo de limpeza da mensagem é controlado pela mensagem do cliente TTL (tempo de vida) e pela variável de ambiente EdgeHub MessageCleanupIntervalSecs . O valor TTL da mensagem padrão é de duas horas e o valor padrão de MessageCleanupIntervalSecs é de 30 minutos. Se seu aplicativo usa um valor TTL menor que o padrão e você não ajusta o valor MessageCleanupIntervalSecs, as mensagens expiradas não serão limpas até o próximo intervalo de limpeza.

Solução

Se você alterar o valor TTL para seu aplicativo que é menor do que o padrão, também ajuste o valor MessageCleanupIntervalSecs . O valor MessageCleanupIntervalSecs deve ser significativamente menor do que o menor valor TTL que o cliente está usando. Por exemplo, se o aplicativo cliente definir um TTL de cinco minutos no cabeçalho da mensagem, defina o valor MessageCleanupIntervalSecs como 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 implantação para o módulo de hub IoT Edge. Para obter mais informações sobre como definir variáveis de ambiente de tempo de execução, consulte Agente de Borda e Variáveis de Ambiente do Hub de Borda.

Rede

O daemon de segurança do IoT Edge falha com um nome do anfitrião inválido

Sintomas

A tentativa de verificar os logs do gerenciador de segurança do IoT Edge falha e imprime a seguinte mensagem:

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

Motivo

O tempo de execução do IoT Edge só pode oferecer suporte a 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 do Windows hospedadas no Azure, em particular, tendem a ser longos.

Solução

Quando vir este erro, pode resolvê-lo configurando o nome DNS da sua máquina virtual e, em seguida, definindo o nome DNS como o nome de anfitrião no comando de configuração.

1. No portal do Azure, navegue até a 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 sua máquina virtual for nova) ou selecione seu nome DNS existente em Nome DNS do Essentials>. Se sua máquina virtual já tiver um nome DNS configurado, não será necessário configurar um novo.

3. Forneça um valor para o rótulo de nome DNS se ainda não tiver um e selecione Salvar.

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

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

   sudo nano /etc/aziot/config.toml
   

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

7. Salve e feche o arquivo e aplique as alterações ao IoT Edge.

   sudo iotedge config apply
   

O módulo do IoT Edge reporta erros de conectividade

Sintomas

Os módulos do IoT Edge que se conectam diretamente aos serviços de nuvem, incluindo os módulos de tempo de execução, param de funcionar conforme o esperado e retornam erros relacionados a falhas de conexão ou rede.

Motivo

Os contêineres dependem do encaminhamento de pacotes IP para se conectarem à Internet e poderem se comunicar com serviços em nuvem. O encaminhamento de pacotes IP é habilitado por padrão no Docker, mas se for desativado, todos os módulos que se conectam a serviços de nuvem não funcionarão conforme o 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.

O IoT Edge por trás de um gateway não consegue executar pedidos HTTP e iniciar o módulo edgeAgent

Sintomas

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

Motivo

Os dispositivos IoT Edge atrás de um gateway obtêm suas imagens de módulo do dispositivo IoT Edge pai especificado no parent_hostname campo do arquivo de configuração. O Could not perform HTTP request erro significa que o dispositivo downstream não é capaz de alcançar seu dispositivo pai via HTTP.

Solução

Verifique se o dispositivo IoT Edge pai pode receber solicitações de entrada do dispositivo IoT Edge downstream. Abra o tráfego de rede nas portas 443 e 6617 para pedidos provenientes do dispositivo a jusante.

O IoT Edge por trás de um gateway não consegue executar pedidos HTTP e iniciar o módulo edgeAgent

Sintomas

O daemon do IoT Edge está ativo com um arquivo de configuração válido, mas não pode iniciar o módulo edgeAgent. O comando iotedge list retorna uma lista vazia. O relatório Could not perform HTTP requestde logs do daemon do IoT Edge .

Motivo

Os dispositivos IoT Edge atrás de um gateway obtêm suas imagens de módulo do dispositivo IoT Edge pai especificado no parent_hostname campo do arquivo de configuração. O Could not perform HTTP request erro significa que o dispositivo downstream não é capaz de alcançar seu dispositivo pai via HTTP.

Solução

Verifique se o dispositivo IoT Edge pai pode receber solicitações de entrada do dispositivo IoT Edge downstream. 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 pode se conectar ao migrar de um hub IoT para outro

Sintomas

Ao tentar migrar uma hierarquia de dispositivos IoT Edge de um hub IoT para outro, o dispositivo IoT Edge pai de nível superior pode se conectar ao Hub IoT, mas os dispositivos IoT Edge downstream não. O relatório Unable to authenticate client downstream-device/$edgeAgent with module credentialsde logs .

Motivo

As credenciais dos dispositivos downstream não foram atualizadas corretamente quando a migração para o novo hub IoT aconteceu. Por causa disso, edgeAgent e edgeHub os módulos foram definidos para ter o tipo de autenticação de none (padrão se não definido explicitamente). Durante a conexão, os módulos nos dispositivos downstream usam credenciais antigas, fazendo com que a autenticação falhe.

Solução

Ao migrar para o novo hub IoT (supondo não usar DPS), siga estas etapas na ordem:

1. Siga este guia para exportar e, em seguida, importar identidades de dispositivo do antigo hub IoT para o novo
2. Reconfigurar todas as implantaçõ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 em [provisioning] 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 o dispositivo Edge pai de nível superior primeiro, verifique se ele está instalado e funcionando
7. Reinicie cada dispositivo em nível hierárquico por nível, de cima para baixo

O IoT Edge tem baixa taxa de transferência de mensagens quando geograficamente distante do Hub IoT

Sintomas

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

Motivo

A alta latência entre o dispositivo e o Hub IoT pode causar uma taxa de transferência de mensagens menor do que o esperado. O IoT Edge usa um tamanho de lote de mensagens padrão de 10. Isso limita o número de mensagens enviadas em um único lote, o que aumenta o número de viagens de ida e volta entre o dispositivo e o Hub IoT.

Solução

Tente aumentar a variável de ambiente MaxUpstreamBatchSize do IoT Edge Hub. Isso permite que mais mensagens sejam enviadas em um único lote, o que reduz o número de viagens de ida e volta entre o dispositivo e o Hub IoT.

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

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

Próximos passos

Encontrou um erro na plataforma do IoT Edge? Envie uma questão para que possamos continuar a melhorar.

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