(プレビュー) Azure Site Recovery レポートを構成する
Azure Site Recovery には、バックアップとディザスター リカバリーの管理者向けに長期的なデータに関する分析情報を得るためのレポート ソリューションが用意されています。 これには、次のものが含まれます。
- 使用されるクラウド ストレージの割り当てと予測。
- バックアップおよび復元を監査します。
- さまざまな詳細レベルで主要な傾向を特定します。
Azure Site Recovery には、Azure Backup と同様に、Azure Monitor ログと Azure ブックを使用するレポート作成ソリューションが用意されています。 これらのリソースは、Site Recovery で保護されている資産に関する分析情報を得るのに役立ちます。
この記事では、Azure Site Recovery レポートを設定して表示する方法について説明します。
サポートされるシナリオ
Azure Site Recovery レポートは、次のシナリオでサポートされます。
- Site Recovery ジョブと Site Recovery のレプリケートされた項目。
- Azure 仮想マシンの Azure へのレプリケーション、Hyper-V の Azure へのレプリケーション、VMware の Azure へのレプリケーション - クラシックおよび最新化。
レポートの構成
Azure Site Recovery レポートを使用し始めるには、次の手順に従います。
Log Analytics ワークスペースを作成するか、既存のワークスペースを使用する
バックアップ レポート データを格納するために、1 つ以上の Log Analytics ワークスペースを設定します。 この Log Analytics ワークスペースの場所とサブスクリプションは、コンテナーが配置またはサブスクライブされている場所とは異なる場合があります。
Log Analytics ワークスペースを設定するには、次の手順に従います。 Log Analytics ワークスペース内のデータは、既定で 30 日間保持されます。 より長期間のデータを表示するには、Log Analytics ワークスペースの保持期間を変更します。 保持期間を変更するには、「Azure Monitor Logsでのデータの保持ポリシーとアーカイブポリシーの構成」を参照してください。
コンテナーの診断設定を構成する
Recovery Services コンテナーなどの Azure Resource Manager リソースに関し、サイト回復ジョブとレプリケートされた項目の情報を診断データとして記録します。
診断設定を構成する方法については、「[Azure Monitor] の [診断設定]」を参照してください。
Azure portal で次の手順を使用して、コンテナーの診断設定を構成することもできます。
選択した Recovery Services コンテナーに移動し、[監視]>[診断設定] を選択します。
Recovery Services コンテナーの診断データのターゲットを指定します。 Recovery Services コンテナーについては、診断イベントの使用の詳細をご覧ください。
[Azure Site Recovery ジョブ] オプションと [Azure Site Recovery でレプリケートされた項目の詳細] オプションを選択し、レポートを設定します。
Note
診断の構成後、最初のデータ プッシュが完了するまでに最大 24 時間かかります。 Log Analytics ワークスペースへのデータの送信が開始された後、レポートのデータが即時には表示されない場合があります。まだ終わっていない当日のデータはレポートに表示されないためです。
詳細については、規則を参照してください。 Log Analytics にデータを送信するようにコンテナーを構成した 2 日後からレポートの表示を開始することをお勧めします。
現時点では、Azure Site Recovery では、特定のスコープ内のすべての Recovery Services コンテナーに対する診断設定の構成を自動化する組み込みの Azure ポリシー定義は提供されていません。
ビジネス継続性センターでレポートを表示する
Log Analytics ワークスペースにデータを転送するようにコンテナーを設定した後、レポートを表示するには、ビジネス継続性センター>[監視とレポート]>[レポート] に移動します。
情報を含むレポートを表示するには、1 つ以上のワークスペース サブスクリプション、1 つ以上のログ分析ワークスペース、任意のレプリケーション シナリオを選択する必要があります。
ビジネス継続性センターで使用できるレポートの一部を次に示します。
Azure Site Recovery ジョブ履歴
このレポートには、操作の種類と完了状態別の Site Recovery ジョブに関する情報が表示されます。 このレポートには、ジョブの状態、開始時刻、期間、コンテナー、サブスクリプションなどに関する情報が含まれます。
また、時間の範囲、操作、リソース グループ、状態、検索項目に対して複数のフィルターが用意されているため、焦点を絞ったレポートと視覚的情報を生成できます。
Azure Site Recovery レプリケーション履歴
このレポートでは、Site Recovery でレプリケートされた項目とその状態に関する情報が、指定された期間にわたって提供されます。 このレポートには、フェールオーバーの日付と、トラブルシューティングのための詳細なレプリケーション正常性エラーの一覧も含まれます。 時間の範囲、コンテナー サブスクリプション、リソース グループ、検索項目のフィルターが提供されるため、焦点を絞ったレポートと視覚的情報を生成できます。
Excel にエクスポート
任意のウィジェット (テーブルやグラフなど) の最上部にある下矢印ボタンを選択すると、既存のフィルターが適用された状態で、そのウィジェットの内容が Excel シートとしてエクスポートされます。 テーブルの行をさらに Excel にエクスポートする場合は、各ウィジェットの上部にある [ページごとの行] オプションを調整して、ページに表示される行の数を増やすことができます。
ダッシュボードにピン留めする
ウィジェットを Azure portal のダッシュボードにピン留めするには、各ウィジェットの上部にあるピン ボタンを選択します。 この機能は、必要とする最も重要な情報を表示するために調整された、カスタマイズされたダッシュボードを作成するのに役立ちます。
テナント間のレポート
複数のテナント環境でサブスクリプションへの委任アクセス権を持つ Azure Lighthouse ユーザーの場合は、既定のサブスクリプション フィルター (Azure portal の右上にあるフィルター ボタンを選択) を選択して、データを表示するすべてのサブスクリプションを選択できます。 これにより、テナント全体で Log Analytics ワークスペースを選択して、マルチテナント レポートを表示できます。
Site Recovery レポートで使用される規則
レポートには、その当日の部分的なデータは表示されません。 [時間の範囲] を [過去 7 日間] に設定すると、レポートには、当日を除く、過去 7 日間に完了したレコードが表示されます。 レポートには、選択した時間の範囲内でトリガーされたジョブに関する情報が表示されます。
トラブルシューティング
レポートにデータが表示されない場合、または表示内容に相違がある場合は、次の点を確認してください。
- すべてのコンテナーが必要な構成を Log Analytics ワークスペースに送信していることを確認します。
- レポートで適切なフィルターが選択されていることを確認します。
- 診断設定の構成中に初期データのプッシュが完了するまでに最大 24 時間かかるため、レポートにデータがすぐには表示されない場合があることに注意してください。
- レポートにはまる 1 日 (UTC) の期間のみが考慮され、部分的な日は含まれません。 次の例を考えてみましょう。
- 3 月 23 日の午後 4 時 30 分から 3 月 24 日の午前 10 時までの時間の範囲を選択した場合、クエリは 3 月 23 日の午前 12:00 UTC から 3 月 24 日午後 11:59 UTC までの間、内部的に実行されます。 つまり、クエリは datetime の時刻コンポーネントをオーバーライドします。
- 今日の日付が 3 月 29 日の場合、レポートに表示されるデータは、3 月 28 日の終わり (午後 11:59 UTC) までのみになります。 3 月 29 日に作成されたジョブは、翌日の 3 月 30 日まではレポートに表示されません。
上記のいずれでもデータがレポートに表示されない場合は、Microsoft サポートにお問い合わせください。
Power BI レポート
Azure ストレージ アカウントからのデータを情報源とするレポート用の Power BI テンプレート アプリは非推奨です。 代わりにレポートを表示するために、まず Log Analytics へのコンテナーの診断データを送信することをお勧めします。
さらに、ストレージ アカウントまたは LA ワークスペースに診断データを送信するための V1 スキーマも非推奨です。 V1 スキーマを使用してカスタム クエリまたは自動化を作成した場合は、現在サポートされている V2 スキーマを使用するように、それらを更新することをお勧めします。