次の方法で共有

Azure Logic Apps でワークフローの状態をチェックし、実行履歴を確認し、アラートを設定する

  • [アーティクル]

適用対象: Azure Logic Apps (従量課金プラン + Standard)

ロジック アプリ ワークフローを作成して実行した後は、ワークフローの実行状態、トリガー履歴、ワークフローの実行履歴、パフォーマンスをチェックできます。

このガイドでは、次のタスクを実行する方法について説明します。

Standard ワークフローのワークフロー実行状態を監視および確認するには、シングルテナント Azure Logic Apps での Standard ロジック アプリ ワークフローの例の作成に関する記事の次のセクションをご覧ください。

リアルタイムでのイベントの監視と高度なデバッグを行うには、Azure Monitor ログを使用してロジック アプリ ワークフローの診断ログを設定できます。 この Azure サービスを使用すると、クラウド環境とオンプレミス環境を監視して、可用性とパフォーマンスをより簡単に維持することができます。 これにより、トリガー イベント、実行イベント、アクション イベントなどのイベントを検索して表示できます。 この情報を Azure Monitor ログに格納することで、この情報の検索と分析に役立つログ クエリを作成できます。 この診断データは、Azure Storage や Azure Event Hubs などの他の Azure サービスで使用することもできます。 詳細については、「Azure Monitor を使用してロジック アプリを監視する」を参照してください。

トリガー履歴を確認する

各ワークフローの実行は、スケジュールに従って起動するか、受信要求やイベントを待機するトリガーによって開始されます。 このトリガー履歴には、ワークフローによるすべてのトリガーの試行と、各トリガーの試行の入出力に関する情報が一覧表示されます。

  1. Azure portal のデザイナーで、ロジック アプリ リソースとワークフローを開きます。

  2. ロジック アプリのメニューで、 [概要] を選択します。 [概要] ウィンドウで、[トリガーの履歴] を選択します。

    スクリーンショットでは、従量課金ロジック アプリ ワークフローの [概要] ペインが示され、[トリガーの履歴] というオプションが選択されています。

    [トリガーの履歴] に、すべてのトリガー試行が表示されます。 トリガーが正常に起動されるたびに、Azure Logic Apps は個々のワークフロー インスタンスを作成し、そのインスタンスを実行します。 既定では、各インスタンスが並列で実行されるため、ワークフローは待ち時間なしで実行が開始されます。 ワークフローが複数のイベントまたは項目に対して同時にトリガーされると、各項目に対して日付と時刻が同じトリガー エントリが表示されます。

    スクリーンショットでは、従量課金ロジック アプリ ワークフローの [概要] ペインと、異なる項目に対する複数のトリガーの試行が示されています。

    次の表に、発生する可能性のあるトリガー状態を示します。

    トリガー状態 説明
    Failed エラーが発生しました。 失敗したトリガーに対して生成されたエラー メッセージを確認するには、そのトリガー試行を選んで、[出力] を選びます。 たとえば、無効な入力が見つかる場合があります。
    Skipped トリガーによりエンドポイントがチェックされましたが、指定された条件を満たすデータが見つかりませんでした。
    Succeeded トリガーによりエンドポイントがチェックされ、使用可能なデータが見つかりました。 通常、この状態は、 [起動済み] と共に表示されます。 表示されない場合、トリガー定義に、十分でない条件または SplitOn コマンドが含まれる可能性があります。

    この状態は、手動トリガー、繰り返しベースのトリガー、またはポーリング トリガーに適用されます。 トリガーは正常に実行できますが、アクションによって未処理のエラーが生成されると、実行自体が引き続き失敗する可能性があります。

    ヒント

    トリガーの再チェックは、そのトリガーが次回起動されるのを待たずに実行できます。 [概要] ウィンドウのツールバーまたはデザイナーのツールバーで、[トリガーの実行]>[実行] を選択します。

  3. 特定のトリガー試行に関する情報を表示するには、そのトリガー イベントを選択します。

    スクリーンショットでは、選択された従量課金ワークフロー トリガー エントリが示されています。

    一覧に多数のトリガー試行が表示され、必要なエントリが見つからない場合は、一覧にフィルターを適用してみます。 必要なデータが見つからない場合は、ツール バーの [更新] を選択してみます。

    選択したトリガー イベントに関する情報を確認できるようになりました。次に例を示します。

    スクリーンショットでは、選択された従量課金ワークフロー トリガーの履歴情報が示されています。

