Prometheus es una opción increíblemente popular para monitorear y series temporales de datos en kubernetes. Muchos desarrolladores simplemente lo instalan y dejan que haga lo suyo. Por lo tanto, puede ser un shock cuando comienza a sentirse abrumado.

¡No entrar en pánico! Lo ayudaremos a comprender algunos de los casos que podría encontrar y cuáles son sus opciones.

La 'estrategia de configuración y olvido'

La estrategia de configurar y olvidar puede llevarte muy lejos. Pero es posible que necesite saber un poco más si:

• Tiene un caso de uso de alto volumen (que es posible que ni siquiera se dé cuenta).
• Necesita que los datos estén allí durante largos períodos de tiempo (años o al menos meses).
• Depende en gran medida del consumo de datos en sus aplicaciones.
• Algo se rompe.

Prometheus y la mayoría de las demás bases de datos de series temporales funcionan de manera muy diferente a las bases de datos SQL. Entendamos mejor esto.

¡Arrgh! ¡Esta roto!

Supongamos que descubrió cómo exponer un extremo de métricas en su aplicación que se ejecuta en kubernetes. Ha creado un tablero de grafana para monitorear el estado de sus aplicaciones o algunos otros datos y se ve muy bien. O tal vez haya creado su propia interfaz de usuario que consulta a Prometheus directamente. Todo está bien en el mundo... hasta que se rompe.

Las consultas se vuelven lentas

Puede haber varias causas para la lentitud. Primero intenta descartar los menos interesantes:

1. Si está llamando a Prometheus en su propio código, ¿está cerrando y agotando el tiempo de sus conexiones http a Prometheus?
2. ¿Has asignado suficientes recursos a Prometheus ? Intente aumentarlo y replicar la carga como prueba (preferiblemente en un entorno con hardware subyacente similar).
3. Cuando haya verificado el aumento de la CPU y la RAM, pruebe también con el disco. Podría ser que el disco se esté llenando y Prometheus tenga que limpiar (más sobre esto en la sección 'Desaparición de datos' a continuación).

Lo más interesante que podría estar saliendo mal es que la forma en que aumenta el volumen de datos hace que las consultas se ralenticen. Esto puede suceder sorprendentemente rápido. Podría haber un cambio en los sistemas que producen los datos, pero también puede ser que cambios aparentemente pequeños tengan grandes efectos.

La razón por la que a menudo no anticipamos cómo un aumento en los datos afectará a Prometheus es porque olvidamos mirar la cardinalidad . Aquí hay una parte importante pero un poco complicada de la documentación de Prometheus :

“Las etiquetas habilitan el modelo de datos dimensionales de Prometheus: cualquier combinación dada de etiquetas para el mismo nombre de métrica identifica una instancia dimensional particular de esa métrica (por ejemplo: todas las solicitudes HTTP que usaron el método POST para el controlador /api/tracks). El lenguaje de consulta permite filtrar y agregar en función de estas dimensiones. Cambiar cualquier valor de etiqueta, incluida la adición o eliminación de una etiqueta, creará una nueva serie temporal”.

Entonces, el resultado es que cada valor diferente para cada etiqueta aumenta significativamente el trabajo que Prometheus está haciendo. Debe considerar no solo cada valor de métrica en cada raspado, sino cada combinación de etiquetas que se está aplicando . Por esta razón, es peligroso generar automáticamente nombres de etiquetas en su código . También es peligroso usar etiquetas como ID de usuario, que pueden tener muchos valores distintos.

Deberíamos pensar en Prometheus como un sistema de monitoreo en lugar de una base de datos. Si hay mucha variación en las etiquetas, se sugiere consultar una base de datos (más sobre esto a continuación).

Si encuentra este problema, hay formas de verificar la cardinalidad de su serie de tiempo. Puede ejecutar una sum(scrape_series_added) by (job) . Consulte las diapositivas de la presentación "Contener su cardinalidad" para obtener más información sobre esto y cómo reducir la cardinalidad.

