次の方法で共有


Azure Logic Apps で Standard ワークフローに対して Application Insights の拡張テレメトリを有効にして表示する

適用対象: Azure Logic Apps (Standard)

Application Insights では、Standard ロジック アプリ リソースに対して拡張テレメトリ収集を有効にして、収集されたデータをワークフローの実行が完了した後に確認できます。 この機能を使用すると、ワークフローに関する分析情報を簡単に取得できるようになり、また、データ ソースでのイベントのフィルター処理をより詳細に制御できるようになるため、ストレージ コストを削減できます。 これらの機能強化は、システムの正常性と動作に関する分析情報を提供するリアルタイムのパフォーマンス メトリックに焦点を当てています。 これは、早い段階で問題を事前に検出して解決するのに役立ちます。

ロジック アプリが Application Insights に接続されている場合、Live Metrics Stream を使用して、Azure portal でログ データやその他のメトリックをほぼリアルタイムで表示できます。 また、受信要求、送信要求、全体的な正常性のプロットや、トレース レベル診断のテーブルへのアクセスに役立つ視覚化も用意されています。

次の一覧では、テレメトリの改善の例を示しています。

  • トリガーとアクションのイベントにトリガーまたはアクションの種類と API 名が含まれるようになりました。これにより、特定のコネクタの使用を照会できるようになります。
  • 再試行イベントを追跡しやすくします。
  • トリガーとアクションの失敗の例外をキャプチャします。
  • ワークフローに関連しないイベントのフィルター処理をより詳細に制御します。
  • トリガーやアクションなどを含むイベントの生成方法をより詳細に制御できる高度なフィルター処理。

このガイドでは、Standard ロジック アプリの Application Insights で拡張テレメトリ収集を有効にする方法について説明します。

前提条件

  • Azure アカウントとサブスクリプション。 サブスクリプションをお持ちでない場合には、無料の Azure アカウントにサインアップしてください。

  • Application Insights のインスタンス。 このリソースは、事前、Standard ロジック アプリ作成時、またはロジック アプリのデプロイ後に作成します。

  • Azure portal または Visual Studio Code での Standard ロジック アプリとワークフロー。

    • ロジック アプリのリソースまたはプロジェクトでは、既定で有効になっている Azure Functions v4 ランタイムを使用する必要があります。

    • ロジック アプリで、診断ログとトレースのための Application Insights が有効になっている必要があります。 ロジック アプリを作成するとき、またはデプロイの後に、それを行うことができます。

Application Insights で拡張テレメトリを有効にする

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

  2. ロジック アプリのメニューの [開発ツール] で、[高度なツール] を選択します。 [高度なツール] ページで、[移動] を選択すると、Kudu ツールが開きます。

  3. [Kudu] ページで、[Debug console] (デバッグ コンソール) メニューの [CMD] を選択します。 フォルダー ディレクトリ テーブルで、次のファイルを参照し、[Edit: site/wwwroot/host.json] を選択します

  4. host.json ファイルに、次の JSON コードを追加します。

    {
       "version": "2.0",
       "extensionBundle": {
          "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
          "version": "[1, 2.00]"
       },
       "extensions": {
          "workflow": {
             "Settings": {
                "Runtime.ApplicationInsightTelemetryVersion": "v2"
             }
          }
       }
    }
    

    この構成により、既定の詳細レベルが有効になります。 その他のオプションについては、「ソースでフィルター処理を適用する」を参照してください。

Application Insights を開く

ワークフローの実行が完了して数分が経過したら、Application Insights リソースを開きます。

  1. Azure portal のロジック アプリのメニューで [設定][Application Insights] を選択します。

  2. Application Insights リソース メニューの [監視] で、[ログ] を選択します。

Application Insights で拡張ログを表示する

以下の各セクションでは、ワークフロー実行から生成された拡張テレメトリを見つけて表示できる Application Insights のテーブルについて説明します。

テーブル名 説明
要求 ワークフロー実行の以下のイベントに関する詳細:

- トリガーおよびアクション イベント
- 再試行回数
- コネクタの使用状況
トレース ワークフロー実行の以下のイベントに関する詳細:

- ワークフローの開始および終了イベント
- バッチ送信およびバッチ受信イベント
例外 ワークフロー実行での例外イベントに関する詳細
依存関係 ワークフロー実行での依存関係イベントに関する詳細

