Azure IoT Edge に関する一般的な問題の解決策

[アーティクル]
07/21/2024

注意事項

この記事では、サービス終了 (EOL) 状態となっている Linux ディストリビューションである CentOS について説明します。適宜、使用と計画を検討してください。詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。

適用対象: IoT Edge 1.5 IoT Edge 1.4

重要

サポートされているリリースは、IoT Edge 1.5 LTS と IoT Edge 1.4 LTS です。 IoT Edge 1.4 LTS は、2024 年 11 月 12 日にサポートが終了します。以前のリリースの場合は、「IoT Edge を更新する」を参照してください。

この記事では、IoT Edge ソリューションを使用するときの一般的な問題を特定して解決します。 IoT Edge デバイスからログやエラーを見つける方法については、IoT Edge デバイスのトラブルシューティングに関するページを参照してください。

プロビジョニングとデプロイ

デプロイに成功した IoT Edge モジュールがデバイスから消える

現象

IoT Edge デバイスのモジュールを設定し、モジュールが正常にデプロイされたものの、そのモジュールが数分後にはデバイスから消え、また Azure portal のデバイス情報からも消えます。定義されていないモジュールがデバイスに表示されることもあります。

原因

デバイスが自動デプロイの対象になった場合、自動デプロイは、個々のデバイスに対するモジュールの手動設定よりも優先されます。 Azure portal の [モジュールの設定] 機能または Visual Studio Code の [Create deployment for single device] (単一デバイスのデプロイの作成) 機能は、少しの間だけ有効になります。定義したモジュールがデバイスで起動したことを確認できます。その後は、自動デプロイが優先されるようになり、デバイスの必要なプロパティは上書きされます。

解決策

使用するデプロイメカニズムは、デバイスごとに 1 種類 (自動デプロイまたはデバイスの個別デプロイのどちらか一方) のみとしてください。デバイスが複数の自動デプロイの対象となっている場合、適切なデプロイが特定のデバイスに適用されるよう、優先度またはターゲットの記述を変更することができます。自動デプロイのターゲットの記述と一致しないよう、デバイスツインを更新することもできます。

詳細については、「1 台のデバイスまたは多数のデバイスを対象とした IoT Edge 自動展開について」を参照してください。

IoT Edge ランタイム

1 分後に IoT Edge エージェントが停止する

現象

edgeAgent モジュールが起動し、約 1 分間正常に実行された後、停止します。ログには、IoT Edge エージェントが AMQP 経由で IoT Hub に接続を試みてから、WebSocket 経由の AMQP を使って接続を試みていることが示されています。それが失敗すると、IoT Edge エージェントは終了します。

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

原因

ホストネットワーク上のネットワーク構成では、IoT Edge エージェントはネットワークに到達できません。エージェントは、最初に AMQP (ポート 5671) で接続を試みます。接続が失敗した場合は、WebSocket (ポート 443) が試されます。

IoT Edge ランタイムは、各モジュールが通信するネットワークをセットアップします。 Linux では、このネットワークはブリッジネットワークです。 Windows では、NAT を使います。この問題は、NAT ネットワークを使う Windows コンテナーを使っている Windows デバイスで、より多く見られます。

解決策

このブリッジと NAT ネットワークに割り当てられている IP アドレスに、インターネットへのルートが存在することを確認します。ホストでの VPN 構成が IoT Edge ネットワークをオーバーライドしている場合があります。

Edge エージェントモジュールで "空の構成ファイル" がレポートされ、デバイスでモジュールが開始しない

現象

デバイスで、デプロイにおいて定義されているモジュールの開始に問題があります。 edgeAgent のみが実行されていますが、 空の構成ファイル...が報告されます。
デバイスで sudo iotedge check を実行すると、コンテナーエンジンは、DNS サーバー設定で構成されていないことが報告されます。これは、IoT Hub への接続に影響を与える可能性があります。ベストプラクティスについては、 https://aka.ms/iotedge-prod-checklist-dns を参照してください。