Prometheus realmente se bloquea

El bloqueo de Prometheus podría ser un efecto de uno de los problemas discutidos anteriormente. Tal vez se haya quedado sin memoria debido a que se ha trabajado demasiado. A menos que tenga mejor información (por ejemplo, de los registros), intentaría investigar lo anterior.

Hay otro comportamiento de falla relacionado que podría ocurrir por las mismas razones, como raspados que se vuelven lentos o picos de memoria.

Desaparición de datos

Digamos que tiene alguna consulta que ejecuta para mostrar cuántas veces ha sucedido algo. Sigue subiendo cada vez que ocurre el evento y todo se ve bien... luego el valor baja misteriosamente. ¿Cómo puede suceder eso?

Bueno, Prometheus normalmente no guarda los datos para siempre. En realidad por defecto tiene un periodo de retención de 15 días (que puedes configurar). Tenga en cuenta que es global, no filtrado por ningún tipo de datos en particular.

También hay una opción para decirle a Prometheus cuánto espacio en disco debe usar. Entonces, si los datos comienzan a ocupar demasiado espacio en el disco, comenzará a eliminarlos.

Esto puede ser contrario a la intuición si se acerca a Prometheus como una base de datos SQL tradicional. No está diseñado para el almacenamiento a largo plazo (aunque puede configurarlo para que se conserve durante períodos muy largos si tiene espacio). Está diseñado para el monitoreo, por lo que se trata de datos transitorios sobre lo que sucede durante un período de tiempo limitado (puede pensar en ello como datos de "lo que está sucediendo ahora").

fuera del disco

Ahora sabemos que Prometheus eliminará los datos más allá del período de retención de forma predeterminada. Es posible que las versiones más nuevas de Prometheus pronto también eliminen datos si el espacio en disco asignado se agota, aunque ese no es el valor predeterminado en el momento de escribir este artículo (debe configurarlo). Entonces, si no ha configurado esto, es posible que se quede sin disco.

Las consultas superan los puntos de datos máximos

Si una sola consulta devuelve demasiados puntos de datos, Prometheus simplemente no la ejecutará por completo. En su lugar, recibirá un mensaje que indica que la consulta supera el límite de puntos de datos , de forma predeterminada, 11 000.

Por lo general, necesitaría ejecutar una consulta durante un período de tiempo bastante largo para solucionar este problema. Lo golpeé al intentar ejecutar una consulta durante un período de meses. Pero puede depender de la cantidad de datos que recopile y de su densidad (incluido el breve intervalo de recuperación).

Cuando presioné esto por primera vez, mi primera respuesta fue una gran exageración. Escribí un proyecto de exportación que leía las métricas de Prometheus, resumía los datos en intervalos para agrandar las brechas (reduciendo así la cantidad de puntos de datos) y lo ponía como una nueva serie temporal. (Este es un uso habitual de un exportador, que normalmente se usa para extraer datos en nombre de otro servicio en lugar de extraerlos y volver a colocarlos).

Lo que estaba haciendo se llama reducción de resolución. Tomar los datos y reestructurarlos aumenta las brechas entre los puntos de datos para que haya menos puntos de datos en general. La forma más fácil de hacer esto suele ser una regla de grabación (que es lo que luego me di cuenta). Estas son básicamente consultas que escribe en su configuración de Prometheus que crean nuevas series de tiempo a partir de las existentes.

¿Realmente tengo que reducir mis datos? ¿No hay una manera más fácil?

Lo que hemos dicho hasta ahora básicamente equivale a:

• No tenga muchos datos densos durante un período prolongado.

• Especialmente, no intente consultar muchos datos densos durante un período prolongado.

• Si debe consultar una gran cantidad de datos, considere reestructurar sus datos para hacerlos menos densos.

  
  

