集計ルールを使用して Log Analytics ワークスペースのデータを集計する (プレビュー)

集計ルールを使用すると、定期的にログ データを集計し、集計結果を Log Analytics ワークスペースのカスタム ログ テーブルに送信できます。 集計ルールを使用して、次の目的でデータを最適化します。

• 分析とレポート。特に、セキュリティおよびインシデント分析、月次または年次ビジネス レポートなどに必要な、大規模なデータ セットと時間の範囲が対象。 大規模なデータ セットに対する複雑なクエリは、多くの場合、タイムアウトになります。"クリーニング済み" および "集計済み"の集計データをより簡単かつ効率的に分析し、レポートできます。

• 詳細ログのコスト削減。低コストの基本ログ テーブルに必要な期間だけ保持し、集計データを分析とレポートのために分析テーブルに送信できます。

• セキュリティとデータ プライバシー。集計された共有可能なデータのプライバシーの詳細を削除または難読化し、生データを含むテーブルへのアクセスを制限することで確保します。

この記事では、集計ルールのしくみと、集計ルールを定義して表示する方法について説明し、集計ルールの使用例とメリットをいくつか紹介します。

次のビデオは、要約ルールの利点の一部の概要を提供します。

集計ルールのしくみ

集計ルールでは、バッチ処理が、Log Analytics ワークスペースで直接実行されます。 集計ルールでは、KQL クエリに基づいて、ビン サイズによって定義されたデータ チャンクが集計され、集計結果が、Analytics ログ プランと共に Log Analytics ワークスペースのカスタム テーブルに再度取り込まれます。

テーブルに含まれるのが 分析データ プランか基本データ プランかに関係なく、どのテーブルのデータでも集計できます。 Azure Monitor により、定義したクエリに基づいてターゲット テーブル スキーマが作成されます。 ターゲット テーブルが既に存在する場合、Azure Monitor によって、クエリ結果をサポートするのに必要な列が追加されます。 また、すべてのターゲット テーブルに、次のような集計ルール情報を含む一連の標準フィールドが含まれます。

• _RuleName: 集計ログ エントリを生成した集計ルール。
• _RuleLastModifiedTime: ルールの最終更新日時。
• _BinSize: 集計間隔。
• _BinStartTime: 集計の開始時刻。

最大 30 個のアクティブなルールを構成して、複数のテーブルのデータを集計し、集計データを個別のターゲット テーブルまたは同じテーブルに送信できます。

集計データをカスタム ログ テーブルからストレージ アカウントまたは Event Hubs にエクスポートするには、データ エクスポート ルールを定義します。

例: ContainerLogsV2 データを集計する

コンテナーを監視している場合は、大量の詳細ログを ContainerLogsV2 テーブルに取り込みます。

集計ルールで次のクエリを使用すると、60 分以内に一意のログ エントリをすべて集計し、分析に役立つデータを保持し、不要なデータを削除することができます。

ContainerLogV2 | summarize Count = count() by  Computer, ContainerName, PodName, PodNamespace, LogSource, LogLevel, Message = tostring(LogMessage.Message)

ContainerLogsV2 テーブルの生データを次に示します。

集計ルールがターゲット テーブルに送信する集計データを次に示します。

1 時間以内に何百もの類似エントリがログに記録されるのではなく、ターゲット テーブルには、KQL クエリで定義されているように、一意の各エントリの数が表示されます。 生データを低コストで保持するために ContainerLogsV2 テーブルで基本データ プランを設定し、分析ニーズに合わせてターゲット テーブルの集計データを使用します。

必要なアクセス許可

制限事項と制約事項

• 現在、集計ルールはパブリック クラウドでのみ使用できます。

• 集計ルールは受信データを処理します。過去の時間の範囲で構成することはできません。

• ビンの再試行が実行し尽くされると、そのビンはスキップされ、再実行できません。

• Lighthouse を使用した別のテナントでの Log Analytics ワークスペースに対するクエリはサポートされていません。

• KQL の制限は、ソース テーブルのテーブル プランによって異なります。

  • 分析: すべての KQL コマンドをサポートします。ただし、次を除きます。

    • リソース間のクエリ (workspaces()、app()、resource() 式を使用) とサービス間クエリ (ADX() および ARG() 式を使用)。
    • データ スキーマを再形成するプラグイン (bag unpack、narrow、pivot など)。

  • 基本: 1 つのテーブルですべての KQL コマンドをサポートします。 lookup 演算子を使用して、最大 5 つの分析テーブルを結合できます。

  • 関数: ユーザー定義関数はサポートされていません。 Microsoft が提供するシステム関数がサポートされています。

価格モデル