要求テーブル

Requests テーブルには、Standard ワークフロー実行での以下のイベントに関するデータを追跡するフィールドが含まれています。

  • トリガーおよびアクション イベント
  • 再試行回数
  • コネクタの使用状況

これらのフィールドにデータがどのように取り込まれるかを示すために、Request トリガーで始まり、その後に Compose アクションと Response アクションが続く、次のような Standard ワークフローの例があるとしましょう。

トリガーとアクションを含む Azure portal と Standard ワークフロー デザイナーを示すスクリーンショット。

トリガーの設定には、Custom Tracking Id という名前のパラメーターがあります。パラメーター値は、受信メッセージの本文から orderId プロパティ値をプルする式に設定されます。

Azure portal、Standard ワークフロー、要求トリガーの選択、設定タブ、カスタム追跡 ID を示すスクリーンショット。

次に、ワークフローの Compose アクション設定に、solutionName という名前の追跡プロパティが追加されます。 プロパティ値は、ロジック アプリ リソースの名前に設定されます。

Azure portal、Standard ワークフロー、作成アクションが選択され、[設定] タブ、および追跡対象プロパティを示すスクリーンショット。

Compose アクションの後に、呼び出し元に応答を返す Response アクションが続きます。

次の一覧に、Requests テーブルに対して作成して実行できるクエリの例を示します。

タスク 手順
すべてのトリガーおよびアクション イベントを表示する すべてのトリガーおよびアクション イベントのクエリ
トリガー イベントまたはアクション イベントのみを表示する トリガーまたはアクション イベントのみのクエリ
特定の操作の種類を使用してトリガーまたはアクション イベントを表示する 操作の種類によるトリガーまたはアクション イベントのクエリ
特定のワークフロー実行 ID を使用してトリガーおよびアクション イベントを表示する ワークフロー実行 ID によるトリガーおよびアクション イベントのクエリ
特定のクライアント追跡 ID を使用してトリガーおよびアクション イベントを表示する クライアント追跡 ID によるトリガーおよびアクション イベントのクエリ
特定のソリューション名を使用してトリガーおよびアクション イベントを表示する ソリューション名によるトリガーおよびアクション イベントのクエリ
再試行回数を使用してトリガーおよびアクション イベントを表示する 再試行回数に関するトリガーおよびアクション イベントのクエリ
コネクタの使用状況でトリガーおよびアクション イベントを表示する コネクタの使用状況に関するトリガーおよびアクション イベントのクエリ

すべてのトリガーおよびアクション イベントのクエリ

