Lösungen für allgemeine Probleme in Azure IoT Edge

Artikel
07/10/2024

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, deren Dienstende (End-of-Life, EOL) ansteht. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS End-of-Life-Leitfaden.

Gilt für: IoT Edge 1.5 IoT Edge 1.4

Wichtig

IoT Edge 1.5 LTS und IoT Edge 1.4 LTS sind unterstützte Releases. Das Ende der Lebensdauer von IoT Edge 1.4 LTS wird am 12. November 2024 erreicht. Wenn Sie ein früheres Release verwenden, finden Sie weitere Informationen unter Aktualisieren von IoT Edge.

Mithilfe dieses Artikels können sie allgemeine Probleme identifizieren und beheben, die bei der Verwendung von IoT Edge-Lösungen auftreten. Wenn Sie erfahren möchten, wie Sie von Ihrem IoT Edge-Gerät stammende Protokolle und Fehler finden, lesen Sie Behandeln von Problemen bei Ihrem IoT Edge-Gerät.

Bereitstellung

IoT Edge-Modul wird erfolgreich bereitgestellt und verschwindet dann vom Gerät

Problembeschreibung

Nach Festlegung von Modulen für ein IoT Edge-Gerät werden die Module erfolgreich bereitgestellt, doch nach einigen Minuten verschwinden sie vom Gerät und aus den Gerätedetails im Azure-Portal. Auch andere als die definierten Module können auf dem Gerät auftauchen.

Ursache

Wenn eine automatische Bereitstellung ein Gerät zum Ziel hat, hat sie Vorrang vor der manuellen Festlegung der Module für ein einzelnes Gerät. Die Funktionalität Module festlegen im Azure-Portal oder Bereitstellung für ein einzelnes Gerät erstellen in Visual Studio Code wird für einen Augenblick wirksam. Sie sehen, dass die von Ihnen definierten Module auf dem Gerät gestartet werden. Dann greift die Priorität der automatischen Bereitstellung und überschreibt die gewünschten Eigenschaften des Geräts.

Lösung

Verwenden Sie nur eine Art von Bereitstellungsmechanismus pro Gerät, entweder eine automatische Bereitstellung oder individuelle Gerätebereitstellungen. Bei mehreren automatischen Bereitstellungen, die ein Gerät zum Ziel haben, können Sie die Priorität oder Zielbeschreibungen ändern, um sicherzustellen, dass die richtige Beschreibung für ein bestimmtes Gerät zutrifft. Sie können auch den Gerätezwilling aktualisieren, sodass er nicht mehr der Zielbeschreibung der automatischen Bereitstellung entspricht.

Weitere Informationen finden Sie unter Grundlegendes zu automatischen IoT Edge-Bereitstellungen für einzelne Geräte oder nach Bedarf.

IoT Edge-Laufzeit

Der IoT Edge-Agent wird nach einer Minute beendet.

Problembeschreibung

Das edgeAgent-Modul startet und wird ungefähr eine Minute lang erfolgreich ausgeführt, dann wird es beendet. Aus den Protokollen geht hervor, dass der IoT Edge-Agent versucht, zuerst über AMQP eine Verbindung mit IoT Hub und dann mithilfe von AMQP über WebSocket eine Verbindung herzustellen. Wenn hierbei ein Fehler auftritt, wird der IoT Edge-Agent beendet.

Beispielprotokolle von „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...

Ursache

Eine Netzwerkkonfiguration im Hostnetzwerk hindert den IoT Edge-Agent daran, das Netzwerk zu erreichen. Der Agent versucht zuerst, eine Verbindung über AMQP (Port 5671) herzustellen. Wenn ein Verbindungsfehler auftritt, verwendet er WebSockets (Port 443).

Die IoT Edge-Runtime richtet ein Netzwerk für die Kommunikation der einzelnen Module ein. Unter Linux ist dieses Netzwerk ein Bridgenetzwerk. Unter Windows wird NAT verwendet. Dieses Problem tritt häufiger auf Windows-Geräten mit Windows-Containern auf, die das NAT-Netzwerk verwenden.

Lösung

Stellen Sie sicher, dass für die diesem Bridge-/NAT-Netzwerk zugewiesenen IP-Adressen eine Route zum Internet besteht. In einigen Fällen hat eine VPN-Konfiguration auf dem Host Vorrang vor dem IoT Edge-Netzwerk.