ワークフロー実行履歴を確認する

トリガーが正常に起動されるたびに、Azure Logic Apps はワークフロー インスタンスを作成し、そのインスタンスを実行します。 既定では、各インスタンスが並列で実行されるため、ワークフローは待ち時間なしで実行が開始されます。 ワークフローの各ステップの状態、入力、出力など、各実行中に何が発生したか確認できます。

  1. Azure portal のデザイナーで、ロジック アプリ リソースとワークフローを開きます。

  2. ロジック アプリのメニューで、 [概要] を選択します。 [概要] ページで、[実行履歴] を選択します。

    [実行の履歴] に、過去、現在、待機中のすべての実行が表示されます。 複数のイベントまたは項目に対して同時にトリガーが起動すると、各項目に対して日付と時刻が同じエントリが表示されます。

    スクリーンショットでは、従量課金ワークフローと [概要] ペインが示され、[実行の履歴] オプションが選択されています。

    次の表に、発生する可能性のある実行の状態を示します。

    実行の状態 説明
    Aborted 外部に問題が発生したため、実行が停止したか、または完了しませんでした。たとえば、システムの停止や Azure サブスクリプションの中断などです。
    取り消し済み 実行がトリガーされ、開始されましたが、キャンセル要求を受け取りました。
    Failed 実行中に少なくとも 1 つのアクションが失敗しました。 ワークフローの後続のアクションは、エラーを処理するように設定されていません。
    実行中 実行がトリガーされ、進行中です。 ただし、この状態は、アクション制限または現在の料金プランによって制限されている実行に対しても表示されます。

    ヒント:診断ログを設定すると、発生するスロットル イベントに関する情報を取得することができます。
    Succeeded 実行は成功しました。 いずれかのアクションが失敗した場合、ワークフロー内の後続のアクションによってそのエラーが処理されます。
    タイムアウト 現在の継続時間が実行継続時間の制限を超えたため、実行がタイムアウトしました。これは、[実行履歴の保持期間 (日数)] 設定によって制御されます。 実行の継続時間は、実行の開始時刻とその開始時刻での実行継続時間の制限を使用して計算されます。

    注: 実行の継続時間が現在の "実行履歴の保持期間の制限" も超えている場合は、毎日のクリーンアップ ジョブによって実行履歴から実行が消去されます。これも、[実行履歴の保持期間 (日数)] 設定によって制御されます。 実行がタイムアウトしたか完了したかにかかわらず、保持期間は常に、実行の開始時刻と "現在の" 保持期間の制限を使用して計算されます。 そのため、処理中の実行の継続時間制限を短くすると、実行はタイムアウトします。ただし、実行が実行履歴に残るか消去されるかは、実行の継続時間が保持期間の制限を超えているかどうかに基づいて決まります。
    待機中 たとえば、その前のワークフロー インスタンスがまだ実行中である等の理由で、実行が開始されていないか、または一時停止しています。

  3. 特定の実行についてのステップとその他の情報を確認するには、 [実行の履歴] でその実行を選択します。 一覧に多数の実行が表示され、必要なエントリが見つからない場合は、一覧をフィルター処理してみてください。

    ヒント

    実行の状態が表示されない場合は、[更新] を選択して [概要] ウィンドウを更新してみてください。 条件が満たされなかったか、データが見つからなかったためにスキップされたトリガーに対しては、実行は行われません。

    スクリーンショットでは、選択された従量課金ワークフローの実行が示されています。

    [ロジック アプリの実行] ウィンドウには、選択した実行の各ステップ、各ステップの実行状態、各ステップの実行にかかった時間が表示されます。次に例を示します。

    スクリーンショットでは、選択されたワークフロー実行の各アクションが示されています。

    この情報をリスト形式で表示するには、 [ロジック アプリの実行] ツール バーで [実行の詳細] を選択します。

    スクリーンショットでは、[ロジック アプリの実行] という名前のツール バーと、選択された [実行の詳細] オプションが示されています。

    [実行の詳細] に、各ステップ、その状態、その他の情報が一覧表示されます。

    ワークフローの各ステップの実行の詳細を示すスクリーンショット。

    たとえば、その実行の関連付け ID プロパティを取得できます。これは、Logic Apps 用の REST API を使用する際に必要になる場合があります。

  4. 特定のステップに関する詳細情報を取得するには、次のいずれかのオプションを選択します。

    • [ロジック アプリの実行] ウィンドウで、ステップを選択してシェイプを展開します。 これにより、そのステップで発生した入力、出力、エラーなどの情報を確認できます。

      たとえば、失敗したアクションがあり、どの入力が原因でそのステップが失敗したか確認したいとします。 シェイプを展開すると、そのステップの入力、出力、エラーを確認できます。

      失敗したステップの例に対して図形が拡大された [ロジック アプリの実行] ウィンドウを示すスクリーンショット。

    • [ロジック アプリの実行の詳細] ウィンドウで、目的のステップを選択します。

      失敗したステップの例が選択された [ロジック アプリの実行の詳細] ペインを示すスクリーンショット。

    Note

    ランタイムのすべての詳細とイベントは Azure Logic Apps 内で暗号化され、ユーザーがそのデータの表示を要求したときにのみ暗号化が解除されます。 実行履歴の入力と出力を非表示にしたり、Azure のロールベースのアクセス制御 (RBAC) を使用して、この情報へのユーザー アクセスを制御したりすることができます。

