Řešení běžných problémů s IoT Edge

Článek
12/10/2024

Platí pro: IoT Edge 1.5 IoT Edge 1.4

Důležité

Podporovanou verzí je IoT Edge 1.5 LTS. IoT Edge 1.4 LTS je konec životnosti od 12. listopadu 2024. Pokud používáte starší verzi, podívejte se na článek Aktualizace IoT Edge.

Tento článek slouží k identifikaci a řešení běžných problémů při používání řešení IoT Edge. Pokud potřebujete informace o tom, jak najít protokoly a chyby ze zařízení IoT Edge, přečtěte si téma Řešení potíží se zařízením IoT Edge.

Zřizování a nasazení

Modul IoT Edge se nasadí úspěšně a pak zmizí ze zařízení

Příznaky

Po nastavení modulů pro zařízení IoT Edge se moduly úspěšně nasadí, ale po několika minutách zmizí ze zařízení a z podrobností o zařízení na webu Azure Portal. Na zařízení se můžou objevit i jiné moduly, než jsou definované moduly.

Příčina

Pokud automatické nasazení cílí na zařízení, má přednost před ručním nastavením modulů pro jedno zařízení. Funkce Sady modulů na webu Azure Portal nebo Vytvoření nasazení pro funkce jednoho zařízení v editoru Visual Studio Code se projeví na chvíli. Zobrazí se moduly, které jste definovali, se spustí v zařízení. Potom se spustí priorita automatického nasazení a přepíše požadované vlastnosti zařízení.

Řešení

Pro každé zařízení používejte pouze jeden typ mechanismu nasazení, a to buď automatické nasazení, nebo jednotlivá nasazení zařízení. Pokud máte více automatických nasazení, která cílí na zařízení, můžete změnit popisy priority nebo cíle, abyste měli jistotu, že se na dané zařízení vztahuje správná nasazení. Můžete také aktualizovat dvojče zařízení tak, aby se přestalo shodovat s cílovým popisem automatického nasazení.

Další informace najdete v tématu Vysvětlení automatických nasazení IoT Edge pro jednotlivá zařízení nebo ve velkém měřítku.

Modul runtime IoT Edge

Agent IoT Edge se zastaví po minutě.

Příznaky

Modul edgeAgent se spustí a úspěšně spustí přibližně minutu a pak se zastaví. Protokoly označují, že se agent IoT Edge pokusí připojit k IoT Hubu přes AMQP a pak se pokusí připojit pomocí AMQP přes WebSocket. Pokud se to nezdaří, agent IoT Edge se ukončí.

Příklady protokolů 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...

Příčina

Konfigurace sítě v hostitelské síti brání agentu IoT Edge v dosažení sítě. Agent se nejprve pokusí připojit přes protokol AMQP (port 5671). Pokud se připojení nezdaří, pokusí se webSockets (port 443).

Modul runtime IoT Edge nastaví pro každý z modulů síť, na které budou komunikovat. V Linuxu je tato síť síťovým mostem. Ve Windows využívá překlad adres (NAT). K tomuto problému častěji dochází na zařízeních s Windows využívajících kontejnery Windows a síť s překladem adres (NAT).

Řešení

Ujistěte se, že existuje trasa k internetu pro IP adresy přiřazené k této síti mostu nebo překladu adres (NAT). Někdy konfigurace sítě VPN na hostiteli přepíše síť IoT Edge.

Modul agenta Edge hlásí prázdný konfigurační soubor a na zařízení se nespouštějí žádné moduly

Příznaky

Zařízení má potíže se spouštěním modulů definovaných v nasazení. Běží pouze agent edgeAgent , ale hlásí prázdný konfigurační soubor....
Při spuštění sudo iotedge check na zařízení hlásí , že modul kontejneru není nakonfigurovaný s nastavením serveru DNS, což může mít vliv na připojení ke službě IoT Hub. Projděte si https://aka.ms/iotedge-prod-checklist-dns osvědčené postupy.

Příčina

