Azure Monitor でログを復元する

復元操作により、高パフォーマンスのクエリのために、テーブル内の特定の時間範囲のデータがホット キャッシュで使用できるようになります。 ソース テーブルと時間範囲を指定すると、Azure Monitor によって名前が _RST で終わる宛先テーブルが作成され、復元されたデータに対してフル KQL クエリを実行できます。 完了したら、復元を無視して課金を停止します。

復元は、 長期的な保有期間のデータにアクセスする 1 つの方法です。 復元を使用して、特定の時間範囲のデータに対して完全な Kusto クエリ言語 (KQL) クエリを実行します。 検索ジョブを使用して、特定の条件に基づいてデータにアクセスします。 また、10 分間のタイムアウト内にログ クエリを完了できない場合は、復元操作を使用して任意の Analytics テーブルに対してクエリを実行します。

前提条件

長期的なリテンション期間からデータを復元するには、Log Analytics ワークスペースに対するMicrosoft.OperationalInsights/workspaces/tables/writeとMicrosoft.OperationalInsights/workspaces/restoreLogs/writeアクセス許可が必要です。 Log Analytics共同作成者の組み込みロールは、これらのアクセス許可を提供します。

補助テーブル プランを持つテーブルでは、データの復元はサポートされていません。 Auxiliary テーブル内の長期保管されているデータを取得するには、検索ジョブを使用します。

注

Azure Lighthouseは、委任されたロールにrestoreLogs/writeアクセス許可が含まれている場合でも、復元ジョブまたは検索ジョブの委任されたアクセスをサポートしていません。

データの復元

データを復元するときは、ソース テーブルと新しい変換先テーブルの名前を指定します。 変換先のテーブル名は、 _RSTで終わる必要があります。 復元操作では、このテーブルが作成され、完全な KQL をサポートする高パフォーマンスクエリを使用して、復元されたデータに対してクエリを実行するための追加のコンピューティング リソースが割り当てられます。 変換先テーブルは、基になるソース データのビューを提供しますが、影響はありません。

開始時刻と終了時刻を、 などの ISO 8601 形式の UTC 文字列として指定します。 復元の制約を満たすソース テーブルの保持データ内の範囲を選択します。

Important

復元が開始されると課金が開始され、 復元されたデータを閉じるまで続行されます。 クエリの実行が終わったら、すぐに復元を終了してください。 コストの詳細については、「 価格の復元」を参照してください。

次のAzure CLI例では、az monitor log-analytics workspace table restore create コマンドを使用します。 ソース テーブルから新しい変換先テーブルにデータの時間範囲を復元します。 --name パラメーターを使用して設定する変換先テーブルの名前は、_RSTで終わる必要があります。

# Set variables
resourceGroupName="<ResourceGroupName>"
workspaceName="<WorkspaceName>"
tableName="<TableName>_RST"
sourceTable="<SourceTableName>"
startRestoreTime="<StartRestoreTime>"
endRestoreTime="<EndRestoreTime>"

# Create the Log Analytics workspace restore logs table
az monitor log-analytics workspace table restore create \
  --resource-group "$resourceGroupName" \
  --workspace-name "$workspaceName" \
  --name "$tableName" \
  --restore-source-table "$sourceTable" \
  --start-restore-time "$startRestoreTime" \
  --end-restore-time "$endRestoreTime" \
  --no-wait

注

Azure CLIコマンドは現在の CLI コンテキストからAzure Resource Manager エンドポイントを使用するため、コマンド構文で management.azure.com を指定する必要はありません。

非同期復元の場合は、 az monitor log-analytics workspace table show、 Get-AzOperationalInsightsTable、または Tables - Getを使用して宛先テーブルを取得します。 クエリを実行する前に、 provisioningState が Succeeded されるまで待ちます。

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

Azure Monitorで復元されたテーブルに対してクエリを実行する場合は、コピー先のテーブル名 (_RSTで終わる) を使用します。 復元されたログは、復元操作の時刻ではなく、元のタイムスタンプを保持します。 データが最初に生成された日時に基づいて、クエリの時間範囲を設定します。

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

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

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

    let startTime = datetime(<StartRestoreTime>);
let endTime = datetime(<EndRestoreTime>);
<TableName>_RST
| where TimeGenerated between (startTime .. endTime)

復元されたデータを破棄する

復元されたデータを閉じるとは、復元先 _RST テーブルを削除して、復元の課金を停止することを意味します。 不要になったら、復元されたテーブルを削除します 。

復元されたテーブルを削除しても、ソース テーブルのデータは削除されません。

注

基になるソース データが使用可能である限り、復元されたデータを使用できます。 ワークスペースからソース テーブルを削除するか、ソース テーブルの保有期間が終了すると、復元されたテーブルからデータが消去されます。 ただし、空のテーブルは、明示的に削除するまで保持されます。

復元に関する考慮事項

Azure Monitorの復元操作には、次の制約があります。

  • サポートされているテーブル プラン: 分析と基本。 補助プランはサポートされていません。
  • 最小時間範囲: 復元ごとに少なくとも 2 日間のデータ。
  • 最大データ ボリューム: 復元あたり最大 60 TB。
  • 同時復元: ワークスペースごとに最大 2 つの復元プロセスを同時に実行できます。
  • テーブルごとに 1 つのアクティブな復元: 既にアクティブな復元があるテーブルで 2 つ目の復元を実行すると失敗します。
  • 週単位の制限: 1 週間あたりテーブルあたり最大 4 回の復元。

価格を復元する

復元されたログのコストは、復元するデータの量と復元がアクティブな期間によって異なります。 価格は、復元がアクティブになっている各 UTC 日の 1 日あたりの GB 単位 です。

主要な価格ルール:

  • 最小データ ボリューム: 復元あたり 2 TB。 復元が少ない場合は、2 TB の料金が発生します。
  • 最小期間: 12 時間。 復元がアクティブな時間が少ない場合は、12 時間 (0.5 日) の料金が発生します。
  • 日割り請求: 初日と最終日は、復元処理が実行されている時間分のみ課金されます。
  • クエリ料金なし: 復元されたテーブルでは分析プランが使用されるため、復元されたデータのクエリには追加のコストはかかりません。

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

コストの例

シナリオ 復元されたデータ 期間 請求日単位のボリューム 計算
大規模な復元、複数日 5 TB (500 GB/日× 10 日間) 終了するまで 5,000 GB 5,000 GB × GB/日あたりの価格 × アクティブだった日数
小規模な復元、複数日 700 GB 終了するまで 2,000 GB (最小) 2,000 GB × 1 GB/日あたりの価格 × 有効日数
大規模な復元、1 時間 5 テラバイト (TB) 1 時間 5,000 GB 5,000 GB × 1 GB/日あたりの価格 × 0.5日（最小12時間）
小さな復元、1 時間 700 GB 1 時間 2,000 GB (最小) 2,000 GB × 1 GB/日あたりの価格 × 0.5 日（12 時間以上）

関連するコンテンツ

  • 最終更新: