Azure Monitor でログを復元する

復元操作により、高パフォーマンスのクエリのために、テーブル内の特定の時間範囲のデータがホット キャッシュで使用できるようになります。 この記事では、データを復元し、そのデータを照会して、完了後にデータを破棄する方法について説明します。

アクセス許可

長期保有からデータを復元するには、Log Analytics ワークスペースに対する Microsoft.OperationalInsights/workspaces/tables/write と Microsoft.OperationalInsights/workspaces/restoreLogs/write のアクセス許可が必要です。これらは、たとえば Log Analytics 共同作成者組み込みロールによって提供されます。

ログを復元する場面

長期保有のデータのクエリを実行するには、復元操作を使います。 また、ソース テーブルに対してログ クエリを実行するとログ クエリのタイムアウト設定である 10 分間以内に完了できない場合、復元操作を使用すれば、Analytics テーブルに対して特定の時間の範囲内で強力なクエリを実行できます。

復元の機能

データを復元するときは、照会するデータを含むソース テーブルと、作成される新しい復元先テーブルの名前を指定します。

復元操作では、復元テーブルが作成され、完全な KQL がサポートされる高パフォーマンスのクエリを使用して復元されたデータを照会するための追加のコンピューティング リソースが割り当てられます。

復元先のテーブルでは、基になるソース データのビューが提供されますが、ソース データに影響することはありません。 このテーブルには保有期間の設定がないため、不要になったときに、復元されたデータを明示的に破棄する必要があります。

データの復元

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

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

az monitor log-analytics workspace table restore create --subscription ContosoSID --resource-group ContosoRG  --workspace-name ContosoWorkspace --name Heartbeat_RST --restore-source-table Heartbeat --start-restore-time "2022-01-01T00:00:00.000Z" --end-restore-time "2022-01-08T00:00:00.000Z" --no-wait

復元されたデータのクエリ

復元されたログには、元のタイムスタンプが保持されます。 復元されたログに対してクエリを実行する場合には、データが生成された当初の時点に基づいてクエリ時間の範囲を設定します。

クエリ時間の範囲を設定するには、次のいずれかを行います。

• クエリ エディターの上部にある [時間の範囲] ドロップダウンで [カスタム] を選択し、[開始] と [終了] の値を設定します。
  
  または

• クエリで時間の範囲を指定します。 次に例を示します。

  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. テーブルが 1 日に 500 GB を保持していて、そのテーブルから 10 日間のデータを復元する場合、復元の合計サイズは 5 TB です。 復元されたデータを閉じるまで、毎日この 5 TB の復元データに対して課金されます。 1 日あたりのコストは 5,000 GB にデータ復元価格を掛けたものになります (「Azure Monitor の価格」を参照)。

2. 代わりに、700 GB のデータのみが復元される場合、復元がアクティブになっているそれぞれの日は、2 TB の最小復元レベルに対して課金されます。 1 日あたりのコストは、2,000 GB にデータ復元価格を掛けたものになります。

3. 5 TB のデータ復元が 1 時間だけアクティブな場合、最小の 12 時間に対して課金されます。 このデータ復元のコストは、5,000 GB にデータ復元価格と 0.5 日 (最小の 12 時間) を掛けたものです。

4. 700 GB のデータ復元が 1 時間だけアクティブな場合、最小の 12 時間に対して課金されます。 このデータ復元のコストは、2,000 GB (請求される最小復元サイズ) にデータ復元価格と 0.5 日 (最小の 12 時間) を掛けたものです。

次のステップ

• データ保有についてさらに詳しく理解する。

• 長期保有からデータを取得するためのもう 1 つの方法である検索ジョブについて理解する。