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

Aplica-se a: IoT Edge 1.1

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ê vai ver os módulos que definiu começarem 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.

Não é possível obter os logs de runtime do IoT Edge no Windows

Sintomas

Você obtém um EventLogException ao usar Get-WinEvent no Windows.

Causa

O comando Get-WinEvent PowerShell depende de que uma entrada do Registro esteja presente para localizar logs por um determinado ProviderName.

Solução

Defina uma entrada do Registro para o daemon do IoT Edge. Crie um arquivo iotedge.reg com o seguinte conteúdo e importe para o Registro do Windows clicando duas vezes nele ou usando o reg import iotedge.reg comando:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\iotedged]
"CustomSource"=dword:00000001
"EventMessageFile"="C:\\ProgramData\\iotedge\\iotedged.exe"
"TypesSupported"=dword:00000007

Erro do cliente DPS

Sintomas

O IoT Edge falha ao iniciar com a mensagem de erro failed to provision with IoT Hub, and no valid device backup was found dps client error.

Causa

Um registro de grupo é usado para provisionar um dispositivo IoT Edge em um Hub IoT. O dispositivo IoT Edge é movido para um hub diferente. O registro é excluído no DPS. Um novo registro é criado no DPS para o novo hub. O dispositivo não é reprovisionado.

Solução

1. Verifique se suas credenciais de DPS estão corretas.
2. Aplique sua configuração usando sudo iotedge apply config.
3. Se o dispositivo não for reprovisionado, reinicie o dispositivo usando sudo iotedge system restart.
4. Caso o dispositivo não seja reprovisionado, force o reprovisionamento usando sudo iotedge system reprovision.

Para reprovisionar automaticamente, defina dynamic_reprovisioning: true no arquivo de configuração do dispositivo. Definir esse sinalizador como true aceita o recurso de reprovisionamento dinâmico. O IoT Edge detecta situações em que o dispositivo parece ter sido reprovisionado na nuvem ao monitorar a própria conexão do IoT Hub para determinados erros. O IoT Edge responde desligando todos os módulos do Edge e a si mesmo. Na próxima vez que o daemon for iniciado, ele tentará reprovisionar esse dispositivo com o Azure para receber as novas informações de provisionamento do Hub IoT.

Ao usar o provisionamento externo, o daemon também notificará o endpoint de provisionamento externo sobre o evento de reprovisionamento antes de desligar. Para obter mais informações, confira Conceitos de reaprovisionamento de dispositivo do Hub IoT.

tempo de execução do IoT Edge

O agente do 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, é 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 encerra.

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, mas continuamente relatando 'arquivo de configuração vazio...'.

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.

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 serão aplicadas 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 local certo para sua plataforma:

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

Reinicie o mecanismo de contêiner para que as atualizações tenham efeito.

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.

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 no manifesto de implantação do 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)

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

Outros processos na máquina host atribuíram uma porta que o módulo edgeHub está tentando atribuir. 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:

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

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

6. Salve suas modificações e crie a implantação.

No arquivo deployment.json:

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

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

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

3. Remova a linha createOptions e a vírgula no final da linha image que a precede.

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

4. Salve o arquivo e aplique-o 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, ela 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 de falta de memória no módulo de hub do IoT Edge, os dispositivos downstream falham ao se conectar, ou o dispositivo falha em 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ções de recursos 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 seu Hub IoT, selecione o seu dispositivo IoT Edge e, na página de detalhes do dispositivo, selecione Configurar Módulos>Configurações de Tempo de Execução. Crie uma variável de ambiente para o módulo do hub do IoT Edge chamado OptimizeForPerformance definido como false.

No manifesto de implantação:

"edgeHub": {
  "type": "docker",
  "settings": {
    "image": "mcr.microsoft.com/azureiotedge-hub:1.1",
    "createOptions": <snipped>
  },
  "env": {
    "OptimizeForPerformance": {
      "value": "false"
    }
  },

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.

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 soquetes, coloque os soquetes em /var/lib/iotedge/.

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

Não foi possível iniciar o módulo devido à incompatibilidade do sistema operacional

Sintoma

O módulo do edgeHub falha ao iniciar no IoT Edge versão 1.1.

Causa

O módulo do Windows usa uma versão do Windows incompatível com a versão do Windows no host. O IoT Edge Windows versão 1809 build 17763 é necessário como a camada base para a imagem do módulo, mas uma versão diferente está em uso.

Solução

Verifique a versão de seus vários sistemas operacionais Windows em Solucionar problemas de incompatibilidade de imagens do host e do contêiner. Se os sistemas operacionais forem diferentes, atualize-os para o IoT Edge Windows versão 1809 build 17763 e recompile a imagem do Docker usada para esse módulo.

Rede

O daemon de segurança do IoT Edge falha com um hostname 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, poderá resolvê-lo configurando o nome DNS de sua máquina virtual e, em seguida, definindo o nome DNS como o nome de host no comando de configuração.

1. No portal do Azure, navegue até a página de visão geral de sua máquina virtual.

2. Selecione configurar no nome DNS. Caso sua máquina virtual já tenha um nome DNS configurado, você não precisará configurar um novo.

   

3. Forneça um valor para o rótulo de nome DNS e selecione Salvar.

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

5. Dentro da máquina virtual, use o seguinte comando para configurar o runtime do IoT Edge com seu nome DNS:

   • No Linux:

     sudo nano /etc/iotedge/config.yaml
     

   • No Windows:

     notepad C:\ProgramData\iotedge\config.yaml
     

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.

Em Windows:

1. Abra o programa Executar.

2. Insira regedit a caixa de texto e selecione Ok.

3. Na janela Editor do Registro , navegue até HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

4. Procure o parâmetro IPEnableRouter .

   1. Se o parâmetro existir, defina o valor do parâmetro como 1.

   2. Se o parâmetro não existir, adicione-o como um novo parâmetro com as seguintes configurações:

      Configurações	Valor
      Nome	IPEnableRouter
      Tipo	REG_DWORD
      Valor	1

5. Feche a janela do editor do Registro.

6. Reinicie o sistema para aplicar as alterações.

No Linux:

1. Abra o arquivo sysctl.conf.

   sudo nano /etc/sysctl.conf
   

2. Adicione a seguinte linha ao arquivo.

   net.ipv4.ip_forward=1
   

3. Salve e feche o arquivo.

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

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.