Partager via

Créer des ressources de monitoring à l’aide de Bicep

  • Article

Azure dispose d’une suite complète d’outils qui peuvent superviser vos applications et services. Vous pouvez créer par programmation vos ressources de monitoring à l’aide de Bicep pour automatiser la création de règles, de paramètres de diagnostic et d’alertes lors du provisionnement de votre infrastructure Azure.

L’ajout de votre configuration de monitoring dans votre code Bicep peut sembler inhabituel, étant donné que des outils sont disponibles dans le Portail Azure pour configurer des règles d’alerte, des paramètres de diagnostic et des tableaux de bord.

Toutefois, les alertes et les paramètres de diagnostic sont essentiellement identiques à vos autres ressources d’infrastructure. En les incluant dans votre code Bicep, vous pouvez déployer et tester vos ressources d’alerte comme vous le feriez pour d’autres ressources Azure.

Si vous utilisez Git ou un autre outil de gestion de versions pour gérer vos fichiers Bicep, vous bénéficiez également de l’historique de votre configuration de monitoring pour pouvoir voir comment les alertes ont été définies et configurées.

Espaces de travail Log Analytics et Application Insights

Vous pouvez créer des espaces de travail Log Analytics avec le type de ressource Microsoft.OperationalInsights/workspaces et des espaces de travail Application Insights avec le type Microsoft.Insights/components. Ces deux composants sont déployés sur des groupes de ressources.

Paramètres de diagnostic

Les paramètres de diagnostic vous permettent de configurer Azure Monitor pour exporter vos journaux et métriques vers un certain nombre de destinations, notamment Log Analytics et Stockage Azure.

Lorsque vous créez des paramètres de diagnostic dans Bicep, n’oubliez pas que cette ressource est une ressource d’extension, ce qui signifie qu’elle est appliquée à une autre ressource. Vous pouvez créer des paramètres de diagnostic dans Bicep à l’aide du type de ressource Microsoft.Insights/diagnosticSettings.

Lorsque vous créez des paramètres de diagnostic dans Bicep, vous devez appliquer l’étendue du paramètre de diagnostic. Le paramètre de diagnostic peut être appliqué au niveau du groupe de gestion, d’abonnements ou de ressources. Utilisez la propriété d’étendue sur cette ressource pour définir l’étendue de cette dernière.

Prenons l’exemple suivant :

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

Dans l’exemple précédent, vous créez un paramètre de diagnostic pour le plan App Service et vous envoyez ces diagnostics à Log Analytics. Vous pouvez utiliser la propriété scope pour définir votre plan App Service comme étendue de votre paramètre de diagnostic, et utiliser la propriété workspaceId pour définir l’espace de travail Log Analytics auquel envoyer les journaux de diagnostic. Vous pouvez également exporter les paramètres de diagnostic vers Event Hubs et des compte de Stockage Azure.

Les types de journaux diffèrent d’une ressource à l’autre. Vous devez donc vérifier que les journaux que vous souhaitez exporter sont applicables à la ressource que vous utilisez.

Paramètres de diagnostic de journal d’activité

Pour utiliser Bicep afin de configurer les paramètres de diagnostic pour exporter le journal d’activité Azure, déployez une ressource de paramètre de diagnostic dans l’étendue de l’abonnement.

L’exemple suivant montre comment exporter plusieurs types de journaux d’activité vers un espace de travail 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
      }
    ]
  }
}

Alertes

Les alertes vous avertissent de manière proactive lorsque des problèmes sont détectés dans votre infrastructure et vos applications Azure en supervisant les données dans Azure Monitor. En définissant votre configuration de monitoring et d’alertes dans votre code Bicep, vous pouvez automatiser la création de ces alertes en même temps que l’infrastructure que vous approvisionnez dans Azure.

Pour plus d’informations sur le fonctionnement des alertes dans Azure, consultez Vue d’ensemble des alertes dans Microsoft Azure.

Les sections suivantes montrent comment vous pouvez configurer différents types d’alertes à l’aide de code Bicep.

Groupes d’actions

Pour être averti lorsque des alertes ont été déclenchées, vous devez créer un groupe d’actions. Un groupe d’actions est une collection de préférences de notification qui sont définies par le propriétaire d’un abonnement Azure. Les groupes d’actions sont utilisés pour avertir les utilisateurs qu’une alerte a été déclenchée ou pour déclencher des réponses automatisées aux alertes.

Pour créer des groupes d’actions dans Bicep, vous pouvez utiliser le type Microsoft.Insights/actionGroups. Voici un exemple :

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’exemple précédent crée un groupe d’actions qui envoie des alertes à une adresse e-mail, mais vous pouvez également définir des groupes d’actions qui envoient des alertes à Event Hubs, Azure Functions, Logic Apps, entre autres.

Règles de traitement des alertes

