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

対象: IoT Edge 1.5

重要

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

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

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

モジュールIoT Edge正常にデプロイされた後、デバイスから消える

症状

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

原因

デバイスが自動デプロイの対象になった場合、自動デプロイは、個々のデバイスに対するモジュールの手動設定よりも優先されます。 Azure ポータルの Set モジュール 機能や、Visual Studio Code の単一デバイス用デプロイメント作成機能が一時的に有効になります。定義したモジュールがデバイスで起動したことを確認できます。その後は、自動デプロイが優先されるようになり、デバイスの必要なプロパティは上書きされます。

解決策

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

詳細については、単一デバイスまたは大規模展開のIoT Edge自動デプロイメントを理解するを参照してください。

IoT Edge ランタイム

IoT Edge エージェントは 1 分後に停止します

症状

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 を実行すると、Container エンジンが DNS サーバー設定で構成されていないことが報告され、IoT Hubへの接続に影響する可能性があります。ベストプラクティスについては、https://aka.ms/iotedge-prod-checklist-dns を参照してください。

原因

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

解決策

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

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

{
    "dns": ["1.1.1.1"]
}

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

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

その場所に 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をスナップとしてインストールする場合は、--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 チェック の出力に警告メッセージが引き続き表示されます。 IoT Edge スナップに Docker スナップへの読み取りアクセス権がないため、エラーを報告します。リリースプロセスで 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

注記

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 ポータルで配置マニフェストを確認します。エラーを修正し、マニフェストをデバイスに再デプロイします。

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 モジュールがバインドを試みるポートがバインドされました。 IoT Edge ハブは、ゲートウェイシナリオで使用するためにポート 443、5671、および 8883 をマップします。別のプロセスが既にこれらのポートの 1 つをバインドしている場合、モジュールの起動に失敗します。

解決策

この問題は、次の 2 つの方法のいずれかで解決します。

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

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

Azure ポータルで次の手順を実行します。

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

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

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

edgeAgentのデザイアードプロパティの欄で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"
}

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

IoT Edgeモジュールは edgeHub にメッセージを送信できません。404 エラーが返されます

症状

カスタム IoT Edge モジュールは、IoT Edge ハブにメッセージを送信できないため、404 Module not found エラーが返されます。 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 モジュールが常に同じプロセス ID を使用して edgeHub にメッセージを送信していることを確認します。たとえば、Docker ファイルの ENTRYPOINT コマンドではなく、CMD コマンドを使用します。 CMD コマンドは、モジュールの 1 つのプロセス ID と、メインプログラムを実行する bash コマンドの別のプロセス ID になります。 ENTRYPOINT コマンドを実行すると、1 つのプロセス ID になります。

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

症状

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

原因

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

解決策

IoT Edge ハブの場合は、環境変数 OptimizeForPerformance を false に設定します。環境変数は、次の 2 つの方法のいずれかで設定できます。

Azure ポータルで次の手順を実行します。

IoT Hubで、IoT Edge デバイスを選択します。デバイスの詳細ページで、[ Set Modules > Runtime Settings] を選択します。
OptimizeForPerformance という名前のIoT Edge ハブモジュールの環境変数True/False を作成し、False に設定します。

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

環境変数が配置マニフェストの 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"
   }

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

セキュリティデーモンを起動できない

症状

セキュリティデーモンを起動できません。モジュールコンテナーは作成されません。 IoT Edge サービスは、edgeAgent、edgeHub、またはその他のカスタムモジュールを開始しません。 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に書き込むことができないため、ソケットのロック解除とマウントができません。 CentOS は終了です (EOL)。詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。

解決策

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

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

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

症状

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

原因

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

解決策

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

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

AMQP プロトコルを使用すると、IoT Edge Hub が System.FormatException エラーを報告する

症状

AMQP プロトコルを使用してIoT Edge デバイスからIoT Hubにメッセージをルーティングし、送信デバイスメッセージで iothub-creation-time-utc プロパティを設定すると、IoT Edge Hub は System.FormatException エラーを報告します。エラーメッセージは、次のようになります。

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

原因

iot-hub-creation-time-utc 値が厳密な形式条件を満たしていません。 Edge Hub に必要な形式は、ISO 8601 のサブセットです。

解決策

この問題は、AMQP プロトコルの IoT Edge Hub の既知の問題です。現在、製品チームは修正プログラムを調査しています。 MQTT プロトコルにはこの問題はありません。

ネットワーク

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

症状

IoT Edgeセキュリティマネージャーログを確認しようとするとが失敗し、次のメッセージが出力されます。

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

原因

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

解決策

このエラーが表示されたら、仮想マシンの DNS 名を構成し、セットアップコマンドで DNS 名をホスト名として設定して解決します。

Azure ポータルで、仮想マシンの概要ページに移動します。
[未構成] (新規仮想マシンの場合) リンクを選択して構成パネルを開くか、[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は、ある IoT ハブから別の IoT ハブに移行するときに接続できません

症状

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

原因

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

解決策

新しい IoT ハブに移行する場合 (DPS を使用していない場合)、次の手順に従います。

このガイドに従って、デバイス ID を古い IoT ハブからエクスポートして新しい IoT ハブにインポートします
新しい IoT ハブ内のすべてのIoT Edgeデプロイと構成を再構成する
新しい IoT ハブで、デバイスのすべての親子関係を再構成します
各デバイスを更新して、新しいIoTハブのホスト名（iothub_hostname の [provisioning] にある config.toml）を指すようにします。
デバイスのエクスポートの間に認証キーを除外した場合は、新しい IoT ハブによって提供された新しいキーで各デバイスを再構成します (device_id_pk で [provisioning.authentication] の下にある config.toml)
最初に最上位レベルの親 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 ポータルAzure Edge Hub 環境変数を設定するには:

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

次のステップ

IoT Edge プラットフォームでバグが見つかったと思いますか? 製品チームが引き続きプラットフォームを改善できるように、問題を送信します。

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

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-11