Soluções para problemas comuns para o Azure IoT Edge

Artigo
12/10/2024

Aplica-se a: IoT Edge 1.5 IoT Edge 1.4

Importante

O IoT Edge 1.5 LTS e o IoT Edge 1.4 LTS são versões com suporte. O IoT Edge 1.4 LTS chegará ao fim da vida útil em 12 de novembro de 2024. Se você estiver em uma versão anterior, confira Atualizar o IoT Edge.

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

Provisionamento e implantação

O módulo do IoT Edge é implantado com êxito e desaparece do dispositivo

Sintomas

Depois de definir os 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 na portal do Azure. Outros módulos, além aqueles definidos, também podem aparecer no dispositivo.

Causa

Se uma implantação automática se destinar a 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 dispositivo único no Visual Studio Code entra em vigor por um momento. Você verá os módulos que definiu iniciar no dispositivo. Em seguida, a prioridade da implantação automática é acionada e substitui as propriedades desejadas do dispositivo.

Solução

Use apenas um tipo de mecanismo de implantação por dispositivo, uma implantação automática ou implantações de dispositivo individuais. Se você tiver várias implantações automáticas direcionadas a um dispositivo, poderá alterar a prioridade ou as descrições de destino para certificar-se de que a correta se aplica 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 saber mais, veja Noções básicas sobre implantações automáticas do IoT Edge para dispositivos únicos ou em escala.

runtime do IoT Edge

O Agente do IoT Edge é interrompido após um minuto

Sintomas

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

Logs do edgeAgent de exemplo:

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 do host está impedindo que o Agente do IoT Edge alcance a rede. O agente tenta se conectar com AMQP (porta 5671) primeiro. Se a conexão falhar, ele tentará usar WebSockets (porta 443).

O runtime do IoT Edge configura uma rede para que cada um dos módulos se comunique. No Linux, esta rede é uma rede de ponte. No Windows, ele usa o NAT. Esse problema é mais comum em dispositivos Windows com contêineres do Windows que usam a rede NAT.

Solução

Verifique se existe uma rota para a Internet para os endereços IP atribuídos a esta rede de ponte/NAT. Às vezes, uma configuração de VPN no host substitui a rede do IoT Edge.

O módulo do agente do Edge reporta ”arquivo de configuração vazio” e nenhum módulo inicia no dispositivo

Sintomas

O dispositivo tem problemas ao iniciar os módulos definidos na implantação. Somente o edgeAgent está em execução, relatando arquivo de configuração vazia....
Quando você executa sudo iotedge check em um dispositivo, ele relata 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 para conhecer as melhores práticas.

Causa

Por padrão, IoT Edge inicia os módulos em sua própria rede de contêiner isolado. O dispositivo pode estar tendo problemas com a resolução de nomes DNS nessa rede privada.
Se estiver usando uma instalação de ajuste do IoT Edge, o arquivo de configuração do Docker será um local diferente. Confira a opção 3 da solução.

Solução

Opção 1: Definir o servidor DNS em 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 arquivo chamado daemon.json especificando o servidor DNS a ser usado. Por exemplo:

{
    "dns": ["1.1.1.1"]
}

Esse servidor DNS é 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 /etc/docker em seu dispositivo.

Se o local já contiver o arquivo daemon.json, adicione a chave de 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"
    ]
  }
}

Aviso

Se você usar esse método e especificar o endereço DNS errado, o edgeAgent perderá a conexão com o Hub IoT e não poderá receber novas implantações para corrigir o problema. Para resolver esse problema, é possível reinstalar o runtime do IoT Edge. Antes de instalar uma nova instância do IoT Edge, remova todos os contêineres de edgeAgent da instalação anterior.

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

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

Se o IoT Edge estiver instalado como um ajuste, use o parâmetro --container-engine-config-file 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 de iotedge mesmo depois de você definir o local do arquivo de configuração. Verifique os relatórios do erro porque o ajuste do IoT Edge não tem acesso de leitura ao ajuste do Docker. Se você usar a verificação de iotedge em seu processo de versão, você poderá suprimir a mensagem de aviso usando o parâmetro --ignore container-engine-dns container-engine-logrotate.

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

Sintomas

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

Causa

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

Solução

Verifique a configuração da MTU da rede do Docker.

docker network inspect <network name>
Verifique a configuração da MTU para o adaptador de rede física no seu dispositivo.

ip addr show eth0

Observação

A MTU da rede do Docker não pode ser maior que a MTU do seu dispositivo. Entre em contato com seu ISP para obter mais informações.

