Definizione di un allarme Prometheus

Quando si definisce un avviso Prometheus, è necessario specificare quanto segue:

Condizione

Immettere un'espressione PromQL valida. A differenza degli avvisi di metrica, le query PromQL restituiscono solo serie temporali che soddisfano la condizione specificata. Ad esempio, se si immette sysdig_host_cpu_used_percent > 80, solo gli host con utilizzo di CPU superiore all ' 80% verranno inclusi nei risultati della query. Se tutti gli host sono al di sotto di questa soglia, la query restituirà uno stato Risolto, che è uguale allo stato Nessun dato.

Gli utenti potrebbero essere confusi nel determinare se un avviso è stato realmente risolto o se la metrica è scomparsa e non è riuscita in modo non presidiato. Ciò si verifica perché lo stato Nessun dato in Prometheus non può essere distinto da uno stato risolto. Esistono strategie per gestire l'assenza di dati in Prometheus.

Durata

La durata è la durata per cui una condizione di avviso deve rimanere true prima di attivare un avviso. Gli avvisi di Prometheus hanno tre stati: Resolved, Pending, e Firing. Se è impostata una durata di 10m, significa che la condizione di avviso deve essere costantemente soddisfatta per un periodo continuo di 10 minuti prima di passare allo stato Firing. Gli avvisi la cui espressione è soddisfatta ma che non hanno soddisfatto la durata richiesta si trovano in uno stato Pending.

Ritardo risoluzione avviso

Il ritardo risoluzione avviso è uguale a keep_firing_for in Prometheus. Questa impostazione abilita l'attivazione continua di una ricorrenza di avviso per una durata definita dall'utente anche dopo che la condizione di avviso non è più valida. Gli avvisi che tendono ad avere intervalli di no-data nella metrica sottostante possono essere configurati con Alert Resolution Delay per evitare rumore non necessario e false risoluzioni. Se la condizione di avviso viene nuovamente soddisfatta prima che sia trascorso il ritardo della risoluzione dell'avviso, l'avviso continuerà ad essere attivato senza dover soddisfare nuovamente la durata.

Intervallo e durata

La durata di un avviso è il periodo di tempo per cui una specifica condizione deve persistere prima di attivare l'avviso. Non deve essere confuso con l'intervallo di un avviso, che definisce il periodo di tempo in cui vengono valutati i relativi dati di metrica.

Considerare i seguenti esempi:

  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'avviso highNetworkTraffic1 esamina la trasmissione di rete media nell'ora precedente. Se questa media supera 10MB per una durata continua di 5 minuti, l'avviso viene attivato.

D'altra parte, highNetworkTraffic2 si concentra sulla trasmissione di rete media negli ultimi 5 minuti. Se questa media supera 10MB per l'ultima ora, viene attivato l'avviso.

Mentre l'utilizzo di una durata più lunga può aiutare a ridurre gli avvisi rumorosi, significa anche che alcuni avvisi possono raggiungere la soglia momentaneamente senza attivazione. Esiste un compromesso tra la soppressione degli avvisi rumorosi e il potenziale ritardo delle notifiche per determinate condizioni.

Le differenze tra gli avvisi Prometheus e Threshold

Gli avvisi di Prometheus interrogano le stesse metriche degli avvisi di soglia. La differenza tra i due tipi di avviso è nell'algoritmo di valutazione.

Gestione di nessun dato e soglie multiple

Per vedere i vantaggi dell'identificazione degli scenari No Data e della configurazione di più soglie, è possibile passare da un avviso Prometheus a un avviso di soglia.

Per creare una gestione degli avvisi della metrica No Data e più soglie:

1. Creare un nuovo avviso metrico.
2. Passare la modalità di creazione degli avvisi da Modulo a PromQL.
3. Continuare a configurare un avviso di soglia utilizzando PromQL.
4. Facoltativamente, aggiungere una soglia di avvertenza e inviare una notifica a No Data.

Importazione delle regole di avviso di Prometheus

Puoi importare le regole Prometheus. Fai clic sull'opzione Upload Prometheus Rules e immetti le regole in formato YAML nell'editor YAML Upload Prometheus Rules. L'importazione delle regole di avviso di Prometheus le convertirà in avvisi di Prometheus.

Ciascuna regola di avviso deve includere i seguenti campi obbligatori:

• alert
• expr
• for

Esempio: avviso di loop Prometheus

Questo avviso rileva potenziali loop di riavvio sui lavori prometheus, pushgateway o 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

Esempio: Avviso sul tasso di errore HTTP

In questo esempio NginxHighHttp5xxErrorRate rileva un tasso di errore HTTP pari o superiore al 5%.

NginxLatencyHigh monitora la latenza p99 per 3 secondi o superiore per tutti gli host e i nodi.

Per avvisare le richieste HTTP con stato 5xx (> 5%) o con latenza elevata:

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