次の方法で共有

Azure Monitor ログ

  • [アーティクル]

Azure Backup では、Recovery Services コンテナーに組み込みの監視とアラートの機能が提供されています。 これらの機能は、管理インフラストラクチャを追加しなくても使用できます。 この機能の唯一の前提条件は、Log Analytics ワークスペースが構成されていることです。 この機能は、次のシナリオでサポートされています。

  • サブスクリプションにまたがる複数の Recovery Services コンテナーのデータの監視
  • カスタム シナリオの可視化
  • カスタム シナリオ向けのアラートの構成
  • オンプレミス コンポーネントからの情報の閲覧。 例: Azure の System Center Data Protection Manager の情報 (ポータルの [バックアップ ジョブ] や [バックアップ アラート] には表示されない)

Log Analytics ワークスペースを使用する

Log Analytics ワークスペースを使用するための前提条件

監視のために Log Analytics を使用する前に、次の前提条件を考慮してください。

Log Analytics を使用してアラートを作成する

Azure Monitor では、Log Analytics ワークスペースで独自のアラートを作成できます。 ワークスペースで、"Azure アクション グループ" を使用して、優先する通知メカニズムを選択します。

重要

このクエリの作成コストについては、「Azure Monitor の価格」を参照してください。

Log Analytics ワークスペースの [ログ] セクションを開き、独自のログにクエリを作成します。 [新しいアラート ルール] を選択すると、次の図に示すように、Azure Monitor のアラート作成ページが開きます。

Log Analytics ワークスペースでアラートを作成する

ここではリソースが既に Log Analytics ワークスペースとしてマークされており、アクション グループの統合が提供されています。

Log Analytics のアラート作成ページ

アラートの条件

アラートの決定的な特徴は、そのトリガー条件です。 [条件] を選択すると、次の図に示すように、 [ログ] ページに Kusto クエリが自動的に読み込まれます。 ここでは、ニーズに合わせて条件を編集できます。 詳細については、「サンプル Kusto クエリ」を参照してください。

アラート条件を設定する

必要に応じて、Kusto クエリを編集できます。 しきい値、期間、頻度を選択します。 どのような場合にアラートが発生するかは、しきい値によって決まります。 期間は、クエリが実行される時間枠です。 たとえば、しきい値が 0 より大きく、期間が 5 分で頻度が 5 分の場合、そのルールでは、5 分ごとにクエリを実行し、前の 5 分間を確認します。 結果の件数が 0 より大きい場合は、選択したアクション グループを使用して通知されます。

Note

特定の日に作成されたすべてのイベント/ログで、1 日に 1 回アラート ルールを実行するには、'period' と 'frequency' の両方の値を 1440、つまり 24 時間に変更します。

アラートのアクション グループ

アクション グループは、通知チャネルを指定するために使用します。 使用可能な通知メカニズムを確認するには、 [アクション グループ] で [新規作成] を選択します。

[アクション グループの追加] ウィンドウの使用可能な通知メカニズム

アラートと監視のすべての要件を Log Analytics 単独で満たすことも、Log Analytics を使用して組み込みの通知を補うこともできます。

詳細については、「Azure Monitor を使用してログ アラートを作成、表示、管理する」と「Azure Portal でのアクション グループの作成および管理」を参照してください。

サンプル Kusto クエリ

既定のグラフによって基本的なシナリオ用の Kusto クエリが提供されるため、それに基づいてアラートを作成できます。 クエリを変更して、アラートを設定する対象のデータをフェッチすることもできます。 次のサンプル Kusto クエリを [ログ] ページに貼り付け、クエリに対してアラートを作成します。

Recovery Services コンテナーと Backup ボールトは、この記事にリストされている一般的なテーブル セットにデータを送信します。 ただし、Recovery Services コンテナーと Backup ボールトのスキーマには若干の違いがあります (詳細)。 そのため、このセクションは複数のサブセクションに分割されています。これは、クエリを実行するワークロードまたはコンテナーの種類に応じて適切なクエリを使用するのに役立ちます。

Recovery Services コンテナーと Backup ボールト間で共通のクエリ

  • 成功したすべてのバックアップ ジョブ

    AddonAzureBackupJobs
