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

Platí na: IoT Edge 1.6

Důležité

IoT Edge 1.6 LTS je podporovaná verze. Podpora IoT Edge 1.5 LTS končí 10. listopadu 2026; IoT Edge 1.4 LTS dosáhl konce životnosti 12. listopadu 2024. Pokud používáte starší verzi, přečtěte si téma Update IoT Edge.

Tento článek slouží k identifikaci a řešení běžných problémů při používání IoT Edge řešení. Informace o tom, jak najít protokoly a chyby ze zařízení IoT Edge, najdete v tématu Řešení IoT Edge zařízení.

Zřizování a nasazení

IoT Edge modul úspěšně nasadí 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 portálu Azure. 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 Nastavení modulů na portálu Azure nebo funkce Vytvoření nasazení pro jedno zařízení ve Visual Studio Code má okamžitý efekt. Vidíte, že moduly, které jste definovali, se spustí na 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žijte 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 prioritu nebo popisy cílů, 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 Pochopení automatického nasazení IoT Edge pro jednotlivá zařízení i ve velkém měřítku.

modul runtime IoT Edge

IoT Edge agent se zastaví po minutě

Příznaky

Modul edgeAgent se spustí a úspěšně spustí přibližně minutu a pak se zastaví. Protokoly ukazují, že se agent IoT Edge pokusí připojit k IoT Hub přes AMQP a pak se pokusí připojit pomocí AMQP přes WebSocket. Když se připojení 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í IoT Edge agenta v připojení k síti. 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í síť pro jednotlivé moduly ke komunikaci. V Linuxu je tato síť síťovým mostem. Na Windows používá překlad adres (NAT). Tento problém je častější u zařízení Windows používajících kontejnery Windows, které používají síť NAT.

Řešení

Ujistěte se, že existuje trasa k internetu pro IP adresy přiřazené k tomuto mostu nebo síti 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í. Pouze edgeAgent je spuštěn, ale hlásí prázdný konfigurační soubor....
Když na zařízení spustíte , hlásí Kontejnerový engine není nakonfigurovaný s nastavením serveru DNS, což může mít vliv na připojení k IoT Hub. Podívejte se na pro osvědčené postupy.

Příčina

Ve výchozím nastavení IoT Edge 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žijete snap instalaci IoT Edge, konfigurační soubor Dockeru je v jiném 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í. Tato nastavení platí pro všechny moduly kontejneru, které modul spouští. 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í vlastní servery DNS a neumožňují přístup k veřejným serverům DNS. Proto pokud vaše edge zařízení nemá přístup k veřejnému serveru DNS, nahraďte jej dostupnou adresou serveru DNS.

Umístěte daemon.json do adresáře /etc/docker na vašem zařízení.

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

Restartujte modul kontejneru, aby se aktualizace projevily.

sudo systemctl restart docker

Option 2: Nastavte server DNS v nasazení IoT Edge pro jednotlivé moduly

Server DNS můžete nastavit pro oddíl createOptions každého modulu v nasazení IoT Edge. Příklad:

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

Upozornění

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

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 instalujete IoT Edge jako snap, použijte parametr --container-engine-config-file ke specifikaci umístění konfiguračního souboru Dockeru. 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'.

V současné době se zpráva upozornění bude dál zobrazovat ve výstupu kontroly iotedge i po nastavení umístění konfiguračního souboru. Kontrola hlásí chybu, protože snap IoT Edge nemá přístup pro čtení k snapu Dockeru. Pokud v procesu vydání použijete příkaz iotedge check, můžete zprávu upozornění potlačit použitím parametru --ignore container-engine-dns container-engine-logrotate.

Modul agenta Edge s připojením LTE hlásí „prázdnou konfiguraci agenta Edge“ a způsobuje „přechodnou chybu sítě“.

Příznaky

