Définition d'une alerte Prometheus

Lorsque vous définissez une alerte Prometheus, vous devez spécifier les éléments suivants :

Condition

Saisissez une expression PromQL valide. Contrairement aux alertes de métrique, les requêtes PromQL renvoient uniquement les séries temporelles qui remplissent la condition spécifiée. Par exemple, si vous entrez sysdig_host_cpu_used_percent > 80, seuls les hôtes dont l'utilisation de l'UC est supérieure à 80% seront inclus dans les résultats de la requête. Si tous les hôtes sont en dessous de ce seuil, la requête renvoie un état Résolu, qui est identique à l'état Aucune donnée.

Les utilisateurs peuvent être confus en déterminant si une alerte a été réellement résolue ou si la métrique a disparu et a échoué en mode silencieux. En effet, l'état Aucune donnée dans Prometheus ne peut pas être distingué d'un état résolu. Il existe des stratégies pour traiter l'absence de données dans Prometheus.

Durée

La durée correspond à la durée pendant laquelle une condition d'alerte doit rester vraie avant de déclencher une alerte. Les alertes Prometheus ont trois états : Resolved, Pending, et Firing. Si une durée de 10m est définie, cela signifie que la condition d'alerte doit être satisfaite de manière cohérente pendant une période continue de 10 minutes avant de passer à l'état Firing. Les alertes dont l'expression est satisfaite mais qui n'ont pas atteint la durée requise sont à l'état Pending.

Délai de résolution d'alerte

Le délai de résolution d'alerte est identique à keep_firing_for dans Prometheus. Ce paramètre permet le déclenchement continu d'une occurrence d'alerte pendant une durée définie par l'utilisateur même lorsque la condition d'alerte n'est plus valide. Les alertes qui ont tendance à avoir des intervalles de no-data dans la métrique sous-jacente peuvent être configurées avec le délai de résolution d'alerte pour éviter les bruits inutiles et les fausses résolutions. Si la condition d'alerte est à nouveau remplie avant l'expiration du délai de résolution d'alerte, l'alerte continue à se déclencher sans avoir à satisfaire à nouveau la durée.

Plage et durée

La durée d'une alerte correspond à la durée pendant laquelle une condition spécifique doit être conservée avant le déclenchement de l'alerte. Il ne doit pas être confondu avec la plage d'une alerte, qui définit la période au cours de laquelle les données de mesure pertinentes sont évaluées.

Prenez en compte les exemples suivants:

  rules:
  - alert: highNetworkTraffic1
    expr: avg(rate(network_bytes_total[1h])) > 10000000
    for: 5m
  - alert: highNetworkTraffic2
    expr: avg(rate(network_bytes_total[5m])) > 10000000
    for: 1h

L'alerte highNetworkTraffic1 examine le facteur moyen de transmission du réseau au cours de l'heure précédente. Si cette moyenne dépasse 10MB pour une durée continue de 5 minutes, l'alerte est déclenchée.

D'autre part, highNetworkTraffic2 se concentre sur la transmission moyenne du réseau au cours des 5 dernières minutes. Si cette moyenne dépasse 10MB au cours de la dernière heure, l'alerte est déclenchée.

L'utilisation d'une durée plus longue peut aider à réduire les alertes bruitées, mais cela signifie également que certaines alertes peuvent atteindre le seuil momentanément sans se déclencher. Il existe un compromis entre la suppression des alertes bruyantes et le risque de retarder les notifications pour certaines conditions.

Les différences entre les alertes Prometheus et Threshold

Les alertes Prometheus interrogent les mêmes métriques que les alertes de seuil. La différence entre les deux types d'alerte se trouve dans l'algorithme d'évaluation.

Traitement de l'absence de données et des seuils multiples

Pour découvrir les avantages de l'identification des scénarios No Data et de la configuration de plusieurs seuils, vous pouvez passer d'une alerte Prometheus à une alerte de seuil.

Pour créer un No Data de traitement des alertes de métrique et plusieurs seuils:

1. Créer une nouvelle alerte métrique.
2. Passez du mode de création d'alerte Formulaire à PromQL.
3. Poursuivre la configuration d'un seuil d'alerte à l'aide de PromQL.
4. Ajoutez éventuellement un seuil d'avertissement et une notification sur No Data.

Importation de règles d'alerte Prometheus

Vous pouvez importer des règles Prometheus. Cliquez sur l'option Upload Prometheus Rules et entrez les règles au format YAML dans l'éditeur YAML Upload Prometheus Rules. L'importation de vos règles d'alerte Prometheus les convertira en alertes Prometheus.

Chaque règle d'alerte doit inclure les zones obligatoires suivantes:

• alert
• expr
• for

Exemple: alerte de bouclage Prometheus

Cette alerte détecte les boucles de redémarrage potentielles sur les travaux prometheus, pushgateway ou alertmanager.

groups:
- name: crashlooping
  rules:
  - alert: PrometheusTooManyRestarts
    expr: changes(process_start_time_seconds{job=~"prometheus|pushgateway|alertmanager"}[10m]) > 2
    for: 0m
    labels:
      severity: warning
    annotations:
      summary: Prometheus too many restarts (instance {{ $labels.instance }})
      description: Prometheus has restarted more than twice in the last 15 minutes. It might be crashlooping.\n  VALUE = {{ $value }}\n

Exemple : Alerte sur le taux d'erreur HTTP

Dans cet exemple, NginxHighHttp5xxErrorRate détecte un taux d'erreur HTTP de 5 % ou plus.

NginxLatencyHigh surveille le temps d'attente p99 pendant 3 secondes ou plus pour tous les hôtes et noeuds.

Pour alerter les requêtes HTTP avec un statut 5xx (> 5%) ou une latence élevée :

groups:
- name: default
  rules:
  - alert: NginxHighHttp5xxErrorRate
    expr: sum(rate(nginx_http_requests_total{status=~"^5.."}[1m])) / sum(rate(nginx_http_requests_total[1m])) * 100 > 5
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: Nginx high HTTP 5xx error rate (instance {{ $labels.instance }})
      description: Too many HTTP requests with status 5xx
  - alert: NginxLatencyHigh
    expr: histogram_quantile(0.99, sum(rate(nginx_http_request_duration_seconds_bucket[2m])) by (host, node)) > 3
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: Nginx latency high (instance {{ $labels.instance }})
      description: Nginx p99 latency is higher than 3 seconds