Das Edge-Agent-Modul meldet „empty config file“, und auf dem Gerät werden keine Module gestartet

Problembeschreibung

Auf dem Gerät treten Probleme beim Starten von in der Bereitstellung definierten Modulen auf. Nur der edgeAgent wird ausgeführt, meldet aber leere Konfigurationsdatei....
Wenn Sie sudo iotedge check auf einem Gerät ausführen, meldet es, dass das Containermodul nicht mit der DNS-Servereinstellung konfiguriert ist, was sich auf die Konnektivität mit IoT Hub auswirken kann. Weitere Informationen finden Sie unter https://aka.ms/iotedge-prod-checklist-dns bei bewährten Methoden.

Ursache

Standardmäßig werden Module in IoT Edge in ihrem eigenen isolierten Containernetzwerk gestartet. Möglicherweise liegt auf dem Gerät ein Problem mit der DNS-Namensauflösung in diesem privaten Netzwerk vor.
Bei Verwendung einer Snap-Installation von IoT Edge befindet sich die Docker-Konfigurationsdatei an einem anderen Speicherort. Weitere Informationen finden Sie unter der Lösungsoption 3.

Lösung

Option 1: Festlegen des DNS-Servers in Containermoduleinstellungen

Geben Sie den DNS-Server für Ihre Umgebung in den Einstellungen der Containerengine an, die für alle durch die Engine gestarteten Containermodule gelten sollen. Erstellen Sie die Datei daemon.json, und geben Sie dann den DNS-Server an, der verwendet werden soll. Beispiel:

{
    "dns": ["1.1.1.1"]
}

Dieser DNS-Server wird auf einen öffentlich zugänglichen DNS-Dienst festgelegt. In einigen Netzwerken, z. B. Unternehmensnetzwerken, sind jedoch eigene DNS-Server installiert, und sie lassen den Zugriff auf öffentliche DNS-Server nicht zu. Wenn Ihr Edgegerät auf einen öffentlichen DNS-Server nicht zugreifen kann, ersetzen Sie ihn deshalb durch eine erreichbare DNS-Serveradresse.

Speichern Sie daemon.json im Verzeichnis /etc/docker auf Ihrem Gerät.

Wenn die Datei daemon.json im Pfad bereits vorhanden ist, fügen Sie ihr den Schlüssel dns hinzu, und speichern Sie die Datei.

Starten Sie die Containerengine neu, damit die Änderungen wirksam werden.

sudo systemctl restart docker

Option 2: Festlegen des DNS-Servers in der IoT Edge-Bereitstellung je Modul

Sie können den DNS-Server für createOptions jedes Moduls in der IoT Edge-Bereitstellung festlegen. Beispiel:

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

Warnung

Wenn Sie diese Methode verwenden und die falsche DNS-Adresse angeben, verliert edgeAgent die Verbindung mit IoT Hub und kann keine neuen Bereitstellungen für die Problembehebung empfangen. Zum Lösen dieses Problems können Sie die IoT Edge-Runtime neu installieren. Bevor Sie eine neue Instanz von IoT Edge installieren, müssen Sie alle edgeAgent-Container aus der vorherigen Installation entfernen.

Achten Sie darauf, diese Konfiguration auch für die Module edgeAgent und edgeHub festzulegen.

Option 3: Übergeben des Speicherorts der Docker-Konfigurationsdatei, um den Befehl zu überprüfen

Wenn IoT Edge als Snap installiert ist, verwenden Sie den Parameter --container-engine-config-file, um den Speicherort der Docker-Konfigurationsdatei anzugeben. Wenn sich beispielsweise die Docker-Konfigurationsdatei unter /var/snap/docker/current/config/daemon.json befindet, führen Sie den folgenden Befehl aus: iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json'.

Derzeit wird die Warnmeldung auch nach dem Festlegen des Konfigurationsdateispeicherorts weiterhin in der Ausgabe von iotedge check angezeigt. Die Überprüfung meldet den Fehler, da das IoT Edge-Snap keinen Lesezugriff auf das Docker-Snap hat. Wenn Sie iotedge check in Ihrem Releaseprozess verwenden, können Sie die Warnmeldung mithilfe des Parameters --ignore container-engine-dns container-engine-logrotate unterdrücken.

Edge-Agent-Modul mit LTE-Verbindungsberichten „leere Edge-Agent-Konfiguration“ und verursacht „vorübergehenden Netzwerkfehler“