IoT Edge ve výchozím nastavení spouští moduly ve vlastní izolované kontejnerové síti. Zařízení může mít problémy s překladem názvů DNS v rámci této privátní sítě.
Pokud používáte instalaci přichycení IoT Edge, konfigurační soubor Dockeru je jiné umístění. Viz možnost řešení 3.

Řešení

Možnost 1: Nastavení serveru DNS v nastavení kontejnerového stroje

V nastavení modulu kontejneru zadejte server DNS pro vaše prostředí, který platí pro všechny moduly kontejneru spuštěné modulem. Vytvořte soubor s názvem daemon.jsona zadejte server DNS, který se má použít. Příklad:

{
    "dns": ["1.1.1.1"]
}

Tento server DNS je nastavený na veřejně přístupnou službu DNS. Některé sítě, jako jsou podnikové sítě, ale mají nainstalované vlastní servery DNS a nepovolují přístup k veřejným serverům DNS. Proto pokud vaše hraniční zařízení nemá přístup k veřejnému serveru DNS, nahraďte ho dostupnou adresou serveru DNS.

Umístěte daemon.json adresář do /etc/docker zařízení.

Pokud už umístění obsahuje daemon.json soubor, přidejte do něj klíč DNS a soubor uložte.

Restartujte modul kontejneru, aby se aktualizace projevily.

sudo systemctl restart docker

Možnost 2: Nastavení serveru DNS v nasazení IoT Edge na modul

Server DNS pro vytváření jednotlivých modulů můžete nastavit v nasazení IoT Edge. Příklad:

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

Upozorňující

Pokud použijete tuto metodu a zadáte nesprávnou adresu DNS, edgeAgent ztratí připojení ke službě IoT Hub a nemůže přijmout nová nasazení, aby se problém vyřešil. Pokud chcete tento problém vyřešit, můžete přeinstalovat modul runtime IoT Edge. Před instalací nové instance IoT Edge nezapomeňte odebrat všechny kontejnery edgeAgent z předchozí instalace.

Nezapomeňte tuto konfiguraci nastavit i pro moduly edgeAgent a edgeHub .

Možnost 3: Předání umístění konfiguračního souboru Dockeru ke kontrole příkazu

Pokud je IoT Edge nainstalovaný jako přichycení, zadejte umístění konfiguračního souboru Dockeru pomocí --container-engine-config-file parametru. Pokud je například konfigurační soubor Dockeru umístěný na /var/snap/docker/current/config/daemon.jsonadrese , spusťte následující příkaz: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'.

Zpráva upozornění se v současné době zobrazuje ve výstupu kontroly iotedge i po nastavení umístění konfiguračního souboru. Zkontrolujte chybu, protože přichycení IoT Edge nemá přístup pro čtení k modulu snap-in Docker. Pokud v procesu vydání použijete kontrolu iotedge, můžete zprávu upozornění potlačit pomocí parametru --ignore container-engine-dns container-engine-logrotate .

Modul agenta Edge s sestavami připojení LTE nahlásí prázdnou konfiguraci agenta Edge a způsobí přechodnou chybu sítě.

Příznaky

Zařízení nakonfigurované s připojením LTE má problémy se spouštěním modulů definovaných v nasazení. EdgeAgent se nemůže připojit ke službě IoT Hub a hlásí prázdnou konfiguraci agenta Edge a došlo k přechodné chybě sítě.

Příčina

Některé sítě mají režijní náklady na pakety, což vede k příliš vysoké hodnotě MTU (1500) sítě Dockeru a způsobuje fragmentaci paketů, která brání přístupu k externím prostředkům.

Řešení

Zkontrolujte nastavení MTU pro vaši síť Dockeru.

docker network inspect <network name>
Zkontrolujte nastavení MTU pro adaptér fyzické sítě na vašem zařízení.

ip addr show eth0

Poznámka:

MTU pro síť Dockeru nemůže být vyšší než MTU pro vaše zařízení. Další informace získáte od svého zprostředkovatele internetových služeb.

Pokud se pro vaši síť Dockeru a zařízení zobrazí jiná velikost MTU, zkuste následující alternativní řešení:

Vytvořte novou síť. Příklad:

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

