Managed Service for OpenTelemetry:Silence policies

Fonctionnement des politiques de silence

Une politique de silence se compose de deux éléments :

Combinez ces deux éléments pour couvrir les scénarios courants :

• Maintenance planifiée -- Mettez en sourdine les alertes provenant de clusters ou de services spécifiques pendant une fenêtre de maintenance programmée, en utilisant une période personnalisée.

• Bruit récurrent de faible priorité -- Mettez en sourdine les alertes de sévérité P4 ou Default les week-ends en utilisant une planification récurrente.

• Suppression d’incidents connus -- Mettez en sourdine les alertes liées à un problème connu en faisant correspondre le tag alertname ou _aliyun_arms_involvedObject_name, avec une période persistante ou personnalisée.

Créer une politique de silence

1. Connectez-vous à la console Managed Service for OpenTelemetry.

2. Dans le volet de navigation de gauche, sélectionnez Alert Management > Alarm policy.

3. Cliquez sur l’onglet Silence Policies, puis cliquez sur Create Silence Policy.

4. Saisissez un nom pour la politique de silence.

5. Dans la section Silent Event Matching Rule, configurez les règles déterminant les alertes à mettre en sourdine.

   1. Sélectionnez une source de données.

      • Pour filtrer les alertes provenant d’une source spécifique, sélectionnez cette source.

      • Pour filtrer toutes les alertes quelle que soit leur source, sélectionnez No Preset Source.

   2. Définissez une ou plusieurs expressions à l’aide de tags existants ou de tags personnalisés.

      Tags disponibles pour les expressions de correspondance :

      • Tags définis dans les expressions des règles d’alerte. Pour plus d’informations sur la création de tags dans Managed Service for Prometheus, consultez la rubrique Create an alert rule for a Prometheus instance.

      • Tags ARMS par défaut, répertoriés dans les tableaux suivants.

      Champs courants

      Tag	Description
      alertname	Nom de l’alerte.
      clustername	Nom du cluster Kubernetes.
      severity	Niveau de sévérité. Valeurs possibles : P1, P2, P3, P4, Default.
      namespace	Namespace Kubernetes.
      pod_name	Nom du pod Kubernetes.

      Champs système prédéfinis

      Tag	Description
      _aliyun_arms_integration_name	Nom de l’intégration spécifié comme source de données. Par défaut : ARMS-DEFAULT.
      _aliyun_arms_involvedObject_id	ID de l’objet qui déclenche l’alerte.
      _aliyun_arms_involvedObject_name	Nom de l’objet qui déclenche l’alerte.
      _aliyun_arms_region_id	ID de région ARMS.
      _aliyun_arms_alert_rule_id	ID de la règle d’alerte.
      _aliyun_arms_alert_type	Type de règle d’alerte. Valeurs possibles : 101 (alerte Prometheus), 5 (alerte Application Monitoring), 4 (alerte Browser Monitoring).

   3. Combinez les conditions et les règles pour définir la logique de correspondance.

      Action	Logique	Cas d’utilisation
      Cliquez sur + Add Condition	ET -- l’alerte doit satisfaire toutes les conditions au sein de la même règle	Mettre en sourdine les alertes qui sont à la fois de sévérité P4 ET provenant d’un cluster spécifique
      Cliquez sur + Add Rule	OU -- l’alerte doit satisfaire l’une des règles	Mettre en sourdine les alertes qui correspondent à la règle A OU à la règle B

6. Définissez la période d’application.

   Option	Comportement	Exemple
   Persistent	La politique reste active indéfiniment.	Supprimer les alertes bruyantes connues sans date de fin.
   Recurring	La politique s’active selon une planification répétitive. Sélectionnez Every Day ou Weekly, puis cliquez sur Create.	Supprimer les alertes non critiques chaque week-end.
   Custom Time Period	La politique s’active pendant une fenêtre temporelle spécifique. Cliquez sur Create et définissez la période.	Supprimer les alertes pendant une fenêtre de maintenance de deux heures le 15 mars.

7. Cliquez sur Save.

Gérer les politiques de silence

Dans l’onglet Silence Policies, effectuez l’une des opérations suivantes :