原因

既定では、IoT Edge は独自の分離されたコンテナーネットワークでモジュールを開始します。デバイスに、このプライベートネットワーク内での DNS 名の解決に関する問題がある可能性があります。
IoT Edge の snap インストールを使用している場合、Docker 構成ファイルは別の場所です。ソリューションのオプション 3 を参照してください。

解決策

オプション 1: コンテナーエンジン設定で DNS サーバーを設定

コンテナーエンジンの設定で環境に対して DNS サーバーを指定すると、そのエンジンによって開始されるすべてのコンテナーモジュールに適用されます。 daemon.json という名前のファイルを作成し、使用する DNS サーバーを指定します。次に例を示します。

{
    "dns": ["1.1.1.1"]
}

この DNS サーバーは、パブリックにアクセス可能な DNS サービスに設定されます。ただし、企業ネットワークなどの一部のネットワークには独自の DNS サーバーがインストールされており、パブリック DNS サーバーへのアクセスは許可されません。そのため、エッジデバイスがパブリック DNS サーバーにアクセスできない場合は、アクセス可能な DNS サーバーアドレスに置き換えます。

デバイスの /etc/docker ディレクトリに daemon.json を配置します。

その場所に daemon.json ファイルが既にある場合は、それに対する dns キーを追加してファイルを保存します。

コンテナーエンジンを再起動して更新を有効にします。

sudo systemctl restart docker

オプション 2: モジュールごとの IoT Edge デプロイで DNS サーバーを設定する

IoT Edge のデプロイで各モジュールの createOptions に DNS サーバーを設定できます。次に例を示します。

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

警告

この方法を使用して間違った DNS アドレスを指定すると、edgeAgent は IoT Hub との接続を失い、問題を修正するための新しいデプロイを受信することができなくなります。この問題を解決するには、IoT Edge ランタイムを再インストールします。 IoT Edge の新しいインスタンスをインストールする前に、以前のインストールから edgeAgent コンテナーを必ず削除してください。

この構成は、edgeAgent および edgeHub モジュールにも忘れずに設定してください。

オプション 3: docker 構成ファイルの場所を渡してコマンドを確認する

IoT Edge が Snap としてインストールされている場合は、--container-engine-config-file パラメーターを使用して、Docker 構成ファイルの場所を指定します。たとえば、Docker 構成ファイルが /var/snap/docker/current/config/daemon.json にある場合は、iotedge check --container-engine-config-file '/var/snap/docker/current/config/daemon.json' コマンドを実行します。

現在、構成ファイルの場所を設定した後でも、iotedge check の出力に警告メッセージが引き続き表示されます。 IoT Edge snap に Docker snap への読み取りアクセス権がないため、検査によってエラーが報告されます。リリースプロセスで iotedge check を使用する場合は、--ignore container-engine-dns container-engine-logrotate パラメーターを使用して警告メッセージを抑制できます。

LTE 接続を備えた Edge エージェントモジュールは、「空のエッジエージェント構成」を報告し、「一時的なネットワークエラー」を引き起こします

現象

LTE 接続で構成されたデバイスで、デプロイで定義されているモジュールの開始に関するイシューが発生しています。 edgeAgent は IoT Hub に接続できず、 空のエッジエージェント構成 と一時的なネットワークエラーが発生を報告します。

原因

一部のネットワークにはパケットオーバーヘッドがあるため、デフォルトの Docker ネットワーク MTU (1500) が高くなりすぎて、外部リソースへのアクセスを妨げるパケットの断片化が発生します。

解決策

Docker ネットワークの MTU 設定を確認します。

docker network inspect <network name>
デバイス上の物理ネットワークアダプターの MTU 設定を確認します。

ip addr show eth0

Note

Docker ネットワークの MTU は、デバイスの MTU より大きくすることはできません。詳細については、ISP にお問い合わせください。

Docker ネットワークとデバイスに別の MTU サイズが表示される場合は、次の回避策を試してください：