V tomto příkladu je nastavení MTU pro zařízení 1430. MtU pro síť Dockeru je proto nastavená na 1430.
Zastavte a odeberte síť Azure.

docker network rm azure-iot-edge
Znovu vytvořte síť Azure.

docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge
Odeberte všechny kontejnery a restartujte službu 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

Agent Edge nemá přístup k imagi modulu (403)

Příznaky

Kontejner se nepodaří spustit a agent edgeAgent hlásí chybu 403.

Příčina

Modul agenta IoT Edge nemá oprávnění pro přístup k imagi modulu.

Řešení

Ujistěte se, že přihlašovací údaje registru kontejneru jsou správné v manifestu nasazení zařízení.

Agent IoT Edge provádí nadměrné volání identity

Příznaky

Agent IoT Edge provádí nadměrné volání identity do Azure IoT Hubu.

Příčina

Chybná konfigurace manifestu nasazení zařízení způsobí neúspěšné nasazení v zařízení. Logika opakování agenta IoT Edge pokračuje v nasazení znovu. Každé opakování provede volání identity, dokud nasazení nebude úspěšné. Pokud například manifest nasazení určuje identifikátor URI modulu, který neexistuje v registru kontejneru nebo je chybně zadaný, agent IoT Edge nasazení opakuje, dokud se manifest nasazení neopraví.

Řešení

Ověřte manifest nasazení na webu Azure Portal. Opravte všechny chyby a znovu nasaďte manifest do zařízení.

Centrum služby IoT Edge se nedaří spustit

Příznaky

Modul EdgeHub se nespustí. V protokolech se může zobrazit zpráva podobná jedné z následujících chyb:

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)

Nebo

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)

Příčina

Některé další procesy na hostitelském počítači vázaly port, který se modul EdgeHub pokouší svázat. Centrum IoT Edge mapuje porty 443, 5671 a 8883 pro použití ve scénářích brány. Modul se nepovede spustit, pokud už jeden z těchto portů vázal jiný proces.

Řešení

Tento problém můžete vyřešit dvěma způsoby:

Pokud zařízení IoT Edge funguje jako zařízení brány, musíte najít a zastavit proces, který používá port 443, 5671 nebo 8883. Chyba portu 443 obvykle znamená, že druhý proces je webový server.

Pokud zařízení IoT Edge nepotřebujete používat jako bránu, můžete odebrat vazby portů z možností vytvoření modulu EdgeHubu. Možnosti vytvoření můžete změnit na webu Azure Portal nebo přímo v souboru deployment.json.

Na webu Azure Portal:

Přejděte do centra IoT a v nabídce Správa zařízení vyberte Zařízení.
Vyberte zařízení IoT Edge, které chcete aktualizovat.
Vyberte Nastavit moduly.
Vyberte Nastavení modulu runtime.
V nastavení modulu Edge Hub odstraňte všechno z textového pole Možnosti vytvoření kontejneru.
Výběrem možnosti Použít uložte změny a vytvořte nasazení.

V souboru deployment.json:

Otevřete soubor deployment.json, který jste použili na zařízení IoT Edge.

edgeHub Vyhledejte nastavení v části požadovaných vlastností 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"
   }

Odeberte čáru createOptions a koncovou čárku na konci image řádku před ní:

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

Pokud ho chcete znovu použít na zařízení IoT Edge, vyberte Vytvořit .

Modul IoT Edge nemůže poslat zprávu centru služby edgeHub kvůli chybě 404

Příznaky

Vlastní modul IoT Edge se nepodaří odeslat zprávu do centra IoT Edge s chybou 404 Module not found . Modul runtime IoT Edge vypíše do protokolů následující zprávu:

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 )

Příčina

Modul runtime IoT Edge vynucuje identifikaci procesů pro všechny moduly připojující se k hraničnímuHubu z bezpečnostních důvodů. Ověřuje, že všechny zprávy odeslané modulem pocházejí z ID hlavního procesu modulu. Pokud modul odesílá zprávu z jiného ID procesu, než je původně navázáno, odmítne zprávu s chybovou zprávou 404.