集計ルールの追加コストは発生しません。 クエリを事項するソース テーブルのテーブル プランに基づいて、クエリと、挿入先テーブルへの結果のインジェストに対してのみ課金されます。

たとえば、ビンあたり 100 レコードを返すルールの時間あたりのコスト計算は次のとおりです。

詳細については、「Azure Monitor の価格」を参照してください。

集計ルールを作成または更新する

ルールを作成する前に、Log Analytics でクエリを試します。 クエリがクエリの制限に達していないこと、または近づいていないことを確認します。 クエリによって目的のスキーマと期待される結果が生成されることを確認します。 クエリがクエリの制限に近づいている場合は、小さな binSize を使用して、ビンごとに処理するデータを減らすことを検討してください。 また、クエリを変更して、返されるレコード数を減らしたり、ボリュームが大きいフィールドを削除したりすることもできます。

クエリを更新し、結果セットから出力フィールドを削除しても、Azure Monitor によってターゲット テーブルから列が自動的に削除されることはありません。 手動で列をテーブルから削除する必要があります。

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}?api-version=2023-01-01-preview
Authorization: {credential}

{
  "properties": {
      "ruleType": "User",
      "description": "My test rule",
      "ruleDefinition": {
          "query": "StorageBlobLogs | summarize count() by AccountName",
          "binSize": 30,
          "destinationTable": "MySummaryLogs_CL"
      }
  }
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceName": {
      "type": "String",
      "metadata": {
        "description": "The workspace name where summary rule is deployed."
      }
    },
    "summaryRuleName": {
      "type": "String",
      "metadata": {
        "description": "The summary rule name."
      }
    },
    "description": {
      "type": "String",
      "metadata": {
        "description": "A description of the rule."
      }
    },
    "location": {
      "defaultValue": "[resourceGroup().location]",
      "type": "String",
      "metadata": {
        "description": "The Location of the workspace summary rule is deployed."
      }
    },
    "ruleType": {
      "defaultValue": "User",
      "allowedValues": [
        "User"
      ],
      "type": "String",
      "metadata": {
        "description": "The summary rule type (User,System). Should be 'User' for and rule with query that you define."
      }
    },
    "query": {
      "type": "String",
      "metadata": {
      "description": "The query used in summary rules."
      }
    },
    "binSize": {
      "defaultValue": 60,
      "allowedValues": [
        20,
        30,
        60,
        120,
        180,
        360,
        720,
        1440
      ],
      "type": "Int",
      "metadata": {
        "description": "The execution interval in minutes, and the lookback time range."
      }
    },
    "destinationTable": {
      "type": "String",
      "metadata": {
        "description": "The name of the custom log table that the summary results are sent to. Name must end with '_CL'."
      }
    }
    // ----- optional -----
    // "binDelay": {
    //   "type": "Int",
    //   "metadata": {
    //     "description": "Optional - The minimum wait time in minutes before bin execution. For example, value of '10' cause bin (01:00-02:00) to be executed after 02:10."
    //   }
    // },
    // "timeSelector": {
    //   "defaultValue": "TimeGenerated",
    //   "allowedValues": [
    //     "TimeGenerated"
    //   ],
    //   "type": "String",  
    //   "metadata": {
    //     "description": "Optional - The time field to be used by the summary rule. Must be 'TimeGenerated'."
    //   }
    // },
    // "binStartTime": {
    //   "type": "String",
    //   "metadata": {
    //     "description": "Optional - The Time of initial bin. Can start at current time minus binSize, or future, and in whole hours. For example: '2024-01-01T08:00'."
    //   }
    // }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.OperationalInsights/workspaces/summaryLogs",
      "apiVersion": "2023-01-01-preview",
      //"name": "[format('{0}/{1}', parameters('workspaceName'), parameters('summaryRuleName'))]",
      "name": "[concat(parameters('workspaceName'), '/', parameters('summaryRuleName'))]",
      "properties": {
        "ruleType": "[parameters('ruleType')]",
        "description": "[parameters('description')]",
        "ruleDefinition": {
          "query": "[parameters('query')]",
          "binSize": "[parameters('binSize')]",
          "destinationTable": "[parameters('destinationTable')]"
          // ----- optional -----
          //"binDelay": "[parameters('binDelay')]",
          //"timeSelector": "[parameters('timeSelector')]",
          //"binStartTime": "[parameters('binStartTime')]"
        }
      }
    }
  ]
}

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "workspaceName": {
      "value": "myworkspace"
    },
    "summaryRuleName": {
      "value": "myrulename"
    },
    "description": {
      "value": "My rule description."
    },
    "location": {
      "value": "eastus" //Log Analytics workspace region
    },
    "ruleType": {
      "value": "User"
    },
    "query": {
      "value": "StorageBlobLogs | summarize Count = count(), DurationMs98 = percentile(DurationMs, 90) by StatusCode, CallerIpAddress, OperationName"
    },
    "binSize": {
      "value": 20
    },
    "destinationTable": {
      "value": "MySummaryLogs_CL"
    }
  }
}