Se você vir um tamanho diferente da MTU da rede do Docker e do dispositivo, experimente a seguinte solução alternativa:

Crie uma nova rede. Por exemplo,

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

No exemplo, a configuração da MTU do dispositivo é 1430. Portanto, a MTU da rede do Docker está definida como 1430.
Pare e remova a rede do Azure.

docker network rm azure-iot-edge
Recrie a rede do Azure.

docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge
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 pode acessar a imagem de um módulo (403)

Sintomas

Falha na execução de um contêiner e os logs do edgeAgent reportam um erro 403.

Causa

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

Solução

Certifique-se de que suas credenciais de registro de contêiner estão corretas em seu 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.

Causa

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 Agente do IoT Edge continua a repetir a implantação. Cada repetição 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 de contêiner ou for digitado incorretamente, o agente do IoT Edge repetirá 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 os erros e reimplante o manifesto no dispositivo.

O Hub do IoT Edge não pode ser iniciado

Sintomas

Falha ao iniciar o módulo edgeHub. Você pode ver uma mensagem como um dos seguintes erros nos logs:

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)

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

Outros processos no computador host associou uma porta que o módulo edgeHub está tentando associar. O Hub do IoT Edge mapeia as portas 443, 5671 e 8883 para usar em cenários de gateway. O módulo não será iniciado se outro processo já tiver associado uma dessas portas.

Solução

Você pode resolver esse problema de duas maneiras:

Se o dispositivo de 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 associaçõ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:

Navegue até o hub IoT e selecione Dispositivos no menu Gerenciamento de dispositivos.
Selecione o dispositivo IoT Edge que você deseja atualizar.
Selecione Definir Módulos.
Selecione Configurações de Runtime.
Nas configurações do módulo hub do Edge, exclua tudo da caixa de texto Opções de criação de contêiner.
Selecione Aplicar para salvar as alterações e criar a implantação.

No arquivo deployment.json:

Abra o arquivo deployment.json que você aplicou ao seu dispositivo do IoT Edge.

Localize 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"
   }

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"
}

Selecione Criar para aplicar ao dispositivo IoT Edge novamente.

Falha do módulo do IoT Edge ao enviar uma mensagem para o edgeHub com o erro 404

Sintomas

Um módulo do IoT Edge personalizado falha ao enviar uma mensagem para o hub do IoT Edge com um erro 404 Module not found. O runtime 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 )

Causa

O runtime 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 da ID do processo principal do módulo. Se uma mensagem estiver sendo enviada por um módulo de uma ID de processo diferente da inicialmente estabelecida, ele rejeitará a mensagem com uma mensagem de erro 404.

Solução

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

Se a atualização para 1.0.7 não for possível, conclua as etapas a seguir. Verifique se a mesma ID de processo sempre é usada pelo módulo personalizado do IoT Edge para enviar mensagens ao edgeHub. Por exemplo, certifique-se de ENTRYPOINT em vez do CMD comando no arquivo do Docker. O CMD comando leva a uma ID de processo para o módulo e outra ID de processo para o comando bash executando o programa principal, mas ENTRYPOINT leva a uma única ID de processo.

Problemas de estabilidade em dispositivos pequenos

Sintomas

Talvez você encontre problemas de estabilidade em dispositivos com restrição de recursos como o Raspberry Pi, principalmente quando usados como um gateway. Os sintomas incluem exceções fora da memória no módulo de hub do IoT Edge, os dispositivos downstream não podem se conectar ou o dispositivo para de enviar mensagens de telemetria após algumas horas.

Causa

O hub do IoT Edge, que faz parte do runtime do IoT Edge, tem o desempenho otimizado, por padrão, e tenta alocar grandes partes de memória. Essa otimização não é ideal para dispositivos de borda com restrição e pode causar problemas de estabilidade.

Solução

Para o hub do IoT Edge, defina uma variável de ambiente OptimizeForPerformance como false. Há duas maneiras de definir variáveis de ambiente:

No Portal do Azure:

No Hub IoT, selecione o dispositivo IoT Edge e, na página detalhes do dispositivo e selecione Definir>configurações de tempo de execuçãode módulos.
Crie uma variável de ambiente para o módulo hub do IoT Edge chamado OptimizeForPerformance com o tipo True/False que está definido como False.

Selecione Aplicar para salvar as alterações e, em seguida, selecione Examinar + criar.

Agora, a variável de ambiente está na propriedade edgeHub 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"
   }

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

O daemon de segurança não pôde iniciar 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 logs de aziot-edged, você verá este erro:

O daemon não pôde ser inicializado: 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 13 de sistema operacional)

Causa

