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

[アーティクル]
11/17/2024

集計ルールを使用すると、定期的にログデータを集計し、集計結果を 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 テーブルで基本データプランを設定し、分析ニーズに合わせてターゲットテーブルの集計データを使用します。

必要なアクセス許可

アクション	必要なアクセス許可
集計ルールを作成または更新する	たとえば、Log Analytics 共同作成者組み込みロールによって提供される、Log Analytics ワークスペースに対する `Microsoft.Operationalinsights/workspaces/summarylogs/write` 権限
ターゲットテーブルを作成または更新する	たとえば、Log Analytics 共同作成者組み込みロールによって提供される、Log Analytics ワークスペースに対する `Microsoft.OperationalInsights/workspaces/tables/write` 権限
ワークスペースでのクエリ操作を有効にする	たとえば、Log Analytics 閲覧者組み込みロールによって提供される、Log Analytics ワークスペースに対する `Microsoft.OperationalInsights/workspaces/query/read` 権限
ワークスペースのすべてのテーブルに対してクエリを実行する	たとえば、Log Analytics 閲覧者組み込みロールによって提供される、Log Analytics ワークスペースに対する `Microsoft.OperationalInsights/workspaces/query/*/read` 権限
テーブルのログに対してクエリを実行する	たとえば、Log Analytics 閲覧者組み込みロールによって提供される、Log Analytics ワークスペースに対する `Microsoft.OperationalInsights/workspaces/query/<table>/read` 権限
テーブルのログに対してクエリを実行する (テーブルアクション)	たとえば、Log Analytics 閲覧者組み込みロールによって提供される、Log Analytics ワークスペースに対する `Microsoft.OperationalInsights/workspaces/tables/query/read` 権限
カスタマーマネージドストレージアカウントで暗号化されたクエリを使用する	ストレージアカウント共同作成者の組み込みロールによって提供される、ストレージアカウントに対する `Microsoft.Storage/storageAccounts/*` アクセス許可。例:

実装の考慮事項

ワークスペース内のアクティブなルールの最大数は 30 です。
現在、集計ルールはパブリッククラウドでのみ使用できます。
集計ルールは受信データを処理します。過去の時間の範囲で構成することはできません。
ビンの再試行が実行し尽くされると、そのビンはスキップされ、再実行できません。
Lighthouse を使用した別のテナントでの Log Analytics ワークスペースに対するクエリはサポートされていません。

価格モデル

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

ソーステーブルプラン	クエリコスト	集計結果のインジェストコスト
分析	無料	分析ログのインジェスト
Basic と Auxiliary	データスキャン	分析ログのインジェスト

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

ソーステーブルプラン	月額料金の計算
分析	インジェスト価格 x レコードボリューム x レコード数 x 24 時間 x 30 日。
Basic と Auxiliary	データスキャン価格 x スキャンボリューム + インジェスト価格 x レコードボリューム x レコード数 x 24 時間 x 30 日。継続的に実行されるルールの場合、ソーステーブルへのすべての受信データがスキャンされます。

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

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

クエリの集計ルールで使用できる演算子は、クエリ内のソーステーブルのプランによって異なります。

分析: 次を除くすべての KQL 演算子と関数をサポートします。
- workspaces()、app()、および resource() 式を使用するリソース間クエリ、および ADX() 式と ARG() 式を使用するサービス間クエリ。
- データスキーマを再形成するプラグイン (bag unpack、narrow、pivot など)。
基本: 1 つのテーブルですべての KQL オペレーターをサポートします。 lookup 演算子を使用して、最大 5 つの分析テーブルを結合できます。
関数: ユーザー定義関数はサポートされていません。 Microsoft が提供するシステム関数がサポートされています。

集計ルールは、結果の数またはボリュームが大幅に削減された場合のコストとクエリエクスペリエンスの観点で最も有益です。たとえば、結果のボリュームをソースの 0.01% 以下にすることを目指します。ルールを作成する前に、Log Analytics 内でクエリを実験し、クエリがクエリ API の制限に達したり近づいたりしていないことを確認します。クエリによって意図した期待どおりの結果とスキーマが生成されることを確認します。クエリがクエリの制限に近づいている場合は、小さな "ビンサイズ" を使用して、ビンごとに処理するデータを減らすことを検討してください。また、クエリを変更して、ボリュームが大きいレコードやフィールドがより少なく返されるようにすることもできます。