Entonces, en este punto, probablemente se esté preguntando '¿realmente tengo que reducir mis datos?' Realmente depende de tu situación. Para cualquiera que se pregunte si existe alguna herramienta que pueda hacer esto más fácil, echemos un vistazo a algunas herramientas que complementan o reemplazan a Prometheus y cómo se comparan.

extendiendo a Prometeo

Alta disponibilidad

Quizás esté pensando, "¿no puedo manejar más datos ejecutando más instancias de Prometheus?" La respuesta es ambas, si y no.

Con HA Prometheus, cada Prometheus maneja algunos de los datos. La forma recomendada de hacer esto es 'fragmentación funcional'. Esto significa que para cada servicio que se extrae, todos sus datos son manejados por un solo Prometheus. La fragmentación funcional no es la única forma de fragmentar datos, pero es la más simple. Significa que cada prometeo tiene un mandato claro y dedicado.

La fragmentación funcional es más para escalar números de servicios. Si tiene un solo servicio que produce una gran cantidad de datos (por ejemplo, demasiados datos para sus consultas), entonces la fragmentación funcional en sí misma no lo ayudará.

Los datos de Prometheus se pueden fragmentar de manera diferente para una alta disponibilidad. Cuando divide los datos, necesita una forma de volver a juntarlos para realizar consultas. Esto se logra con la federación . Básicamente, ciertas instancias de Prometheus recopilan datos de los demás, por lo que los datos están lo suficientemente consolidados como para saber qué Prometheus consultar.

La documentación de Prometheus sobre la federación sugiere tener algunas instancias de Prometheus que solo tienen datos globales agregados. La agregación sería una forma de reducir la cardinalidad y hacer posible ejecutar consultas que, de otro modo, llegarían a los límites. Pero configurar esto aún requiere reglas de grabación . Entonces, para reducir la cardinalidad, es la regla de grabación la que está haciendo el trabajo, no la federación. Sin embargo, esto no significa que las reglas de registro sean la única forma.

Thanos

Thanos es otro proyecto de código abierto en el CNCF. Complementa a Prometheus y se puede usar para escalar mejor Prometheus. Sus puntos clave:

• Agrega una capa a Prometheus para escalar.

• Admite reducción de muestreo, almacenamiento a largo plazo y agregación de datos de varias instancias de Prometheus.

• Tiene varios componentes inc. sidecars de baile, compactador y módulo de consulta: es bastante pesado si se usan todos.

• Puede ser complicado de instalar y probar correctamente debido a la cantidad de componentes.

• El módulo de consulta admite PromQL.

  
  

Para obtener detalles sobre todos estos componentes, hay un buen artículo de descripción general de AWS . La idea principal es que thanos puede ayudar con el almacenamiento a largo plazo, los límites de los puntos de datos de consulta y la federación. Pero no es una solución de un solo clic. Tiene diferentes componentes dirigidos a cada preocupación.

Si su principal preocupación es que las consultas individuales lleguen a los límites (que era el principal problema al que me enfrentaba antes), entonces el componente particular que será de su interés es el compactador . Ese componente puede reducir automáticamente la muestra de datos para que las consultas puedan ejecutarse en horizontes de tiempo más amplios sin alcanzar los límites máximos de puntos de datos.

Thanos no es la única herramienta que puede funcionar con Prometheus para ayudarlo a escalar. Hay una serie de herramientas que pueden tomar datos de Prometheus y almacenarlos a largo plazo y hay una lista de ellas en los documentos oficiales de Prometheus .

También hay alternativas a Prometheus por ahí. En realidad, hay algunas herramientas que se pueden usar con Prometheus o en lugar de Prometheus. Esto puede hacer que las opciones sean confusas, así que tratemos de aclarar un poco.

La escena de las bases de datos de series temporales

Esta es una mirada selectiva a algunas bases de datos de series de tiempo. No es completo. Mi objetivo es cubrir una selección que brinde una buena imagen de la gama de opciones y cómo comprender su enfoque y propósito.

