Definición de una alerta Prometheus

Cuando defina una alerta Prometheus deberá especificar lo siguiente:

Condición

Introduzca una expresión PromQL válida. A diferencia de las alertas de métrica, las consultas PromQL sólo devuelven series temporales que cumplen la condición especificada. Por ejemplo, si especifica sysdig_host_cpu_used_percent > 80, sólo se incluirán en los resultados de la consulta los hosts con un uso de CPU superior al 80%. Si todos los hosts están por debajo de este umbral, la consulta devolverá un estado Resuelto, que es el mismo que el estado Sin datos.

Los usuarios pueden estar confundidos al determinar si una alerta se ha resuelto realmente o si la métrica ha desaparecido y ha fallado de forma silenciosa. Esto se debe a que el estado Sin datos en Prometheus no se puede distinguir de un estado resuelto. Existen estrategias para tratar con Sin datos en Prometheus.

Duration

La duración es el tiempo que una condición de alerta debe permanecer verdadera antes de desencadenar una alerta. Las alertas de Prometheus tienen tres estados: Resolved, Pending, y Firing. Si se establece una duración de 10m, significa que la condición de alerta debe satisfacerse de forma coherente durante un periodo continuo de 10 minutos antes de pasar al estado Firing. Las alertas cuya expresión se satisface pero no han cumplido la duración necesaria están en un estado Pending.

Retardo de resolución de alerta

El retardo de resolución de alerta es el mismo que keep_firing_for en Prometheus. Este valor habilita la activación continua de una aparición de alerta para una duración definida por el usuario incluso después de que la condición de alerta ya no sea válida. Las alertas que tienden a tener intervalos de no-data en la métrica subyacente se pueden configurar con retardo de resolución de alerta para evitar ruido innecesario y resoluciones falsas. Si la condición de alerta se cumple de nuevo antes de que haya transcurrido el retardo de resolución de alerta, la alerta continuará desencadenándose sin necesidad de volver a satisfacer la duración.

Rango y duración

La duración de una alerta es el tiempo que una condición específica debe persistir antes de desencadenar la alerta. No debe confundirse con el rango de una alerta, que define el periodo de tiempo durante el cual se evalúan los datos de métrica relevantes.

Considere los ejemplos siguientes:

  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

La alerta highNetworkTraffic1 examina el promedio de transmisión de red durante la hora anterior. Si este promedio supera los 10MB durante una duración continua de 5 minutos, se desencadena la alerta.

Por otro lado, highNetworkTraffic2 se centra en la transmitancia media de la red durante los últimos 5 minutos. Si este promedio supera los 10MB durante la última hora, se desencadena la alerta.

Si bien el uso de una duración más larga puede ayudar a reducir las alertas ruidosas, también significa que algunas alertas pueden cumplir el umbral momentáneamente sin desencadenarse. Existe un equilibrio entre la supresión de alertas ruidosas y el posible retraso de notificaciones para determinadas condiciones.

Las diferencias entre las alertas Prometheus y Threshold

Las alertas Prometheus consultan las mismas métricas que las alertas de umbral. La diferencia entre los dos tipos de alerta está en el algoritmo de evaluación.

Manejo sin datos y varios umbrales

Para ver las ventajas de identificar los escenarios de No Data y configurar varios umbrales, puede pasar de una alerta Prometheus a una alerta de umbral.

Para crear un No Data de manejo de alertas de medida y varios umbrales:

1. Crear una nueva alerta métrica.
2. Conmute la modalidad de creación de alerta de Formulario a PromQL.
3. Continúe configurando una Alerta de Umbral utilizando PromQL.
4. Opcionalmente, añada un umbral de aviso y notifíquelo en No Data.

Importación de reglas de alerta de Prometheus

Puede importar reglas de Prometheus. Pulse la opción Cargar reglas de Prometheus y especifique las reglas en formato YAML en el editor YAML Cargar reglas de Prometheus. La importación de sus reglas de alerta Prometheus etheus las convertirá en alertas de Prometheus.

Cada regla de alerta debe incluir los siguientes campos obligatorios:

• alert
• expr
• for

Ejemplo: alerta de bucle de bloqueo de Prometheus

Esta alerta detecta posibles bucles de reinicio en los trabajos 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

Ejemplo: Alerta de tasa de error HTTP

En este ejemplo NginxHighHttp5xxErrorRate detecta una tasa de error HTTP del 5% o superior.

NginxLatencyHigh supervisa la latencia de p99 durante 3 segundos o más para todos los hosts y nodos.

Para alertar de peticiones HTTP con estado 5xx (> 5%) o alta latencia:

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