PromQL-Alerts

Mit IBM Cloud Monitoring können Sie PromQL verwenden, um Änderungen in Ihrer Infrastruktur zu überwachen und Alerts zu generieren.

Definieren eines Prometheus

Wenn Sie einen Prometheus definieren, müssen Sie Folgendes angeben:

Bedingung

Geben Sie einen gültigen PromQL ein. Im Gegensatz zu Metrikalerts geben PromQL-Abfragen nur Zeitreihen zurück, die die angegebene Bedingung erfüllen. Wenn Sie beispielsweise sysdig_host_cpu_used_percent > 80 eingeben, werden nur die Hosts mit einer CPU-Auslastung über 80% in die Abfrageergebnisse eingeschlossen. Wenn alle Hosts unter diesem Schwellenwert liegen, gibt die Abfrage den Status Aufgelöst zurück, der dem Status Keine Daten entspricht.

Benutzer können verwirrt sein, wenn sie feststellen, ob ein Alert tatsächlich behoben wurde oder ob die Metrik verschwunden und im Hintergrund fehlgeschlagen ist. Dies liegt daran, dass der Status Keine Daten in Prometheus nicht von einem aufgelösten Status unterschieden werden kann. Es gibt Strategien für den Umgang mit "Keine Daten" in Prometheus.

Dauer

Die Dauer gibt an, wie lange eine Alertbedingung wahr bleiben muss, bevor ein Alert ausgelöst wird. Prometheus haben drei Zustände: Resolved, Pending, und Firing. Wenn eine Dauer von 10m festgelegt ist, bedeutet dies, dass die Alertbedingung für einen fortlaufenden Zeitraum von 10 Minuten konsistent erfüllt sein muss, bevor sie in den Status Firing übergeht. Alerts, deren Ausdruck erfüllt ist, aber die erforderliche Dauer nicht erreicht hat, befinden sich im Status Pending.

Verzögerung für Alertauflösung

Die Verzögerung der Alertauflösung entspricht keep_firing_for in Prometheus. Diese Einstellung aktiviert die fortlaufende Auslösung eines Alertvorkommens für eine benutzerdefinierte Dauer, auch wenn die Alertbedingung nicht länger gültig ist. Alerts, die in der Regel Intervalle von no-data in der zugrunde liegenden Metrik aufweisen, können mit Alert Resolution Delay konfiguriert werden, um unnötige Störungen und falsche Auflösungen zu vermeiden. Wenn die Alertbedingung erneut erfüllt wird, bevor die Alertauflösungsverzögerung abgelaufen ist, wird der Alert weiterhin ausgelöst, ohne dass die Dauer erneut erfüllt werden muss.

Bereich und Dauer

Die Dauer eines Alerts ist die Zeitdauer, die eine bestimmte Bedingung bestehen bleiben muss, bevor der Alert ausgelöst wird. Er sollte nicht mit dem Bereich eines Alerts verwechselt werden, der den Zeitraum definiert, über den die relevanten Metrikdaten ausgewertet werden.

Betrachten Sie die folgenden Beispiele:

  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

Der Alert highNetworkTraffic1 untersucht die durchschnittliche Netzübertragungen während der letzten Stunde. Wenn dieser Durchschnitt 10MB für eine fortlaufende Dauer von 5 Minuten überschreitet, wird der Alert ausgelöst.

Auf der anderen Seite konzentriert sich highNetworkTraffic2 auf die durchschnittliche Netzübertragungen in den letzten 5 Minuten. Wenn dieser Durchschnitt 10MB für die letzte Stunde überschreitet, wird der Alert ausgelöst.

Die Verwendung einer längeren Dauer kann zwar dazu beitragen, verrauschte Alerts zu reduzieren, aber es bedeutet auch, dass einige Alerts den Schwellenwert vorübergehend erreichen können, ohne dass sie ausgelöst werden. Es gibt einen Kompromiss zwischen der Unterdrückung verrauschter Alerts und der potenziellen Verzögerung von Benachrichtigungen für bestimmte Bedingungen.

Die Unterschiede zwischen Prometheus und Threshold-Warnungen

Prometheus fragen die gleichen Metriken ab wie Schwellenwertwarnungen. Der Unterschied zwischen den beiden Alerttypen liegt im Auswertungsalgorithmus.

Unterschiede zwischen Prometheus und Threshold-Ausschreibungen
Schwellenwertalerts Prometheus
Native No Data-Unterstützung No Data-Status ist identisch mit Resolved-Status
Unterstützung mit mehreren Schwellenwerten Sie müssen zwei Alerts für mehrere Schwellenwerte erstellen.
Keine Dauer Dauer erstellt einen zusätzlichen Pending-Alertstatus
Abfragen geben standardmäßig alle Zeitreihen zurück Abfragen geben nur Zeitreihen zurück, die die Alertabfrage erfüllen

Handhabung ohne Daten und mit mehreren Schwellenwerten

Um die Vorteile der Identifizierung von No Data Szenarien und der Konfiguration mehrerer Schwellenwerte zu sehen, können Sie von einem Prometheus zu einem Schwellenwert-Alarm wechseln.

So erstellen Sie eine Handhabung von Metrikalerts No Data und mehrere Schwellenwerte:

  1. Erstellen Sie einen neuen Metrischen Alert.
  2. Schalten Sie den Alerterstellungsmodus von Formular auf PromQL um.
  3. Fahren Sie mit der Konfiguration eines Schwellenwertalarms mit PromQL fort.
  4. Fügen Sie optional einen Warnungsschwellenwert hinzu und benachrichtigen Sie No Data.

Prometheus-Alertregeln importieren

Sie können Prometheus-Regeln importieren. Klicken Sie auf die Option Prometheus Regeln und geben Sie die Regeln im YAML-Format im YAML-Format im YAML-Editor Prometheus Regeln ein. Wenn Sie Ihre Prometheus importieren, werden diese in Prometheus umgewandelt.

Jede Alertregel muss die folgenden Pflichtfelder enthalten:

  • alert
  • expr
  • for

Beispiel: Absturzschleifenalert Prometheus

Dieser Alert erkennt potenzielle Neustartschleifen für die prometheus-, pushgateway-oder alertmanager-Jobs.

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

Beispiel: HTTP

In diesem Beispiel erkennt NginxHighHttp5xxErrorRate eine HTTP von 5 % oder mehr.

NginxLatencyHigh überwacht die p99-Latenzzeit für 3 Sekunden oder höher für alle Hosts und Knoten.

Zur Warnung vor HTTP mit Status 5xx (> 5%) oder hoher Latenz:

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