ワークフローが実行され、数分が経過したら、Requests テーブルに対するクエリを作成して、すべての操作イベントを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. すべてのトリガーおよびアクション イベントを表示するには、次のクエリを作成して実行します。

    requests
    | sort by timestamp desc
    | take 10
    

    次の例では、各行に注記された列とデータを含む [結果] タブが表示されています。

    ワークフロー実行の Application Insights、クエリ、結果タブ、操作イベントを示すスクリーンショット。

    説明
    name ワークフロー操作の名前 この例では、行には manual (Request トリガー)、ComposeResponse が表示されています。
    success 操作実行の状態 この例では、すべての行が、正常に実行されると [True] と表示されます。 エラーが発生した場合、値は [False] です。
    resultCode 操作実行の状態コード この例では、すべての行が [成功] (200) と表示されます。
    duration 操作の実行時間 操作ごとに異なります。
  3. 特定の操作の詳細を表示するには、トリガーまたはアクションの行を展開します。

    次の例は、Request トリガーの展開された詳細を示しています。

    Application Insights、要求トリガーの [結果] タブ、および詳細を示すスクリーンショット。

    プロパティ 説明
    カテゴリ 操作カテゴリ。操作に基づいて、常に Workflow.Operations.Triggers または Workflow.Operations.Actions のいずれかです Workflow.Operations.Triggers
    clientTrackingId カスタム追跡 ID (指定されている場合) 123456
    runId ワークフロー実行インスタンスの ID 08585358375819913417237801890CU00
    triggerName トリガー名 手動
    workflowId トリガーを実行したワークフローの ID c7711d107e6647179c2e15fe2c2720ce
    workflowName トリガーを実行したワークフローの名前 Request-Response-Workflow
    operation_Name トリガーを実行した操作の名前。 この場合、この名前はワークフロー名と同じです。 Request-Response-Workflow
    operation_Id 先ほど実行したコンポーネントまたはワークフローの ID。 この ID は、ワークフロー実行インスタンスの runId 値と同じです。 例外または依存関係が存在する場合、この値はテーブルを超えるので、このトリガー レコードをそれらの例外または依存関係にリンクできます。 08585358375819913417237801890CU00
    operation_ParentId トリガーを呼び出したワークフローのリンク可能な ID f95138daff8ab129

    次の例は、Compose アクションの展開された詳細を示しています。

    Application Insights、作成アクションの [結果] タブ、および詳細を示すスクリーンショット。

    プロパティ 説明
    カテゴリ 操作カテゴリ。操作に基づいて、常に Workflow.Operations.Triggers または Workflow.Operations.Actions のいずれかです Workflow.Operations.Actions
    clientTrackingId カスタム追跡 ID (指定されている場合) 123456
    actionName Action name Compose
    runId ワークフロー実行インスタンスの ID 08585358375819913417237801890CU00
    workflowId アクションを実行したワークフローの ID c7711d107e6647179c2e15fe2c2720ce
    workflowName アクションを実行したワークフローの名前 Request-Response-Workflow
    solutionName 追跡対象のプロパティ名 (指定されている場合) LA-AppInsights
    operation_Name アクションを実行した操作の名前。 この場合、この名前はワークフロー名と同じです。 Request-Response-Workflow
    operation_Id 先ほど実行したコンポーネントまたはワークフローの ID。 この ID は、ワークフロー実行インスタンスの runId 値と同じです。 例外または依存関係が存在する場合、この値はテーブルを超えるので、このアクション レコードをそれらの例外または依存関係にリンクできます。 08585358375819913417237801890CU00
    operation_ParentId アクションを呼び出したワークフローのリンク可能な ID f95138daff8ab129

トリガーまたはアクション イベントのみのクエリを実行する

Requests テーブルに対するクエリを作成して、操作カテゴリとワークフロー名に基づいて操作イベントのサブセットを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. 特定のワークフロー内のすべてのトリガー イベントを表示するには、customDimensions.Category プロパティ値を Workflow.Operations.Triggers に設定し、operation_Name をワークフロー名に設定したクエリを作成して実行します。次に例を示します。

    requests
    | where customDimensions.Category == "Workflow.Operations.Triggers" and operation_Name == "Request-Response-Workflow"
    

    トリガーのみの Requests テーブル クエリを示すスクリーンショット。

  3. 特定のワークフロー内のすべてのアクション イベントを表示するには、customDimensions.Category プロパティ値を Workflow.Operations.Actions に設定し、operation_Name をワークフロー名に設定したクエリを作成します。次に例を示します。

    requests
    | where customDimensions.Category == "Workflow.Operations.Actions" and operation_Name == "Request-Response-Workflow"
    

    アクションのみの Requests テーブル クエリを示すスクリーンショット。

操作の種類によるトリガーまたはアクション イベントのクエリ

特定のトリガーまたはアクションの種類のイベントを表示する、Requests テーブルに対するクエリを作成できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. 特定のトリガーの種類に該当するすべての操作イベントを表示するには、customDimensions.triggerType 値を目的のトリガーの種類に設定したクエリを作成して実行します。次に例を示します。

    requests
    | where customDimensions.triggerType == "Request"
    

    要求トリガーの種類に対する Requests テーブル クエリを示すスクリーンショット。

  3. 特定のアクションの種類に該当するすべての操作イベントを表示するには、customDimensions.actionType 値を目的のアクションの種類に設定したクエリを作成して実行します。次に例を示します。

    requests
    | where customDimensions.actionType == "Compose"
    

    作成アクションの種類に対する Requests テーブル クエリを示すスクリーンショット。

ワークフロー実行 ID によるトリガーおよびアクション イベントのクエリ

