Creare risorse di monitoraggio usando Bicep

  • Articolo

Azure offre una suite completa di strumenti in grado di monitorare le applicazioni e i servizi. È possibile creare risorse di monitoraggio a livello di codice usando Bicep per automatizzare la creazione di regole, impostazioni di diagnostica e avvisi durante il provisioning dell'infrastruttura di Azure.

L'inserimento della configurazione di monitoraggio nel codice Bicep potrebbe sembrare insolito, considerando che nel portale di Azure sono disponibili strumenti per configurare regole di avviso, impostazioni di diagnostica e dashboard.

Tuttavia, gli avvisi e le impostazioni di diagnostica sono essenzialmente gli stessi delle altre risorse dell'infrastruttura. Includendoli nel codice Bicep, è possibile distribuire e testare le risorse di avviso come si farebbe per altre risorse di Azure.

Se si usa Git o un altro strumento di controllo della versione per gestire i file Bicep, si ottiene anche il vantaggio di avere una cronologia della configurazione di monitoraggio in modo da poter vedere come sono stati impostati e configurati gli avvisi.

Aree di lavoro Log Analytics e Application Insights

È possibile creare aree di lavoro Log Analytics con il tipo di risorsa Microsoft.OperationalInsights/workspaces e le aree di lavoro di Application Insights con il tipo Microsoft.Insights/components. Entrambi questi componenti vengono distribuiti nei gruppi di risorse.

Impostazioni di diagnostica

Le impostazioni di diagnostica consentono di configurare Monitoraggio di Azure per esportare i log e le metriche in diverse destinazioni, tra cui Log Analytics e Archiviazione di Azure.

Quando si creano impostazioni di diagnostica in Bicep, tenere presente che questa risorsa è una risorsa di estensione, ovvero viene applicata a un'altra risorsa. È possibile creare impostazioni di diagnostica in Bicep usando il tipo di risorsa Microsoft.Insights/diagnosticSettings.

Quando si creano impostazioni di diagnostica in Bicep, è necessario applicare l'ambito dell'impostazione di diagnostica. L'impostazione di diagnostica può essere applicata a livello di gestione, sottoscrizione o gruppo di risorse. Usare la proprietà scope in questa risorsa per impostare l'ambito per questa risorsa.

Si consideri l'esempio seguente:

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 
        }
      }
    ]
  }
}

Nell'esempio precedente si crea un'impostazione di diagnostica per il piano di servizio app e si invia la diagnostica a Log Analytics. È possibile usare la proprietà scope per definire il piano di servizio app come ambito per l'impostazione di diagnostica e usare la proprietà workspaceId per definire l'area di lavoro Log Analytics a cui inviare i log di diagnostica. È anche possibile esportare le impostazioni di diagnostica in Hub eventi e in account di archiviazione di Azure.

I tipi di log differiscono tra le risorse, quindi assicurarsi che i log da esportare siano applicabili per la risorsa in uso.

Impostazioni di diagnostica del log attività

Per usare Bicep per configurare le impostazioni di diagnostica per esportare il log attività di Azure, distribuire una risorsa delle impostazioni di diagnostica nell'ambito della sottoscrizione.

L'esempio seguente illustra come esportare diversi tipi di log attività in un'area di lavoro 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
      }
    ]
  }
}

Avvisi

Gli avvisi segnalano in modo proattivo quando vengono rilevati problemi all'interno dell'infrastruttura e delle applicazioni di Azure monitorando i dati in Monitoraggio di Azure. Configurando la configurazione del monitoraggio e degli avvisi all'interno del codice Bicep, è possibile automatizzare la creazione di questi avvisi insieme all'infrastruttura di cui si effettua il provisioning in Azure.

Per altre informazioni sul funzionamento degli avvisi in Azure, vedere Panoramica degli avvisi in Microsoft Azure.

Le sezioni seguenti illustrano come configurare diversi tipi di avvisi usando il codice Bicep.

Gruppi di azioni

Per ricevere una notifica quando sono stati attivati gli avvisi, è necessario creare un gruppo di azioni. Un gruppo di azioni è una raccolta delle preferenze di notifica definite dal proprietario di una sottoscrizione di Azure. I gruppi di azioni vengono usati per notificare agli utenti che è stato attivato un avviso o per attivare risposte automatiche agli avvisi.

Per creare gruppi di azioni in Bicep, è possibile usare il tipo Microsoft.Insights/actionGroups. Ecco un esempio:

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
      }
    ]
  }
}

L'esempio precedente crea un gruppo di azioni che invia avvisi a un indirizzo di posta elettronica, ma è anche possibile definire gruppi di azioni che inviano avvisi a Hub eventi, Funzioni di Azure, App per la logica e altro ancora.

Regole di elaborazione degli avvisi