| where JobOperation=="Backup"
| summarize arg_max(TimeGenerated,*) by JobUniqueId
| where JobStatus=="Completed"

  • 失敗したすべてのバックアップ ジョブ

    AddonAzureBackupJobs
| where JobOperation=="Backup"
| summarize arg_max(TimeGenerated,*) by JobUniqueId
| where JobStatus=="Failed"

Recovery Services コンテナーのワークロードに固有のクエリ

  • 成功したすべての Azure VM バックアップ ジョブ

    AddonAzureBackupJobs
| where JobOperation=="Backup"
| summarize arg_max(TimeGenerated,*) by JobUniqueId
| where JobStatus=="Completed"
| join kind=inner
(
    CoreAzureBackup
    | where OperationName == "BackupItem"
    | where BackupItemType=="VM" and BackupManagementType=="IaaSVM"
    | distinct BackupItemUniqueId, BackupItemFriendlyName
)
on BackupItemUniqueId

  • 成功したすべての SQL ログ バックアップ ジョブ

    AddonAzureBackupJobs
| where JobOperation=="Backup" and JobOperationSubType=="Log"
| summarize arg_max(TimeGenerated,*) by JobUniqueId
| where JobStatus=="Completed"
| join kind=inner
(
    CoreAzureBackup
    | where OperationName == "BackupItem"
    | where BackupItemType=="SQLDataBase" and BackupManagementType=="AzureWorkload"
    | distinct BackupItemUniqueId, BackupItemFriendlyName
)
on BackupItemUniqueId

  • 成功したすべての Azure Backup エージェント ジョブ

    AddonAzureBackupJobs
| where JobOperation=="Backup"
| summarize arg_max(TimeGenerated,*) by JobUniqueId
| where JobStatus=="Completed"
| join kind=inner
(
    CoreAzureBackup
    | where OperationName == "BackupItem"
    | where BackupItemType=="FileFolder" and BackupManagementType=="MAB"
    | distinct BackupItemUniqueId, BackupItemFriendlyName
)
on BackupItemUniqueId

  • バックアップ項目ごとに使用されるバックアップ ストレージ

    CoreAzureBackup
//Get all Backup Items
| where OperationName == "BackupItem"
//Get distinct Backup Items
| distinct BackupItemUniqueId, BackupItemFriendlyName
| join kind=leftouter
(AddonAzureBackupStorage
| where OperationName == "StorageAssociation"
//Get latest record for each Backup Item
| summarize arg_max(TimeGenerated, *) by BackupItemUniqueId
| project BackupItemUniqueId , StorageConsumedInMBs)
on BackupItemUniqueId
| project BackupItemUniqueId , BackupItemFriendlyName , StorageConsumedInMBs
| sort by StorageConsumedInMBs desc

Backup ボールトのワークロードに固有のクエリ

  • 成功したすべての Azure PostgreSQL バックアップ ジョブ

    AddonAzureBackupJobs
| where JobOperation=="Backup"
| summarize arg_max(TimeGenerated,*) by JobUniqueId
  | where DatasourceType == "Microsoft.DBforPostgreSQL/servers/databases"
| where JobStatus=="Completed"

  • 成功したすべての Azure ディスク復元ジョブ

    AddonAzureBackupJobs
| where JobOperation == "Restore"
| summarize arg_max(TimeGenerated,*) by JobUniqueId
| where DatasourceType == "Microsoft.Compute/disks"
| where JobStatus=="Completed"

  • バックアップ項目ごとに使用されるバックアップ ストレージ

    CoreAzureBackup
| where OperationName == "BackupItem"
| summarize arg_max(TimeGenerated, *) by BackupItemUniqueId
| project BackupItemUniqueId, BackupItemFriendlyName, StorageConsumedInMBs

診断データの更新頻度