新しいネットワークを作成します。たとえば、にします。

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

この例では、デバイスの MTU 設定は 1430 です。そのため、Docker ネットワークの MTU は 1430 に設定されます。
Azure ネットワークを停止して削除します。

docker network rm azure-iot-edge
Azure ネットワークを再作成します。

docker network create --opt com.docker.network.driver.mtu=1430 azure-iot-edge
すべてのコンテナーを削除し、 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 エージェントがモジュールのイメージにアクセスできない (403)

現象

コンテナーの実行が失敗し、edgeAgent ログで 403 エラーが報告されます。

原因

IoT Edge エージェントモジュールに、モジュールのイメージにアクセスするためのアクセス許可がありません。

解決策

配置マニフェストで、コンテナーレジストリの資格情報が正しいことを確認します。

IoT Edge エージェントによる過剰な ID 呼び出し

現象

IoT Edge エージェントから Azure IoT Hub に過剰な ID 呼び出しが行われます。

原因

デバイス配置マニフェストの構成が正しく行われません。これにより、デバイスでのデプロイが失敗します。 IoT Edge エージェントの再試行ロジックは引き続きデプロイを再試行します。デプロイが成功するまで、再試行のたびに ID 呼び出しが行われます。たとえば、配置マニフェストで、コンテナーレジストリに存在しないモジュール URI や誤入力されたモジュール URI が指定されている場合、IoT Edge エージェントは、配置マニフェストが修正されるまでデプロイを再試行します。

解決策

Azure portal で配置マニフェストを確認します。エラーを修正し、マニフェストをデバイスに再デプロイします。

IoT Edge ハブが起動に失敗する

現象

edgeHub モジュールが起動に失敗します。次のいずれかのエラーに似たメッセージがログに表示される場合があります。

One or more errors occurred.
(Docker API responded with status code=InternalServerError, response=
{\"message\":\"driver failed programming external connectivity on endpoint edgeHub (6a82e5e994bab5187939049684fb64efe07606d2bb8a4cc5655b2a9bad5f8c80):
Error starting userland proxy: Bind for 0.0.0.0:443 failed: port is already allocated\"}\n)

または

info: edgelet_docker::runtime -- Starting module edgeHub...
warn: edgelet_utils::logging -- Could not start module edgeHub
warn: edgelet_utils::logging --     caused by: failed to create endpoint edgeHub on network nat: hnsCall failed in Win32:
        The process cannot access the file because it is being used by another process. (0x20)

原因

edgeHub モジュールがバインドしようとしているポートには、ホストマシン上の他のプロセスが既にバインドしています。ポート 443、5671、8883 は、ゲートウェイのシナリオで使用するためためのポートとして、IoT Edge ハブによってマップされます。そのいずれかのポートが別のプロセスによって既にバインドされていると、モジュールは起動に失敗します。

解決策

この問題は、次の 2 つの方法で解決できます。

IoT Edge デバイスがゲートウェイデバイスとして機能している場合、443、5671、8883 のいずれかのポートを使用しているプロセスを見つけて停止する必要があります。ポート 443 のエラーは通常、他のプロセスが Web サーバーであることを意味します。

IoT Edge デバイスをゲートウェイとして使用する必要がなければ、ポートのバインドを edgeHub のモジュール作成オプションから削除することができます。作成オプションは Azure portal で変更できるほか、deployment.json ファイルで直接変更することもできます。

Azure portal で次の操作を行います。

IoT ハブに移動し、[デバイス管理] メニューで [デバイス] を選択します。
更新する IoT Edge デバイスを選択します。
[Set Modules] \(モジュールの設定) を選択します。
[ランタイムの設定] を選択します。
Edge Hub モジュールの設定で、[ コンテナーの作成オプション] テキストボックスからすべてを削除します。
[ 適用 ] を選択して変更を保存し、デプロイを作成します。

deployment.json ファイルで次の操作を行います。

IoT Edge デバイスに適用した deployment.json ファイルを開きます。

edgeAgent の desired プロパティセクションで、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"
   }

createOptions 行とその前の image 行の末尾にあるコンマを削除します。

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

[作成 ] を選択して、IoT Edge デバイスに再度適用します。

IoT Edge モジュールが 404 エラーで edgeHub にメッセージを送信できない

現象

カスタム IoT Edge モジュールは、404 Module not found エラーで IoT Edge ハブにメッセージを送信できません。 IoT Edge ランタイムによって、次のメッセージがログに出力されます。

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 )