次の表では、集計ルールのパラメーターについて説明します。

集計のタイミングを構成する

既定では、集計ルールによって、次の 1 時間の直後に最初の集計が作成されます。

Azure Monitor が追加する短い延期時間では、インジェストの待ち時間、つまり監視対象システムでデータが作成されてから、Azure Monitor で分析に使用できるようになるまでの時間が考慮されます。 既定では、この延期時間は、各データ チャンクを集計する前の 3 分半から binSize 値の 10% の間です。 ほとんどの場合、この延期時間によって、各ビンの期間内にログに記録されたすべてのデータが、Azure Monitor で確実に集計されるようになります。

次に例を示します。

• ビン サイズが 30 分の集計ルールを 14:44 に作成します。

  このルールでは、15:00 の直後、たとえば 15:04 に、14:30 から 15:00 の間にログに記録されたデータに対する最初の集計が作成されます。

• ビン サイズが 720 分 (12 時間) の集計ルールを 14:44 に作成します。

  このルールでは、15:00 の 72 分後 (720 ビン サイズの 10%) である 16:12 に、03:00 から 15:00 の間にログに記録されたデータに対する最初の集計が作成されます。

binStartTime パラメーターと binDelay パラメーターを使用して、最初の集計のタイミングと、各集計の前に Azure Monitor が追加する延期時間を変更します。

次のセクションでは、既定の集計のタイミングと、より詳細な集計のタイミングのオプションの例を示します。

既定の集計のタイミングを使用する

この例では、集計ルールは 2023-06-07 の 14:44 に作成され、Azure Monitor によって既定の延期時間 4 分が追加されます。

オプションの集計のタイミング パラメーターを設定する

この例では、集計ルールは 2023-06-07 の 14:44 に作成され、ルールには次の詳細な構成設定が含まれています。

• binStartTime: 2023-06-08 07:00
• binDelay: 8 分

集計ルールを表示する

特定の集計ルールの構成を表示するには、次の GET API 呼び出しを使用しします。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName1}?api-version=2023-01-01-preview
Authorization: {credential}

Log Analytics ワークスペース内のすべての集計ルールの構成を表示するには、次の GET API 呼び出しを使用します。

GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs?api-version=2023-01-01-preview
Authorization: {credential}

集計ルールを停止して再起動する

一定の期間、たとえば、データがテーブルに取り込まれたことを確認したい場合、集計されたテーブルやレポートに影響を与えたくないときに、ルールを停止することができます。 ルールを再起動すると、Azure Monitor によって、次の 1 時間から、または定義された binStartTime (オプション) パラメーターに基づいてデータの処理が開始されます。

ルールを停止するには、次の POST API 呼び出しを使用します。

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}/stop?api-version=2023-01-01-preview
Authorization: {credential}

ルールを再起動するには、次の POST API 呼び出しを使用します。

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}/start?api-version=2023-01-01-preview
Authorization: {credential}

集計ルールを削除する

Log Analytics ワークスペースには、最大 30 個のアクティブな集計ルールを含めることができます。 新しいルールを作成したいときに、既に 30 個のアクティブなルールがある場合は、アクティブな集計ルールを停止または削除する必要があります。

ルールを削除するには、次の DELETE API 呼び出しを使用します。

DELETE https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourcegroup}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/summarylogs/{ruleName}?api-version=2023-01-01-preview
Authorization: {credential}

集計ルールを監視する

集計ルールを監視するには、Log Analytics ワークスペースの診断設定で概要ログ カテゴリを有効にします。 Azure Monitor によって、集計ルール実行の詳細、たとえば集計ルール実行の開始、成功、失敗に関する情報が、ワークスペースの LASummaryLogs テーブルに送信されます。

次に示すように、ビンが失敗したとき、またはビン実行のタイムアウトに近づいたときに通知を受け取るように、ログ アラート ルールを設定することをお勧めします。 失敗の理由に応じて、各実行で処理されるデータが少なくなるようにビン サイズを小さくするか、クエリを変更して、より少ないレコードまたはフィールドが、より大きなボリュームで返されるようにします。

次のクエリは、失敗した実行を返します。

LASummaryLogs | where Status == "Failed"

次のクエリは、QueryDurationMs 値が 0.9 x 600,000 ミリ秒を超えるビンの実行を返します。

LASummaryLogs | where QueryDurationMs > 0.9 * 600000

データの完全性を確認する

