Freigeben über

Erstellen von Überwachungsressourcen mithilfe von Bicep

  • Artikel

Azure verfügt über eine umfassende Sammlung von Tools, die Ihre Anwendungen und Dienste überwachen können. Sie können Ihre Überwachungsressourcen programmgesteuert mithilfe von Bicep erstellen, um die Erstellung von Regeln, Diagnoseeinstellungen und Warnungen beim Bereitstellen Ihrer Azure-Infrastruktur zu automatisieren.

Die Einführung Ihrer Überwachungskonfiguration in Ihren Bicep-Code mag ungewöhnlich erscheinen, in Anbetracht dessen, dass es Tools innerhalb der Azure-Portal gibt, mit denen Sie Warnungsregeln, Diagnoseeinstellungen und Dashboards einrichten können.

Warnungen und Diagnoseeinstellungen sind allerdings im Wesentlichen identisch mit Ihren anderen Infrastrukturressourcen. Wenn Sie sie in Ihren Bicep-Code aufnehmen, können Sie Ihre Warnungsressourcen, wie für andere Azure-Ressourcen auch, bereitstellen und testen.

Wenn Sie Git oder ein anderes Versionskontrolltool zum Verwalten Ihrer Bicep-Dateien verwenden, erhalten Sie auch den Vorteil, dass Sie einen Verlauf Ihrer Überwachungskonfiguration besitzen, über den Sie feststellen können, wie Warnungen eingerichtet und konfiguriert wurden.

Log Analytics- und Application Insights-Arbeitsbereiche

Sie können Log Analytics-Arbeitsbereiche mit dem Ressourcentyp "Microsoft.OperationalInsights/workspaces und Application Insights-Arbeitsbereiche mit dem Typ Microsoft.Insights/components erstellen. Beide Komponenten werden in Ressourcengruppen bereitgestellt.

Diagnoseeinstellungen

Mithilfe von Diagnoseeinstellungen können Sie Azure Monitor so konfigurieren, dass Ihre Protokolle und Metriken in eine Reihe von Zielen exportiert werden, darunter Log Analytics und Azure Storage.

Denken Sie beim Erstellen von Diagnoseeinstellungen in Bicep daran, dass diese Ressource eine Erweiterungsressource ist, was bedeutet, dass sie auf eine andere Ressource angewendet wird. Sie können Diagnoseeinstellungen in Bicep mithilfe des Ressourcentyps Microsoft.Insights/diagnosticSettings erstellen.

Beim Erstellen von Diagnoseeinstellungen in Bicep müssen Sie den Bereich der Diagnoseeinstellung anwenden. Die Diagnoseeinstellung kann auf Verwaltungs-, Abonnement- oder Ressourcengruppenebene angewendet werden. Verwenden Sie die Bereichseigenschaft für diese Ressource, um den Bereich für diese Ressource festzulegen.

Betrachten Sie das folgende Beispiel:

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

Im vorherigen Beispiel erstellen Sie eine Diagnoseeinstellung für den App Service-Plan und senden diese Diagnose an Log Analytics. Sie können die scope-Eigenschaft verwenden, um Ihren App Service-Plan als den Bereich für Ihre Diagnoseeinstellung zu definieren, und mit der workspaceId-Eigenschaft können Sie den Log Analytics-Arbeitsbereich definieren, an den die Diagnoseprotokolle gesendet werden sollen. Sie können Diagnoseeinstellungen auch nach Event Hubs und Azure Storage-Konten exportieren.

Protokolltypen unterscheiden sich je nach Ressource. Stellen Sie daher sicher, dass die Protokolle, die Sie exportieren möchten, auf die verwendete Ressource anwendbar sind.

Diagnoseeinstellungen für Aktivitätsprotokolle

Um Diagnoseeinstellungen mithilfe von Bicep für den Export des Azure-Aktivitätsprotokolls zu konfigurieren, stellen Sie eine Diagnoseeinstellungsressource im Abonnementbereich bereit.