Requests テーブルに対するクエリを作成して、ワークフロー実行 ID に基づいて操作イベントのサブセットを表示できます。 このワークフロー実行 ID は、ワークフローの実行履歴に見つかるのと同じ ID です。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. 特定のワークフロー実行 ID を持つすべての操作イベントを表示するには、operation_Id 値をワークフロー実行 ID に設定したクエリを作成して実行します。次に例を示します。

    requests
    | where operation_Id == "08585287554177334956853859655CU00"
    

    ワークフロー実行 ID に基づく要求テーブル クエリを示すスクリーンショット。

クライアント追跡 ID によるトリガーおよびアクション イベントのクエリ

Requests テーブルに対するクエリを作成して、ワークフロー名とクライアント追跡 ID に基づいて操作イベントのサブセットを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. 特定のワークフロー内の特定のクライアント追跡 ID を持つすべての操作イベントを表示するには、operation_Name 値をワークフロー名に設定し、clientTrackingId プロパティ値を目的の値に設定したクエリを作成して実行します。次に例を示します。

    requests
    | where operation_Name == "Request-Response-Workflow"
    | extend correlation = todynamic(tostring(customDimensions.correlation))
    | where correlation.clientTrackingId == "123456"
    

    操作名とクライアント追跡 ID を使用したクエリ結果を示すスクリーンショット。

ソリューション名によるトリガーおよびアクション イベントのクエリ

Requests テーブルに対するクエリを作成して、ワークフロー名とソリューション名に基づいて操作イベントのサブセットを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. 特定のワークフロー内の特定のクライアント追跡 ID を持つすべての操作イベントを表示するには、operation_Name 値をワークフロー名に設定し、solutionName プロパティ値を目的の値に設定したクエリを作成して実行します。次に例を示します。

    requests
    | where operation_Name == "Request-Response-Workflow" and customDimensions has "trackedProperties"
    | extend trackedProperties = todynamic(tostring(customDimensions.trackedProperties))
    | where trackedProperties.solutionName == "LA-AppInsights"
    

    操作名とソリューション名を使用したクエリ結果を示すスクリーンショット。

再試行回数

このデータが Requests テーブルにどのように取り込まれるかを示すために、次の Standard ワークフローの例では、URL を呼び出す HTTP アクションを使用しますが、これは解決されません。 ワークフローには、60 秒ごとに 3 回再試行する固定間隔に設定された再試行ポリシーもあります。

Azure portal、Standard ワークフロー、選択された HTTP アクション、設定タブ、再試行ポリシーを示すスクリーンショット。

再試行回数に関するトリガーおよびアクション イベントのクエリ

Requests テーブルに対するクエリを作成して、再試行回数を使用して操作イベントのサブセットを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. 再試行履歴があるトリガーおよびアクション イベントのみを表示するには、Application Insights で次のクエリを作成して実行します。

    requests
    | extend retryHistory = tostring(tostring(customDimensions.retryHistory))
    | where isnotempty(retryHistory)
    
  3. 再試行ポリシーを使用して特定の操作の再試行回数を表示するには、その操作の行を展開します。

    次の例は、HTTP アクションの展開された詳細を示しています。

    Application Insights、HTTP アクションの [結果] タブ、および詳細を示すスクリーンショット。

    success および resultCode プロパティ値は、HTTP アクションが失敗したことを示します。 Requests テーブルに対する「すべてのトリガーおよびアクション イベントのクエリ」で説明されているプロパティと共に、レコードには次の情報が含まれています。これには、3 回の再試行が含まれます。

    プロパティ 説明
    retryHistory 1 回以上の再試行回数についての履歴の詳細
    code 特定の再試行回数に該当するエラーの種類
    error 発生した特定のエラーに関する詳細

コネクタの使用状況に関するトリガーおよびアクション イベントのクエリ