集計ルールはスケールを考慮して設計されており、たとえば、クエリ制限に関連する一時的なサービスまたはクエリの失敗を克服するための再試行メカニズムが含まれます。 再試行メカニズムでは、失敗したビンの集計が 8 時間以内に 10 回試行され、試行され尽くしたら、ビンがスキップされます。 ルールは isActive: false に設定され、8 回連続してビンの再試行が行われた後、保留になります。 集計ルールの監視を有効にすると、Azure Monitor によって、イベントがワークスペースの LASummaryLogs テーブルのログに記録されます。

失敗したビン実行を再実行することはできませんが、次のクエリを使用すると、失敗した実行を表示できます。

let startTime = datetime("2024-02-16");
let endtTime = datetime("2024-03-03");
let ruleName = "myRuleName";
let stepSize = 20m; // The stepSize value is equal to the bin size defined in the rule
LASummaryLogs
| where RuleName == ruleName
| where Status == 'Succeeded'
| make-series dcount(BinStartTime) default=0 on BinStartTime from startTime to endtTime step stepSize
| render timechart

次のクエリでは、結果が時間グラフとしてレンダリングされます。

ルールの修復オプションとプロアクティブなアラートについては、「集計ルールを監視する」セクションを参照してください。

カスタマー マネージド キーを使用して集計ルールを暗号化する

KQL クエリでは、コメントまたはクエリ構文に機密情報を含めることができます。 集計ルールのクエリを暗号化するには、ストレージ アカウントを Log Analytics ワークスペースにリンクし、カスタマー マネージド キーを使用します。

暗号化されたクエリを使用する場合の考慮事項:

• ストレージ アカウントをリンクしてクエリを暗号化しても、既存のルールは中断されません。
• 既定では、Azure Monitor によって、集計ルールのクエリが Log Analytics ストレージに保存されます。 既存の集計ルールがある場合は、ストレージ アカウントを Log Analytics ワークスペースにリンクする前に、集計ルールを更新して、既存のクエリがストレージ アカウントに保存されるようにします。
• ストレージ アカウントに保存したクエリは、CustomerConfigurationStoreTable テーブルに配置されます。 これらのクエリはサービスの成果物と見なされ、その形式は変更される可能性があります。
• 集計ルール クエリ、Log Analytics に保存されたクエリ、およびログ アラートには、同じストレージ アカウントを使用できます。

集計ルールのトラブルシューティング

このセクションでは、集計ルールのトラブルシューティングに関するヒントを提供します。

集計ルールのターゲット テーブルが誤って削除された

集計ルールがアクティブな状態でターゲット テーブルを削除すると、そのルールは中断され、ルールが中断されたことを示すメッセージを含むイベントが、Azure Monitor によって LASummaryLogs テーブルに送信されます。

ターゲット テーブルに集計結果が必要ない場合は、ルールとテーブルを削除してください。 集計結果を回復する必要がある場合は、「集計ルールを作成または更新する」セクションの手順に従ってテーブルを再作成します。 ターゲット テーブルは、削除前に取り込まれたデータを含め、テーブル内のアイテム保持ポリシーに応じて復元されます。

ターゲット テーブルに集計結果が必要ない場合は、ルールとテーブルを削除してください。 集計結果が必要な場合は、「集計ルールを作成または更新する」セクションの手順に従って、ターゲット テーブルを再作成し、すべてのデータ (削除前に取り込まれたデータを含む) を、テーブル内のアイテム保持ポリシーに応じて復元します。

ターゲット テーブルに新しい列を作成する演算子をクエリで使用する

ターゲット テーブル スキーマは、集計ルールを作成または更新するときに定義されます。 集計ルールのクエリに、受信データに基づいて出力スキーマの拡張を許可する演算子が含まれている場合 (たとえば、クエリで arg_max(expression, *) 関数が使用されている場合)、集計ルールを作成または更新した後、Azure Monitor によって新しい列がターゲット テーブルに追加されません。これらの列を必要とする出力データは削除されます。 新しいフィールドをターゲット テーブルに追加するには、集計ルールを更新するか、手動で列をテーブルに追加します。

削除された列のデータは、テーブルのデータ保持設定に基づいて、ワークスペースに残ります

クエリで列を削除すると、列とデータは宛先テーブルに残り、テーブルまたはワークスペースで定義された保持期間に基づきます。 削除したものが宛先テーブルで必要ない場合は、テーブル スキーマから列を削除します。 その後、同じ名前の列を追加すると、保持期間を過ぎていないデータが再び表示されます。

関連するコンテンツ

• Azure Monitor ログのデータ プランの詳細について、ご確認ください。
• Log Analytics での KQL モードの使用に関するチュートリアルを行います。
• 完全な KQL のリファレンス ドキュメントにアクセスします。