Im folgenden Beispiel wird gezeigt, wie mehrere Aktivitätsprotokolltypen in einen Log Analytics-Arbeitsbereich exportiert werden:

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

Alerts

Warnungen benachrichtigen Sie proaktiv, wenn Probleme in Ihrer Azure-Infrastruktur und den Azure-Anwendungen gefunden werden, indem Daten in Azure Monitor überwacht werden. Durch die Konfiguration Ihrer Überwachungs- und Warnungskonfiguration in Ihrem Bicep-Code können Sie die Erstellung dieser Warnungen parallel zu der Infrastruktur automatisieren, die Sie in Azure bereitstellen.

Weitere Informationen zur Funktionsweise von Warnungen in Azure finden Sie unter Übersicht über Warnungen in Microsoft Azure.

In den folgenden Abschnitten wird veranschaulicht, wie Sie verschiedene Arten von Warnungen mithilfe von Bicep-Code konfigurieren können.

Aktionsgruppen

Um benachrichtigt zu werden, wenn Warnungen ausgelöst wurden, müssen Sie eine Aktionsgruppe erstellen. Eine Aktionsgruppe ist eine Sammlung von Benachrichtigungseinstellungen, die vom Besitzer eines Azure-Abonnements definiert wurden. Aktionsgruppen werden verwendet, um Benutzer darüber zu informieren, dass eine Warnung ausgelöst wurde, oder um automatisierte Antworten auf Warnungen auszulösen.

Zum Erstellen von Aktionsgruppen in Bicep können Sie den Typ Microsoft.Insights/actionGroups verwenden. Ein Beispiel:

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

Im vorherigen Beispiel wird eine Aktionsgruppe erstellt, die Warnungen an eine E-Mail-Adresse sendet, aber Sie können auch Aktionsgruppen definieren, die Warnungen an Event Hubs, Azure Functions, Logic Apps und mehr senden.

Warnungsverarbeitungsregeln

Mit Warnungsverarbeitungsregeln (zuvor als Aktionsregeln bezeichnet) können Sie die Verarbeitung auf Warnungen anwenden, die ausgelöst wurden. Sie können Warnungsverarbeitungsregeln in Bicep mithilfe des Typs Microsoft.AlertsManagement/actionRules erstellen.

Jede Warnungsverarbeitungsregel besitzt einen Bereich, der eine Liste einer oder mehrerer spezifischer Ressourcen, eine bestimmte Ressourcengruppe oder Ihr gesamtes Azure-Abonnement sein kann. Wenn Sie Warnungsverarbeitungsregeln in Bicep definieren, definieren Sie eine Liste mit Ressourcen-IDs in der scope-Eigenschaft (Bereich), die auf diese Ressourcen für die Warnungsverarbeitungsregel abzielt.

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

Im vorherigen Beispiel wird die Warnungsverarbeitungsregel MonitorService für den Azure Backup-Tresor definiert, die auf die vorhandene Aktionsgruppe angewendet wird. Diese Regel löst Warnungen an die Aktionsgruppe aus.

Protokollwarnungsregeln

Protokollwarnungen führen automatisch eine Log Analytics-Abfrage aus. Die Abfrage, die zum Auswerten von Ressourcenprotokollen in einem von Ihnen definierten Intervall verwendet wird, bestimmt, ob die Ergebnisse von Ihnen angegebene Kriterien erfüllen, und löst dann eine Warnung aus.

Sie können Protokollwarnungsregeln in Bicep mithilfe des Typs Microsoft.Insights/scheduledQueryRules erstellen.

Metrikwarnungsregeln

Metrikwarnungen benachrichtigen Sie, wenn eine Ihrer Metriken einen definierten Schwellenwert überschreitet. Sie können eine Metrikwarnungsregel in Ihrem Bicep-Code mithilfe des Typs Microsoft.Insights/metricAlerts definieren.

Aktivitätsprotokollwarnungen