Requests テーブルに対するクエリを作成して、特定のコネクタの使用状況に基づいて操作イベントのサブセットを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. 特定のコネクタの種類を使用してすべてのトリガー イベントを表示するには、次のプロパティと値を使用してクエリを作成して実行します。

    requests
    | where customDimensions.Category == "Workflow.Operations.Triggers" and customDimensions.triggerType =="ApiConnectionWebhook" and customDimensions.apiName =="commondataservice"
    
    プロパティ 値の例
    customDimensions.Category Workflow.Operations.Triggers
    customDimensions.triggerType 操作の種類 (例: ApiConnectionWebhook)
    customDimensions.apiName JSON 形式でのコネクタの API 名 (例: Microsoft Dataverse コネクタの commondataservice)

    ApiConnectionWebhook 接続を使用した Microsoft Dataverse トリガー イベントの Application Insights の [結果] タブを示すスクリーンショット。

  3. 特定のコネクタの使用状況に該当するすべてのアクション イベントを表示するには、customDimensions.Category 値を Workflow.Operations.Actions に設定し、customDimensions.triggerType 値を操作の種類に設定し、customDimensions.apiName を JSON 形式でのコネクタの API 名に設定したクエリを作成して実行します。次に例を示します。

    プロパティ 値の例
    customDimensions.Category Workflow.Operations.Actions
    customDimensions.triggerType 操作の種類 (例: ApiConnection)
    customDimensions.apiName JSON 形式でのコネクタの API 名 (例: Microsoft Office 365 Outlook コネクタの office365)
    requests
    | where customDimensions.Category == "Workflow.Operations.Actions" and customDimensions.actionType == "ApiConnection" and customDimensions.apiName == "office365"
    

    ApiConnection 接続を使用した Microsoft Office 365 Outlook アクション イベントの Application Insights の [結果] タブを示すスクリーンショット。

Application Insights では、トリガーとアクションの両方で、存在する接続の種類が区別されます。 actionTypetriggerType フィールドには、接続に ApiConnectionApiConnectionWebhookRequest のような組み込みの基本的な種類、またはサービス プロバイダー ベースの ServiceProvider の種類があるかどうかに基づいて、さまざまな値が表示される可能性があります。

トレース テーブル

Traces テーブルには、Standard ワークフロー実行の以下のイベントに関するデータを追跡するフィールドが含まれています。

  • ワークフローの開始および終了イベント

    この情報は、実行時間の長いワークフロー実行の可能性があるため、2 つの異なるイベントとして表されます。

  • バッチ送信および受信イベント

    詳細については、「Azure Logic Apps での組み込みバッチ操作の使用 (Standard)」を参照してください

次の一覧に、Traces テーブルに対して作成して実行できるクエリの例を示します。

タスク 手順
すべてのワークフロー実行での開始および終了イベントを表示する すべてのワークフロー実行での開始および終了イベントのクエリ
特定のワークフロー実行での開始および終了イベントを表示する ワークフロー実行での開始および終了イベントのクエリ
すべてのワークフロー実行でのバッチ送信および受信イベントを表示する すべてのワークフロー実行でのバッチ送信およびバッチ受信イベントのクエリ

すべてのワークフロー実行での開始および終了イベントのクエリ

Traces テーブルに対するクエリを作成して、すべてのワークフロー実行のすべての開始および終了イベントを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. customDimensions.Category 値を Workflow.Operations.Runs に設定したクエリを作成して実行します。次に例を示します。

    traces
    | where customDimensions.Category == "Workflow.Operations.Runs"
    

    すべてのワークフロー実行の開始とイベントの Application Insights の [結果] タブを示すスクリーンショット。

特定のワークフロー実行での開始および終了イベントのクエリ

Traces テーブルに対するクエリを作成して、特定のワークフロー実行の開始および終了イベントを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. customDimensions.Category 値を Workflow.Operations.Runs に設定し、operation_Id 値をワークフロー実行 ID に設定したクエリを作成して実行します。次に例を示します。

    traces
    | where customDimensions.Category == "Workflow.Operations.Runs"
    | and operation_Id == "08585287571846573488078100997CU00"
    

    Application Insights、開始用の [結果] タブ、および特定の実行のイベントを示すスクリーンショット。

すべてのワークフロー実行でのバッチ送信およびバッチ受信イベントのクエリ

Traces テーブルに対するクエリを作成して、すべてのワークフロー実行のバッチ送信および受信イベントを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. customDimensions.Category 値を Workflow.Operations.Runs に設定し、operation_Id 値をワークフロー実行 ID に設定したクエリを作成して実行します。次に例を示します。

    traces
    | where customDimensions.Category == "Workflow.Operations.Batch"
    

    すべてのワークフロー実行でのバッチ送信とバッチ受信イベントの Application Insights の [結果] タブを示すスクリーンショット。

例外テーブル