同じ入力を使用してワークフローを再実行する

以前に完了したワークフローは、そのワークフローが以前に使用したのと同じ入力を使用して、次の方法で再実行できます。

  • ワークフロー全体を再実行する。

  • 特定のアクションから開始してワークフローを再実行する。 再送信されたアクションとその後のすべてのアクションは、通常どおりに実行されます。

このタスクを完了すると、ワークフローの実行履歴に新しいワークフロー実行が作成および追加されます。

制限と考慮事項

  • 既定では、実行履歴を記録して保存する従量課金ワークフローとステートレス Standard ワークフローのみがサポートされています。 ステートレス Standard ワークフローでこれらの機能を使用するには、ステートフル モードを有効にします。 詳細については、「ステートレス ワークフローの実行履歴を有効にする」とステートレス コネクタのステートフル モードを有効にするに関するページを参照してください。

  • ワークフロー定義を更新した場合でも、再送信された実行では元の実行と同じワークフロー バージョンが実行されます。

  • 再実行できるのは、シーケンシャル ワークフローからのアクションのみです。 現在、並列パスを含むワークフローはサポートされていません。

  • ワークフローは、Succeeded (成功)、Failed (失敗)、Cancelled (キャンセル) などの完了した状態である必要があります。

  • 特定のアクションから再実行するには、ワークフローのアクションが 40 個以下である必要があります。

  • ワークフローに作成操作や削除操作などの操作がある場合、実行を再送信すると重複するデータが作成されたり、存在しなくなったデータを削除しようとしたりしてエラーが発生する可能性があります。

  • 現在、これらの機能は Visual Studio Code または Azure CLI では使用できません。

ワークフロー全体を再実行する

  1. Azure portal のデザイナーで、ロジック アプリ リソースとワークフローを開きます。

  2. ロジック アプリのメニューで、 [概要] を選択します。 [概要] ページで、[実行履歴] を選択します。

    [実行の履歴] に、過去、現在、待機中のすべての実行が表示されます。 複数のイベントまたは項目に対して同時にトリガーが起動すると、各項目に対して日付と時刻が同じエントリが表示されます。

  3. [実行履歴] ウィンドウで、再送信する実行を選択します。

  4. [ロジック アプリの実行] ツール バーで、[再送信] を選択し、[はい] を選択します。

    [実行履歴] ウィンドウに、再送信された実行が表示されるようになりました。

    ヒント

    再送信された実行が表示されない場合、[実行履歴] ウィンドウのツール バーで、[更新] を選択します。 条件が満たされなかったか、データが見つからなかったためにスキップされたトリガーに対しては、実行は行われません。

  5. 再送信されたワークフローの実行の入力と出力を確認するには、[実行履歴] タブで、その実行を選択してください。