Zařízení nakonfigurované pomocí připojení LTE má problémy se spouštěním modulů definovaných v nasazení. edgeAgent se nemůže připojit k 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, takže výchozí síť Docker Network MTU (1500) je příliš vysoká a způsobuje fragmentaci paketů. Tato fragmentace 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 fyzického síťového adaptéru 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. Nastavte MTU pro síť Dockeru 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

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

Příznaky

Kontejner se nedaří spustit a edgeAgent protokoly 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í.

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

Příznaky

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

Příčina

Chybná konfigurace manifestu nasazení zařízení způsobí neúspěšné nasazení v zařízení. IoT Edge Agent s logikou opakování pokračuje v pokusech o nasazení. 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 opakuje nasazení, dokud se manifest nasazení neopraví.

Řešení

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

Byla překročena kvóta operací s identitami ve službě IoT Hub pro rozsáhlou flotilu zařízení.

Příznaky

Zařízení v zaneprázdněném centru IoT se nepodaří připojit, seznam zařízení se nenačte na portálu Azure a operace vrátí ThrottlingBacklogTimeout chybu. V protokolech služby IoT Identity Service (aziot-identityd) se zobrazují opakovaná HTTP request throttled upozornění a v protokolech centra IoT Edge se zobrazují položky jako Encountered an error while refreshing the device scope identities cache. Will retry.

Tento příznak se obvykle objevuje pouze u rozbočovačů s rozsáhlou a hustou flotilou zařízení (mnoho tisíc okrajových zařízení na jednom rozbočovači).

Příčina

Každé centrum IoT Edge uchovává místní mezipaměť zařízení a modulů v jejím oboru, aby bylo možné ověřovat podřízená zařízení a moduly místně. Centrum IoT Edge aktualizuje tuto mezipaměť na časovači tím, že vyčíslí její rozsah z IoT Hub, což generuje operace identit s centrem. Ve výchozím nastavení se tato aktualizace spouští každou hodinu na každém IoT Edge zařízení.

IoT Hub uplatňuje omezení identity operací pro každý hub. Když jedno centrum obsluhuje velký počet zařízení IoT Edge, která všechna obnovují svůj rozsah ve stejném výchozím intervalu, může kombinovaná míra operací výčtu rozsahů překročit kvótu centra pro operace s identitami. Výsledkem je omezování, které může zabránit úspěšnému obnovení rozsahu i normálnímu připojení zařízení. Protože se omezení propustnosti vztahuje na každý rozbočovač, problém závisí na hustotě zařízení (počtu zařízení na rozbočovač), nikoli na konfiguraci jednotlivých zařízení.

Na rozdíl od příčiny opakování popsané v předchozí části není tato příčina chybnou konfigurací. Je to charakteristika škálování, která se zobrazuje při vysokém počtu zařízení v jednom centru.

Řešení

Pokud chcete snížit objem operací aktualizace rozsahu, zvyšte interval aktualizace mezipaměti oboru centra IoT Edge. Nastavte proměnnou DeviceScopeCacheRefreshRateSecs prostředí v modulu IoT Edge hub ($edgeHub) na hodnotu větší než výchozí hodnota 3600 sekund. Nastavte ji například na 43200 (12 hodin), abyste snížili frekvenci aktualizace na dvanáctou dvanáctou z výchozích hodnot. Další informace o proměnných prostředí centra IoT Edge naleznete v tématu Vlastnosti agenta IoT Edge a dvojčata modulu centra IoT Edge.

Tuto změnu pečlivě zvažte, pokud vaše zařízení fungují jako brány pro následná (podřízená) zařízení. Delší interval znamená, že rozšíření změn identity podřízeného zařízení, jako je odebrání nebo zakázání zařízení, do mezipaměti IoT Edge centra trvá delší dobu. Nové ověřování zařízení není ovlivněno, protože centrum IoT Edge aktualizuje jednu identitu na vyžádání, když se klient připojí. U samostatného IoT Edge zařízení s pouze místními moduly a bez podřízených zařízení můžete interval prodloužit s minimálním kompromisem. Nejprve otestujte delší interval na několika zařízeních a ověřte, že varování o omezování v protokolech aziot-identityd ubývají.

