Azure IoT Edge に関する一般的な問題の解決策
注意事項
この記事では、サービス終了 (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 Edge デバイスは、構成ファイルの parent_hostname
フィールドに指定されている親 IoT Edge デバイスからモジュール イメージを取得します。 Could not perform HTTP request
エラーは、ダウンストリーム デバイスが HTTP 経由で親デバイスに到達できないことを意味します。
解決策
親 IoT Edge デバイスがダウンストリーム IoT Edge デバイスからの受信要求を受信できることを確認します。 ダウンストリーム デバイスからの要求に対してポート 443 と 6617 でのネットワーク トラフィックを開きます。
別の 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 プラットフォームのバグを発見したと思われる場合は、 改善を続けられるように問題を報告してください。
その他に質問がある場合は、サポート リクエストを作成して対応を要請してください。