你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

使用 Bicep 创建监视资源

Azure 提供了一套全面的工具,可监视应用程序和服务。 在预配 Azure 基础结构时,你可以使用 Bicep 以编程方式创建监视资源,以自动创建规则、诊断设置和警报。

考虑到 Azure 门户中提供了用于设置警报规则、诊断设置和仪表板的工具,将监视配置引入 Bicep 代码中看起来多此一举。

但是,警报和诊断设置在本质上与其他基础结构资源相同。 通过将它们添加到 Bicep 代码中,可以像部署和测试其他 Azure 资源一样部署和测试警报资源。

如果使用 Git 或其他版本控制工具来管理 Bicep 文件,还可以获得保留监视配置历史记录的好处,以便查看警报的设置和配置方式。

Log Analytics 和 Application Insights 工作区

可以使用资源类型 Microsoft.OperationalInsights/workspacesMicrosoft.Insights/components 分别创建 Log Analytics 工作区和 Application Insights 工作区。 这两个组件都部署到资源组。

诊断设置

使用诊断设置可以将 Azure Monitor 配置为将日志和指标导出到多个目标,包括 Log Analytics 和 Azure 存储。

在 Bicep 中创建诊断设置时,请记住,此资源是扩展资源,这意味着它应用于另一个资源。 可以使用资源类型 Microsoft.Insights/diagnosticSettings 在 Bicep 中创建诊断设置。

在 Bicep 中创建诊断设置时,需要应用诊断设置的作用域。 可以在管理、订阅或资源组级别应用诊断设置。 使用此资源的上 scope 属性设置此资源的作用域

请考虑以下示例:

param location string = resourceGroup().location
param appPlanName string = '${uniqueString(resourceGroup().id)}asp'
param logAnalyticsWorkspace string = '${uniqueString(resourceGroup().id)}la'

var appPlanSkuName = 'S1'

resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2023-09-01' existing = {
  name: logAnalyticsWorkspace
}

resource appServicePlan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: appPlanName
  location: location
  sku: {
    name: appPlanSkuName
    capacity: 1
  } 
}

resource diagnosticLogs 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: appServicePlan.name
  scope: appServicePlan
  properties: {
    workspaceId: logAnalytics.id
    logs: [
      {
        category: 'AllMetrics'
        enabled: true
        retentionPolicy: {
          days: 30
          enabled: true 
        }
      }
    ]
  }
}

在前面的示例中,为应用服务计划创建了诊断设置,并将这些诊断发送到 Log Analytics。 可以使用 scope 属性将应用服务计划定义为诊断设置的作用域,并使用 workspaceId 属性来定义要将诊断日志发送到其中的 Log Analytics 工作区。 还可以将诊断设置导出到事件中心和 Azure 存储帐户。

日志类型因资源而异,因此请确保要导出的日志适用于所用的资源。

活动日志诊断设置

若要使用 Bicep 来配置诊断设置以导出 Azure 活动日志,请在订阅范围部署一个诊断设置资源。

以下示例演示如何将多种活动日志类型导出到 Log Analytics 工作区:

targetScope = 'subscription'

param logAnalyticsWorkspaceId string

var activityLogDiagnosticSettingsName = 'export-activity-log'

resource subscriptionActivityLog 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: activityLogDiagnosticSettingsName
  properties: {
    workspaceId: logAnalyticsWorkspaceId
    logs: [
      {
        category: 'Administrative'
        enabled: true
      }
      {
        category: 'Security'
        enabled: true
      }
      {
        category: 'ServiceHealth'
        enabled: true
      }
      {
        category: 'Alert'
        enabled: true
      }
      {
        category: 'Recommendation'
        enabled: true
      }
      {
        category: 'Policy'
        enabled: true
      }
      {
        category: 'Autoscale'
        enabled: true
      }
      {
        category: 'ResourceHealth'
        enabled: true
      }
    ]
  }
}

警报

当通过监视 Azure Monitor 中的数据在 Azure 基础结构和应用程序中发现问题时,警报会主动通知你。 通过在 Bicep 代码中配置监视和警报配置,可以自动创建这些警报以及在 Azure 中预配的基础结构。