Mezi další možnosti, jak snížit zátěž operací s identitami, patří rozložení zařízení do více rozbočovačů (omezení se uplatňuje na každý rozbočovač) a snížení počtu modulů v jednom zařízení, což snižuje počet identit v rámci každého zařízení.

IoT Edge centrum 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ějaký jiný proces na hostitelském počítači obsadil port, který se modul edgeHub pokouší navázat. Centrum IoT Edge mapuje porty 443, 5671 a 8883 pro použití ve scénářích brány. Modul se nepovede spustit, pokud jiný proces již jeden z těchto portů vázal.

Řešení

Tento problém můžete vyřešit jedním ze dvou způsobů:

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

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

Na portálu Azure:

Přejděte do centra IoT a v nabídce Správa zařízení vyberte Zařízení.
Vyberte IoT Edge zařízení, 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.6",
         "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"443/tcp\":[{\"HostPort\":\"443\"}],\"5671/tcp\":[{\"HostPort\":\"5671\"}],\"8883/tcp\":[{\"HostPort\":\"8883\"}]}}}"
      },
      "status": "running",
      "type": "docker"
   }

Odeberte řádek createOptions a koncovou čárku na konci řádku image před ním.

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

Vyberte Create a znovu ho použijte na zařízení IoT Edge.

IoT Edge modul nemůže odeslat zprávu do EdgeHubu a vrátí chybu 404

Příznaky

Vlastní modul IoT Edge nemůže odeslat zprávu do centra IoT Edge a vrátí chybu 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

Pro bezpečnostní důvody IoT Edge runtime prostředí vynucuje identifikaci procesů pro všechny moduly připojující se k edgeHubu. Ověřuje, že všechny zprávy, které modul odesílá, pocházejí z ID hlavního procesu modulu. Pokud se modul pokusí odeslat zprávu z jiného ID procesu, modul runtime zprávu odmítne a vrátí chybovou zprávu 404.

Řešení

Od verze 1.0.7 se můžou připojit všechny procesy modulů. Další informace najdete v protokolu změn vydané verze 1.0.7.

Pokud nemůžete upgradovat na verzi 1.0.7, postupujte takto. Ujistěte se, že vlastní modul IoT Edge vždy používá stejné identifikátor procesu (process ID) k odesílání zpráv do edgeHubu. Například místo příkazu v souboru Dockeru ENTRYPOINT použijte CMD příkaz. Výsledkem CMD příkazu je jedno ID procesu modulu a další ID procesu pro příkaz Bash, který spouští hlavní program. Výsledkem ENTRYPOINT příkazu je jedno 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í

V centru IoT Edge nastavte proměnnou prostředí OptimizeForPerformance na false. Proměnné prostředí můžete nastavit jedním ze dvou způsobů:

Na portálu Azure:

V IoT Hub vyberte zařízení IoT Edge. Na stránce s podrobnostmi o zařízení vyberte Nastavení parametrů modulu za běhu>.
Vytvořte proměnnou prostředí pro modul centra IoT Edge s názvem OptimizeForPerformance s typem True/False a nastavte ji na False.

Pokud chcete změny uložit, vyberte Použít a pak vyberte Zkontrolovat a vytvořit.

