¿Cómo soluciono los problemas de datos faltantes en mi base de datos Prometheus?

13

He ido integrando gradualmente Prometheus en mis flujos de trabajo de monitoreo, a fin de recopilar métricas detalladas sobre la ejecución de la infraestructura.

Durante esto, me di cuenta de que a menudo me encuentro con un problema peculiar: a veces, un exportador del que se supone que Prometheus extrae datos no responde. Tal vez debido a una configuración incorrecta de la red, ya no es accesible, o simplemente porque el exportador se bloqueó.

Cualquiera sea el motivo, creo que faltan algunos de los datos que espero ver en Prometheus y no hay nada en la serie durante un período de tiempo determinado. A veces, la falla de un exportador (¿está agotando el tiempo?) También parece causar que otros fallen (¿el primer tiempo de espera empujó todo el trabajo por encima del tiempo de espera del nivel superior? Solo especulando).

Brecha en los datos

Todo lo que veo es un vacío en la serie, como se muestra en la visualización anterior. No hay nada en el registro cuando esto sucede. Las métricas de Prometeo también parecen bastante estériles. Acabo de tener que recurrir a intentar manualmente replicar lo que Prometheus está haciendo y ver dónde se rompe. Esto es molesto. ¡Tiene que haber una mejor manera! Si bien no necesito alertas en tiempo real, al menos quiero poder ver que un exportador no pudo entregar datos. Incluso un indicador booleano de "oye comprobar tus datos" sería un comienzo.

¿Cómo obtengo información significativa sobre Prometheus que no puede obtener datos de los exportadores? ¿Cómo entiendo por qué existen brechas sin tener que realizar una simulación manual de la recopilación de datos de Prometheus? ¿Cuáles son las prácticas sensatas a este respecto, tal vez incluso cuando se extienden al monitoreo de la recolección de datos en general, más allá de Prometeo?

monitoring prometheus Lijadora
fuente
¿Tiene entradas de registro o advertencias / errores relevantes para el problema?
kenorb
Nada en absoluto, solo veo un vacío en la serie de datos. La salida de Prometheus solo tiene las líneas regulares normales sobre guardar los cambios pendientes cada pocos minutos y otras cosas (a menos que pierda algunos registros ocultos para mirar).
Sander
También nos enfrentamos a este problema. @Sander, ¿pudiste encontrar la causa?
Deepak N
@DeepakN no, desafortunadamente no tengo información útil para agregar aquí. Sigue siendo un punto de dolor cuando se usa Prometeo.
Sander

Respuestas:

5

Creo que puedes hacer algún tipo de alerta en una métrica ratecon algo como esto:

ALERT DropInMetricsFromExporter
  IF rate(<metric_name>[1m]) == 0
  FOR 3m
  ANNOTATIONS {
    summary = "Rate of metrics is 0 {{ $labels.<your_label> }}",
    description = "Rate of metric dropped, actually: {{ $value }}%",
}

La idea principal es alertar siempre que la tasa métrica esté en 0 durante 3 minutos, con el nombre de la métrica adecuada y una etiqueta en algún lugar que indique de qué exportador proviene, que debería darle la información correcta.

Elegir la métrica correcta para monitorear por exportador podría ser complejo, sin más información es difícil dar un mejor consejo de la nada.
Esta publicación de blog podría ser una inspiración también para una detección más genérica.

Tensibai
fuente
rate calcula una tasa por segundo para un contador dado. Esto no tiene nada que ver con la velocidad a la que se raspan las métricas (-> scrape_interval). Su ejemplo alertaría si el contador dado (metric_name) no aumenta durante 3 minutos, lo que probablemente no sea lo que quiere el OP.
Johannes 'fish' Ziemke
@ Johannes'fish'Ziemke Por eso dije que encontrar la métrica correcta podría ser complejo. timePor ejemplo, usar la métrica en un exportador de nodos sería suficiente. Si tiene una mejor manera de alertar sobre la falla de un exportador, siéntase libre de agregar una respuesta
Tensibai
@ Johannes'fish'Ziemke Bienvenido en devops.se por cierto :)
Tensibai
1

Hay algunas razones que podrían haber causado la brecha. Lo más probable es que el exportador no sea accesible, en cuyo caso la serie de uptiempo será 0. Puede alertar sobre esto de esta manera (tomado de https://prometheus.io/docs/alerting/rules/#templating ):

# Alert for any instance that is unreachable for >5 minutes.
ALERT InstanceDown
  IF up == 0
  FOR 5m
  LABELS { severity = "page" }
  ANNOTATIONS {
    summary = "Instance {{ $labels.instance }} down",
    description = "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.",
  }

En la página de estado también debería ver que está inactivo, incluido un mensaje de error. Desafortunadamente, no hay forma de ver el error pasado, pero hay un problema para rastrear esto: https://github.com/prometheus/prometheus/issues/2820

Su servidor Prometheus también puede sobrecargarse, lo que hace que se detenga el raspado, lo que también explicaría las brechas. En ese caso, debería ver Storage needs throttling. Scrapes and rule evaluations will be skipped.errores en el registro y aumentos en las prometheus_target_skipped_scrapes_totalmétricas. También debe alertar sobre eso, por ejemplo:

ALERT PrometheusSkipsScrapes
  IF rate(prometheus_target_skipped_scrapes_total[2m]) > 0
  FOR 5m
Johannes 'pez' Ziemke
fuente
1

No estoy seguro si este es el mismo problema que estás viendo. Pero vimos estas brechas aleatorias para aplicaciones Java que no establecieron específicamente la configuración de GC. Lo que significa que estábamos viendo brechas cuando la recopilación de datos se detuvo porque la actividad de la instancia se detuvo mientras la JVM estaba haciendo un GC completo. Si está utilizando Java, esto puede suceder. Nuestra solución fue utilizar explícitamente el recolector de basura G1 (Java 8+) con un límite especificado en la duración de la actividad de GC para evitar estos intervalos de tiempo en la recopilación de datos.

cwa
fuente