Das Aktivitätsprotokollist ein Plattformprotokoll in Azure, das Erkenntnisse über Ereignisse auf Abonnementebene gewährt. Dies umfasst Informationen, z. B. wenn eine Ressource in Azure geändert wird.

Aktivitätsprotokollwarnungen sind Warnungen, die aktiviert werden, wenn ein neues Aktivitätsprotokollereignis eintritt, das die in der Warnung angegebenen Bedingungen erfüllt.

Sie können die scope-Eigenschaft innerhalb des Typs Microsoft.Insights/activityLogAlerts verwenden, um Aktivitätsprotokollwarnungen für eine bestimmte Ressource oder für eine Liste von Ressourcen zu erstellen, indem Sie die Ressourcen-IDs als Präfix verwenden.

Sie definieren Ihre Warnungsregelbedingungen innerhalb der condition-Eigenschaft und konfigurieren dann die Warnungsgruppe, an die diese Warnungen ausgelöst werden sollen, indem Sie das actionGroup-Array verwenden. Hier können Sie je nach Ihren Anforderungen eine einzelne oder mehrere Aktionsgruppen übergeben, an die Aktivitätsprotokollwarnungen gesendet werden sollen.

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

Ressourcenintegritätsbenachrichtigungen

Azure Resource Health informiert Sie über den aktuellen und den vergangenen Integritätsstatus Ihrer Azure-Ressourcen. Durch das Erstellen Ihrer Resource Health-Warnungen mithilfe von Bicep können Sie diese Warnungen massenweise erstellen und anpassen.

In Bicep können Sie Resource Health-Warnungen mit dem Typ Microsoft.Insights/activityLogAlerts erstellen.

Resource Health-Warnungen können so konfiguriert werden, dass Ereignisse auf der Ebene eines Abonnements, einer Ressourcengruppe oder einer einzelnen Ressource überwacht werden.

Betrachten Sie das folgende Beispiel, in dem Sie eine Resource Health-Warnung erstellen, die Service Health-Warnungen meldet. Die Warnung wird auf Abonnementebene (mithilfe der scope-Eigenschaft) angewendet und sendet Warnungen an eine vorhandene Aktionsgruppe:

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

Warnungen der intelligenten Erkennung

Warnungen der intelligenten Erkennung warnen Sie vor potenziellen Leistungsproblemen und Fehleranomalien in Ihrer Webanwendung. Sie können Warnungen der intelligenten Erkennung in Bicep mithilfe des Typs Microsoft.AlertsManagement/smartDetectorAlertRules erstellen.

Dashboards

In Bicep können Sie Portaldashboards mithilfe des Ressourcentyps Microsoft.Portal/Dashboards erstellen.

Weitere Informationen über das Erstellen von Dashboards mit Code finden Sie unter Programmgesteuertes Erstellen eines Azure-Dashboards.

Autoskalierungsregeln

Zum Erstellen einer automatischen Skalierungseinstellung definieren Sie diese mithilfe des Ressourcentyps Microsoft.Insights/autoscaleSettings.

Um die Ressource, auf die die Einstellung für die automatische Skalierung angewendet werden soll, als Ziel zu verwenden, müssen Sie den Zielressourcenbezeichner der Ressource angeben, der die Einstellung hinzugefügt werden soll.

In diesem Beispiel eine Bedingung für das Aufskalieren für den App Service-Plan, basierend auf dem durchschnittlichen CPU-Prozentsatz über einen Zeitraum von 10 Minuten. Wenn der App Service-Plan den durchschnittlichen CPU-Verbrauch von 70 % 10 Minuten lang überschreitet, skaliert das Autoskalierungsmodul den Plan auf, indem eine Instanz hinzugefügt wird.

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

Hinweis

Beachten Sie beim Definieren von Autoskalierungsregeln bewährte Methoden, um Probleme bei der Autoskalierung zu vermeiden, z. B. Fluktuation. Weitere Informationen finden Sie in der folgenden Dokumentation zu bewährten Methoden für die Autoskalierung.