有关 Azure 中的警报工作原理的详细信息,请参阅 Microsoft Azure 中的警报概述

下面的部分演示如何使用 Bicep 代码配置不同类型的警报。

操作组

若要在触发警报时收到通知,需要创建操作组。 操作组是由 Azure 订阅所有者定义的通知首选项的集合。 操作组用于通知用户已触发警报,或触发对警报的自动响应。

若要在 Bicep 中创建操作组,可以使用类型 Microsoft.Insights/actionGroups。 下面是一个示例:

param actionGroupName string = 'On-Call Team'
param location string = resourceGroup().location

var actionGroupEmail = 'oncallteam@contoso.com'

resource supportTeamActionGroup 'Microsoft.Insights/actionGroups@2023-01-01' = {
  name: actionGroupName
  location: location
  properties: {
    enabled: true
    groupShortName: actionGroupName
    emailReceivers: [
      {
        name: actionGroupName
        emailAddress: actionGroupEmail
        useCommonAlertSchema: true
      }
    ]
  }
}

前面的示例创建了一个向电子邮件地址发送警报的操作组,但也可以定义向事件中心、Azure Functions、逻辑应用等发送警报的操作组。

警报处理规则

警报处理规则(以前称为操作规则)允许对已触发的警报应用处理。 可以使用类型 Microsoft.AlertsManagement/actionRules 在 Bicep 中创建警报处理规则。

每个警报处理规则都有一个范围,可以是一个或多个特定资源的列表、特定资源组或整个 Azure 订阅。 在 Bicep 中定义警报处理规则时,可以在 scope 属性中定义资源 ID 列表,该列表面向警报处理规则的那些资源。

param alertRuleName string = 'AlertRuleName'
param actionGroupName string = 'On-Call Team'
param location string = resourceGroup().location

resource actionGroup 'Microsoft.Insights/actionGroups@2023-09-01-preview' existing = {
  name: actionGroupName
}

resource alertProcessingRule 'Microsoft.AlertsManagement/actionRules@2023-05-01-preview' = {
  name: alertRuleName
  location: location
  properties: {
    actions: [
      {
        actionType: 'AddActionGroups'
        actionGroupIds: [
          actionGroup.id
        ]
      }
    ]
    conditions: [
      {
        field: 'MonitorService'
        operator: 'Equals'
        values: [
          'Azure Backup'
        ]
      }
    ]
    enabled: true
    scopes: [
      subscription().id
    ]
  }
}

在前面的示例中,定义了 Azure 备份保管库上的 MonitorService 警报处理规则,该规则应用于现有操作组。 此规则会触发操作组的警报。

日志警报规则

日志警报会自动运行 Log Analytics 查询。 该查询用于按定义的时间间隔评估资源日志,确定结果是否满足指定的一些条件,然后触发警报。

可以在 Bicep 中使用类型 Microsoft.Insights/scheduledQueryRules 创建日志警报规则。

指标警报规则

当某个指标超过定义的阈值时,指标警报会通知你。 可以使用类型 Microsoft.Insights/metricAlerts 在 Bicep 代码中定义指标警报规则。

活动日志警报

Azure 活动日志是 Azure 中的一种平台日志,提供对订阅级别事件的见解。 这包括何时修改了 Azure 中的资源等信息。

活动日志警报是当新发生的活动日志事件与警报中指定的条件匹配时激活的警报。

可以在类型 Microsoft.Insights/activityLogAlerts 中使用 scope 属性,针对特定资源或使用资源 ID 作为前缀的资源列表创建活动日志警报。

condition 属性中定义警报规则条件,然后使用 actionGroup 数组配置要针对其触发这些警报的警报组。 可以在此处传递要向其发送活动日志警报的单个或多个操作组,具体取决于你的需求。

param activityLogAlertName string = '${uniqueString(resourceGroup().id)}-alert'
param actionGroupName string = 'adminactiongroup'

resource actionGroup 'Microsoft.Insights/actionGroups@2023-09-01-preview' existing = {
  name: actionGroupName
}

