Azure Logic Apps でのワークフローの問題のトラブルシューティングと診断
適用対象: Azure Logic Apps (従量課金プラン + Standard)
ロジック アプリ ワークフローでは、アプリの問題の診断とデバッグに役立つ情報が生成されます。 Azure portal を使用して、ワークフローの各ステップの入力、出力、およびその他の情報を確認することによって、ワークフローを診断できます。 また、ランタイム デバッグのための手順をいくつかワークフローに追加することもできます。
トリガーの履歴を確認してください
各ワークフローの実行は、スケジュールに従って起動するか、受信要求やイベントを待機する、トリガーによって開始されます。 このトリガー履歴には、ワークフローによるすべてのトリガーの試行と、各トリガーの試行の入出力に関する情報が一覧表示されます。 トリガーが起動しない場合は、次の手順を試してください。
従量課金プランのロジック アプリでトリガーの状態を確認するには、トリガーの履歴を確認します。 トリガーの試行に関する詳細情報を表示するには、そのトリガーイベントを選択します。次に例を示します。
トリガー入力をチェックして、期待どおりに表示されることを確認します。 [履歴] ウィンドウの [入力のリンク] で、リンクを選択します。これにより、[入力] ウィンドウが表示されます。
トリガー入力には、トリガーがワークフローの開始を要求するデータが含まれます。 これらの入力を確認すると、トリガー入力が正しいかどうか、およびワークフローを続行できるように条件が満たされたかどうかを判断するのに役立ちます。
トリガー出力がある場合は、それをチェックして、期待したとおりに表示されているか確認します。 [履歴] ウィンドウの [出力のリンク] で、リンクを選択します。これにより、[出力] ウィンドウが表示されます。
トリガー出力には、トリガーがワークフローの次のステップに渡すデータが含まれます。 これらの出力を確認すると、正しい値または想定していた値がワークフローの次のステップに渡されたかどうかを判別できます。
たとえば、エラー メッセージで RSS フィードが見つからなかったことが示されます。
ヒント
認識できないコンテンツが見つかった場合は、Azure Logic Apps のさまざまなコンテンツタイプについて学習します。
ワークフロー実行履歴を確認する
トリガーが起動されるたびに、Azure Logic Apps ではワークフロー インスタンスが作成され、そのインスタンスが実行されます。 実行が失敗した場合は、その実行中に何が起こったかを確認できるようにするために、次の手順を試してください。 ワークフローの各ステップの状態、入力、出力を確認できます。
従量課金プラン ロジック アプリでワークフローの実行状態を確認するには、実行履歴を確認します。 失敗した実行のすべての手順のステータスなど、失敗した実行の詳細を表示するには、失敗した実行を選択します。
実行のすべての手順が表示されたら、各手順を選択して図形を展開します。
失敗した手順の入力、出力、およびエラー メッセージを確認します。
たとえば、次のスクリーンショットは失敗した RSS アクションからの出力を示しています。
ランタイム デバッグを実行する
デバッグに役立つように、ロジックアプリケーションのワークフローに診断手順を追加し、トリガーと実行履歴を確認できます。 たとえば、Webhook Tester サービスを使用する手順を追加できます。これにより、HTTP 要求を調べて、正確なサイズ、シェイプ、および形式を特定できます。
ブラウザーで Webhook Testerサイトに移動し、生成された固有の URL をコピーします。
ロジック アプリで、テスト対象の HTTP POST アクションと本文コンテンツを追加します (式、別の手順の出力など)。
Webhook TesterからHTTP POSTアクションにURLを貼り付けます。
Azure Logic Apps で要求が生成および形成される方法を確認するには、ロジック アプリ ワークフローを実行します。 その後、Webhook Tester のサイトに再びアクセスして詳細を確認できます。
パフォーマンス - よくあるご質問 (FAQ)
ワークフローの実行時間が、すべてのワークフロー アクション時間の合計よりも長くなるのはなぜですか?
アクションの実行時にスケジュール設定のオーバーヘッドが存在します。さらに、バックエンド システムの負荷が原因で、アクション間の待機時間が発生する可能性があります。 ワークフロー実行期間には、すべてのアクション期間の合計に加えて、これらのスケジュール設定時間と待機時間が含まれます。
通常、ワークフローは 10 秒以内に完了します。 ただし、完了にかなり時間がかかる場合があります。 どのようにすればワークフローが必ず 10 秒以内に完了するようにできますか?
SLA の保証は、待機時間については存在しません。
従量課金ワークフローはマルチテナントの Azure Logic Apps で実行されるため、他のお客様のワークロードがご自身のワークフローのパフォーマンスに悪影響を及ぼす可能性があります。
より予測可能なパフォーマンスを得るには、シングルテナントの Azure Logic Apps で実行される Standard ワークフローを作成することを検討してください。 パフォーマンスを向上させるために、スケールアップまたはスケールアウトをより詳細に制御できます。
アクションが 2 分後にタイムアウトになります。 タイムアウト値を増やすにはどうすればよいですか?
アクションのタイムアウト値は変更できず、2 分に固定されています。 HTTP アクションを使用していて、HTTP アクションによって呼び出されるサービスを所有している場合は、非同期パターンを使用すると、2 分のタイムアウトを回避するようにサービスを変更できます。 詳細については、「ポーリング アクション パターンで長時間タスクを実行する」を参照してください。
一般的な問題 - Standard ロジック アプリ
Azure ストレージ アカウント内のアクセスできない成果物
Standard ロジック アプリでは、すべての成果物を Azure ストレージ アカウントに格納します。 これらの成果物にアクセスできない場合は、次のエラーが発生する可能性があります。 たとえば、ストレージ アカウント自体にアクセスできない場合や、ストレージ アカウントがファイアウォールの内側にあるが、ストレージ サービスで使用するようにプライベート エンドポイントが設定されていない場合などがあります。
| Azure portal の場所 | エラー |
|---|---|
| [概要] ペイン | - System.private.corelib:パス 'C:\home\site\wwwroot\hostj.son へのアクセスが拒否されました - Azure.Storage.Blobs: この要求では、この操作の実行は許可されません |
| [ワークフロー] ペイン | - ホスト ランタイムにアクセスできません。エラーの詳細、コード: 'BadRequest'、メッセージ: 'Encountered an error (InternalServerError) from host runtime.'(ホスト ランタイムからエラー (InternalServerError) が発生しました) - ホスト ランタイムにアクセスできません。エラーの詳細、コード: 'BadRequest'、メッセージ: 'Encountered an error (ServiceUnavailable) from host runtime.'(ホスト ランタイムからエラー (ServiceUnavailable) が発生しました) - ホスト ランタイムにアクセスできません。エラーの詳細、コード: 'BadRequest'、メッセージ: 'Encountered an error (BadGateway) from host runtime.'(ホスト ランタイムからエラー (BadGateway) が発生しました) |
| ワークフローの作成と実行中 | - ワークフローの保存失敗 - Error in the designer: GetCallFailed. Failed fetching operations (デザイナーのエラー: GetCallFailed。フェッチ操作に失敗しました) - ajaxExtended call failed (ajaxExtended 呼び出しに失敗しました) |
トラブルシューティングのオプション
次の一覧には、これらのエラーの考えられる原因とトラブルシューティングに役立つ手順が含まれています。
パブリック ストレージ アカウントの場合は、次の方法でストレージ アカウントへのアクセスを確認します。
Azure Storage Explorer を使用してストレージ アカウントの接続を確認します。
ロジック アプリ リソースのアプリ設定で、アプリ設定 AzureWebJobsStorage および WEBSITE_CONTENTAZUREFILECONNECTIONSTRING のストレージ アカウントの接続文字列を確認します。 詳細については、シングルテナントの Azure Logic Apps でのロジック アプリのホストとアプリの設定に関するページを参照してください。
接続に失敗した場合は、接続文字列の Shared Access Signature (SAS) キーが最新であるかどうかを確認します。
ファイアウォールの内側にあるストレージ アカウントの場合は、次の方法でストレージ アカウントへのアクセスを確認します。
ストレージ アカウントでファイアウォールの制限が有効になっている場合は、BLOB、ファイル、テーブル、キュー ストレージ サービス用のプライベート エンドポイントが設定されているかどうかを確認します。
Azure Storage Explorer を使用してストレージ アカウントの接続を確認します。
接続の問題が検出された場合、以下の手順を続行します。
ロジック アプリに統合されているのと同じ仮想ネットワークで、別のサブネットに配置できる Azure 仮想マシンを作成します。
コマンド プロンプトから nslookup を実行して、BLOB、ファイル、テーブル、キュー ストレージ サービスが予想される IP アドレスに解決されることを確認します。
構文:
nslookup [StorageaccountHostName] [OptionalDNSServer]BLOB:
nslookup {StorageaccountName}.blob.core.windows.netファイル:
nslookup {StorageaccountName}.file.core.windows.netテーブル:
nslookup {StorageaccountName}.table.core.windows.netキュー:
nslookup {StorageaccountName}.queue.core.windows.netストレージ サービスにサービス エンドポイントがある場合、サービスはパブリック IP アドレスに解決されます。
ストレージ サービスにプライベート エンドポイントがある場合、サービスはそれぞれのネットワーク インターフェイス コントローラー (NIC) のプライベート IP アドレスに解決されます。
前のドメイン ネーム サーバー (DNS) のクエリが正常に解決される場合は、 psping または tcpping コマンドを実行して、ポート 443 経由でストレージ アカウントへの接続を確認します。
構文:
psping [StorageaccountHostName] [Port] [OptionalDNSServer]BLOB:
psping {StorageaccountName}.blob.core.windows.net:443ファイル:
psping {StorageaccountName}.file.core.windows.net:443テーブル:
psping {StorageaccountName}.table.core.windows.net:443キュー:
psping {StorageaccountName}.queue.core.windows.net:443各ストレージ サービスが Azure 仮想マシンから解決可能な場合は、仮想マシンによって解決に使用される DNS を見つけます。
ロジック アプリの WEBSITE_DNS_SERVER アプリ設定を DNS に設定し、DNS が正常に動作することを確認します。
VNet 統合が、Standard ロジック アプリ内の適切な仮想ネットワークとサブネットを使用して正しく設定されていることを確認します。
ストレージ アカウントのプライベート エンドポイント サービスにプライベート Azure DNS ゾーンを使用する場合は、ロジック アプリの統合仮想ネットワークへの仮想ネットワーク リンク が作成されていることを確認します。
詳細については、サービスまたはプライベート エンドポイントを使用して、ファイアウォールの背後にあるストレージ アカウントに Standard ロジック アプリをデプロイすることに関する記事を参照してください。