Exceptions テーブルには、Standard ワークフロー実行の例外イベントに関するデータを追跡するフィールドが含まれています。 これらのフィールドにデータがどのように取り込まれるかを示すために、Request トリガーで始まり、その後に Compose アクションと Response アクションが続く、次のような Standard ワークフローの例があるとしましょう。 Compose アクションでは、値を 0 で除算する式が使用され、例外が生成されます。

Azure portal、Standard ワークフロー デザイナー、要求トリガー、例外生成式を使用した作成アクション、および応答アクションを示すスクリーンショット。

すべてのワークフロー実行での例外イベントのクエリ

Exceptions テーブルに対するクエリを作成して、すべてのワークフロー実行での例外イベントを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. すべての例外イベントを表示するには、Application Insights で次のクエリを作成して実行します。

    exceptions
    | sort by timestamp desc
    
  3. 特定の例外の詳細を表示するには、その例外の行を展開します。

    次の例は、Compose アクションの展開された例外と、例外に関する詳細を示しています。

    Application Insights、例外イベントの [結果] タブ、および作成アクションの例外イベントが展開され、例外の詳細を示すスクリーンショット。

    プロパティ 説明
    problemId 例外の種類、または発生した例外に関する簡単な説明
    outerMessage 例外に関する詳細な説明
    詳細 例外に関する詳細で最も完全な情報
    clientTrackingId クライアント追跡 ID (指定されている場合)
    workflowId 例外が発生したワークフローの ID
    workflowName 例外が発生したワークフローの名前
    runId ワークフロー実行インスタンスの ID
    actionName 例外で失敗したアクションの名前
    operation_Name 例外が発生したワークフローの名前
    operation_Id 先ほど実行したコンポーネントまたはワークフローの ID。 この ID は、ワークフロー実行インスタンスの runId 値と同じです。 この値はテーブルを超えるので、この例外レコードをワークフロー実行インスタンスにリンクできます。
    operation_ParentId アクションを呼び出したワークフローの ID。これを Requests テーブル内のアクションの ID にリンクできます
  4. 特定のワークフローの例外を表示するには、次のクエリを作成して実行します。

    exceptions
    | where operation_Name contains "Request-Response-Workflow-Exception"
    

依存関係テーブル

Dependencies テーブルには、Standard ワークフロー実行の依存関係イベントに関するデータを追跡するフィールドが含まれています。 これらのイベントは、あるリソースが別のリソースを呼び出すとき、および両方のリソースが Application Insights を使用するときに生成されます。 Azure Logic Apps の例には、HTTP 経由で別のサービスを呼び出すサービス、データベース、またはファイル システムが含まれます。 Application Insights は、依存関係呼び出しの継続時間と、それらの呼び出しが成功したか失敗したかを、依存関係名などの情報と共に測定します。 特定の依存関係呼び出しを調査し、要求や例外に関連付けることができます。

これらのフィールドにデータがどのように取り込まれるかを示すために、HTTP アクションを使用して HTTP 経由で子ワークフローを呼び出す Standard 親ワークフローの例があるとしましょう。

HTTP アクションを使用して子ワークフローを呼び出す親ワークフローを持つ Azure portal の Standard ワークフロー デザイナーを示すスクリーンショット。

特定のワークフローでの依存関係イベントのクエリ

Dependencies テーブルに対するクエリを作成して、特定のワークフロー実行での依存関係イベントを表示できます。

  1. 必要に応じて、確認する時間範囲を選択します。 既定では、この値は過去 24 時間です。

  2. 親ワークフローと子ワークフローの間の依存関係イベントを表示するには、次のクエリを作成して実行します。

    union requests, dependencies
    | where operation_Id contains "<runId>"
    

    このクエリでは、union 演算子を使用して、Requests テーブルと Dependencies テーブルからレコードを返します。 また、クエリでは、operation_Id プロパティ値を使用し、必要なワークフロー runId 値を指定してレコード間のリンクを提供します。次に例を示します。

    union requests, dependencies
    | where operation_Id contains "08585355753671110236506928546CU00"
    

    次の例は、指定したワークフローの依存関係イベントを示しています。これには、Requests テーブルからの親ワークフローでの操作イベントのレコードと、Dependencies テーブルの依存関係レコードが含まれます。

    特定のワークフローの依存関係イベントを含む Application Insights の [結果] タブを示すスクリーンショット。

    操作イベント レコードの場合、itemType 列にはレコードの種類が request として表示されます。 依存関係レコードの場合、itemType 列はレコードの種類を dependency として示します。

    プロパティ 説明
    runId ワークフロー実行インスタンスの ID
    actionName 依存関係イベントが発生するアクションの名前
    operation_Id 指定したワークフローの ID。 この ID は、ワークフロー実行インスタンスの runId 値と同じです。 この値はテーブルを超えるので、この依存関係レコードをワークフロー実行インスタンスにリンクできます。
    operation_ParentId 依存関係イベントが発生するアクションの ID。操作イベント レコードと依存関係イベント レコードをリンクするものでもあります

