Azure Monitor でログを復元する
復元操作により、高パフォーマンスのクエリのために、テーブル内の特定の時間範囲のデータがホット キャッシュで使用できるようになります。 この記事では、データを復元し、そのデータを照会して、完了後にデータを破棄する方法について説明します。
アクセス許可
アーカイブされたテーブルからデータを復元するには、Log Analytics ワークスペースに対する Microsoft.OperationalInsights/workspaces/tables/write および Microsoft.OperationalInsights/workspaces/restoreLogs/write のアクセス許可が必要です。これらは、たとえば 組み込みの Log Analytics 共同作成者ロールによって提供されます。
ログを復元する場面
アーカイブ済みログのデータを照会するには、復元操作を使用します。 また、ソース テーブルに対してログ クエリを実行するとログ クエリのタイムアウト設定である 10 分間以内に完了できない場合、復元操作を使用すれば、Analytics テーブルに対して特定の時間の範囲内で強力なクエリを実行できます。
注意
復元は、アーカイブされたデータにアクセスするための 1 つの方法です。 特定の時間範囲内の一連のデータに対してクエリを実行するには、復元を使用します。 特定の条件に基づいてデータにアクセスするには、検索ジョブ を使用します。
復元の機能
データを復元するときは、照会するデータを含むソース テーブルと、作成される新しい復元先テーブルの名前を指定します。
復元操作では、復元テーブルが作成され、完全な KQL がサポートされる高パフォーマンスのクエリを使用して復元されたデータを照会するための追加のコンピューティング リソースが割り当てられます。
復元先のテーブルでは、基になるソース データのビューが提供されますが、ソース データに影響することはありません。 このテーブルには保有期間の設定がないため、不要になったときに、復元されたデータを明示的に破棄する必要があります。
データの復元
テーブルからデータを復元するには、Tables - Create または Update API を呼び出します。 復元先のテーブルの名前は、_RST で終わる必要があります。
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/tables/{user defined name}_RST?api-version=2021-12-01-preview
要求本文
要求の本文には、次の値を含める必要があります。
| Name | 種類 | 説明 |
|---|---|---|
| properties.restoredLogs.sourceTable | string | 復元するデータを含むテーブル。 |
| properties.restoredLogs.startRestoreTime | string | 復元する時間範囲の始まり。 |
| properties.restoredLogs.endRestoreTime | string | 復元する時間範囲の終わり。 |
テーブルの状態の復元
provisioningState プロパティは、テーブルの復元操作の現在の状態を示しています。 API では、復元を開始するときにこのプロパティを返します。後でテーブルに対して GET 操作を使用して、このプロパティを取得することもできます。 provisioningState プロパティには、次のいずれかの値が含まれています。
| 値 | 説明 |
|---|---|
| 更新中 | 復元操作が進行中です。 |
| 成功 | 復元操作が完了しました。 |
| 削除中 | 復元されたテーブルを削除しています。 |
要求のサンプル
このサンプルでは、Usage テーブルの 2020 年 1 月のデータを Usage_RST というテーブルに復元します。
Request
PUT https://management.azure.com/subscriptions/00000000-0000-0000-0000-00000000000/resourcegroups/testRG/providers/Microsoft.OperationalInsights/workspaces/testWS/tables/Usage_RST?api-version=2021-12-01-preview
要求本文:
{
"properties": {
"restoredLogs": {
"startRestoreTime": "2020-01-01T00:00:00Z",
"endRestoreTime": "2020-01-31T00:00:00Z",
"sourceTable": "Usage"
}
}
}
復元されたデータのクエリ
復元されたログには、元のタイムスタンプが保持されます。 復元されたログに対してクエリを実行する場合には、データが生成された当初の時点に基づいてクエリ時間の範囲を設定します。
クエリ時間の範囲を設定するには、次のいずれかを行います。
クエリ エディターの上部にある [時間の範囲] ドロップダウンで [カスタム] を選択し、[開始] と [終了] の値を設定します。
またはクエリで時間の範囲を指定します。 次に例を示します。
let startTime =datetime(01/01/2022 8:00:00 PM); let endTime =datetime(01/05/2022 8:00:00 PM); TableName_RST | where TimeGenerated between(startTime .. endTime)
復元されたデータを破棄する
コストを節約するために、復元されたデータが必要なくなったら、復元されたテーブルを削除してそのデータを破棄することをお勧めします。
復元されたテーブルを削除しても、ソース テーブルのデータは削除されません。
注意
基になるソース データが使用可能である限り、復元されたデータを使用できます。 ワークスペースからソース テーブルを削除するか、ソース テーブルの保有期間が終了すると、復元されたテーブルからデータが消去されます。 ただし、空のテーブルを明示的に削除しないと、そのまま残ります。
制限事項
復元には、次の制限事項が適用されます。
次のことを実行できます。
少なくとも 2 日間の期間からデータを復元します。
最大 60 TB 復元します。
1 つのワークスペースで同時に最大 2 つの復元処理を実行します。
特定のテーブルに対して、特定の時点でアクティブな復元を 1 つだけ実行します。 アクティブな復元が既に実行されているテーブルに対して 2 個目の復元を実行すると失敗します。
1 週間あたり、1 つのテーブルごとに最大 4 回の復元を実行します。
価格モデル
復元されたログの料金は、復元するデータの量と、復元がアクティブである期間に基づいています。 したがって、価格の単位は、1 日あたりの GB あたりです。 データ復元は、復元がアクティブになっている UTC 日ごとに課金されます。
課金には、復元ごとに 2 TB の最小復元データ ボリュームが適用されます。 復元するデータが少ない場合は、復元が破棄されるまで毎日、2 TB の最小値に対して課金されます。
復元がアクティブになった最初と最後の日には、復元がアクティブだった日の部分に対してのみ課金されます。
復元のアクティブな期間が 12 時間未満の場合でも、最小料金は 12 時間の復元期間になります。
データ復元の価格の詳細については、[ログ] タブの「Azure Monitor の価格」を参照してください。
データ復元コストの計算を示す例を次に示します。
テーブルが 1 日に 500 GB を保持していて、そのテーブルから 10 日間のデータを復元する場合、復元の合計サイズは 5 TB です。 復元されたデータを閉じるまで、毎日この 5 TB の復元データに対して課金されます。 1 日あたりのコストは 5,000 GB にデータ復元価格を掛けたものになります (「Azure Monitor の価格」を参照)。
代わりに、700 GB のデータのみが復元される場合、復元がアクティブになっているそれぞれの日は、2 TB の最小復元レベルに対して課金されます。 1 日あたりのコストは、2,000 GB にデータ復元価格を掛けたものになります。
5 TB のデータ復元が 1 時間だけアクティブな場合、最小の 12 時間に対して課金されます。 このデータ復元のコストは、5,000 GB にデータ復元価格と 0.5 日 (最小の 12 時間) を掛けたものです。
700 GB のデータ復元が 1 時間だけアクティブな場合、最小の 12 時間に対して課金されます。 このデータ復元のコストは、2,000 GB (請求される最小復元サイズ) にデータ復元価格と 0.5 日 (最小の 12 時間) を掛けたものです。
Note
復元されたログは Analytics ログであるため、クエリの料金はかかりません。