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 > 80eingeben, 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, undFiring. 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 StatusFiringübergeht. Alerts, deren Ausdruck erfüllt ist, aber die erforderliche Dauer nicht erreicht hat, befinden sich im StatusPending. - Verzögerung für Alertauflösung
-
Die Verzögerung der Alertauflösung entspricht
keep_firing_forin 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 vonno-datain 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.
| 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:
- Erstellen Sie einen neuen Metrischen Alert.
- Schalten Sie den Alerterstellungsmodus von Formular auf PromQL um.
- Fahren Sie mit der Konfiguration eines Schwellenwertalarms mit PromQL fort.
- 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:
alertexprfor
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