Problembeschreibung

Ein mit LTE-Verbindung konfiguriertes Gerät hat Probleme beim Starten von Modulen, die in der Bereitstellung definiert sind. Der edgeAgent kann keine Verbindung mit dem IoT Hub herstellen und meldet eine leere Konfiguration des Edge-Agents und einen vorübergehenden Netzwerkfehler.

Ursache

Einige Netzwerke haben Paketaufwand, wodurch die standardmäßige Docker-Netzwerk-MTU (1500) zu hoch ist und die Paketfragmentierung den Zugriff auf externe Ressourcen verhindert.

Lösung

Überprüfen Sie die MTU-Einstellung für Ihr Docker-Netzwerk.

docker network inspect <network name>
Überprüfen Sie die MTU-Einstellung für den physischen Netzwerkadapter auf Ihrem Gerät.

ip addr show eth0

Hinweis

Die MTU für das Docker-Netzwerk darf nicht höher sein als die MTU für Ihr Gerät. Wenden Sie sich für weitere Informationen an Ihren ISP.

Wenn für Ihr Docker-Netzwerk und das Gerät eine andere MTU-Größe angezeigt wird, probieren Sie die folgende Problemumgehung aus:

Erstellen Sie ein neues Netzwerk. Ein auf ein Objekt angewendeter

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

Im Beispiel ist die MTU-Einstellung für das Gerät 1430. Daher ist die MTU für das Docker-Netzwerk auf 1430 festgelegt.
Beenden sie das Azure-Netzwerk, und entfernen Sie es.

docker network rm azure-iot-edge
Erstellen Sie das Azure-Netzwerk neu.

docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge
Entfernen Sie alle Container und starten Sie den aziot-edged-Dienst neu.

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

Der IoT Edge-Agent kann nicht auf das Image eines Moduls (403) zugreifen.

Problembeschreibung

Ein Container kann nicht ausgeführt werden, und die edgeAgent-Protokolle weisen melden Fehler 403.

Ursache

Das IoT Edge-Agent-Modul hat keine Zugriffsberechtigungen für das Image eines Moduls.

Lösung

Stellen Sie sicher, dass Ihre Anmeldeinformationen für die Containerregistrierung im Bereitstellungsmanifest des Geräts richtig sind.

IoT Edge-Agent führt übermäßige Identitätsaufrufe aus

Problembeschreibung

Der IoT Edge-Agent führt übermäßige Identitätsaufrufe an Azure IoT Hub durch.

Ursache

Die Fehlkonfiguration des Gerätebereitstellungsmanifests führt zu einer erfolglosen Bereitstellung auf dem Gerät. Die Wiederholungslogik des IoT Edge-Agents wiederholt weiterhin die Bereitstellung. Jeder Wiederholungsversuche führt Identitätsaufrufe aus, bis die Bereitstellung erfolgreich ist. Wenn das Bereitstellungsmanifest z. B. einen Modul-URI angibt, der nicht in der Containerregistrierung vorhanden ist oder falsch eingegeben wird, überprüft der IoT Edge-Agent die Bereitstellung, bis das Bereitstellungsmanifest korrigiert wird.

Lösung

Überprüfen Sie das Bereitstellungsmanifest im Azure-Portal. Korrigieren Sie alle Fehler, und stellen Sie das Manifest erneut auf dem Gerät bereit.

IoT Edge-Hub kann nicht gestartet werden.

Problembeschreibung

Das Modul edgeHub kann nicht gestartet werden. Möglicherweise wird eine Fehlermeldung wie eine der folgenden in den Protokollen angezeigt:

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)

Oder

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)

Ursache

Ein anderer Prozess auf dem Hostcomputer hat einen Port gebunden, den das Modul edgeHub zu binden versucht. IoT Edge-Hub ordnet die Ports 443, 5671 und 8883 für den Einsatz in Gatewayszenarien zu. Das Modul kann nicht gestartet werden, wenn ein anderer Prozess bereits einen dieser Ports gebunden hat.

Lösung

Sie können dieses Problem auf zwei Arten beheben:

Wenn das IoT Edge-Gerät als Gatewaygerät fungiert, müssen Sie den Prozess, der Port 443, 5671 oder 8883 verwendet, finden und beenden. Ein Fehler für Port 443 bedeutet in der Regel, dass der andere Prozess ein Webserver ist.