原因

IoT Edge ランタイムでは、セキュリティ上の理由から、edgeHub に接続するすべてのモジュールのプロセス識別が強制されます。モジュールによって送信されているすべてのメッセージが、モジュールのメインプロセス ID から来ていることが確認されます。モジュールによって、最初に確立されたのと異なるプロセス ID からメッセージが送信されている場合、そのメッセージは 404 エラーメッセージで拒否されます。

解決策

バージョン 1.0.7 時点では、モジュールのすべてのプロセスが接続を承認されています。詳しくは、1.0.7 リリース変更ログのページをご覧ください。

1.0.7 へのアップグレードが不可能な場合は、次の手順を完了します。カスタム IoT Edge モジュールによる edgeHub へのメッセージの送信で、常に同じプロセス ID が使用されるようにします。たとえば、Docker ファイル内で、CMD コマンドではなく ENTRYPOINT を使用するようにします。 CMD コマンドでは、モジュールに使用されるプロセス ID とメインプログラムを実行している bash コマンドに使用されるプロセス ID とが異なりますが、ENTRYPOINT であれば単一のプロセス ID が使用されます。

小型のデバイスでの安定性の問題

現象

Raspberry Pi のようなリソースに制約があるデバイスを、特にゲートウェイとして使用した場合、安定性の問題が発生する可能性があります。 IoT Edge ハブモジュールでメモリ不足例外が発生したり、ダウンストリームのデバイスが接続に失敗したり、数時間後にデバイスからテレメトリメッセージを送信できなくなったりするなどの症状が発生します。

原因

IoT Edge ハブは IoT Edge ランタイムの一部であり、既定でパフォーマンスに対して最適化され、メモリの大部分を割り当てようとします。この最適化は、制約のある Edge デバイスには適していないため、安定性の問題が発生する可能性があります。

解決策

IoT Edge ハブに対して、環境変数 OptimizeForPerformance を false に設定します。環境変数を設定するには、次の 2 つの方法があります。

Azure portal で次の操作を行います。

IoT Hub で、IoT Edge デバイスを選択し、[デバイスの詳細] ページから [モジュールの設定]>[ランタイムの設定] の順に選択します。
True/FalseではFalseに設定された型をもつ OptimizeForPerformance と呼ばれる IoT Edge ハブモジュールの環境変数を作成します。

[ 適用 ] を選択して変更を保存し、[ 確認と作成]を選択。

環境変数が配置マニフェストの edgeHub プロパティに含まれるようになりました:

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

[作成 ] を選択して変更を保存し、モジュールをデプロイします。

セキュリティデーモンを正常に開始できませんでした

現象

セキュリティデーモンが起動に失敗し、モジュールコンテナーが作成されません。 edgeAgent、edgeHub、およびその他のカスタムモジュールは、IoT Edge サービスによって開始されません。 aziot-edged ログで、次のエラーが表示されます。

デーモンを正常に開始できませんでした。管理サービスを開始できませんでした

原因: path/var/run/iotedge/mgmt.sock でエラーが発生しました

原因: アクセス許可が拒否されました (os エラー 13)

原因