特定のアクションから再実行する

再実行機能は、次の制限事項に従い、非シーケンシャルおよび複雑なコンカレンシー シナリオを除くすべてのアクションで使用できます。

アクション 再送信の利用可能性と制限事項
条件アクションと True および False パスのアクション - 条件 アクションの場合は使用可能
- True と False パスのアクションの場合は使用不可
ループ内およびループ後の For each アクションとすべてのアクション すべてのアクションで使用不可
Switch アクションと、Default パスおよび Case パス内のすべてのアクション - Switch アクションの場合は使用可能
- Default パスおよび Case パス内のアクションは使用不可
ループ内およびループ後の Until アクションとすべてのアクション すべてのアクションで使用不可

  1. Azure portal で、ロジック アプリ リソースを開きます。

  2. ロジック アプリのリソース メニューで、[概要] を選択します。 [概要] ページで、[実行履歴] を選択すると、ワークフローの実行履歴が表示されます。

  3. [実行履歴] タブで、再送信する実行を選択します。

    [実行の詳細] ページが開き、実行の各ステップの状態が表示されます。

  4. [実行の詳細] ページで、ワークフロー実行を再送信するアクションを見つけ、ショートカット メニューを開き、[このアクションから送信] を選択してください。

    [実行の詳細] ページが更新され、新しい実行が表示されます。 再送信されたアクションの前にあるすべての操作には、再利用された入力と出力を表す明るい色の状態アイコンが表示されます。 再送信されたアクションとその後のアクションには、通常の色の状態アイコンが表示されます。 詳細については、「ワークフロー実行履歴の確認」を参照してください。

    ヒント

    実行が完全に完了していない場合は、[実行の詳細] ページのツール バーで [最新の情報に更新] を選択してください。

監視アラートを設定する

ロジック アプリの特定のメトリックまたはしきい値の超過に基づいてアラートを発生させるには、Azure Monitor のアラートを設定します。 詳細については、「Azure のメトリック」を参照してください。

Azure Monitor を使わずにアラートを設定するには、次の手順のようにします。これは、従量課金と Standard 両方のロジック アプリ リソースに適用されます。

  1. ロジック アプリのメニューで、[監視] の下にある [アラート] を選択します。 ツールバーで、[作成]>[アラート ルール] を選択します。

  2. [アラート ルールの作成] ページの [シグナル名] の一覧で、アラートを受け取るシグナルを選びます。

    Note

    従量課金ロジック アプリと Standard ロジック アプリでは、使用可能なアラート シグナルが異なります。 たとえば、従量課金ロジック アプリには、トリガー完了やトリガー失敗など、トリガー関連のシグナルが多数あります。一方、Standard ワークフローには、ワークフロー トリガー完了数やワークフロー トリガー失敗率のシグナルがあります。

    たとえば、従量課金ワークフローでトリガーが失敗したときにアラートを送信するには、次の手順に従います。

    1. [シグナル名] の一覧で、[トリガーが失敗しました] シグナルを選びます。

    2. [アラート ロジック] で、次の例のような条件を設定します。

      プロパティ 例値
      しきい値 Static
      集計の種類 Count
      Operator 次の値以上
      単位 Count
      しきい値 1

      [プレビュー] セクションに、次の例のように、設定した条件が表示されます。

      Whenever the count Triggers Failed is greater than or equal to 1 ("トリガーが失敗しました" の数が 1 以上の場合常に)

    3. [評価するタイミング] で、条件をチェックするスケジュールを設定します。

      プロパティ 例値
      確認する間隔 1 分
      ルックバック期間 5 分

      たとえば、完成した条件は次の例のようになり、そのアラートを実行するためのコストが [アラート ルールの作成] ページに表示されます。

      従量課金ロジック アプリとアラート ルールの条件を示すスクリーンショット。

  3. 準備ができたら、[確認および作成] を選択します。

一般的な情報については、特定のリソースからのアラート ルールの作成 - Azure Monitor に関する記事をご覧ください。

次のステップ