Řešení

Od verze 1.0.7 jsou všechny procesy modulů autorizované k připojení. Další informace najdete v protokolu změn vydané verze 1.0.7.

Pokud upgrade na verzi 1.0.7 není možný, proveďte následující kroky. Ujistěte se, že vlastní modul IoT Edge vždy používá stejné ID procesu k odesílání zpráv do edgeHubu. Nezapomeňte ENTRYPOINT CMD například místo příkazu v souboru Dockeru. Příkaz CMD vede k jednomu ID procesu modulu a k jinému ID procesu pro příkaz Bash, který spouští hlavní program, ale ENTRYPOINT vede k jednomu ID procesu.

Problémy se stabilitou na menších zařízeních

Příznaky

Na zařízeních s omezenými prostředky, jako je Raspberry Pi, může docházet k problémům se stabilitou, zejména pokud se používá jako brána. Mezi příznaky patří výjimky z nedostatku paměti v modulu centra IoT Edge, podřízená zařízení se nedaří připojit nebo zařízení, které po několika hodinách neodesílá telemetrické zprávy.

Příčina

Centrum IoT Edge, které je součástí modulu runtime IoT Edge, je ve výchozím nastavení optimalizované pro výkon a pokouší se přidělit velké bloky paměti. Tato optimalizace není ideální pro omezená hraniční zařízení a může způsobit problémy se stabilitou.

Řešení

Pro centrum IoT Edge nastavte proměnnou prostředí OptimizeForPerformance na false. Proměnné prostředí můžete nastavit dvěma způsoby:

Na webu Azure Portal:

Ve službě IoT Hub vyberte své zařízení IoT Edge a na stránce s podrobnostmi o zařízení vyberte Nastavení>modulu runtime.
Vytvořte proměnnou prostředí pro modul centra IoT Edge s názvem OptimizeForPerformance s typem True/False , který je nastavený na False.

Chcete-li uložit změny, vyberte Zkontrolovat a vytvořit.

Proměnná prostředí je teď ve edgeHub vlastnosti manifestu nasazení:

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

Výběrem možnosti Vytvořit uložte změny a nasaďte modul.

Proces démon zabezpečení se nepodařilo spustit úspěšně

Příznaky

Proces démon zabezpečení se nespustí a kontejnery modulů se nevytvořily. edgeHub Služba edgeAgentIoT Edge nespustit moduly a další vlastní moduly. V aziot-edged protokolech se zobrazí tato chyba:

Proces démon se nepodařilo úspěšně spustit: Nepodařilo se spustit službu správy.

způsobené: Došlo k chybě pro cestu /var/run/iotedge/mgmt.sock

způsobené: Oprávnění odepřeno (chyba operačního systému 13)

Příčina