Una cosa que confunde a la gente acerca de las bases de datos de series temporales es que no se basan en un estándar como SQL o en una filosofía de diseño única como las bases de datos relacionales. Cualquier base de datos que funcione bien para almacenar pares de una marca de tiempo y un valor y usos asociados para esos datos (por ejemplo, monitoreo).

InflujoDB

InfluxDB está diseñado como una base de datos de series temporales adecuada para métricas. Puede ser una alternativa a Prometheus o puede ser un backend para Prometheus como almacenamiento a largo plazo. Si se ejecuta solo, recopila los datos. Si se ejecuta con Prometheus, Prometheus recopila los datos e InfluxDB los obtiene de Prometheus.

Algunos puntos clave en InfluxDB:

• Hace downsampling y almacenamiento a largo plazo.
• Más joven y sin tanta presencia como Prometeo.
• Parece más fácil de ejecutar que Thanos.
• Necesita su propio formato de consulta, no es compatible con PromQL .
• Capaz de raspar como Prometeo .

Elasticsearch

Elasticsearch es, por supuesto, una base de datos y un motor de búsqueda basados en documentos, por lo que este podría ser una sorpresa. Pero elasticsearch también se puede usar para datos de series temporales. Y el elástico se puede utilizar como almacenamiento a largo plazo para Prometheus .

Elastic se puede usar para series temporales de forma nativa, sin Prometheus . Tienen un ejemplo de métricas de CPU que sugiere que puede reducir la resolución en el momento de la consulta. También puede ingerir kube-state-metrics .

El principal desafío para los usuarios de Prometheus interesados en Elastic es que Elastic no está tan bien establecido para estos casos de uso, por lo que puede ser difícil encontrar ejemplos detallados (al menos en el momento de escribir este artículo, pero si alguien tiene alguno, no dude en ponerse en contacto conmigo, por ejemplo, en twitter ).

La comparación con influx sugiere que tanto elastic como influx pueden usarse para series temporales y que influx no puede usarse para texto (p. ej., casos de uso de nlp, recopilación de registros EFK). Esto tiene sentido: elastic es una base de datos de documentos que también puede hacer series temporales, mientras que influx es específicamente para series temporales.

Escala de tiempo DB

TimescaleDB es relacional y se basa en postgres. Algunos puntos clave sobre TimescaleDB:

• Código abierto con una oferta administrada también disponible.
• Admite reducción de resolución y almacenamiento a largo plazo.
• Los autores de TimescaleDB ofrecen conjuntos de datos de muestra interesantes.
• Se puede utilizar como un almacén a largo plazo para datos de Prometheus.
• Puede admitir raspado al estilo de Prometheus con Promscale.
• Puede admitir PromQL con Promscale .

Otros

Hay muchas más ofertas en este espacio que no hemos cubierto aquí, como Cortex, VictoriaMetrics, M3db, Graphite, Datadog y más . La selección anterior pretende dar una idea de la variedad del espacio y ayudar a los lectores a explorar por sí mismos.

Usted no está solo

Si su Prometeo se siente abrumado, recuerde que no está solo. Es bastante normal encontrar limitaciones con Prometheus. Hay todo un espacio de herramientas para abordar esto. Incluso hay enfoques emergentes que no hemos abordado aquí (como la detección de cómo y cuándo ocurre la explosión de cardinalidad ).

No existe una única solución fácil que funcione para todos los casos. Tienes que pensar en tu situación y en lo que más te importa. Mis mejores consejos para dejarte son:

• Explore realmente la interfaz de usuario de Prometheus y PromQL. Todas las reglas de grabación y lo que se extrae, etc., se encuentran en la interfaz de usuario de Prometheus si sabe cómo encontrarlo.
• Use grupos de holgura para preguntar qué hicieron los demás. Este artículo se ha beneficiado enormemente de las conversaciones sobre kubernetes y los datos sobre los grupos de slack de kubernetes (DOK).