resource activityLogAlert 'Microsoft.Insights/activityLogAlerts@2023-01-01-preview' = {
  name: activityLogAlertName
  location: 'Global'
  properties: {
    condition: {
      allOf: [
        {
          field: 'category'
          equals: 'Administrative'
        }
        {
          field: 'operationName'
          equals: 'Microsoft.Resources/deployments/write'
        }
        {
          field: 'resourceType'
          equals: 'Microsoft.Resources/deployments'
        }
      ]
    }
    actions: {
      actionGroups: [
        {
          actionGroupId: actionGroup.id
        }
      ]
    }
    scopes: [
      subscription().id
    ]
  }
}

资源运行状况警报

通过 Azure 资源运行状况可得知 Azure 资源的当前及历史运行状况。 通过使用 Bicep 创建资源运行状况警报,可以批量创建和自定义这些警报。

在 Bicep 中,可以使用类型 Microsoft.Insights/activityLogAlerts 创建资源运行状况警报。

可以将资源运行状况警报配置为监视订阅、资源组或单个资源级别的事件。

请考虑以下示例,你在其中创建了报告服务运行状况警报的资源运行状况警报。 警报在订阅级别应用(使用 scope 属性),并将警报发送到现有操作组:

param activityLogAlertName string = uniqueString(resourceGroup().id)
param actionGroupName string = 'oncallactiongroup'

resource actionGroup 'Microsoft.Insights/actionGroups@2023-09-01-preview' existing = {
  name: actionGroupName
}

resource resourceHealthAlert 'Microsoft.Insights/activityLogAlerts@2023-01-01-preview' = {
  name: activityLogAlertName
  location: 'global'
  properties: {
    condition: {
      allOf: [
        {
          field: 'category'
          equals: 'ServiceHealth'
        }
      ]
    }
    scopes: [
      subscription().id
    ]
    actions: {
      actionGroups: [
        {
          actionGroupId: actionGroup.id
        }
      ]
    }
  }
}

智能检测警报

当 Web 应用程序中存在潜在性能问题和故障异常时,智能检测警报会向你发出警告。 可以使用类型 Microsoft.AlertsManagement/smartDetectorAlertRules 在 Bicep 中创建智能检测警报。

仪表板

在 Bicep 中,可以使用资源类型 Microsoft.Portal/dashboards 创建门户仪表板。

有关使用代码创建仪表板的详细信息,请参阅以编程方式创建 Azure 仪表板

自动缩放规则

若要创建自动缩放设置,请使用资源类型 Microsoft.Insights/autoscaleSettings 定义这些设置。

若要将自动缩放设置应用到的资源作为目标,需要提供应向其添加设置的资源的目标资源标识符。

在此示例中,应用服务计划的横向扩展条件基于 10 分钟时段内的平均 CPU 百分比。 如果应用服务计划在 10 分钟内超过 70% 的平均 CPU 消耗,则自动缩放引擎通过添加一个实例来横向扩展该计划。

param location string = resourceGroup().location
param appPlanName string = '${uniqueString(resourceGroup().id)}asp'

var appPlanSkuName = 'S1'

resource appServicePlan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: appPlanName
  location: location
  properties: {}
  sku: {
    name: appPlanSkuName
    capacity: 1
  }
}

resource scaleOutRule 'Microsoft.Insights/autoscalesettings@2022-10-01' = {
  name: appServicePlan.name
  location: location
  properties: {
    enabled: true
    profiles: [
      {
        name: 'Scale out condition'
        capacity: {
          maximum: '3'
          default: '1'
          minimum: '1'
        }
        rules: [
          {
            scaleAction: {
              type: 'ChangeCount'
              direction: 'Increase'
              cooldown: 'PT5M'
              value: '1'
            }
            metricTrigger: {
              metricName: 'CpuPercentage'
              operator: 'GreaterThan'
              timeAggregation: 'Average'
              threshold: 70
              metricResourceUri: appServicePlan.id
              timeWindow: 'PT10M'
              timeGrain: 'PT1M'
              statistic: 'Average'
            }
          }
        ]
      }
    ]
    targetResourceUri: appServicePlan.id
  }
}

注意

定义自动缩放规则时,请牢记最佳做法,以避免尝试自动缩放时出现问题,例如不稳定。 有关详细信息,请参阅以下有关自动缩放最佳做法的文档。