CentOS 7 を除くすべての Linux ディストリビューションの場合、IoT Edge の既定の構成は systemd ソケットアクティブ化を使用することです。構成ファイルを変更してソケットのアクティブ化を使用せずに URL を /var/run/iotedge/*.sock のままにすると、アクセス許可エラーが発生します。これは、iotedge ユーザーが /var/run/iotedge に書き込むことができず、ソケット自体のロックを解除してマウントできないためです。

解決策

ソケットのアクティブ化がサポートされているディストリビューションでは、ソケットのアクティブ化を無効にする必要はありません。ただし、ソケットのアクティブ化をまったく使用しない場合は、ソケットを /var/lib/iotedge/ に配置します。

systemd が不必要に起動しないように、systemctl disable iotedge.socket iotedge.mgmt.socket を実行してソケットユニットを無効にします
connect セクションと listen セクションの両方で /var/lib/iotedge/*.sock を使用するように iotedge 構成を変更します
既にモジュールがある場合は、古い /var/run/iotedge/*.sock マウントがあるので、それらを docker rm -f します。

メッセージキューのクリーンアップが遅い

現象

メッセージが処理された後、メッセージキューがクリーンアップされません。メッセージキューは時間の経過と同時に増加し、最終的に IoT Edge ランタイムのメモリ不足が発生します。

原因

メッセージのクリーンアップ間隔は、クライアントメッセージ TTL (有効期間) と EdgeHub MessageCleanupIntervalSecs 環境変数によって制御されます。既定のメッセージ TTL 値は 2 時間で、既定の MessageCleanupIntervalSecs 値は 30 分です。アプリケーションで既定よりも短い TTL 値を使用し、MessageCleanupIntervalSecs 値を調整しない場合、期限切れのメッセージは次のクリーンアップ間隔までクリーンアップされません。

解決策

既定よりも短いアプリケーションの TTL 値を変更する場合は、MessageCleanupIntervalSecs 値も調整してください。 MessageCleanupIntervalSecs 値は、クライアントが使用している最小の TTL 値よりも大幅に小さくする必要があります。たとえば、クライアントアプリケーションでメッセージヘッダーに 5 分の TTL が定義されている場合、MessageCleanupIntervalSecs 値は 1 分に設定します。これらの設定により、6 分 (5 + 1 分) 以内にメッセージがクリーンアップされます。

MessageCleanupIntervalSecs 値を構成するには、IoT Edge ハブモジュールの配置マニフェストでこの環境変数を設定します。ランタイム環境変数の設定の詳細については、「Edge エージェントと Edge ハブの環境変数」を参照してください。

ネットワーク

IoT Edge セキュリティデーモンが無効なホスト名で失敗する

現象

IoT Edge Security Manager のログを確認しようとするとエラーが発生し、次のメッセージが出力されます。

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

原因

IoT Edge ランタイムは、64 文字未満のホスト名のみをサポートできます。通常、物理マシンに長いホスト名は付いていませんが、これは仮想マシンではより一般的な問題です。特に、Azure でホストされる Windows 仮想マシンのために自動生成されるホスト名は長くなる傾向があります。

解決策

このエラーが発生したときは、仮想マシンの DNS 名を構成し、setup コマンドでその DNS 名をホスト名として設定することで、エラーを解決できます。

Azure Portal で、目的の仮想マシンの概要ページに移動します。
[未構成] (新規仮想マシンの場合) リンクを選択して構成パネルを開くか、[Essentials]>[DNS 名] で既存の DNS 名を選択します。仮想マシンに既に構成済みの DNS 名がある場合は、新しいものを構成する必要はありません。
まだ DNS 名ラベル がない場合は値を指定し、[ 保存]を選択します。
次の形式の新しい DNS 名をコピーします：
<DNSnamelabel>.<vmlocation>.cloudapp.azure.com.
IoT Edge デバイスで構成ファイルを開きます。
```
sudo nano /etc/aziot/config.toml
```
hostname の値を DNS 名に置き換えます。
ファイルを保存して閉じ、IoT Edge に変更を適用します。
```
sudo iotedge config apply
```

IoT Edge モジュールによって接続エラーが報告されます

現象

ランタイムモジュールなど、クラウドサービスに直接接続する IoT Edge モジュールは想定どおりに動作を停止し、接続またはネットワークの障害に関するエラーを返します。

原因

コンテナーでは、IP パケット転送がなければインターネットに接続できず、クラウドサービスと通信できません。 Docker では IP パケット転送が既定で有効になっていますが、無効になった場合、クラウドサービスに接続するモジュールは正常に機能しません。詳細については、Docker ドキュメントの「コンテナ通信の理解」を参照してください。

解決策

IP パケット転送を次の手順で有効にします。

sysctl.conf ファイルを開きます。
```
sudo nano /etc/sysctl.conf
```
次の行をファイルに追加します。
```
net.ipv4.ip_forward=1
```
ファイルを保存して閉じます。
ネットワークサービスと docker サービスを再起動し、変更を適用します。

ゲートウェイの背後にある IoT Edge が HTTP 要求を実行して edgeAgent モジュールを起動できない

現象

IoT Edge ランタイムが、有効な構成ファイルでアクティブになっていますが、edgeAgent モジュールを起動できません。コマンド iotedge list を実行すると、空のリストが返されます。 IoT Edge ランタイムのログで Could not perform HTTP request が報告されます。

原因

ゲートウェイの背後にある IoT Edge デバイスは、構成ファイルの parent_hostname フィールドに指定されている親 IoT Edge デバイスからモジュールイメージを取得します。 Could not perform HTTP request エラーは、ダウンストリームデバイスが HTTP 経由で親デバイスに到達できないことを意味します。

解決策

親 IoT Edge デバイスがダウンストリーム IoT Edge デバイスからの受信要求を受信できることを確認します。ダウンストリームデバイスからの要求に対してポート 443 と 6617 でのネットワークトラフィックを開きます。

ゲートウェイの背後にある IoT Edge が HTTP 要求を実行して edgeAgent モジュールを起動できない

現象

IoT Edge デーモンが、有効な構成ファイルでアクティブになっていますが、edgeAgent モジュールを起動できません。コマンド iotedge list を実行すると、空のリストが返されます。 IoT Edge デーモンのログでは、Could not perform HTTP request が報告されます。

原因

解決策

別の IoT ハブに移行すると、ゲートウェイの内側にある IoT Edge が接続できない

現象

IoT Edge デバイスの階層をある IoT ハブから別の IoT ハブに移行すると、最上位の親 IoT Edge デバイスは IoT Hub に接続できますが、ダウンストリームの IoT Edge デバイスは接続できません。ログでは Unable to authenticate client downstream-device/$edgeAgent with module credentials が報告されます。

原因

新しい IoT ハブに移行されたとき、ダウンストリームデバイスの資格情報が正しく更新されませんでした。このため、edgeAgent および edgeHub モジュールの認証の種類が none (明示的に設定されない場合の既定値) に設定されました。接続の間に、ダウンストリームデバイス上のモジュールで古い資格情報が使用され、認証が失敗します。

解決策

新しい IoT ハブに移行するときは (DPS を使わない場合)、次の手順のようにします。

このガイドに従って、デバイス ID を古い IoT ハブからエクスポートして新しい IoT ハブにインポートします
新しい IoT ハブで、IoT Edge のすべてのデプロイと構成を再構成します
新しい IoT ハブで、デバイスのすべての親子関係を再構成します
IoT ハブの新しいホスト名を指すように、各デバイスを更新します (config.toml で [provisioning] の下にある iothub_hostname)
デバイスのエクスポートの間に認証キーを除外した場合は、新しい IoT ハブによって提供された新しいキーで各デバイスを再構成します (config.toml で [provisioning.authentication] の下にある device_id_pk)
最初に最上位レベルの親 Edge デバイスを再起動し、稼働状態になることを確認します
階層レベルの上から下に向けて、各デバイスを再起動します

IoT Hub から地理的に離れている場合、IoT Edge のメッセージスループットが低い

現象

Azure IoT Hub から地理的に離れている Azure IoT Edge デバイスのメッセージスループットは、予想よりも低くなります。

原因

デバイスと IoT Hub の間の待機時間が長いと、予想よりも低いメッセージスループットが発生する可能性があります。 IoT Edge では、デフォルトメッセージバッチサイズ 10 が使用されます。これにより、1 つのバッチで送信されるメッセージの数が制限され、デバイスと IoT Hub の間のラウンドトリップの数が増えます。

解決策

IoT Edge Hub MaxUpstreamBatchSize 環境変数を増やしてみてください。これにより、1 つのバッチでより多くのメッセージを送信できるため、デバイスと IoT Hub の間のラウンドトリップの数が減ります。

Azure portal で Azure Edge Hub 環境変数を設定するには:

IoT Hub に移動し、[ デバイス管理 ]メニューの下にある [ デバイス ] を選択します。
更新する IoT Edge デバイスを選択します。
[Set Modules] \(モジュールの設定) を選択します。
[ランタイムの設定] を選択します。
Edge Hub モジュールの設定タブで、 MaxUpstreamBatchSize 環境変数を、値が 20 の数値の種類として追加します。
[適用] を選択します。

次のステップ

IoT Edge プラットフォームのバグを発見したと思われる場合は、改善を続けられるように問題を報告してください。

その他に質問がある場合は、サポートリクエストを作成して対応を要請してください。

次の方法で共有

Azure IoT Edge に関する一般的な問題の解決策

プロビジョニングとデプロイ

デプロイに成功した IoT Edge モジュールがデバイスから消える

現象

原因

解決策

IoT Edge ランタイム

1 分後に IoT Edge エージェントが停止する

現象

原因

解決策

Edge エージェント モジュールで "空の構成ファイル" がレポートされ、デバイスでモジュールが開始しない

現象

原因

解決策

LTE 接続を備えた Edge エージェント モジュールは、「空のエッジ エージェント構成」 を報告し、「一時的なネットワーク エラー」 を引き起こします

現象

原因

解決策

IoT Edge エージェントがモジュールのイメージにアクセスできない (403)

現象

原因

解決策

IoT Edge エージェントによる過剰な ID 呼び出し

現象

原因

解決策

IoT Edge ハブが起動に失敗する

現象

原因

解決策

IoT Edge モジュールが 404 エラーで edgeHub にメッセージを送信できない

現象

原因

解決策

小型のデバイスでの安定性の問題

現象

原因

解決策

セキュリティ デーモンを正常に開始できませんでした

現象

原因

解決策

メッセージ キューのクリーンアップが遅い

現象

原因

解決策

ネットワーク

IoT Edge セキュリティ デーモンが無効なホスト名で失敗する

現象

原因

解決策

IoT Edge モジュールによって接続エラーが報告されます

現象

原因

解決策

ゲートウェイの背後にある IoT Edge が HTTP 要求を実行して edgeAgent モジュールを起動できない

現象

原因

解決策

ゲートウェイの背後にある IoT Edge が HTTP 要求を実行して edgeAgent モジュールを起動できない

現象

原因

解決策

別の IoT ハブに移行すると、ゲートウェイの内側にある IoT Edge が接続できない

現象

原因

解決策

IoT Hub から地理的に離れている場合、IoT Edge のメッセージ スループットが低い

現象

原因

解決策

次のステップ

フィードバック

その他のリソース

Edge エージェントモジュールで "空の構成ファイル" がレポートされ、デバイスでモジュールが開始しない

LTE 接続を備えた Edge エージェントモジュールは、「空のエッジエージェント構成」を報告し、「一時的なネットワークエラー」を引き起こします

セキュリティデーモンを正常に開始できませんでした

メッセージキューのクリーンアップが遅い

IoT Edge セキュリティデーモンが無効なホスト名で失敗する

IoT Hub から地理的に離れている場合、IoT Edge のメッセージスループットが低い