Pro všechny distribuce Linuxu s výjimkou CentOS 7 je výchozí konfigurace IoT Edge používat systemd aktivaci soketu. K chybě oprávnění dojde v případě, že změníte konfigurační soubor tak, aby nepoužít aktivaci soketu, ale adresy URL ponecháte jako /var/run/iotedge/*.sock, protože iotedge uživatel nemůže zapisovat, což /var/run/iotedge znamená, že nemůže odemknout a připojit samotné sokety. CentOS je Konec životnosti (EOL). Další informace najdete v doprovodných materiálech CentOS End Of Life.

Řešení

Aktivaci soketu v distribuci, ve které se podporuje aktivace soketu, není nutné zakázat. Pokud však raději nepoužíváte aktivaci soketu vůbec, vložte sokety do /var/lib/iotedge/.

Spuštěním systemctl disable iotedge.socket iotedge.mgmt.socket zakažte jednotky soketů, aby se systém nespustí zbytečně.
Změna konfigurace iotedge tak, aby se používala /var/lib/iotedge/*.sock v obou connect listen částech
Pokud už máte moduly, mají staré /var/run/iotedge/*.sock přípojky, takže docker rm -f jsou.

Vyčištění fronty zpráv je pomalé

Příznaky

Fronta zpráv se po zpracování zpráv nevyčistí. Fronta zpráv postupně roste a nakonec způsobí, že modul runtime IoT Edge dojde k nedostatku paměti.

Příčina

Interval čištění zpráv je řízen hodnotu TTL (time to live) a proměnnou prostředí EdgeHub MessageCleanupIntervalSecs . Výchozí hodnota TTL zprávy je dvě hodiny a výchozí hodnota MessageCleanupIntervalSecs je 30 minut. Pokud vaše aplikace používá hodnotu TTL, která je kratší než výchozí hodnota a neupravíte hodnotu MessageCleanupIntervalSecs , zprávy s vypršenou platností se do dalšího intervalu vyčištění nevyčistí.

Řešení

Pokud změníte hodnotu TTL pro vaši aplikaci, která je kratší než výchozí, upravte také hodnotu MessageCleanupIntervalSecs . Hodnota MessageCleanupIntervalSecs by měla být výrazně menší než nejmenší hodnota TTL, kterou klient používá. Pokud například klientská aplikace definuje hodnotu TTL 5 minut v hlavičce zprávy, nastavte hodnotu MessageCleanupIntervalSecs na jednu minutu. Tato nastavení zajistí, že se zprávy vyčistí do šesti (5 + 1) minut.

Pokud chcete nakonfigurovat hodnotu MessageCleanupIntervalSecs , nastavte proměnnou prostředí v manifestu nasazení pro modul centra IoT Edge. Další informace o nastavení proměnných prostředí modulu runtime najdete v tématu o proměnných prostředí edge agenta a centra Edge.

IoT Edge Hub hlásí System.FormatException pomocí protokolu AMQP.

Příznaky

Při směrování zpráv ze zařízení IoT Edge do IoT Hubu pomocí protokolu AMQP a nastavíte iothub-creation-time-utc vlastnost u odchozích zpráv zařízení, IoT Edge Hub hlásí System.FormatException chybu. Chybová zpráva je podobná následující:

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

Příčina

Hodnota iot-hub-creation-time-utc nesplňuje striktní kritéria formátu. Formát Edge Hubu vyžaduje podmnožinu ISO 8601.

Řešení

Jedná se o známý problém ve službě IoT Edge Hub pro protokol AMQP. V současné době se problém prošetřuje kvůli opravě. Tento problém nemá protokol MQTT.

Sítě

Proces démon zabezpečení IoT Edge selže s neplatným názvem hostitele

Příznaky

Pokus o kontrolu protokolů správce zabezpečení IoT Edge se nezdaří a vytiskne následující zprávu:

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

Příčina

Modul runtime IoT Edge může podporovat pouze názvy hostitelů, které jsou kratší než 64 znaků. Fyzické počítače obvykle nemají dlouhé názvy hostitelů, ale problém je častější na virtuálním počítači. Automaticky generované názvy hostitelů pro virtuální počítače s Windows hostované v Azure jsou zejména dlouhé.

Řešení

Když se zobrazí tato chyba, můžete ji vyřešit konfigurací názvu DNS virtuálního počítače a následným nastavením názvu DNS jako názvu hostitele v příkazu nastavení.

Na webu Azure Portal přejděte na stránku s přehledem vašeho virtuálního počítače.
Otevřete konfigurační panel výběrem odkazu Nenakonfigurováno (pokud je váš virtuální počítač nový) nebo v části Základní>název DNS vyberte existující název DNS. Pokud už váš virtuální počítač má nakonfigurovaný název DNS, nemusíte ho konfigurovat.
Zadejte hodnotu pro popisek názvu DNS, pokud ho ještě nemáte, a vyberte Uložit.
Zkopírujte nový název DNS, který by měl být ve formátu:
<DNSnamelabel>.<vmlocation.cloudapp.azure.com>.
Na zařízení IoT Edge otevřete konfigurační soubor.
```
sudo nano /etc/aziot/config.toml
```
Nahraďte hodnotu hostname názvem DNS.
Uložte a zavřete soubor a pak použijte změny na IoT Edge.
```
sudo iotedge config apply
```

Modul IoT Edge hlásí chyby připojení

Příznaky

Moduly IoT Edge, které se připojují přímo ke cloudovým službám, včetně modulů runtime, přestanou fungovat podle očekávání a vrací chyby související s připojením nebo selháním sítě.

Příčina

Kontejnery spoléhají na předávání paketů PROTOKOLU IP, aby se mohly připojit k internetu, aby mohly komunikovat s cloudovými službami. Předávání paketů IP je ve výchozím nastavení v Dockeru povolené, ale pokud se zakáže, nebudou všechny moduly, které se připojují ke cloudovým službám, fungovat podle očekávání. Další informace najdete v tématu Vysvětlení komunikace kontejneru v dokumentaci k Dockeru.

Řešení

Pomocí následujících kroků povolte předávání paketů PROTOKOLU IP.

Otevřete soubor sysctl.conf.
```
sudo nano /etc/sysctl.conf
```
Do souboru přidejte následující řádek.
```
net.ipv4.ip_forward=1
```
Soubor uložte a zavřete.
Restartujte síťovou službu a službu Dockeru, aby se změny použily.

IoT Edge za bránou nemůže provádět požadavky HTTP a spouštět modul edgeAgent

Příznaky

Modul runtime IoT Edge je aktivní s platným konfiguračním souborem, ale nemůže spustit modul edgeAgent . Příkaz iotedge list vrátí prázdný seznam. Sestavy modulu runtime Could not perform HTTP request IoT Edge v protokolech.

Příčina

Zařízení IoT Edge za bránou získávají image modulů z nadřazeného zařízení IoT Edge zadaného v parent_hostname poli konfiguračního souboru. Tato Could not perform HTTP request chyba znamená, že podřízené zařízení se nemůže spojit s nadřazeným zařízením přes protokol HTTP.

Řešení

Ujistěte se, že nadřazené zařízení IoT Edge může přijímat příchozí požadavky z podřízeného zařízení IoT Edge. Otevřete síťový provoz na portech 443 a 6617 pro požadavky přicházející z podřízeného zařízení.

IoT Edge za bránou nemůže provádět požadavky HTTP a spouštět modul edgeAgent

Příznaky

Démon IoT Edge je aktivní s platným konfiguračním souborem, ale nemůže spustit modul edgeAgent. Příkaz iotedge list vrátí prázdný seznam. Sestava Could not perform HTTP requestprotokolů démona IoT Edge .

Příčina

Řešení

IoT Edge se nemůže připojit při migraci z jednoho centra IoT do jiného

Příznaky

Při pokusu o migraci hierarchie zařízení IoT Edge z jednoho centra IoT do jiného se nadřazené zařízení IoT Edge nejvyšší úrovně může připojit ke službě IoT Hub, ale podřízená zařízení IoT Edge nemůžou. Sestava Unable to authenticate client downstream-device/$edgeAgent with module credentialsprotokolů .

Příčina

Přihlašovací údaje pro podřízená zařízení se při migraci do nového centra IoT neaktualizovaly správně. Z tohoto důvodu byly nastaveny moduly tak, edgeAgent edgeHub aby měly typ none ověřování (výchozí, pokud není nastaven explicitně). Během připojení moduly na podřízených zařízeních používají staré přihlašovací údaje, což způsobuje selhání ověřování.

Řešení

Při migraci na nové centrum IoT (za předpokladu, že nepoužíváte DPS), postupujte takto:

Podle tohoto průvodce exportujte a importujte identity zařízení ze starého centra IoT do nového.
Změna konfigurace všech nasazení a konfigurací IoT Edge v novém ioT Hubu
Změna konfigurace všech relací zařízení nadřazených a podřízených v novém centru IoT
Aktualizujte každé zařízení tak, aby odkazovat na nový název hostitele služby IoT Hub (iothub_hostnamev části [provisioning] )config.toml
Pokud jste se rozhodli vyloučit ověřovací klíče během exportu zařízení, překonfigurujte každé zařízení pomocí nových klíčů, které poskytne nové centrum IoT (device_id_pk v části [provisioning.authentication] in config.toml).
Nejprve restartujte nadřazené zařízení Edge nejvyšší úrovně, ujistěte se, že je spuštěné.
Restartujte každé zařízení na úrovni hierarchie podle úrovně shora dolů.

IoT Edge má nízkou propustnost zpráv, když je geograficky vzdálená od IoT Hubu

Příznaky

Zařízení Azure IoT Edge, která jsou geograficky vzdálená od Azure IoT Hubu, mají nižší, než se očekávala propustnost zpráv.

Příčina

Vysoká latence mezi zařízením a IoT Hubem může způsobit nižší, než očekávanou propustnost zpráv. IoT Edge používá výchozí velikost dávky zpráv 10. Tím se omezí počet zpráv odesílaných v jedné dávce, což zvyšuje počet odezv mezi zařízením a IoT Hubem.

Řešení

Zkuste zvýšit proměnnou prostředí IoT Edge Hub MaxUpstreamBatchSize . To umožňuje odesílání více zpráv v jedné dávce, což snižuje počet odezv mezi zařízením a IoT Hubem.

Nastavení proměnných prostředí Azure Edge Hubu na webu Azure Portal:

Přejděte do služby IoT Hub a v nabídce Správa zařízení vyberte Zařízení.
Vyberte zařízení IoT Edge, které chcete aktualizovat.
Vyberte Nastavit moduly.
Vyberte Nastavení modulu runtime.
Na kartě Nastavení modulu Edge Hub přidejte proměnnou prostředí MaxUpstreamBatchSize jako typ Číslo s hodnotou 20.
Vyberte Použít.

Další kroky

Myslíte si, že jste v platformě IoT Edge našli chybu? Odešlete problém , abychom mohli pokračovat v vylepšování.

Pokud máte další otázky, vytvořte žádost o pomoc.

Sdílet prostřednictvím

Řešení běžných problémů s IoT Edge

Zřizování a nasazení

Modul IoT Edge se nasadí úspěšně a pak zmizí ze zařízení

Příznaky

Příčina

Řešení

Modul runtime IoT Edge

Agent IoT Edge se zastaví po minutě.

Příznaky

Příčina

Řešení

Modul agenta Edge hlásí prázdný konfigurační soubor a na zařízení se nespouštějí žádné moduly

Příznaky

Příčina

Řešení

Modul agenta Edge s sestavami připojení LTE nahlásí prázdnou konfiguraci agenta Edge a způsobí přechodnou chybu sítě.

Příznaky

Příčina

Řešení

Agent Edge nemá přístup k imagi modulu (403)

Příznaky

Příčina

Řešení

Agent IoT Edge provádí nadměrné volání identity

Příznaky

Příčina

Řešení

Centrum služby IoT Edge se nedaří spustit

Příznaky

Příčina

Řešení

Modul IoT Edge nemůže poslat zprávu centru služby edgeHub kvůli chybě 404

Příznaky

Příčina

Řešení

Problémy se stabilitou na menších zařízeních

Příznaky

Příčina

Řešení

Proces démon zabezpečení se nepodařilo spustit úspěšně

Příznaky

Příčina

Řešení

Vyčištění fronty zpráv je pomalé

Příznaky

Příčina

Řešení

IoT Edge Hub hlásí System.FormatException pomocí protokolu AMQP.

Příznaky

Příčina

Řešení

Sítě

Proces démon zabezpečení IoT Edge selže s neplatným názvem hostitele

Příznaky

Příčina

Řešení

Modul IoT Edge hlásí chyby připojení

Příznaky

Příčina

Řešení

IoT Edge za bránou nemůže provádět požadavky HTTP a spouštět modul edgeAgent

Příznaky

Příčina

Řešení

IoT Edge za bránou nemůže provádět požadavky HTTP a spouštět modul edgeAgent

Příznaky

Příčina

Řešení

IoT Edge se nemůže připojit při migraci z jednoho centra IoT do jiného

Příznaky

Příčina

Řešení

IoT Edge má nízkou propustnost zpráv, když je geograficky vzdálená od IoT Hubu

Příznaky

Příčina

Řešení

Další kroky

Váš názor

Další materiály