クエリを使用して、Application Insights でアプリケーション マップを使用するときに、親ワークフローから子ワークフローへの依存関係の呼び出しを視覚化することもできます。 クエリの operation_Id 値は、この視覚化を可能にするリンクを提供します。

アプリケーション マップを開くには、Application Insights リソース メニューの [調査][アプリケーション マップ] を選択します。

親ワークフローと子ワークフローの間の依存関係を持つ Application Insights とアプリケーション マップを示すスクリーンショット。

イベントのフィルター処理

Application Insights では、次の方法でイベントをフィルター処理できます。

  • 前のセクションで説明したように、クエリを作成して実行します。

  • イベントを生成する前に評価する条件を指定して、ソースでフィルター処理します。

    ソースでフィルターを適用することで、必要なストレージの量を減らし、その結果、運用コストを削減できます。

ソースでフィルター処理を適用する

Requests テーブルまたはTraces テーブルでは、レコードには customDimensions という名前のノードがあり、Category プロパティが含まれています。 たとえば、Requests テーブルでは、Batch トリガー イベントの要求レコードは次の例のようになります。

バッチ メッセージ トリガー イベントの Application Insights と Requests テーブルとレコードを示すスクリーンショット。

Requests テーブルでは、次の Category プロパティ値を使用して、さまざまな詳細レベルを区別して関連付けることができます。

Category 値 説明
Workflow.Operations.Triggers トリガー イベントの要求レコードを識別します
Workflow.Operations.Actions アクション イベントの要求レコードを識別します

Category 値ごとに、ロジック アプリ リソースまたはプロジェクトの host.json ファイルで詳細レベルを個別に設定できます。 たとえば、エラーが発生したトリガーまたはアクション イベントのレコードのみを返すには、host.json ファイルに次の logging JSON オブジェクトを追加できます。これには、必要な詳細レベルを持つ logLevel JSON オブジェクトが含まれます。

{
   "logging": {
      "logLevel": {
         "Workflow.Operations.Actions": "Error",
         "Workflow.Operations.Triggers": "Error"
      }
   }
}

Traces テーブル レコードの場合、次の例は、イベントの詳細レベルを変更する方法を示しています。

{
   "logging": {
      "logLevel": {
         "Workflow.Host": "Warning",
         "Workflow.Jobs": "Warning",
         "Workflow.Runtime": "Warning"
      }
   }
}

次の例では、ログの既定の詳細レベルを Warning に設定しますが、トリガー、アクション、ワークフロー実行イベントの詳細レベルは Information に維持します。

{
   "logging": {
      "logLevel": {
         "default": "Warning",
         "Workflow.Operations.Actions": "Information",
         "Workflow.Operations.Runs": "Information",
         "Workflow.Operations.Triggers": "Information"
      }
   }
}

logLevel 値を指定しない場合、既定の詳細レベルは Information です。 詳細については、「ログ レベルを構成する」を参照してください。

ストレージ依存関係のエラーを除外する

404 見つかりません」エラーや「412 前提条件が満たされていません」エラーなどのストレージ依存関係エラーを除外するには、Host.Workflow ログ レベルを None に設定します。