クエリを更新し、集計結果に含まれるフィールドが少なくなったら、Azure Monitor では宛先テーブルから列が自動的に削除されないため、テーブルから列を手動で削除する必要があります。

API
Azure Resource Manager テンプレート

集計ルールを作成または更新するには、次の PUT API 呼び出しを行います。

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"
      }
  }
}

このテンプレートを使用して、集計ルールを作成または更新します。 Azure Resource Manager テンプレートの使用およびデプロイの詳細については、Azure Resource Manager テンプレートに関するページを参照してください。

テンプレートファイル

{
  "$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"
    }
  }
}

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

パラメーター	有効な値	説明
`ruleType`	`User` または `System`	ルールの種類を指定します。 - `User`: 定義するルール。 - `System`: Azure サービスによって管理される定義済みのルール。
`description`	String	ルールとその関数について説明します。このパラメーターは、複数のルールがある場合に便利です。また、ルール管理に役立ちます。
`binSize`	`20`、`30`、`60`、`120`、`180`、`360`、`720`、または `1440` (分)	集計間隔とルックバック時間の範囲を定義します。たとえば、`"binSize": 120` を設定すると、`02:00 to 04:00` と `04:00 to 06:00` のエントリを取得できます。
`query`	Kusto クエリ言語 (KQL) クエリ	ルールで実行するクエリを定義します。集計間隔は `binSize` パラメーターによって決まるため、時間の範囲を指定する必要はありません。たとえば、`"binSize": 60` の場合は `02:00 to 03:00` です。クエリに時間フィルターを追加した場合、クエリで使用される時間の範囲は、フィルターとビンサイズとの交差です。
`destinationTable`	`tablename_CL`	ターゲットカスタムログテーブルの名前を指定します。名前の値にはサフィックス `_CL` が必要です。ワークスペースにテーブルがまだ存在しない場合、ルールで設定したクエリに基づいて、Azure Monitor によって作成されます。ワークスペースにテーブルが既に存在する場合は、クエリで導入された新しい列すべてが、Azure Monitor によって追加されます。集計結果に予約列の名前 (`TimeGenerated`、`_IsBillable`、`_ResourceId`、`TenantId`、`Type` など) が含まれている場合、Azure Monitor によって `_Original` プレフィックスが元のフィールドに追加され、元の値が保持されます。
`binDelay` (任意)	整数 (分)	ビンの実行の前に待機する時間を設定します。通常は、到着遅延データ (インジェストの待ち時間とも呼ばれます) に対して実行すると便利であり、ほとんどのデータが到着できるようにします。既定の延期時間は、3 分半から `binSize` 値の 10% です。クエリの実行先データの取り込みが通常延期されることがわかっている場合は、その延期時間以上の値 (最長 1,440 分) を使用して `binDelay` パラメーターを設定します。詳細については、集計のタイミングの構成に関するページを参照してください。場合によっては、Azure Monitor では、サービスの信頼性とクエリの成功を確保するために、設定されたビンの延期時間の少し後にビンの実行が開始されることがあります。
`binStartTime` (任意)	日付/時刻 `%Y-%n-%eT%H:%M %Z`形式	最初のビン実行の日付と時刻を指定します。この値は、ルールの作成日時から `binSize` 値を引いた時点以降から開始し、1 時間単位で指定できます。たとえば、datetime が `2023-12-03T12:13Z` で、`binSize` が 1,440 の場合、最も早い有効な `binStartTime` 値は `2023-12-02T13:00Z` で、集計には 02T13:00 から 03T13:00 の間にログに記録されたデータが含まれます。このシナリオでは、ルールによって、03T13:00 に、既定の延期時間または指定された延期時間を加えた時刻に集計が開始されます。 `binStartTime` パラメーターは、毎日の集計シナリオで役に立ちます。たとえば、UTC-8 タイムゾーンで `2023-12-03T12:13Z` に毎日のルールを作成するとします。そのルールは、1 日を開始する 8:00 (00:00 UTC) の前に完了する必要があります。 `binStartTime` パラメーターを `2023-12-02T22:00Z` に設定します。最初の集計には、ローカル時刻の 02T:06:00 から 03T:06:00 の間にログに記録されたすべてのデータが含まれ、ルールは毎日同時に実行されます。詳細については、集計のタイミングの構成に関するページを参照してください。ルールを更新する場合は、次のいずれかを実行できます。 - 既存の `binStartTime` 値を使用するか、`binStartTime` パラメーターを削除する。この場合、最初の定義に基づいて実行が続行されます。 - 新しい `binStartTime` 値を使用してルールを更新し、新しい日付/時刻の値を設定する。
`timeSelector` (任意)	`TimeGenerated`	タイムスタンプフィールドを定義します。これは Azure Monitor がデータ集計の際に使用するものです。たとえば、`"binSize": 120` を設定すると、`02:00` と `04:00` の間の `TimeGenerated` 値を持つエントリを取得できる可能性があります。

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

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