Wenn Sie das IoT Edge-Gerät nicht als Gatewaygerät verwenden müssen, können Sie die Portbindungen aus den Optionen zur Modulerstellung von edgeHub entfernen. Sie können die Erstellungsoptionen im Azure-Portal oder direkt in der Datei „deployment.json“ ändern.

Führen Sie im Azure-Portal die folgenden Schritte aus:

Navigieren Sie zu Ihrem IoT-Hub, und wählen Sie Geräte im Menü Geräteverwaltung aus.
Wählen Sie das IoT Edge-Gerät aus, das Sie aktualisieren oder entfernen möchten.
Wählen Sie Module festlegen aus.
Wählen Sie Runtimeeinstellungen aus.
Löschen Sie in den Einstellungen des Moduls Edge Hub alles aus dem Textfeld Containererstellungsoptionen.
Wählen Sie Übernehmen aus, um Ihre Änderungen zu speichern und die Bereitstellung zu erstellen.

Gehen Sie in der Datei „deployment.json“ so vor:

Öffnen Sie zunächst die Datei „deployment.json“, die Sie auf Ihr IoT Edge-Gerät angewendet haben.

Suchen Sie im Abschnitt mit den gewünschten Einstellungen für edgeAgent die Einstellungen für edgeHub:

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

Entfernen Sie die Zeile createOptions und das abschließende Komma am Ende der Zeile image davor:

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

Wählen Sie Erstellen aus, um es erneut auf Ihr IoT Edge-Gerät anzuwenden.

Beim Versuch des IoT Edge-Moduls, eine Nachricht an edgeHub zu senden, tritt ein 404-Fehler auf

Problembeschreibung

Beim Versuch eines benutzerdefinierten IoT Edge-Moduls, eine Nachricht an den IoT Edge-Hub zu senden, tritt ein 404-Fehler (Module not found) auf. Die IoT Edge-Runtime gibt folgende Meldung an die Protokolle aus:

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 )

Ursache

Die IoT Edge-Runtime erzwingt aus Sicherheitsgründen die Prozessidentifizierung für alle Module, die eine Verbindung mit edgeHub herstellen. Dadurch wird sichergestellt, dass alle von einem Modul gesendeten Nachrichten von der Hauptprozess-ID des Moduls stammen. Wenn eine Nachricht von einem Modul mit einer anderen Prozess-ID als der ursprünglich festgelegten gesendet wird, wird die Nachricht mit einem Fehlercode 404 abgelehnt.

Lösung

Ab Version 1.0.7 dürfen alle Modulprozesse eine Verbindung herstellen. Weitere Informationen finden Sie im Änderungsprotokoll zum Release 1.0.7.

Wenn ein Upgrade auf Version 1.0.7 nicht möglich ist, führen Sie die folgenden Schritte aus. Stellen Sie sicher, dass das benutzerdefinierte IoT Edge-Modul beim Senden von Nachrichten an den Edge-Hub immer die gleiche Prozess-ID verwendet. Stellen Sie beispielsweise sicher, dass Sie in Ihrer Docker-Datei den Befehl ENTRYPOINT und nicht den Befehl CMD verwenden. Der Befehl CMD führt zu einer Prozess-ID für das Modul und einer weiteren Prozess-ID für den bash-Befehl, der das Hauptprogramm ausführt, aber ENTRYPOINT führt zu einer einzelnen Prozess-ID.

Stabilitätsprobleme auf kleineren Geräten

Problembeschreibung

Auf Geräten mit eingeschränkten Ressourcen wie Raspberry Pi können Stabilitätsprobleme auftreten, insbesondere wenn sie als Gateway verwendet werden. Zu den Symptomen gehören Arbeitsspeicherausnahmen im IoT Edge-Hub-Modul. Nachgeschaltete Geräte können sich nicht verbinden, oder das Gerät sendet nach einigen Stunden keine Telemetrienachrichten mehr.

Ursache

Der zur IoT Edge-Runtime gehörige IoT Edge-Hub ist standardmäßig für die Leistungserbringung optimiert und versucht, große Blöcke des Speichers zuzuordnen. Diese Optimierung ist für eingeschränkte Edge-Geräte nicht ideal und kann zu Stabilitätsproblemen führen.

Lösung

Legen Sie für den IoT Edge-Hub eine Umgebungsvariable OptimizeForPerformance auf false fest. Es gibt zwei Möglichkeiten zur Festlegung von Umgebungsvariablen:

Führen Sie im Azure-Portal die folgenden Schritte aus:

Wählen Sie in Ihrem IoT Hub Ihr IoT Edge-Gerät und dann auf der Seite mit den Gerätedetails Module festlegen>Runtimeeinstellungen aus.
Erstellen Sie eine Umgebungsvariable für das IoT Edge-Hubmodul namens OptimizeForPerformance mit dem Typ True/False, der auf False festgelegt ist.

Wählen Sie Übernehmen aus, um Änderungen zu speichern, und wählen Sie dann Überprüfen + erstellen aus.

Die Umgebungsvariable befindet sich jetzt in der edgeHub-Eigenschaft des Bereitstellungsmanifests:

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

Wählen Sie Erstellen aus, um Ihre Änderungen zu speichern und das Modul bereitzustellen.

Sicherheitsdaemon konnte nicht gestartet werden

Problembeschreibung

Der Sicherheitsdaemon kann nicht gestartet werden, und es werden keine Modulcontainer erstellt. edgeAgent, edgeHub und andere benutzerdefinierte Module werden vom IoT Edge-Dienst nicht gestartet. In den Protokollen zu aziot-edged wird dieser Fehler angezeigt:

Der Daemon konnte nicht gestartet werden: Der Verwaltungsdienst konnte nicht gestartet werden.

Ursache: Fehler im Pfad „/var/run/iotedge/mgmt.sock“

Ursache: Berechtigung verweigert (Betriebssystemfehler 13)

Ursache

