概要ルールを使用すると、定期的にログ データを集計し、集計された結果を Log Analytics ワークスペースのカスタム ログ テーブルに送信できます。 集計ルールを使用して、次の目的でデータを最適化します。
分析とレポート。特に、セキュリティとインシデントの分析、月単位および年次ビジネス レポートなど、大規模なデータ セットと時間範囲に対する分析とレポート。 大規模なデータ セットに対する複雑なクエリは、多くの場合、タイムアウトになります。"クリーニング済み" および "集計済み"の集計データをより簡単かつ効率的に分析し、レポートできます。
コスト削減 — 詳細ログは、必要に応じて短期間でも長期間でも低コストの Basic ログ テーブルに保持し、要約データは分析とレポート作成のために Analytics テーブルに送信できます。
セキュリティとデータ プライバシー。集計された共有可能なデータのプライバシーの詳細を削除または難読化し、生データを含むテーブルへのアクセスを制限することで確保します。
この記事では、集計ルールのしくみと、集計ルールを定義して表示する方法について説明し、集計ルールの使用例とメリットをいくつか紹介します。
次のビデオは、要約ルールの利点の一部の概要を提供します。
集計ルールのしくみ
概要ルールは、Log Analytics ワークスペースでバッチ処理を直接実行します。 この概要ルールは、KQL クエリに基づいて bin サイズで定義されたデータのチャンクを集計し、Log Analytics ワークスペースにAnalytics ログ プランを含むカスタム テーブルに集計結果を再取り込みします。
集計ルールは、テーブルに Analytics データ プランと Basic データ プランのどちらが含まれているかに関係なく、任意のテーブルのデータを集計します。 Azure Monitorは、定義したクエリに基づいて変換先テーブル スキーマを作成します。 変換先テーブルが既に存在する場合、Azure Monitor は、クエリ結果をサポートするために必要な列を追加します。 また、すべてのターゲット テーブルに、次のような集計ルール情報を含む一連の標準フィールドが含まれます。
-
_RuleName: 集計ログ エントリを生成した集計ルール。 -
_RuleLastModifiedTime: ルールの最終更新日時。 -
_BinSize: 集計間隔。 -
_BinStartTime: 集計の開始時刻。
複数のテーブルのデータを集計し、集計されたデータを個別の変換先テーブルまたは同じテーブルに送信するように、最大 100 個のアクティブなルールを構成します。
さらに統合するために、カスタム ログ テーブルからストレージ アカウントまたは Event Hubs に集計データをエクスポートするには、 データ エクスポート ルールを定義します。
例: ContainerLogV2 データの集計
コンテナーを監視している場合は、大量の詳細ログを ContainerLogV2 テーブルに取り込みます。
集計ルールでこのクエリを使用して、60 分以内に一意のレコードを集計し、分析に役立つデータのみを宛先テーブルに昇格させることができます。
ContainerLogV2
| summarize Count = count()
by
Computer,
ContainerName,
PodName,
PodNamespace,
LogSource,
LogLevel,
Message = tostring(LogMessage.Message)
ContainerLogV2 テーブルの生データを次に示します。
集計ルールがターゲット テーブルに送信する集計データを次に示します。
1 時間以内に何百もの類似エントリがログに記録されるのではなく、ターゲット テーブルには、KQL クエリで定義されているように、一意の各エントリの数が表示されます。
テーブルにContainerLogV2を設定して生データを低コストで保持し、分析のニーズに合わせて変換先テーブルの集計データを使用します。
必要なアクセス許可
| アクション | 必要なアクセス許可 |
|---|---|
| 集計ルールを作成または更新する | 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 アクセス許可。これは、たとえば Log Analytics 閲覧者の組み込みロールによって付与されます。 |
| カスタマー マネージド ストレージ アカウントで暗号化されたクエリを使用する |
Microsoft.Storage/storageAccounts/*によって提供される、ストレージ アカウントに対する アクセス許可。例: |
実装の考慮事項
- ワークスペース内のアクティブなルールの最大数は 100 です。
- 現在、集計ルールはパブリック クラウドでのみ使用できます。
- 概要ルールでは受信データが処理され、履歴時間範囲は許可されません。 データは、最近の過去から最大 24 時間まで処理できます。 これは、
binSizeが完全な 24 時間ウィンドウに設定されている場合の最大binStartTime1440 分に対応します。 - Lighthouse の下の別のテナント間でクエリを使用したサマリー ルールの作成はサポートされていません。
- サマリー ルールの変換先テーブルへの ワークスペース変換 の追加はサポートされていません。
- 概要ルール クエリでの
union *とisfuzzy=trueの使用はサポートされていません。
概要ルールの価格モデル
サマリー ルールでは、追加コストは発生しません。 クエリを実行するソーステーブルのテーブルプランに基づいて、クエリと、宛先テーブルへの結果の取り込みに対してのみ課金されます。
| ソーステーブル計画 | クエリのコスト | 集計結果のインジェスト コスト |
|---|---|---|
| Analytics | 無料 | 分析ログの取り込み |
| Basic と Auxiliary | データ スキャン | 分析ログの取り込み |
たとえば、ビンあたり 100 レコードを返すルールの時間あたりのコスト計算は次のとおりです。
| ソーステーブル計画 | 月額料金の計算 |
|---|---|
| Analytics | インジェスト価格 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 オペレーターをサポートします。 ルックアップ演算子を使用して、最大 5 つの Analytics テーブルを結合します。
- 関数: ユーザー定義関数はサポートされていません。 Microsoft が提供するシステム関数がサポートされています。
サマリー ルールは、ルール クエリに summarize 演算子が含まれており、結果の数または量が大幅に削減された場合に、コストとクエリの利点が最も大きくなります。 たとえば、ソースの 0.01% 以下の結果ボリュームを目指します。 ルールを作成する前に、Log Analyticsでクエリをテストし、次のことを確認します。
- このクエリでは、意図した結果とスキーマが生成されます。
- クエリがクエリ API の制限に達しない、または近くに達しない。 クエリがクエリの制限に近い場合は、小さな
binSizeを使用して、ビンあたりのデータ処理量を減らすことを検討してください。 別の方法として、クエリを変更して、返されるレコード数を減らしたり、大量のフィールドを減らしたりします。 - 結果のレコード サイズが 1 MB 未満です。
注
クエリはビン サイズによって定義された時間範囲で既に動作するため、サマリー ルール クエリでは時間フィルターを使用しないでください。 時間フィルターを追加すると、ビン サイズと組み合わせられ、その結果、重複する期間のみが使用されます。
クエリを更新し、集計結果に含まれるフィールドの数が少ない場合、Azure Monitorは変換先テーブルから列を自動的に削除しません。 必要に応じて、テーブルから列を手動で削除してください。
概要ルールを作成または更新するには:
Azure ポータルから、Log Analytics ワークスペースに移動します。
左側のメニューの [設定] で、[ルール] を選択 します。
[ 概要ルール ] タブを選択します。
[ + 作成] を選択して、新しいサマリー ルールを作成します。
[ルール名]、[説明]、[宛先] テーブルを入力し、[次へ: ルール ロジックを設定] を選択します。
ルール ロジック ステップは、Log Analyticsのクエリ エクスペリエンスで開始されます。 ここでクエリを作成してテストし、期待した結果が生成されたら 適用 します。
に対応する
binSize値を選択し、必要に応じて、その他のスケジュール設定オプションを調整します。 次に、Next: Review + create を選択します。概要ルールの設定を確認し、[ 作成] を選択します。
集計ルールのプロパティ
次の表では、概要ルールの作成と管理に使用できるパラメーターについて説明します。
| パラメーター | 有効な値 | 説明 |
|---|---|---|
ruleType |
User または System |
ルールの種類を指定します。 - User: 定義するルール。 - System: Azure サービスによって管理される定義済みの規則。 |
description |
文字列 | ルールとその関数について説明します。 このパラメーターは、複数のルールがある場合に便利です。また、ルール管理に役立ちます。 |
binSize |
20、30、60、120、180、360、720、または 1440 (分) |
集計間隔とルックバック時間の範囲を定義します。 たとえば、"binSize": 120 を設定すると、02:00 to 04:00 と 04:00 to 06:00 のエントリを取得できます。 |
query |
Kusto クエリ言語のクエリ | ルールで実行するクエリを定義します。
binSize パラメーターは集計間隔を決定するため、時間範囲を指定する必要はありません (たとえば、02:00 to 03:00場合"binSize": 60)。 クエリに時間フィルターを追加する場合、クエリで使用される時間範囲は、フィルターと bin サイズの交差部分です。 |
destinationTable |
tablename_CL | ターゲット カスタム ログ テーブルの名前を指定します。 名前の値にはサフィックス _CL が必要です。 Azure Monitor は、ルールで設定したクエリに基づいて、ワークスペースにテーブルがまだ存在しない場合に作成します。 テーブルがワークスペースに既に存在する場合は、Azure Monitorクエリで導入された新しい列が追加されます。 TimeGenerated、_IsBillable、_ResourceId、TenantId、または Type などの予約列名が集計結果に含まれている場合は、元のフィールドに _Original プレフィックスを追加Azure Monitor、元の値を保持します。 |
binDelay (任意) |
整数 (分) | ビンの実行の前に待機する時間を設定します。通常は、到着遅延データ (インジェストの待ち時間とも呼ばれます) に対して実行すると便利であり、ほとんどのデータが到着できるようにします。 既定の延期時間は、3 分半から binSize 値の 10% です。 クエリの実行先データの取り込みが通常延期されることがわかっている場合は、その延期時間以上の値 (最長 1,440 分) を使用して binDelay パラメーターを設定します。 詳細については、集計のタイミングの構成に関するページを参照してください。場合によっては、サービスの信頼性とクエリの成功を確保するために、Azure Monitorは、bin の設定遅延の少し後にビンの実行を開始することがあります。 |
retryBinStartTime |
日付/時刻%Y-%n-%eT%H:%M %Z 形式 |
指定された retryBinStartTime がビンを再実行します。 ルールの残りの定義は、最後の更新ごとに残ります。 選択した retryBinStartTime 値は、 RuleLastModifiedTime の後にあり、 binSizeの分割内に収まる必要があります。 たとえば、次のようになります。 ルールの binSize が 20 分の場合は、 retryBinStartTime を "2026-02-16T10:00:00Z"、"2026-02-16T10:20:00Z"、または "2026-02-16T10:40:00Z" に設定できます。 |
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 値を使用してルールを更新し、新しい日付/時刻の値を設定する。 |
name |
文字列 | ルール名を指定します。 名前はワークスペース内で一意である必要があり、文字、数字、アンダースコア、ハイフン、ピリオド (スペースなし) を含めることができます。 名前の値は、変換先テーブルの _RuleName フィールドで使用されます。 |
displayName (任意) |
文字列 | Azureポータルのエクスペリエンスでルールの表示名を指定します。 |
timeSelector (任意) |
TimeGenerated |
データの集計に使用Azure Monitorタイムスタンプ フィールドを定義します。 たとえば、"binSize": 120 を設定すると、TimeGenerated と 02:00 の間の 04:00 値を持つエントリを取得できる可能性があります。 |
集計のタイミングを構成する
既定では、集計ルールによって、次の 1 時間の直後に最初の集計が作成されます。
Azure Monitor では、取り込み遅延を考慮して短い遅延が加わります。これは、監視対象システムでデータが作成されてから、そのデータが Azure Monitor で分析できるようになるまでの時間です。 既定では、この遅延は各ビンを集計する前に、3 分半からビン サイズ値の 10% の間で設定されます。 ほとんどの場合、この遅延により、Azure Monitorは各ビン期間内にログに記録されたすべてのデータを集計します。
次に例を示します。
- ビン サイズが 30 分の集計ルールを 14:44 に作成します。 最初の集計は 15:04 に生成されます。これは、次の 1 時間に 4 分の遅延を加えた時刻です。
- ビン サイズが 720 分のサマリー ルールを 14:44 に作成します。 最初の集計は 16:12 に生成されます。これは、次の 1 時間に 72 分 (720 ビン サイズの 10%) の遅延を加えた時刻です。
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 |
| 六十 | 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年6月8日 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 |
| 六十 | 2023-06-08 08:08 | 2023年06月08日 07:00～2023年06月08日 08:00 | 2023年6月8日 08時00分 - 2023年6月8日 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 |
すべての概要ルールを表示する
ワークスペース内のすべての概要ルールを表示または列挙します。
Azure ポータルに表示される概要ルールのdisplayNameプロパティは、特にポータルを使用してルールを作成した場合に、API 呼び出しで使用されるname プロパティとは異なります。
name プロパティはルールの一意識別子であり、ルールを管理するために API 呼び出しで使用されます。
displayNameは、識別を容易にするために、Azure ポータルに表示されるわかりやすい名前です。
- Azure ポータルから、Log Analytics ワークスペースに移動します。
- 左側のメニューの [設定] で、[ルール] を選択 します。
- [ 概要ルール ] タブを選択します。
![Azure ポータルのすべての概要ルールを含む [概要ルール] ウィンドウを示すスクリーンショット。](media/summary-rules/view-all-summary-rules.png#lightbox)
概要ルールを表示する
特定の概要ルールの構成を表示または更新します。
Azure ポータルから、Log Analytics ワークスペースに移動します。
左側のメニューの [設定] で、[ルール] を選択 します。
[ 概要ルール ] タブを選択します。
一覧から表示するサマリー ルールの横にある 省略記号 (...) を選択します。
[ 編集] を 選択して、概要ルールの構成を表示します。
[ 次へ: 集計ルール で使用されるクエリを表示するルール ロジックを設定する] を選択します。
概要ルールを停止する
一定期間ルールを停止します。 ユース ケースの例の 1 つは、集計テーブルとレポートに影響を与えずにデータがテーブルに取り込まれたことを確認する場合です。
ルールを停止するには:
- Azure ポータルから、Log Analytics ワークスペースに移動します。
- 左側のメニューの [設定] で、[ルール] を選択 します。
- [ 概要ルール ] タブを選択します。
- [ アクティブな状態] トグル ボタンを選択し、状態が [非アクティブ] に変わるのを確認します。
概要ルールを開始する
ルールを再起動すると、Azure Monitorは、次の 1 時間から、または定義された binStartTime (省略可能) パラメーターに基づいてデータの処理を開始します。
ルールを開始するには:
- Azure ポータルから、Log Analytics ワークスペースに移動します。
- 左側のメニューの [設定] で、[ルール] を選択 します。
- [ 概要ルール ] タブを選択します。
- [非アクティブ状態] トグル ボタンを選択し、状態が [アクティブ] に変わるのを確認します。
集計ルールを削除する
Log Analytics ワークスペースでは、最大 100 個のアクティブなサマリー ルールがサポートされます。 既に 100 個のアクティブなルールがあり、新しいルールを作成する場合は、最初にアクティブなサマリー ルールを停止または削除する必要があります。
ルールを削除するには:
- Azure ポータルから、Log Analytics ワークスペースに移動します。
- 左側のメニューの [設定] で、[ルール] を選択 します。
- [ 概要ルール ] タブを選択します。
- 一覧から表示するサマリー ルールの横にある 省略記号 (...) を選択します。
- を選択して、を削除します。
集計ルールを監視する
概要ルールを監視するには、Log Analytics ワークスペースの ログ カテゴリを diagnostic settings で有効にします。 Azure Monitor、概要ルールの実行の開始、成功、失敗の情報など、サマリー ルールの実行の詳細をワークスペースの LASummaryLogs テーブルに送信します。
次の例に示すように、bin エラーの通知または bin の実行がタイムアウトに近い場合に通知を受け取るようにログ アラート ルールを設定します。 失敗の理由に応じて、各実行で処理されるデータが少ないほどビン サイズを小さくするか、クエリを変更して返されるレコード数が少なくなったり、大量のフィールドが少なくなったりします。
次のクエリは、失敗した実行を返します。
LASummaryLogs | where Status == "Failed"
このクエリは、 QueryDurationMs 値が 最大クエリ実行時間の 90% を超える bin 実行を返します。
LASummaryLogs | where QueryDurationMs > 0.9 * 600000
データの完全性を確認する
概要ルールはスケーリング用に設計されており、 クエリ制限に関連する一時的なサービスまたはクエリエラーを克服するための再試行メカニズムが含まれています。 再試行メカニズムでは、失敗したビンを 8 時間以内に 10 回集計し、すべての試行が使い果たされた場合はビンをスキップします。 ルールは isActive: false に設定され、8 回連続してビンの再試行が行われた後、保留になります。
診断設定で監視概要ルールを有効にすると、Azure Monitor はワークスペースのLASummaryLogsテーブルにイベントを記録するため、実行履歴を表示したり、失敗したものを再試行したりできます。 次のクエリを使用するか、ポータルから実行を表示できます。
let startTime = datetime("2024-02-16");
let endTime = 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 endTime step stepSize
| render timechart
次のクエリでは、結果が時間グラフとしてレンダリングされます。
ルールの修復オプションとプロアクティブなアラートについては、「集計ルールを監視する」セクションを参照してください。
概要ルールのビンを再試行する
概要ルールはスケール用に設計されており、一時的なサービスの問題やクエリの制限エラーを克服するための再試行メカニズムが含まれています。 サービスの再試行が使い果たされたら、失敗した実行 (または bin) を手動で再試行します。
- 再試行する要約ルールのいちばん右側にある 省略記号 (...) を選択します。
- メニューから実行履歴を表示を選択します。
- フィルターを変更して、 失敗した実行を 表示します。
- 再試行する 実行時間 を見つけて、行の末尾にある 省略記号 (...) を選択します。
- メニューから [このビンを再実行 ] を選択します。
カスタマー マネージド キーを使用して集計ルールを暗号化する
KQL クエリでは、コメントまたはクエリ構文に機密情報を含めることができます。 概要ルール クエリを暗号化するには、ストレージ アカウントを Log Analytics ワークスペースにリンクし、カスタマー マネージド キーを使用します。
暗号化されたクエリを使用する場合の考慮事項:
- ストレージ アカウントをリンクしてクエリを暗号化しても、既存のルールは中断されません。
- 既定では、Azure Monitorはサマリー ルール クエリをLog Analyticsストレージに格納します。 ストレージ アカウントを Log Analytics ワークスペースにリンクする前に、既存の概要ルールがある場合は、クエリがストレージ アカウントに保存されるようにそれらのルールを更新します。
- ストレージ アカウントに保存したクエリは、
CustomerConfigurationStoreTableテーブルに配置されます。 これらのクエリはサービスの成果物と見なされ、その形式は変更される可能性があります。 - 同じストレージ アカウントでは、概要ルール クエリ、Log Analyticsに保存されたクエリ、ログ アラートがサポートされます。
集計ルールのトラブルシューティング
このセクションでは、集計ルールのトラブルシューティングに関するヒントを提供します。
集計ルールのターゲット テーブルが誤って削除された
サマリー ルールがアクティブな状態で宛先テーブルを削除すると、ルールは中断され、Azure Monitorルールが中断されたことを示すメッセージを含むイベントが LASummaryLogs テーブルに送信されます。
ターゲット テーブルに集計結果が必要ない場合は、ルールとテーブルを削除してください。 集計結果が必要な場合は、「集計ルールを作成または更新する」セクションの手順に従って、ターゲット テーブルを再作成し、すべてのデータ (削除前に取り込まれたデータを含む) を、テーブル内のアイテム保持ポリシーに応じて復元します。
ターゲット テーブルに新しい列を作成する演算子をクエリで使用する
ターゲット テーブル スキーマは、集計ルールを作成または更新するときに定義されます。 クエリに、受信データ (arg_max(expression, *) 関数など) に基づく出力スキーマの拡張を許可する演算子が含まれている場合、ルールの作成または更新後にAzure Monitorは新しい列を変換先テーブルに追加せず、これらの列を必要とする出力データは削除されます。 新しいフィールドをターゲット テーブルに追加するには、集計ルールを更新するか、手動で列をテーブルに追加します。
削除された列のデータは、テーブルのデータ保持設定に基づいて、ワークスペースに残ります
クエリからフィールドを削除すると、テーブルまたはワークスペースで定義されている 保持期間 に基づいて、列とデータが移動先テーブルに残ります。 変換先テーブルで削除された列が不要な場合は、 テーブル スキーマから列を削除します。 その後、同じ名前の列を追加すると、保持期間より古くないデータが再び表示されます。