集計ルールを使用すると、定期的にログ データを集計し、集計結果を 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を設定し、分析ニーズに合わせてターゲット テーブルの集計データを使用します。
必要なアクセス許可
| アクション | 必要なアクセス許可 |
|---|---|
| 集計ルールを作成または更新する | 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 ワークスペースに対する権限は、たとえば Log Analytics 閲覧者組み込みロール によって提供されます |
| カスタマー マネージド ストレージ アカウントで暗号化されたクエリを使用する | Microsoft.Storage/storageAccounts/*によって提供される、ストレージ アカウントに対する アクセス許可。例: |
実装の考慮事項
- ワークスペース内のアクティブなルールの最大数は 30 です。
- 現在、集計ルールはパブリック クラウドでのみ使用できます。
- 集計ルールは受信データを処理します。過去の時間の範囲で構成することはできません。
- ビンの再試行が実行し尽くされると、そのビンはスキップされ、再実行できません。
- Lighthouse の下の別のテナント間でのクエリを使用したサマリー ルールの作成はサポートされていません。
- サマリー ルールの変換先テーブルへの ワークスペース変換 の追加はサポートされていません。
価格モデル
集計ルールの追加コストは発生しません。 クエリを実行するソーステーブルのテーブルプランに基づいて、クエリと、宛先テーブルへの結果の取り込みに対してのみ課金されます。
| ソーステーブル計画 | クエリのコスト | 集計結果のインジェスト コスト |
|---|---|---|
| アナリティクス | 無料 | 分析ログの取り込み |
| 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 の制限に達しないか、または近くにありません。
- 結果のレコード サイズが 1 MB 未満です。
クエリがクエリの制限に近づいている場合は、小さな "ビン サイズ" を使用して、ビンごとに処理するデータを減らすことを検討してください。 また、クエリを変更して、ボリュームが大きいレコードやフィールドがより少なく返されるようにすることもできます。
クエリを更新し、集計結果に含まれるフィールドが少なくなったら、Azure Monitor では宛先テーブルから列が自動的に削除されないため、テーブルから列を手動で削除する必要があります。
集計ルールを作成または更新するには、次の 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"
}
}
}
次の表では、集計ルールのパラメーターについて説明します。
| パラメーター | 有効な値 | 説明 |
|---|---|---|
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 です。 クエリに時間フィルターを追加した場合、クエリで使用される時間の範囲は、フィルターとビン サイズとの交差です。 |
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 値を使用してルールを更新し、新しい日付/時刻の値を設定する。 |
displayName (任意) |
文字列 | Azure portal エクスペリエンスでのルールの表示名を指定します。 |
timeSelector (任意) |
TimeGenerated |
タイムスタンプ フィールドを定義します。これは Azure Monitor がデータ集計の際に使用するものです。 たとえば、"binSize": 120 を設定すると、TimeGenerated と 02:00 の間の 04:00 値を持つエントリを取得できる可能性があります。 |
集計のタイミングを構成する
既定では、集計ルールによって、次の 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 |
| 六十 | 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-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 のリファレンス ドキュメントにアクセスします。