Für alle Linux-Distributionen mit Ausnahme von CentOS 7 wird bei der Standardkonfiguration von IoT Edge die systemd-Socketaktivierung verwendet. Ein Berechtigungsfehler tritt auf, wenn Sie die Konfigurationsdatei so ändern, dass nicht die Socketaktivierung verwendet wird, aber als URLs /var/run/iotedge/*.sock beibehalten, da iotedge-Benutzer*innen nicht in /var/run/iotedge schreiben können. Das bedeutet, dass die Sockets selbst nicht entsperrt und eingebunden werden können.

Lösung

Sie müssen die Socketaktivierung bei Distributionen, unter denen die Socketaktivierung unterstützt wird, nicht deaktivieren. Wenn Sie die Socketaktivierung jedoch überhaupt nicht verwenden möchten, platzieren Sie die Sockets in /var/lib/iotedge/.

Führen Sie systemctl disable iotedge.socket iotedge.mgmt.socket aus, um die Socketeinheiten zu deaktivieren, damit systemd sie nicht unnötig startet.
Ändern der IoT Edge-Konfiguration zur Verwendung von /var/lib/iotedge/*.sock in den Abschnitten connect und listen
Wenn Sie bereits über Module verfügen, haben sie die alten /var/run/iotedge/*.sock-Bereitstellungen. Sie sollten sie daher mit docker rm -f entfernen.

Die Bereinigung der Nachrichtenwarteschlange ist langsam

Problembeschreibung

Die Nachrichtenwarteschlange wird nach dem Verarbeiten von Nachrichten nicht bereinigt. Die Nachrichtenwarteschlange wächst im Laufe der Zeit und führt schließlich dazu, dass die IoT Edge-Runtime nicht mehr genügend Arbeitsspeicher hat.

Ursache

Das Nachrichtenbereinigungsintervall wird durch den TTL-Wert für Clientnachrichten (Time To Live) und die EdgeHub-Umgebungsvariable MessageCleanupIntervalSecs gesteuert. Der TTL-Standardwert für Nachrichten beträgt zwei Stunden, und der Standardwert für MessageCleanupIntervalSecs beträgt 30 Minuten. Wenn Ihre Anwendung einen TTL-Wert verwendet, der kürzer als der Standardwert ist, und Sie den Wert für MessageCleanupIntervalSecs nicht anpassen, werden abgelaufene Nachrichten erst beim nächsten Bereinigungsintervall bereinigt.

Lösung

Wenn Sie für Ihre Anwendung den TTL-Wert ändern, der kürzer als der Standardwert ist, passen Sie auch den Wert für MessageCleanupIntervalSecs an. Der Wert für MessageCleanupIntervalSecs sollte deutlich kleiner sein als der kleinste TTL-Wert, den der Client verwendet. Wenn die Clientanwendung beispielsweise einen TTL-Wert von fünf Minuten im Nachrichtenkopf definiert, legen Sie den Wert für MessageCleanupIntervalSecs auf eine Minute fest. Diese Einstellungen stellen sicher, dass Nachrichten innerhalb von sechs (5 + 1) Minuten bereinigt werden.

Um den Wert für MessageCleanupIntervalSecs zu konfigurieren, legen Sie die Umgebungsvariable im Bereitstellungsmanifest für das IoT Edge-Hubmodul fest. Weitere Informationen zum Einstellen der Runtime-Umgebungsvariablen finden Sie unter Umgebungsvariablen für Edge Agent und Edge Hub.

Netzwerk

Fehler für den Daemon für die IoT Edge-Sicherheit aufgrund eines ungültigen Hostnamens

Problembeschreibung

Der Versuch, die Protokolle des IoT Edge-Sicherheits-Managers zu prüfen, schlägt mit folgender Meldung fehl:

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

Ursache

Die IoT-Edge-Runtime unterstützt nur Hostnamen, die kürzer als 64 Zeichen sind. Physische Computer weisen in der Regel keine langen Hostnamen auf, das Problem ist eher bei virtuellen Computern üblich. Die automatisch generierten Hostnamen für in Azure gehostete virtuelle Windows-Computer sind tendenziell lang sein.

Lösung

Wenn dieser Fehler angezeigt wird, können Sie ihn durch Konfigurieren des DNS-Namens des virtuellen Computers und anschließendes Festlegen des DNS-Namens als Hostname im Setupbefehl beheben.

Navigieren Sie im Azure-Portal zur Übersichtsseite Ihrer VM.
Öffnen Sie den Konfigurationsbereich, indem Sie unter DNS-Namen den Link Nicht konfiguriert auswählen (wenn Ihre VM neu ist), oder wählen Sie Ihren vorhandenen DNS-Namen unter Essentials>DNS-Name aus. Wenn für Ihren virtuellen Computer bereits ein DNS-Name konfiguriert wurde, müssen Sie keinen neuen konfigurieren.
Geben Sie einen Wert für die DNS-Namensbezeichnung an, wenn Sie noch keinen haben, und wählen Sie Speichern aus.
Kopieren Sie den neuen DNS-Namen, der im Format vorliegen soll:
<DNSnamelabel>.<vmlocation>.cloudapp.azure.com.
Öffnen Sie die Konfigurationsdatei auf dem IoT Edge-Gerät.
```
sudo nano /etc/aziot/config.toml
```
Ersetzen Sie den Wert von hostname durch Ihren DNS-Namen.
Speichern und schließen Sie die Datei. Wenden Sie die Änderungen dann auf IoT Edge an.
```
sudo iotedge config apply
```

IoT Edge-Modul meldet Verbindungsfehler

Problembeschreibung

IoT Edge-Module, die eine direkte Verbindung mit Clouddiensten herstellen, einschließlich der Runtimemodule, funktionieren nicht mehr wie erwartet und geben Verbindungs- oder Netzwerkfehler zurück.

Ursache

Container benötigen die IP-Paketweiterleitung, um eine Verbindung mit dem Internet herzustellen, damit sie mit Clouddiensten kommunizieren können. Die IP-Paketweiterleitung ist in Docker standardmäßig aktiviert. Wenn sie jedoch deaktiviert wird, funktionieren Module, die eine Verbindung mit Clouddiensten herstellen, nicht mehr wie erwartet. Weitere Informationen finden Sie in der Docker-Dokumentation unter Understand container communication (Informationen zur Containerkommunikation).

Lösung

Gehen Sie nach folgenden Schritte vor, um die IP-Paketweiterleitung zu aktivieren.

Öffnen Sie die Datei sysctl.conf.
```
sudo nano /etc/sysctl.conf
```
Fügen Sie der Datei die folgende Zeile hinzu:
```
net.ipv4.ip_forward=1
```
Speichern und schließen Sie die Datei.
Starten Sie den Netzwerkdienst und den Docker-Dienst neu, um die Änderungen anzuwenden.

IoT Edge hinter einem Gateway kann keine HTTP-Anforderungen ausführen und das edgeAgent-Modul nicht starten.

Problembeschreibung

Die IoT Edge-Runtime ist bei einer gültigen Konfigurationsdatei aktiv, kann aber das edgeAgent-Modul nicht starten. Der Befehl iotedge list gibt eine leere Liste zurück. Die IoT Edge-Runtime meldet Could not perform HTTP request in den Protokollen.

Ursache

IoT Edge-Geräte hinter einem Gateway erhalten ihre Modulimages von dem übergeordneten IoT Edge-Gerät, das im Feld parent_hostname der Konfigurationsdatei angegeben ist. Der Fehler Could not perform HTTP request bedeutet, dass das nachgeschaltete Gerät sein übergeordnetes Gerät über HTTP nicht erreichen kann.

Lösung

Stellen Sie sicher, dass das übergeordnete IoT Edge-Gerät eingehende Anforderungen vom nachgeschalteten IoT Edge-Gerät empfangen kann. Öffnen Sie Netzwerkdatenverkehr an den Ports 443 und 6617 für Anforderungen vom nachgeschalteten Gerät.

IoT Edge hinter einem Gateway kann keine HTTP-Anforderungen ausführen und das edgeAgent-Modul nicht starten.

Problembeschreibung

Der IoT Edge-Daemon ist bei einer gültigen Konfigurationsdatei aktiv, kann aber das edgeAgent-Modul nicht starten. Der Befehl iotedge list gibt eine leere Liste zurück. Der IoT Edge-Daemon protokolliert den Bericht Could not perform HTTP request.

Ursache

Lösung

Von IoT Edge hinter einem Gateway kann bei der Migration zwischen IoT-Hubs keine Verbindung hergestellt werden.

Problembeschreibung

Wenn Sie versuchen, eine Hierarchie von IoT Edge-Geräten zwischen IoT-Hubs zu migrieren, kann das übergeordnete IoT Edge-Gerät auf oberster Ebene eine Verbindung mit IoT Hub herstellen. Nachgeschaltete IoT Edge-Geräte können jedoch keine Verbindung herstellen. Die Protokolle enthalten Folgendes: Unable to authenticate client downstream-device/$edgeAgent with module credentials.

Ursache

Die Anmeldeinformationen für die nachgeschalteten Geräte wurden bei der Migration zum neuen IoT-Hub nicht ordnungsgemäß aktualisiert. Daher wurde für die Module edgeAgent und edgeHub der Authentifizierungstyp none festgelegt (Standardeinstellung, wenn nicht explizit festgelegt). Bei der Verbindungsherstellung werden von den Modulen der nachgeschalteten Geräte alte Anmeldeinformationen verwendet, wodurch die Authentifizierung nicht erfolgreich ist.

Lösung

Führen Sie bei der Migration zum neuen IoT-Hub die folgenden Schritte in der angegeben Reihenfolge aus (vorausgesetzt, DPS wird nicht verwendet):

Gehen Sie wie in dieser Anleitung beschrieben vor, um Geräteidentitäten aus dem alten IoT-Hub zu exportieren und dann in den neuen IoT-Hub zu importieren.
Passen Sie die Konfiguration aller IoT Edge-Bereitstellungen sowie die Konfigurationen im neuen IoT-Hub an.
Konfigurieren Sie alle Beziehungen zwischen über- und untergeordneten Geräten im neuen IoT-Hub neu.
Aktualisieren Sie jedes Gerät so, dass es auf den neuen IoT-Hub-Hostnamen verweist (iothub_hostname unter [provisioning] in config.toml).
Falls Sie Authentifizierungsschlüssel beim Geräteexport ausgeschlossen haben, konfigurieren Sie jedes Gerät mit den neuen Schlüsseln, die vom neuen IoT-Hub ausgegeben wurden (device_id_pk unter [provisioning.authentication] in config.toml).
Starten Sie zuerst das übergeordnete Edgegerät der obersten Ebene neu, und vergewissern Sie sich, dass es betriebsbereit ist.
Starten Sie die einzelnen Geräte der Hierarchieebene neu. Gehen Sie dabei von oben nach unten vor.

IoT Edge weist einen niedrigen Nachrichtendurchsatz auf, wenn es geografisch von IoT Hub entfernt ist

Problembeschreibung

Azure IoT Edge-Geräte, die geografisch von Azure IoT Hub entfernt sind, weisen einen niedrigeren Nachrichtendurchsatz als erwartet auf.

Ursache

Hohe Latenz zwischen dem Gerät und IoT Hub kann zu einem niedrigeren Nachrichtendurchsatz als erwartet führen. IoT Edge verwendet eine Standard-Nachrichtenbatchgröße von 10. Dadurch wird die Anzahl der Nachrichten begrenzt, die in einem einzelnen Batch gesendet werden, wodurch die Anzahl der Roundtrips zwischen dem Gerät und dem IoT Hub erhöht wird.

Lösung

Versuchen Sie, die Umgebungsvariable MaxUpstreamBatchSize des IoT Edge Hub zu erhöhen. Dadurch können mehr Nachrichten in einem einzelnen Batch gesendet werden, wodurch die Anzahl der Roundtrips zwischen dem Gerät und dem IoT Hub reduziert wird.

So legen Sie Azure Edge Hub-Umgebungsvariablen im Azure-Portal fest:

Navigieren Sie zu Ihrem IoT-Hub und wählen Sie Geräte im Menü Geräteverwaltung aus.
Wählen Sie das IoT Edge-Gerät aus, das Sie aktualisieren oder entfernen möchten.
Wählen Sie Module festlegen aus.
Wählen Sie Runtimeeinstellungen aus.
Fügen Sie auf der Registerkarte Edge Hub-Moduleinstellungen die MaxUpstreamBatchSize-Umgebungsvariable als Typ Nummer mit dem Wert 20 hinzu.
Wählen Sie Übernehmen.

Nächste Schritte

Sind Sie der Meinung, dass Sie in der IoT Edge-Plattform einen Fehler gefunden haben? Melden Sie ein Problem, damit wir die Plattform weiter verbessern können.

Wenn Sie weitere Fragen haben, erstellen Sie eine Supportanfrage, um Hilfe zu erhalten.

Teilen über

Lösungen für allgemeine Probleme in Azure IoT Edge

Bereitstellung

IoT Edge-Modul wird erfolgreich bereitgestellt und verschwindet dann vom Gerät

Problembeschreibung

Ursache

Lösung

IoT Edge-Laufzeit

Der IoT Edge-Agent wird nach einer Minute beendet.

Problembeschreibung

Ursache

Lösung

Das Edge-Agent-Modul meldet „empty config file“, und auf dem Gerät werden keine Module gestartet

Problembeschreibung

Ursache

Lösung

Edge-Agent-Modul mit LTE-Verbindungsberichten „leere Edge-Agent-Konfiguration“ und verursacht „vorübergehenden Netzwerkfehler“

Problembeschreibung

Ursache

Lösung

Der IoT Edge-Agent kann nicht auf das Image eines Moduls (403) zugreifen.

Problembeschreibung

Ursache

Lösung

IoT Edge-Agent führt übermäßige Identitätsaufrufe aus

Problembeschreibung

Ursache

Lösung

IoT Edge-Hub kann nicht gestartet werden.

Problembeschreibung

Ursache

Lösung

Beim Versuch des IoT Edge-Moduls, eine Nachricht an edgeHub zu senden, tritt ein 404-Fehler auf

Problembeschreibung

Ursache

Lösung

Stabilitätsprobleme auf kleineren Geräten

Problembeschreibung

Ursache

Lösung

Sicherheitsdaemon konnte nicht gestartet werden

Problembeschreibung

Ursache

Lösung

Die Bereinigung der Nachrichtenwarteschlange ist langsam

Problembeschreibung

Ursache

Lösung

Netzwerk

Fehler für den Daemon für die IoT Edge-Sicherheit aufgrund eines ungültigen Hostnamens

Problembeschreibung

Ursache

Lösung

IoT Edge-Modul meldet Verbindungsfehler

Problembeschreibung

Ursache

Lösung

IoT Edge hinter einem Gateway kann keine HTTP-Anforderungen ausführen und das edgeAgent-Modul nicht starten.

Problembeschreibung

Ursache

Lösung

IoT Edge hinter einem Gateway kann keine HTTP-Anforderungen ausführen und das edgeAgent-Modul nicht starten.

Problembeschreibung

Ursache

Lösung

Von IoT Edge hinter einem Gateway kann bei der Migration zwischen IoT-Hubs keine Verbindung hergestellt werden.

Problembeschreibung

Ursache

Lösung

IoT Edge weist einen niedrigen Nachrichtendurchsatz auf, wenn es geografisch von IoT Hub entfernt ist

Problembeschreibung

Ursache

Lösung

Nächste Schritte

Feedback

Zusätzliche Ressourcen