{
   "logging": {
      "logLevel": {
         "Workflow.Host": "Warning",
         "Workflow.Jobs": "Warning",
         "Workflow.Runtime": "Warning",
         "Host.Workflow": "None"
      }
   }
}
  1. Azure portal で、Standard ロジック アプリ リソースを開きます。

  2. ロジック アプリのメニューの [開発ツール] で、[高度なツール] を選択します。 [高度なツール] ページで、[移動] を選択すると、Kudu ツールが開きます。

  3. [Kudu] ページで、[Debug console] (デバッグ コンソール) メニューの [CMD] を選択します。 フォルダー ディレクトリ テーブルで、次のファイルを参照し、[Edit: site/wwwroot/host.json] を選択します

  4. host.json ファイルで、logLevel 値を目的の詳細レベルに設定した logging JSON オブジェクトを追加します。

    {
       "logging": {
          "logLevel": {
             "Workflow.Operations.Actions": "<verbosity-level>",
             "Workflow.Operations.Triggers": "<verbosity-level>"
          }
       }
    }
    

Application Insights でワークフロー メトリックを表示する

Application Insights のテレメトリの機能強化により、メトリック ダッシュボードでワークフローの分析情報を取得することもできます。

メトリック ダッシュボードを開いて基本的なフィルターを設定する

  1. Azure portal で、まだ開いていない場合は Application Insights のリソースを開きます。

  2. Application Insights リソース メニューの [監視] で、[メトリック] を選択します。

  3. [スコープ] の一覧から、Application Insights インスタンスを選択します。

  4. [メトリック名前空間] の一覧から、workflow.operations を選択します。

  5. [メトリック] の一覧から、メトリック ([完了した実行] など) を選択します。

  6. [集計] の一覧から、CountAvg などの種類を選択します。

    完了すると、メトリック ダッシュボードに、完了したワークフロー実行を含むグラフが表示されます。

    メトリック ダッシュボードを含む Application Insights と、時間の経過に伴う完了したワークフロー実行の数を示すグラフを示すスクリーンショット。

特定のワークフローに基づいてフィルター処理する

メトリック ダッシュボードで多次元メトリックを有効にすると、Application Insights で取得されたイベント全体のサブセットを対象にして、特定のワークフローに基づいてイベントをフィルター処理できます。

  1. Application Insights リソースで、多次元メトリックを有効にします

  2. Application Insights で、メトリック ダッシュボードを開きます

  3. グラフ ツール バーで、[フィルターの追加] を選択します。

  4. [プロパティ] の一覧から、[ワークフロー] を選択します。

  5. [演算子] の一覧から等号 (=) を選択します。

  6. [値] の一覧から、目的のワークフローを選択します。

    メトリック ダッシュボードと多次元メトリックを含む Application Insights を示すスクリーンショット。

"ライブ" ログ データとメトリックを表示する

Application Insights の拡張テレメトリを有効にすると、Azure portal で Application Insights インスタンスからほぼリアルタイムのログ データやその他のメトリックを表示できます。 この視覚化を使用して、受信要求、送信要求、全体的な正常性をプロットできます。 トレース レベル診断用のテーブルもあります。

  1. Azure portal で、まだ開いていない場合は Application Insights のリソースを開きます。

  2. Application Insights リソース メニューの [調査] で、[ライブ メトリック] を選択します。

    [ライブ メトリック] ページには、ログ データとその他のメトリックが表示されます。次に例を示します。

    Live メトリックという名前の項目が選択された Azure portal と Application Insights メニューを示すスクリーンショット。

詳細については、「 ライブメトリック: 1秒の待機時間のモニターと 診断」を参照してください。

Note

Standard ロジック アプリ ワークフローは Azure Functions に基づいているので、[ライブ メトリック] ではこれらのロジック アプリ ワークフローがサポートされます。

アプリケーション ログ ファイルからのデバッグ出力のストリーミングと表示

Application Insights の拡張テレメトリを有効にすると、Azure portal でアプリケーションのログ ファイルの詳細なデバッグ情報をストリーミングできます。 この情報は、ローカルの Visual Studio Code 環境でのワークフローのデバッグから生成された出力と同じです。

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

  2. ロジック アプリ リソースのメニューで [監視] の下にある [ログ ストリーム] を選択します。

    [ログ ストリーム] ページが Application Insights インスタンスに接続され、デバッグ出力が表示されます。 たとえば、次の出力には、他の情報の中から要求と応答の呼び出しが含まれています。

    Log stream という名前の項目が選択されている Azure portal と Standard ロジック アプリのメニューを示すスクリーンショット。

次のステップ

Application Insights を有効にするか開く