次の方法で共有

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

  • [アーティクル]

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

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

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

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

トリガー履歴を確認する

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

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

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

    Azure portal、従量課金ワークフロー、[トリガーの履歴] という名前のタブが選択されている [概要] ページを示すスクリーンショット。

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

    従量課金ワークフローの [概要] ページと、異なる項目に対する複数のトリガーの試行を示すスクリーンショット。

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

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

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

    ヒント

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

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

    従量課金ワークフロー トリガーの履歴と選択したエントリを示すスクリーンショット。

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

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

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

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

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

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

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

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

    ヒント

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

    従量課金ワークフローと、[実行の履歴] という名前のタブが選択された [概要] ページを示すスクリーンショット。

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

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

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

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

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

    選択された従量課金ワークフローの実行を示すスクリーンショット。

    実行履歴ページが開き、選択した実行の各ステップの状態が表示されます。次に例を示します。

    従量課金ワークフローの実行履歴と、実行内の各アクションを示すスクリーンショット。

    次の表は、各ワークフローのアクションの状態として考えられるものを示しています。これらはポータルに表示されます。

    アクションの状態 Icon 説明
    Aborted [中止] アイコン 外部に問題が発生したため、アクションが停止したか、または完了しませんでした。たとえば、システムの停止や Azure サブスクリプションの中断などです。
    取り消し済み [キャンセル済み] アイコン アクションは実行中でしたが、取り消し要求を受け取りました。
    Failed 失敗時のアイコン アクションに失敗しました。
    実行中 実行中アイコン アクションは現在実行中です。
    Skipped [スキップ済み] アイコン runAfter 条件が満たされていない (例: 前のアクションが失敗した) ため、アクションはスキップされました。 各アクションの runAfter オブジェクトには、現在のアクションが実行可能になる前に満たされる必要がある条件を設定できます。
    Succeeded [成功] アイコン アクションに成功しました。
    再試行により成功 [再試行により成功] アイコン アクションは成功しましたが、1 回以上の再試行がありました。 再試行履歴を確認するには、実行履歴ページでその操作を選択し、入力と出力を表示します。
    タイムアウト [タイムアウト済み] アイコン アクションの設定によって指定されたタイムアウト制限により、アクションが停止しました。
    待機中 [待機中] アイコン 呼び出し元からの受信要求を待機している Webhook アクションに適用されます。

  4. リスト フォームで情報を表示するには、実行履歴ツール バーの [実行の詳細] を選択します。

    [ロジック アプリの実行の詳細] ウィンドウには、各ステップ、その状態、その他の情報が一覧表示されます。

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

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

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

    • 実行履歴ページで、ステップを選択して、入力、出力、そのステップで発生したエラーを表示するウィンドウを開きます。

      たとえば、ステップが失敗したワークフローがあるとします。 ステップの失敗の原因となった可能性のある入力を確認する必要があります。

      このシナリオでは、メールの送信に使用されるメール アカウントへの接続が無効、または見つからないことが原因でエラーが発生しました。

      失敗したステップの例に加えて、失敗したステップの入力、出力、エラーが選択された従量課金ワークフローの [実行履歴] ページが示されたスクリーンショット。

    • [実行履歴] ページ ツール バーで、[実行の詳細] を選択します。 開いた [ロジック アプリの実行の詳細] ウィンドウで、目的のステップを選択します。次に例を示します。

      従量課金ワークフローと [ロジック アプリの実行の詳細] という名前のウィンドウを示すスクリーンショット。このウィンドウに、失敗した手順の選択した例が表示されます。

    Note

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

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

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

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

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

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

制限と考慮事項

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

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

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

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

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

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

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

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

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

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

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

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

    [実行履歴] タブで、再送信された実行が実行リストに追加されます。

    ヒント

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

  4. 再送信された実行の終了後、入力と出力を確認するには、[実行履歴] タブで、その実行を選択します。

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

再実行アクション機能は、非シーケンシャル ワークフロー、複雑なコンカレンシー シナリオ、次の制限事項を除くほとんどのアクションに対して使用できます。

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

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

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

  3. [実行履歴] タブで、ワークフローを再実行するアクションを含む実行を選択します。

    実行履歴ページが開き、選択した実行の各ステップの状態が表示されます。

  4. 特定のアクションから開始してワークフローを再実行するには、次のいずれかのオプションを選択します。

    • ワークフローの再実行を開始するアクションを見つけ、ショートカット メニューを開き、[Submit from this action]\(このアクションから送信\) を選択します。

    • ワークフローの再実行を開始するアクションを選択します。 開いたウィンドウで、アクション名の下にある [Submit from this action]\(このアクションから送信\) を選択します。

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

    ヒント

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

監視アラートを設定する

ワークフロー内の特定のメトリックまたはしきい値の超過に基づいてアラートを発生させるには、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 に関する記事をご覧ください。

関連するコンテンツ