コンテナーの診断データは少し遅れて Log Analytics ワークスペースに送られます。 すべてのイベントは、Recovery Services コンテナーからプッシュされてから "20 分から 30 分" 後に Log Analytics ワークスペースに到着します。 ここでは、その遅れの詳細について説明します。

  • すべてのソリューションについて、バックアップ サービスの組み込みアラートは、作成されるとすぐにプッシュされます。 そのため、通常は 20 分から 30 分後に Log Analytics ワークスペースに表示されます。
  • すべてのソリューションについて、オンデマンド バックアップ ジョブと復元ジョブは、"終了" するとすぐにプッシュされます。
  • すべてのソリューション (SQL バックアップと SAP HANA 以外) について、スケジュール済みバックアップ ジョブは、終了するとすぐにプッシュされます。
  • SQL と SAP HANA のバックアップでは、15 分ごとにログ バックアップを行うことができるため、完了したすべてのスケジュール済みバックアップ ジョブの情報は、ログも含めて 6 時間ごとにバッチ処理されてプッシュされます。
  • すべてのソリューションにわたって、バックアップ項目、ポリシー、復旧ポイント、ストレージなどのその他の情報は、少なくとも "1 日 1 回" プッシュされます。
  • バックアップ構成を変更すると (ポリシーの変更や編集など)、関連するすべてのバックアップ情報のプッシュがトリガーされます。

Note

ストレージアカウントや Event Hubs など、診断データの他の出力先にも同じ遅延が適用されます。

Recovery Services コンテナーのアクティビティ ログを使用する

注意

次の手順は、Azure VM のバックアップにのみ適用されます。Azure Backup エージェント、Azure 内での SQL バックアップ、Azure Files などのソリューションでは、これらの手順は使用できません。

アクティビティ ログを使用して、バックアップ成功などのイベントの通知を受け取ることもできます。 開始するには、次の手順に従います。

  1. Azure Portal にサインインします。
  2. 関連する Recovery Services コンテナーを開きます。
  3. コンテナーのプロパティで、 [アクティビティ ログ] セクションを開きます。

適切なログを指定してアラートを作成するには:

  1. 次の図に示すようにフィルターを適用して、成功したバックアップのアクティビティ ログを受信しているかどうかを確認します。 レコードを表示するために、必要に応じて [期間] の値を変更します。

    Azure VM バックアップのアクティビティ ログを検索するためのフィルター処理

  2. 操作名を選択すると、関連する詳細が表示されます。

  3. [新しいアラート ルール] を選択して [ルールの作成] ページを開きます。

  4. 「Azure Monitor を使用してアクティビティ ログ アラートを作成、表示、管理する」の手順に従って、アラートを作成します。

    新しいアラート ルール

ここで、リソースは Recovery Services コンテナー自体です。 アクティビティ ログを使用して通知を受け取るすべてのコンテナーに対して同じ手順を繰り返します。 このアラートはイベントに基づいているため、この条件にしきい値、期間、または頻度は設定されません。 関連するアクティビティ ログが生成されるとすぐに、アラートが発生します。

Log Analytics を使用した Azure Backup の大規模な監視

Azure Monitor では、アクティビティ ログと Log Analytics ワークスペースから作成されたすべてのアラートを表示できます。 左側の [アラート] ウィンドウを開くだけです。

アクティビティ ログを使用して通知を受け取ることはできますが、大規模な監視にはアクティビティ ログではなく Log Analytics を使用することを強くお勧めします。 理由は次のとおりです。

  • シナリオの制限:アクティビティ ログを使用した通知は、Azure VM バックアップにのみ適用されます。 通知は、Recovery Services コンテナーごとに設定する必要があります。
  • 定義の一致:スケジュール済みバックアップ アクティビティは、アクティビティ ログの最新定義と一致しません。 代わりに、リソース ログと一致します。 この一致によって、アクティビティ ログ チャネルを通過するデータが変更された場合に、予期しない影響が発生します。
  • アクティビティ ログ チャネルの問題:Recovery Services コンテナーでは、Azure Backup から取り込まれたアクティビティ ログは、新しいモデルに従ったものになっています。 残念ながら、この変更は、Azure Government、Azure Germany、および 21Vianet portal によって運営される Microsoft Azure のアクティビティ ログの生成に影響します。 これらのクラウド サービスのユーザーが Azure Monitor のアクティビティ ログからアラートを作成または構成した場合、アラートはトリガーされません。 また、すべての Azure パブリック リージョンにおいて、ユーザーが Recovery Services のアクティビティ ログを Log Analytics ワークスペースに収集した場合、それらのログは表示されません。

Azure Backup で保護されるすべてのワークロードでは、大規模な監視とアラートのためには Log Analytic ワークスペースを使用してください。

次のステップ

カスタム クエリを作成するには、Log Analytics データ モデルに関する記事を参照してください。