Le regole di elaborazione degli avvisi (definite in precedenza regole di azione) consentono di applicare l'elaborazione agli avvisi attivati. È possibile creare regole di elaborazione degli avvisi in Bicep usando il tipo Microsoft.AlertsManagement/actionRules.

Ogni regola di elaborazione degli avvisi ha un ambito, che può essere un elenco di una o più risorse specifiche, un gruppo di risorse specifico o l'intera sottoscrizione di Azure. Quando si definiscono le regole di elaborazione degli avvisi in Bicep, si definisce un elenco di ID risorsa nella proprietà ambito, destinata a tali risorse per la regola di elaborazione degli avvisi.

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
    ]
  }
}

Nell'esempio precedente viene definita la regola di elaborazione degli avvisi MonitorService nell'insieme di credenziali di Backup di Azure, che viene applicata al gruppo di azioni esistente. Questa regola attiva gli avvisi per il gruppo di azioni.

Regole di avviso per i log

Gli avvisi del log eseguono automaticamente una query di Log Analytics. La query usata per valutare i log delle risorse a un intervallo definito dall'utente determina se i risultati soddisfano alcuni criteri specificati e quindi genera un avviso.

È possibile creare regole di avviso del log in Bicep usando il tipo Microsoft.Insights/scheduledQueryRules.

Regole di avviso per le metriche

Gli avvisi delle metriche segnalano quando una delle metriche supera una soglia definita. È possibile definire una regola di avviso delle metriche nel codice Bicep usando il tipo Microsoft.Insights/metricAlerts.

Avvisi dei log attività

Il log attività di Azure è un log della piattaforma in Azure che fornisce informazioni dettagliate sugli eventi a livello di sottoscrizione. Sono incluse informazioni come quando una risorsa in Azure viene modificata.

Gli avvisi del log attività sono avvisi attivati quando si verifica un nuovo evento del log attività che corrisponde alle condizioni specificate nell'avviso.

È possibile usare la proprietà scope all'interno del tipo Microsoft.Insights/activityLogAlerts per creare avvisi del log attività in una risorsa specifica o in un elenco di risorse usando gli ID risorsa come prefisso.

È possibile definire le condizioni della regola di avviso all'interno della proprietà condition e quindi configurare il gruppo di avvisi per attivare questi avvisi usando la matrice di actionGroup. Qui è possibile passare un singolo o più gruppi di azioni a cui inviare avvisi del log attività, a seconda dei propri requisiti.

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
    ]
  }
}

Avvisi sull'integrità delle risorse

Integrità risorse di Azure comunica lo stato di integrità attuale e cronologico delle risorse di Azure. Creando gli avvisi di integrità delle risorse usando Bicep, è possibile creare e personalizzare questi avvisi in blocco.

In Bicep è possibile creare avvisi di integrità delle risorse con il tipo Microsoft.Insights/activityLogAlerts.

Gli avvisi di integrità delle risorse possono essere configurati per monitorare gli eventi a livello di sottoscrizione, gruppo di risorse o singola risorsa.

Si consideri l'esempio seguente, in cui si crea un avviso di integrità delle risorse che segnala gli avvisi di integrità dei servizi. L'avviso viene applicato a livello di sottoscrizione (usando la proprietà scope) e invia avvisi a un gruppo di azioni esistente:

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
        }
      ]
    }
  }
}

Avvisi del rilevamento intelligente

Gli avvisi di rilevamento intelligente segnalano potenziali problemi di prestazioni e anomalie degli errori nell'applicazione Web. È possibile creare avvisi di rilevamento intelligente in Bicep usando il tipo Microsoft.AlertsManagement/smartDetectorAlertRules.

Dashboard

In Bicep è possibile creare dashboard del portale usando il tipo di risorsa Microsoft.Portal/dashboards.

Per altre informazioni sulla creazione di dashboard con codice, vedere creare un dashboard di Azure a livello di codice.

Regole di scalabilità automatica

Per creare un'impostazione di scalabilità automatica, definirli usando il tipo di risorsa Microsoft.Insights/autoscaleSettings.

Per specificare come destinazione la risorsa a cui si vuole applicare la scalabilità automatica, è necessario specificare l'identificatore della risorsa di destinazione a cui deve essere aggiunta l'impostazione.

In questo esempio, una condizione di aumento per il piano di servizio app in base alla percentuale media della CPU in un periodo di tempo di 10 minuti. Se il piano di servizio app supera il 70% del consumo medio della CPU in più di 10 minuti, il motore di scalabilità automatica aumenta il numero di istanze del piano aggiungendo un'istanza.

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
  }
}

Nota

Quando si definiscono regole di scalabilità automatica, tenere presenti le procedure consigliate per evitare problemi durante il tentativo di ridimensionamento automatico, ad esempio il flapping. Per altre informazioni, vedere la documentazione seguente sulle procedure consigliate per la scalabilità automatica.