使用 Azure Monitor 进行大规模监视

Azure 备份在恢复服务保管库中提供内置的监视和警报功能。 无需任何附加的管理基础结构即可使用这些功能。 但是，仅限在以下方案中使用此内置服务：

• 监视不同订阅中多个恢复服务保管库中的数据
• 首选的通知通道不是电子邮件
• 用户想要接收更多方案的警报
• 在 Azure 中查看来自本地组件（例如 System Center Data Protection Manager）的信息。门户不会在备份作业或备份警报中显示这些信息

使用 Log Analytics 工作区

使用 Log Analytics 创建警报

在 Azure Monitor 中，可以在 Log Analytics 工作区内创建你自己的警报。 在工作区中，可以使用 Azure 操作组来选择首选的通知机制。

打开 Log Analytics 工作区的“日志”部分，并为自己的日志创建查询。 选择“新建警报规则”时，将打开 Azure Monitor 警报创建页，如下图所示。

此处的资源已标记为 Log Analytics 工作区，并提供了操作组集成。

警报条件

警报的定义特征是其触发条件。 选择“条件”可在“日志”页上自动加载 Kusto 查询，如下图所示。 在此处可根据需要编辑条件。 有关详细信息，请参阅示例 Kusto 查询。

如果需要，可以编辑 Kusto 查询。 选择阈值、期限和频率。 阈值确定何时引发警报。 期限是运行查询的时间范围。 例如，如果阈值大于 0，期限为 5 分钟，频率为 5 分钟，那么，该规则将每隔 5 分钟运行一次查询，并检查前 5 分钟的数据。 如果结果数大于 0，则系统将通过所选的操作组通知你。

警报操作组

使用操作组指定通知通道。 若要查看可用的通知机制，请在“操作组”下选择“新建”。

单纯地在 Log Analytics 中就能满足所有的警报和监视要求；你也可以使用 Log Analytics 来补充内置通知。

有关详细信息，请参阅使用 Azure Monitor 创建、查看和管理日志警报以及在 Azure 门户中创建和管理操作组。

示例 Kusto 查询

默认图形提供可对其生成警报的基本方案的 Kusto 查询。 此外，你还可以修改查询，以提取要向其发出警报的数据。 在“日志”页中粘贴以下 Kusto 查询示例，然后在查询上创建警报。

恢复服务保管库和备份保管库会将数据发送到本文中列出的一组常见表。 但是，恢复服务保管库和备份保管库的架构略有不同（了解详细信息）。 因此，此部分拆分为多个子部分，可帮助你根据要查询的工作负荷或保管库类型使用正确的查询。

跨恢复服务保管库和备份保管库的常见查询

• 所有成功的备份作业

  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"
  

特定于恢复服务保管库工作负荷的查询

• 所有成功的 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 备份代理作业

  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
  

特定于备份保管库工作负荷的查询

• 所有成功的 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 工作区，但会出现一定的延迟。 从恢复服务保管库推送每个事件 20 到 30 分钟后，这些事件将抵达 Log Analytics 工作区。 下面是有关延迟的更多详细信息：

• 在所有解决方案中，一旦创建备份服务的内置警报，就会立即推送这些警报。 因此，它们通常会在 20 到 30 分钟后显示在 Log Analytics 工作区中。
• 在所有解决方案中，在完成按需备份作业和还原作业后，会立即推送这些作业。
• 对于除 SQL 和 SAP HANA 备份以外的所有解决方案，计划的备份作业会在完成后立即推送。
• 对于 SQL 和 SAP HANA 备份，由于日志备份可能每 15 分钟执行一次，因此所有已完成的计划备份作业（包括日志）的信息每 6 小时进行一次批量推送。
• 在所有解决方案中，备份项、策略、恢复点、存储等其他信息每天至少推送一次。
• 备份配置发生更改（例如更改策略或编辑策略）会触发所有相关备份信息的推送。

使用恢复服务保管库的活动日志

还可以使用活动日志来获取事件通知，例如备份成功。 遵循以下步骤开始：

1. 登录 Azure 门户。
2. 打开相关的恢复服务保管库。
3. 在保管库的属性中，打开“活动日志”部分。

若要识别相应的日志并创建警报：

1. 应用下图中所示的筛选器，验证是否能够接收成功备份的活动日志。 根据需要更改“时间跨度”值以查看记录。

   

2. 选择操作名称以查看相关详细信息。

3. 选择“新建警报规则”打开“创建规则”页。

4. 遵循使用 Azure Monitor 创建、查看和管理活动日志警报中的步骤创建警报。

   

此处的资源是恢复服务保管库本身。 请针对要在其中通过活动日志接收通知的所有保管库重复相同的步骤。 条件中不包含阈值、期限或频率，因为此警报基于事件。 生成相关的活动日志后，会立即引发警报。

使用 Log Analytics 进行大规模监视

可以在 Azure Monitor 中查看从活动日志和 Log Analytics 工作区创建的所有警报。 只需打开左侧的“警报”窗格即可。

尽管你可以通过活动日志获取通知，但我们强烈建议使用 Log Analytics（而不是活动日志）进行大规模监视。 原因如下：

• 方案受限：通过活动日志发送通知仅适用于 Azure VM 备份。 必须为每个恢复服务保管库设置通知。
• 定义适应：计划的备份活动不能适应活动日志的最新定义。 相反，它适用于资源日志。 当通过活动日志通道传送数据发生变化时，这种相符性会导致意外的影响。
• 活动日志通道问题：在恢复服务保管库中，从 Azure 备份抽取的活动日志将遵循新模型。 遗憾的是，此项更改会影响由世纪互联运营的 Microsoft Azure 中活动日志的生成。 如果这些云服务的用户在 Azure Monitor 中基于活动日志创建或配置了任何警报，将不会触发警报。

使用 Log Analytics 工作区可对 Azure 备份保护的所有工作负荷进行大规模监视和发出警报。

后续步骤

若要创建自定义查询，请参阅 Log Analytics 数据模型。