Les règles de traitement des alertes (précédemment appelées « règles d’action ») vous permettent d’appliquer le traitement sur les alertes qui ont été déclenchées. Vous pouvez créer des règles de traitement des alertes dans Bicep à l’aide du type Microsoft.AlertsManagement/actionRules.

Chaque règle de traitement des alertes a une étendue, qui peut être une liste d’une ou de plusieurs ressources spécifiques, un groupe de ressources spécifique ou l’ensemble de votre abonnement Azure. Lorsque vous définissez des règles de traitement des alertes dans Bicep, vous définissez une liste d’ID de ressource dans la propriété scope, qui cible ces ressources pour la règle de traitement des alertes.

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

Dans l’exemple précédent, la règle de traitement des alertes MonitorService sur Azure Backup Vault est définie, et est appliquée au groupe d’actions existant. Cette règle déclenche des alertes sur le groupe d’actions.

Règles d’alerte de journal

Les alertes de journal exécutent automatiquement une requête Log Analytics. La requête utilisée pour évaluer les journaux de ressources à un intervalle que vous définissez détermine si les résultats répondent à certains critères que vous spécifiez, puis déclenche une alerte.

Vous pouvez créer des règles d’alerte de journal dans Bicep à l’aide du type Microsoft.Insights/scheduledQueryRules.

Règles d’alerte de métrique

Les alertes de métrique vous avertissent lorsque l’une de vos métriques dépasse un seuil défini. Vous pouvez définir une règle d’alerte de métrique dans votre code Bicep à l’aide du type Microsoft.Insights/metricAlerts.

Alertes de journal d’activité

Le journal d’activité Azure est un journal de plateforme disponible dans Azure qui fournit des insights sur les événements au niveau de l’abonnement. Cela inclut des informations telles que le moment où une ressource est modifiée dans Azure.

Les alertes de journal d’activité sont des alertes qui sont activées lorsqu’un nouvel événement du journal d’activité correspondant aux conditions spécifiées dans l’alerte se produit.

Vous pouvez utiliser la propriété scope dans le type Microsoft.Insights/activityLogAlerts pour créer des alertes de journal d’activité sur une ressource spécifique ou une liste de ressources en utilisant les ID de ressource en tant que préfixe.

Vous définissez vos conditions de règle d’alerte dans la propriété condition, puis vous configurez le groupe d’alertes pour déclencher ces alertes à l’aide du tableau actionGroup. Ici, vous pouvez passer un seul ou plusieurs groupes d’actions auxquels envoyer des alertes de journal d’activité, en fonction de vos besoins.

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

Alertes Resource Health

Azure Resource Health vous tient informé de l’état d’intégrité actuel et précédent de vos ressources Azure. En créant vos alertes Resource Health à l’aide de Bicep, vous pouvez créer et personnaliser ces alertes en bloc.

Dans Bicep, vous pouvez créer des alertes Resource Health avec le type Microsoft.Insights/activityLogAlerts.

Les alertes Resource Health peuvent être configurées pour superviser les événements au niveau d’un abonnement, d’un groupe de ressources ou d’une ressource individuelle.

Prenons l’exemple suivant, où vous créez une alerte Resource Health qui génère un rapport sur les alertes Service Health. L’alerte est appliquée au niveau de l’abonnement (à l’aide de la propriété scope) et envoie des alertes à un groupe d’actions existant :

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

Alertes de détection intelligente

Les alertes de détection intelligente vous informent d’éventuels problèmes de performances et anomalies d’échecs dans votre application web. Vous pouvez créer des alertes de détection intelligente dans Bicep à l’aide du type Microsoft.AlertsManagement/smartDetectorAlertRules.

Tableaux de bord

Dans Bicep, vous pouvez créer des tableaux de bord du portail à l’aide du type de ressource Microsoft.Portal/dashboards.

Pour plus d’informations sur la création de tableaux de bord avec du code, consultez Créer par programmation un tableau de bord Azure.

Règles de mise à l’échelle automatique

Pour créer un paramètre de mise à l’échelle automatique, vous les définissez à l’aide du type de ressource Microsoft.Insights/autoscaleSettings.

Pour cibler la ressource à laquelle vous souhaitez appliquer le paramètre de mise à l’échelle automatique, vous devez fournir l’identificateur de ressource cible de la ressource à laquelle le paramètre doit être ajouté.

Cet exemple illustre une condition de scale-out pour le plan App Service en fonction du pourcentage de processeur moyen sur une période de 10 minutes. Si le plan App Service dépasse 70 % de la consommation moyenne du processeur sur 10 minutes, le moteur de mise à l’échelle automatique effectue un scale-out du plan en ajoutant une instance.

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

Notes

Lorsque vous définissez des règles de mise à l’échelle automatique, gardez à l’esprit les bonnes pratiques pour éviter les problèmes survenant lors d’une tentative de mise à l’échelle automatique, comme le bagottement. Pour plus d’informations, consultez la documentation suivante sur les bonnes pratiques concernant la mise à l’échelle automatique.