Para todas as distribuições do Linux, exceto CentOS 7, a configuração padrão do IoT Edge deve usar a ativação de soquete systemd. Ocorrerá um erro de permissão 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 usuário iotedge não pode gravar em /var/run/iotedge, o que significa que ele não pode desbloquear e montar os soquetes por conta própria. O CentOS chegou ao fim da vida útil (EOL). Para obter mais informações, confira as Diretrizes de Fim do Suporte do CentOS.

Solução

Você não precisa desabilitar a ativação de soquete em uma distribuição em que há suporte para a ativação de soquete. No entanto, se você preferir não usar a ativação de soquete, coloque os soquetes em /var/lib/iotedge/.

Execute systemctl disable iotedge.socket iotedge.mgmt.socket para desabilitar as unidades de soquete para que o sistema não as inicie desnecessariamente
Alterar a configuração de iotedge para usar /var/lib/iotedge/*.sock nas seções connect e listen
Se você já tiver módulos, eles terão as /var/run/iotedge/*.sock montagens antigas, portanto, docker rm -f delas.

A limpeza da fila de mensagens está lenta

Sintomas

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

Causa

O intervalo de limpeza de mensagens é controlado pelo TTL (vida útil) da mensagem do cliente e pela variável de ambiente EdgeHub MessageCleanupIntervalSecs. O valor do TTL da mensagem padrão é de duas horas e o valor de MessageCleanupIntervalSecs padrão é de 30 minutos. Se o aplicativo usar um valor de TTL menor que o padrão e você não ajustar 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 do TTL do aplicativo que é menor que o padrão, ajuste também o valor MessageCleanupIntervalSecs. O valor MessageCleanupIntervalSecs deve ser significativamente menor do que o menor valor do 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 do hub do IoT Edge. Para obter mais informações sobre como definir as variáveis de ambiente de runtime, confira Variáveis de Ambiente do Agente do Edge e do Hub do Edge.

O Hub do IoT Edge relata System.FormatException usando o protocolo AMQP

Sintomas

Ao rotear mensagens de um dispositivo IoT Edge para um Hub IoT usando o protocolo AMQP e você definir a propriedade iothub-creation-time-utc em mensagens de dispositivo de saída, Hub do IoT Edge relatará 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 valor iot-hub-creation-time-utc não atende a critérios de formato estrito. O formato exigido pelo Hub do Edge é um subconjunto da ISO 8601.

Solução

Esse é um problema conhecido no Hub do IoT Edge para o protocolo AMQP. Atualmente, o problema está sendo investigado para uma correção. O protocolo MQTT não tem esse problema.

Rede

O daemon de segurança de IoT Edge falhará com um nome de host 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

Causa

O runtime do IoT Edge só pode oferecer suporte a nomes de host com menos de 64 caracteres. Normalmente, máquinas físicas 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 você vir esse erro, você pode resolvê-lo a configurar o nome DNS de sua máquina virtual e, em seguida, definindo o nome DNS de nome de host no comando de instalação.

No portal do Azure, navegue até a página de visão geral de sua máquina virtual.
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 Essentials>Nome DNS. Caso sua máquina virtual já tenha um nome DNS configurado, você não precisará configurar um novo.
Forneça um valor para o rótulo do nome DNS se ainda não tiver um e, em seguida, selecione Salvar.
Copie o novo nome DNS, que deve estar no formato:
<DNSnamelabel>.<vmlocation>.cloudapp.azure.com.
No dispositivo do IoT Edge, abra o arquivo de configuração.
```
sudo nano /etc/aziot/config.toml
```
Substitua o valor de hostname com seu nome DNS.
Salve e feche o arquivo e aplique as alterações a IoT Edge.
```
sudo iotedge config apply
```

O módulo do IoT Edge relata erros de conectividade

Sintomas

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

Causa

Os contêineres dependem do encaminhamento de pacotes IP para se conectarem com a Internet e se comunicarem com os serviços de nuvem. O encaminhamento de pacotes IP é habilitado por padrão no Docker, mas se ele for desabilitado, os módulos conectados com os serviços de nuvem não funcionarão conforme o esperado. Para obter mais informações, confira Entender a comunicação de contêiner na documentação do Docker.

Solução

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

Abra o arquivo sysctl.conf.
```
sudo nano /etc/sysctl.conf
```
Adicione a seguinte linha ao arquivo.
```
net.ipv4.ip_forward=1
```
Salve e feche o arquivo.
Reinicie o serviço de rede e o serviço Docker para aplicar as alterações.

IoT Edge por trás de um gateway não pode executar solicitações HTTP e iniciar o módulo edgeAgent

Sintomas

O runtime 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 runtime do IoT Edge relata Could not perform HTTP request nos logs.

Causa

Dispositivos IoT Edge por trás de um gateway obtêm suas imagens de módulo do dispositivo de IoT Edge pai especificado no campo parent_hostname do arquivo de configuração. O erro Could not perform HTTP request significa que o dispositivo downstream não consegue acessar o 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 as solicitações provenientes do dispositivo downstream.

IoT Edge por trás de um gateway não pode executar solicitações HTTP e iniciar o módulo edgeAgent

Sintomas

O IoT Edge daemon 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 de logs do IoT Edge daemon Could not perform HTTP request.

Causa

Soluçã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 de IoT Edge pai de nível superior pode se conectar ao Hub IoT, mas os dispositivos IoT Edge downstream não podem. O relatório de logs Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Causa

As credenciais para os dispositivos downstream não foram atualizadas corretamente quando ocorreu a migração para o novo Hub IoT. Por isso, os módulos edgeAgent e edgeHub foram definidos para ter o tipo de autenticação de none (padrão, se não for 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 que não use DPS), siga essas etapas na ordem:

Siga este guia para exportar e importar identidades de dispositivos do hub IoT antigo para o novo
Reconfigurar todas as implantações e configurações de IoT Edge no novo Hub IoT
Reconfigurar todas os relacionamento de dispositivo pai-filho no novo hub IoT
Atualize cada dispositivo para apontar para o novo nome de host do Hub IoT (iothub_hostname em [provisioning] em config.toml)
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)
Reinicie o dispositivo de borda pai de nível superior primeiro, certifique-se de que ele está em execução
Reinicie cada dispositivo no nível da hierarquia 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 geograficamente distantes do Hub IoT do Azure têm uma taxa de transferência de mensagem menor do que o esperado.

Causa

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 hub do IoT Edge. 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 hub do Azure Edge no portal do Azure:

Navegue até o Hub IoT e selecione Dispositivos no menu Gerenciamento de dispositivos.
Selecione o dispositivo IoT Edge que você deseja atualizar.
Selecione Definir Módulos.
Selecione Configurações de Runtime.
Na guia de configurações do módulo hub do Edge, adicione a variável de ambiente MaxUpstreamBatchSize como do tipo Número com um valor de 20.
Escolha Aplicar.

Próximas etapas

Você acha que encontrou um bug na plataforma IoT Edge? Envie um problema para que possamos continuar melhorando.

Se você tiver mais dúvidas, crie uma Solicitação de suporte para obter ajuda.

Compartilhar via

Soluções para problemas comuns para o Azure IoT Edge

Provisionamento e implantação

O módulo do IoT Edge é implantado com êxito e desaparece do dispositivo

Sintomas

Causa

Solução

runtime do IoT Edge

O Agente do IoT Edge é interrompido após um minuto

Sintomas

Causa

Solução

O módulo do agente do Edge reporta ”arquivo de configuração vazio” e nenhum módulo inicia no dispositivo

Sintomas

Causa

Solução

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

Sintomas

Causa

Solução

O Agente do IoT Edge não pode acessar a imagem de um módulo (403)

Sintomas

Causa

Solução

O agente do IoT Edge faz chamadas de identidade excessivas

Sintomas

Causa

Solução

O Hub do IoT Edge não pode ser iniciado

Sintomas

Causa

Solução

Falha do módulo do IoT Edge ao enviar uma mensagem para o edgeHub com o erro 404

Sintomas

Causa

Solução

Problemas de estabilidade em dispositivos pequenos

Sintomas

Causa

Solução

O daemon de segurança não pôde iniciar com êxito

Sintomas

Causa

Solução

A limpeza da fila de mensagens está lenta

Sintomas

Causa

Solução

O Hub do IoT Edge relata System.FormatException usando o protocolo AMQP

Sintomas

Causa

Solução

Rede

O daemon de segurança de IoT Edge falhará com um nome de host inválido

Sintomas

Causa

Solução

O módulo do IoT Edge relata erros de conectividade

Sintomas

Causa

Solução

IoT Edge por trás de um gateway não pode executar solicitações HTTP e iniciar o módulo edgeAgent

Sintomas

Causa

Solução

IoT Edge por trás de um gateway não pode executar solicitações HTTP e iniciar o módulo edgeAgent

Sintomas

Causa

Solução

IoT Edge atrás de um gateway não pode se conectar ao migrar de um hub IoT para outro

Sintomas

Causa

Solução

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

Sintomas

Causa

Solução

Próximas etapas

Comentários

Recursos adicionais