Azure Monitor が追加する短い延期時間では、インジェストの待ち時間、つまり監視対象システムでデータが作成されてから、Azure Monitor で分析に使用できるようになるまでの時間が考慮されます。既定では、この延期時間は、各ビンを集計する前の 3 分半から "ビンサイズ" 値の 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 分が追加されます。

binSize (分)	最初のルール実行	最初の集計	2 回目の集計
1440	2023-06-07 15:04	2023-06-06 15:00 - 2023-06-07 15:00	2023-06-07 15:00 - 2023-06-08 15:00
720	2023-06-07 15:04	2023-06-07 03:00 - 2023-06-07 15:00	2023-06-07 15:00 - 2023-06-08 03:00
360	2023-06-07 15:04	2023-06-07 09:00 - 2023-06-07 15:00	2023-06-07 15:00 - 2023-06-07 21:00
180	2023-06-07 15:04	2023-06-07 12:00 - 2023-06-07 15:00	2023-06-07 15:00 - 2023-06-07 18:00
120	2023-06-07 15:04	2023-06-07 13:00 - 2023-06-07 15:00	2023-06-07 15:00 - 2023-06-07 17:00
60	2023-06-07 15:04	2023-06-07 14:00 - 2023-06-07 15:00	2023-06-07 15:00 - 2023-06-07 16:00
30	2023-06-07 15:04	2023-06-07 14:30 - 2023-06-07 15:00	2023-06-07 15:00 - 2023-06-07 15:30
20	2023-06-07 15:04	2023-06-07 14:40 - 2023-06-07 15:00	2023-06-07 15:00 - 2023-06-07 15:20

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

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

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

binSize (分)	最初のルール実行	最初の集計	2 回目の集計
1440	2023-06-09 07:08	2023-06-08 07:00 - 2023-06-09 07:00	2023-06-09 07:00 - 2023-06-10 07:00
720	2023-06-08 19:08	2023-06-08 07:00 - 2023-06-08 19:00	2023-06-08 19:00 - 2023-06-09 07:00
360	2023-06-08 13:08	2023-06-08 07:00 - 2023-06-08 13:00	2023-06-08 13:00 - 2023-06-08 19:00
180	2023-06-08 10:08	2023-06-08 07:00 - 2023-06-08 10:00	2023-06-08 10:00 - 2023-06-08 13:00
120	2023-06-08 09:08	2023-06-08 07:00 - 2023-06-08 09:00	2023-06-08 09:00 - 2023-06-08 11:00
60	2023-06-08 08:08	2023-06-08 07:00 - 2023-06-08 08:00	2023-06-08 08:00 - 2023-06-08 09:00
30	2023-06-08 07:38	2023-06-08 07:00 - 2023-06-08 07:30	2023-06-08 07:30 - 2023-06-08 08:00
20	2023-06-08 07:28	2023-06-08 07:00 - 2023-06-08 07:20	2023-06-08 07:20 - 2023-06-08 07:40

集計ルールを表示する

特定の集計ルールの構成を表示するには、次の 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 のリファレンスドキュメントにアクセスします。

次の方法で共有

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

集計ルールのしくみ

例: ContainerLogsV2 データを集計する

必要なアクセス許可

実装の考慮事項

価格モデル

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

テンプレートファイル

パラメーターファイル

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

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

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

集計ルールを表示する

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

集計ルールを削除する

集計ルールを監視する

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

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

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

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

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

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

フィードバック

その他のリソース

次の方法で共有

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

集計ルールのしくみ

例: ContainerLogsV2 データを集計する

必要なアクセス許可

実装の考慮事項

価格モデル

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

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

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

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

集計ルールを表示する

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

集計ルールを削除する

集計ルールを監視する

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

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

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

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

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

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

関連するコンテンツ

フィードバック

その他のリソース

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

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

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

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