Proměnná prostředí se nyní nachází ve vlastnosti edgeHub manifestu nasazení:

   "edgeHub": {
      "env": {
            "OptimizeForPerformance": {
               "value": false
            }
      },
      "restartPolicy": "always",
      "settings": {
            "image": "mcr.microsoft.com/azureiotedge-hub:1.6",
            "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.

Démon zabezpečení nelze spustit

Příznaky

Démon zabezpečení se nemůže spustit a kontejnery modulů nejsou vytvořeny. Služba IoT Edge nespustí edgeAgent, edgeHub ani jiné vlastní moduly. aziot-edged V protokolech se zobrazí tato chybová zpráva:

Démon se nepodařilo úspěšně spustit: Službu správy nelze spustit.

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 IoT Edge ve výchozím nastavení používá aktivaci soketu systemd. Pokud změníte konfigurační soubor tak, aby zakázal aktivaci soketu, ale adresy URL ponecháte jako /var/run/iotedge/*.sock, zobrazí se chyba oprávnění. Uživatel iotedge nemůže zapisovat do /var/run/iotedge, takže nemůže odemknout a připojit sokety. CentOS dosáhl konce své životnosti (EOL). Další informace najdete v doprovodných materiálech CentOS End Of Life.

Řešení

Nezakažujte aktivaci soketu v distribuci, která podporuje aktivaci soketu. Pokud však nechcete používat aktivaci soketu, vložte sokety do /var/lib/iotedge/.

Spuštěním systemctl disable iotedge.socket iotedge.mgmt.socket zakažte jednotky soketů, aby je systém nespustí.
Změňte konfiguraci iotedge tak, aby se používala /var/lib/iotedge/*.sock v obou částech connect a listen.
Pokud už máte moduly, mají staré /var/run/iotedge/*.sock držáky, takže spusťte docker rm -f pro jejich odstranění.

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 IoT Edge runtime dojde k nedostatku paměti.

Příčina

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

Řešení

Pokud změníte hodnotu TTL vaší aplikace na hodnotu kratší než výchozí hodnota, upravte MessageCleanupIntervalSecs ji také. 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 na jednu minutu MessageCleanupIntervalSecs . 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í runtime viz Edge Agent a Edge Hub Environment Variables.

Vlastní moduly po prodloužení platnosti certifikátu certifikační autority Edge přestanou odesílat zprávy

Příznaky

Vlastní moduly přestanou komunikovat s EdgeHubem po určité době, obvykle přibližně 24 až 30 dnů při použití výchozího 30denního certifikátu certifikační autority Edge nebo 80% nakonfigurované životnosti certifikátu. Moduly EdgeHub a EdgeAgent se budou dál spouštět, ale vlastní moduly už nemůžou odesílat ani přijímat zprávy přes EdgeHub.

Příčina

Když se certifikát certifikační autority Edge automaticky obnoví, IoT Edge zastaví a restartuje všechny moduly, aby dostávaly nové certifikáty serveru. Po restartování musí moduly znovu vytvořit připojení k EdgeHubu. Pokud vlastní modul neimplementuje logiku opakování připojení, modul se spustí, ale nemůže se znovu připojit k EdgeHubu, protože nový certifikát serveru EdgeHub ještě není k dispozici nebo modul nezopakuje počáteční pokus o připojení.

Řešení

Zkontrolujte události obnovení certifikátu v protokolech EdgeAgent:

sudo iotedge logs edgeAgent | grep -i "renewal"

Řešení je následující:

Ověřte, že každý vlastní modul má "restartPolicy": "always" v manifestu nasazení.
Implementujte logiku opakování připojení ve vlastních modulech. Použijte integrované zásady opakování sady SDK zařízení Azure IoT nebo přidejte logiku exponenciálního zpětného odběru, aby se modul po restartu automaticky znovu připojil k EdgeHubu. Další informace najdete v tématu Správa připojení a spolehlivé zprávy pomocí sad SDK pro zařízení Azure IoT Hub.
Pokud chcete řídit, kdy dojde k přerušení obnovení, nastavte threshold místo procenta absolutní čas. Například threshold = "10d" aktivuje prodloužení 10 dnů před vypršením platnosti certifikátu. Další informace najdete v tématu Plan for Edge CA renewal.

IoT Edge Hub hlásí chybu System.FormatException při použití protokolu AMQP

Příznaky

Při směrování zpráv ze zařízení IoT Edge do IoT Hub pomocí protokolu AMQP a nastavení vlastnosti iothub-creation-time-utc u odchozích zpráv zařízení IoT Edge Hub hlásí chybu System.FormatException. 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, který Edge Hub vyžaduje, je podmnožina ISO 8601.

Řešení

Tento problém je známý problém v centru IoT Edge pro protokol AMQP. V současné době produktový tým prošetřuje opravu. Tento problém nemá protokol MQTT.

Sítě

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

Příznaky

Pokus o zkontrolovat protokoly správce zabezpečení IoT Edge se nezdaří a zobrazí se následující zpráva:

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

Příčina

Modul runtime IoT Edge podporuje názvy hostitelů 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 Windows hostované v Azure bývají zejména dlouhé.

Řešení

Když se zobrazí tato chyba, vyřešte ji tak, že nakonfigurujete název DNS vašeho virtuálního počítače a pak v příkazu nastavení nastavíte název DNS jako název hostitele.

Na portálu Azure přejděte na stránku s přehledem 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.
Pokud název DNS ještě nemáte, zadejte hodnotu pro popisek názvu DNS 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 IoT Edge zařízení 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 změny použijte na IoT Edge.
```
sudo iotedge config apply
```

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

Příznaky

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

Příčina

Kontejnery spoléhají na předávání paketů PROTOKOLU IP pro připojení k internetu, aby mohly komunikovat s cloudovými službami. Docker ve výchozím nastavení povolí předávání paketů PROTOKOLU IP, ale pokud ho zakážete, 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řízení za bránou nemůže provádět požadavky HTTP nebo spustit 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. IoT Edge runtime oznamuje Could not perform HTTP request do protokolů.

Příčina

IoT Edge zařízení za bránou získávají image modulů z nadřazeného zařízení IoT Edge zadaného v poli konfiguračního souboru parent_hostname. 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é IoT Edge zařízení může přijímat příchozí požadavky z podřízeného IoT Edge zařízení. 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 se nemůže připojit při migraci z jednoho centra IoT do jiného

Příznaky

Když migrujete hierarchii IoT Edge zařízení z jednoho IoT hub do jiného, nadřazené IoT Edge zařízení nejvyšší úrovně se připojí k IoT Hub, ale podřízená zařízení IoT Edge nemůžou. Protokoly hlásí Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Příčina

Migrace neaktualizuje správně přihlašovací údaje pro podřízená zařízení. V důsledku tohoto problému mají moduly edgeAgent a edgeHub typ autentizace none (což je výchozí nastavení, pokud ho explicitně nenastavíte). 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 do nového centra IoT (za předpokladu, že službu DPS nepoužíváte), postupujte takto:

Podle tohoto průvodce exportujte a importujte identity zařízení ze starého centra IoT do nového.
Překonfigurujte všechna nasazení a konfigurace 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 odkazovalo na nový název hostitele IoT Hub (iothub_hostname pod [provisioning] v 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, pokud je geograficky vzdálená od IoT Hub

Příznaky

Azure IoT Edge zařízení, která jsou geograficky vzdálená od Azure IoT Hub mají nižší propustnost zpráv.

Příčina

Vysoká latence mezi zařízením a IoT Hub způsobuje nižší propustnost zpráv. IoT Edge používá výchozí velikost dávky zprávy 10. Tato velikost dávky omezuje počet zpráv odesílaných v jedné dávce, což zvyšuje počet cest mezi zařízením a IoT Hub.

Řešení

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

Nastavení proměnných prostředí Azure Edge Hubu na portálu Azure:

Přejděte na svůj IoT Hub a v nabídce Správa zařízení vyberte Zařízení.
Vyberte IoT Edge zařízení, 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 a použijte.

Další kroky

Myslíte si, že jste v IoT Edge platformě našli chybu? Submit an issue, aby produktový tým mohl dále vylepšovat platformu.

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

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-07-16