En poco tiempo, Prometheus se ha convertido en una de las herramientas de monitoreo más populares. Gracias, en particular, y la alta velocidad de su trabajo. Su almacenamiento local es ideal para el almacenamiento a corto plazo de métricas y para trabajar con ellas. A veces, desea mantener las métricas distribuidas durante meses y años, cortando automáticamente los datos antiguos, pero sin cambiar la interfaz para trabajar con ellos.
Justo sobre esto, la decodificación del informe de Alexey Palazhchenko en RootConf 2018. En el informe: Prometheus, Local Storage TSDB, Remote Storage Prometheus, PromQL, TSDB, Clickhouse, PromHouse, un poco InfluxDB.
A quién le importa, por favor, debajo del gato.
Amigos! Hola a todos! Me llamo Alexey Palazhchenko. Yo trabajo en Percona. Me gustaría informarle sobre el almacenamiento a largo plazo de métricas en Prometheus.
Trabajo en Percona y hago un producto llamado monitoreo y gestión de percona. Esta es la solución en caja que nuestros clientes se propusieron. PMM es completamente de código abierto. Consiste en Prometheus, Grafana para gráficos, software de análisis de consultas personalizado y nuestro propio contenedor que le permite administrar algo. Por ejemplo, puede agregar un objetivo de raspado a Prometheus. Estas son nuevas fuentes de donde tomará métricas sin tener que ingresar manualmente un contenedor o máquina virtual y editar el archivo de configuración.
Es importante entender que estos no son SaaS. No tenemos producción. Nuestra producción se ubica con nuestros clientes. Experimentar con eso no es muy bueno. Tenemos lo más cercano que podría llamarse producción: esto es https://pmmdemo.percona.com/ . En el momento del informe, pmmdemo.percona.com tuvo que cerrarse debido a GDPR.
Entregamos PMM a los clientes: una solución en caja: un contenedor acoplable o una máquina virtual. A todos les gusta Prometeo. Algunas personas que miran a Prometheus por primera vez se encuentran con un modelo pull. Para principiantes, esto es inconveniente. Generalmente una gran conversación separada. Puede discutir sobre los métodos de extracción o inserción. En promedio, esto es casi lo mismo.
Algunas cosas en Prometeo son muy geniales.
El lenguaje de consulta de Prometheus es realmente una cosa genial que no tiene análogo en ningún lado.
Lo segundo que te gusta es el descubrimiento de servicios. Si tiene algún tipo de infraestructura dinámica, kubernetes, automáticamente no necesita agregar todos los objetivos para monitorear con sus manos. Si es estático, esto también se puede hacer de manera bastante simple. Necesita usar el archivo de configuración.
A los clientes de Prometheus les gusta. Quieren mantener las métricas cada vez más. Alguien usa Prometheus solo para monitoreo operativo. Pero alguien quiere mantener las métricas por más tiempo, observar la dinámica, comparar con los gráficos de hace un año. Sin embargo, el objetivo del almacenamiento a largo plazo de las métricas no es el objetivo del proyecto Prometheus. Inicialmente, se creó para almacenar métricas por un corto tiempo. SoundCloud almacena métricas en solo unos días. Hay mecanismos en Prometeo que le permiten hacer esto por más tiempo, pero están dispuestos un poco al costado. Por lo tanto, podemos tomar una decisión para el ecosistema Prometheus sin cambiar el núcleo del sistema en sí. Con base en ellos, podemos tomar nuestra propia decisión dentro del mismo ecosistema.
Este no es un informe sobre soluciones preparadas. Este es un informe sobre nuestra experiencia, sobre nuestro dolor, sobre nuestros intentos. Si esperaba que después de este informe descargue el repositorio o el contenedor acoplable, lo ejecute y funcionará, entonces no es así. Pero al mismo tiempo está lo suficientemente cerca de serlo. Tenemos algunas bases. Todos son de código abierto. Puedes intentarlo. Todavía no están listos para la producción. Pero con la información que se encuentra en este informe, puede comprender por qué, entonces, ¿qué se puede hacer mejor? Puede tomar su propia decisión que más le convenga.
¿Cómo se almacenan las métricas en Prometheus? Hay almacenamiento local. Hay almacenamiento remoto. Estos son en realidad dos mundos diferentes. Se cruzan débilmente. Por lo tanto, el informe también se divide en 2 partes.
Si estuvo en un informe anterior en la sala principal, donde hubo una buena introducción en Prometheus, sabrá que el almacenamiento local es una biblioteca separada llamada TSDB. TSDB no tiene nada que ver con OpenTSDB. TSDB es un paquete Go separado que puede usar desde su programa Go. En el nivel de biblioteca TSDB, no hay cliente o servidor.
Esta biblioteca está optimizada para trabajar con datos de series temporales. Por ejemplo, TSDB tiene codificación delta, que le permite almacenar no los números en sí, sino los cambios entre estos números. Esto le permite almacenar 1 byte en lugar de 16 bytes. 1 byte por tiempo y 1 byte por valor. Es decir, almacena en promedio 1 o 2 bytes precisamente debido a esta buena compresión.
TSDB está optimizado para modelos pull. Los datos solo se agregan allí. Prometeo no puede escribir datos históricos. No hay API para esto. El delta máximo es de aproximadamente 5 minutos. Si los datos son más antiguos, no serán aceptados.
No hay una toma de muestras incorporada tsdb # 313 en TSDB. Hay un tema abierto en el que hubo una discusión sobre el hecho de que, en general, hay proyectos que hacen algo a Prometheus y hay una disminución de muestreo allí. Hasta ahora, la solución es que TSDB no agregará disminución de muestreo.
¿Cómo obtendríamos datos de TSDB? TSDB es una base de datos en disco. Puede trabajar con él si está escribiendo un programa Go. Pero si no escribe un programa en Go, entonces hay una API JSON que le permite realizar consultas de consulta. Si alguna vez ha utilizado Prometheus y al menos una vez ha creado un gráfico, conoce la API de consulta estándar, en la que hay un parámetro de consulta en el que puede ejecutar cualquier consulta de PromQL y, opcionalmente, el tiempo. Si no hay tiempo, se toma el tiempo actual.
Se resalta una consulta específica en la diapositiva, que rara vez se ve en la vida real. Este es un truco. Esto nos permite extraer todas las métricas que tiene Prometheus. Como funciona A nivel de PromQL se dice que es imposible escribir una expresión que atrape todo el tiempo los números de serie. Esto está escrito directamente en las reglas. Otra regla dice que no puede hacer una coincidencia en la que todos los valores estén vacíos. Si simplemente escribe llaves, esto no funcionará. Si escribe el nombre no es igual a nada (no es un valor vacío), entonces no funcionará. Pero este es un truco real que te permite hacer esto. Sin embargo, ni siquiera está particularmente documentado. Hay comentarios en el código mismo de que esto funciona.
La segunda consulta es query_range, que hace lo mismo, pero le devuelve datos en un rango y con algún paso. Básicamente, realiza una consulta varias veces para cada paso desde el principio hasta el final. Esta es la API utilizada para dibujar gráficos. La primera API se usa para obtener valores instantáneos.
Tenemos una API para recuperar metadatos. Si queremos obtener todos los nombres de las métricas, hacemos una consulta como esta, donde match es una matriz de métricas. Puede haber varios argumentos, pero en este caso pasamos la misma coincidencia, que todo nos devuelve.
La segunda meta API, que nos devuelve el valor de todas las etiquetas. Si queremos ver una lista de todos los trabajos, en lugar de label_name escribimos el trabajo y obtenemos esta lista. Estas API nos devuelven JSON.
Hay otra API que devuelve todas las métricas de Prometheus en un formato nativo de los exportadores. El formato se llama expfmt. En Prometheus, existe una API de federación que le permite realizar dicha solicitud. ¿Para qué es esto? La opción más fácil, si tiene algún código que ya funciona con expfmt, entonces no necesita volver a entrenarlo para que funcione con alguna API JSON personalizada. Este formato es mucho más fácil de transmitir, porque si tiene JSON en algún lugar en el nivel superior del objeto, la mayoría de las veces necesita analizar este objeto como un todo. Aquí se puede hacer línea por línea.
Lo más importante es que es una API separada. Funciona igual que una exportación real. Puedes tomar el otro Prometeo para rasparlo. Este es un trabajo regular con los parámetros habituales. Debe pasar el parámetro: consulta url. Si realiza una solicitud de rizo, obtendrá lo mismo aquí. Obtenemos todas las métricas para el valor de tiempo actual. La única advertencia: debe establecer etiquetas de honor para que Prometheus, que eliminará otro Prometheus a través de esta API, no borre el valor del trabajo y la etiqueta de instancia. Con esta API de federación, puede cargar todos los datos de un Prometheus a otro.
¿Cómo se puede usar esto?
Primero, lo más importante que debes decir es que no necesitas hacer esto. TSDB está optimizado para diferentes modos de funcionamiento. Si tiene un Prometheus que raspa muchos datos, entonces hace muchas E / S. Si usa la API de federación, la cantidad de entrada y salida aumentará aproximadamente 2 veces. Hay matices Dependiendo de con qué frecuencia raspe en federar y con qué frecuencia raspe los objetivos. Si no se ha cambiado el tiempo, esto realmente duplica la carga. Por lo tanto, si desea escalar su Prometheus y habilitar la federación, lo matará. La carga se duplicará.
Segundo momento Saltará datos. Obtendrá un conflicto de datos. Por qué Esta API, como casi cualquier API en Prometheus, no es atómica. Si llegan nuevos datos, un nuevo scraping finalizará en el momento en que su solicitud de federación aún esté en curso, puede obtener uno para una serie de tiempo y nuevos datos para otra. Si se trata de una serie temporal no relacionada, generalmente no da miedo. Pero si tiene un resumen o un histograma, que en el nivel de representación está representado por varias métricas básicas, entonces habrá inconsistencia entre ellas.
¿Cómo podemos resolver este problema atómico? Prometheus tiene reglas de grabación que le permiten crear una nueva serie de tiempo a partir de una serie de tiempo existente. Esto se puede hacer con menos frecuencia. Esta es una forma de reducir el muestreo. Por ejemplo, deseche el objetivo cada segundo, pero luego queremos hacer la agregación node_cpu en un minuto. Agrupar en Prometheus 2.0 le permite hacer estas agregaciones secuencialmente. Las reglas que están en el mismo grupo se ejecutan estrictamente secuencialmente. En este punto, no hay problema de atomicidad, no hay problema de que los datos cambien en el proceso. Pero esto no resuelve el problema del hecho de que es admisible algún otro dato que esté lógicamente conectado con esto, pero que no está conectado desde el punto de vista del modelo de datos. No hay atomicidad pura todavía. Hay un problema abierto sobre este tema. Puedes hacer instantáneas. Puede realizar una consulta de PromQL a la base de datos TSDB y descartar todas las muestras que sean inferiores a algún valor del tiempo que comenzó en la evaluación a partir de los valores obtenidos. Esta sería la forma más fácil, pero hasta ahora no se ha hecho.
Es importante comprender que las reglas de registro deben realizarse en el Prometheus inferior y no en el que hace la federación. De lo contrario, omitirá los picos, su monitoreo no funcionará correctamente.
¿Cómo podemos usar esta combinación de estas cosas para hacer un muestreo y almacenamiento a largo plazo?
El primero Acabamos de configurar la federación y descargamos todos los datos de ese Prometheus. Esta extraña expresión regular es como un zoidberg: en realidad es solo un colon. Un asterisco a la izquierda y derecha del colon. Usamos el nombre estándar para las reglas de grabación, que agrega dos puntos al medio. Al dividir el nombre original, habrá un nivel de agregación a la izquierda y una función a la derecha. Una métrica normal de colon no. Si hay dos puntos, entonces esta es una señal de que esto es agregación. Después de eso, usamos este nombre de métrica en nuestro gráfico. Si queremos que nuestro horario, nuestro tablero en grafana trabaje con el Prometeo principal, y con aquellos que son más altos, podemos usar la expresión o . Tomamos una métrica u otra, dependiendo de cuál sea. Podemos hacer trampa y usar el reetiquetado para cambiar el nombre de la nueva métrica al antiguo nombre. Este es un enfoque bastante peligroso. Puede deletrear archivos adjuntos regulares incorrectamente y tendrá un conflicto de series de tiempo. Prometeo escribirá muchas advertencias en el registro. Verá esto, pero encontrar la razón puede ser bastante difícil. Pero si se hace con cuidado, por ejemplo, generando estas expresiones regulares mediante programación, esto funcionará. A continuación, tendrá un panel de control normal donde solo se utiliza node_cpu. Dependiendo de qué Prometheus se use, recibirá datos sin procesar o datos agregados.
Como dije, las reglas de grabación se pueden generar de manera bastante simple. Acabamos de obtener todas las series de tiempo a través de la API que ya mostré. Creamos reglas y estas reglas deben usar las funciones y operadores correctos. No es necesario usar la tasa con el medidor allí. Esto no funcionará correctamente. Debe usarse solo con conteo. En el nivel donde trabaja, es posible que no tenga información sobre los tipos de datos. Por ejemplo, si usa expfmt. Hay información sobre los tipos. Si la API JSON no está allí. Como resultado, la expresión que genera automáticamente puede no tener ningún significado físico. Por lo tanto, puede usar una lista blanca o una lista negra allí. Dependiendo de esto, genere la regla que necesita o deseche las reglas que no tienen sentido. Hay una herramienta de promtool que le permite verificar que las reglas que generó, la configuración que generó, tiene sentido. Tiene la sintaxis correcta.
Si tenemos Grafana y hay varios Prometeo, necesitamos saber a qué Prometeo enviar la solicitud. ¿Cómo haríamos esto?
Una forma es poner un proxy especial que mirará la hora en la solicitud, y dependiendo de esto, seleccione Prometheus. Las consultas tienen una hora de inicio y una hora de finalización. Dependiendo de esto, puedes hacer rutas con tus manos. Se podría escribir algún tipo de programa que haga esto. En la práctica, esto lo hace nginx con el módulo lua o un pequeño programa.
¿Realmente necesitamos una API? ¿Podemos trabajar con TSDB directamente? Hay un matiz. En primer lugar, si tratamos de usar TSDB, que Prometheus usa ahora, no podremos hacerlo. Hay un archivo de bloqueo especial que evita esto. Si escribimos código que ignorará esto y tratamos de leer o escribir datos, tenemos la garantía de dañarlos. Por otra parte, incluso la lectura. Que se puede hacer Podemos leer datos a través de la API y crear TSDB lado a lado. Luego detenga Prometheus y reemplácelo con TSDB. Pero al mismo tiempo, podemos reducir el rendimiento si leemos todos los datos a través de la API. Hablaré de esto un poco más tarde.
La segunda opción. Puede copiar (hacer una copia de seguridad) estos archivos, es decir, copiarlos tal cual. Sí, serán dañados. Cuando abra, recibirá una advertencia de que los datos están dañados. Necesitan ser reparados. Puede perder nuevos datos. Pero no nos importa. Queremos reducir el muestreo de datos antiguos. La disminución de resolución se puede hacer usando PromQL. Pero hay un matiz. Es mucho más difícil arrancarlo de Prometheus que TSDB. Si está un poco familiarizado con Go y la gestión de dependencias, el proveedor PromQL es un gran problema. No te aconsejaría Evita esto si es posible.
Pasamos a Almacenamiento Remoto. ¿Alguien ha trabajado con Almacenamiento remoto en Prometheus? Unas pocas manos. Almacenamiento remoto es una API que existe desde hace mucho tiempo. Ahora en la versión 2.2 Almacenamiento remoto: marcado como experimental. Además, se sabe que la API de almacenamiento remoto definitivamente cambiará.
Almacenamiento remoto le permite trabajar solo con datos sin procesar. No hay PromQL en la entrada o salida. Cuando lees, no puedes usar toda la potencia de PromQL. Básicamente, bombea todos los datos del Almacenamiento remoto que coinciden con la condición. Además, PromQL ya funciona con ellos. Esto tiene una sobrecarga bastante grande. Necesita bombear muchos datos a través de la red. Por lo tanto, en Prometheus 2.3, que aún no se ha lanzado, pero ya se ha retrasado, se leerá una pista. Hablaremos de esto un poco más tarde.
Todavía no hay API para metadatos. No puede crear una API que devuelva todas las series temporales del Almacenamiento remoto. Si realiza una solicitud a la API de Prometheus, no irá a Almacenamiento remoto. Le devolverá la serie de tiempo, que se encuentra en su base de datos local. Si su base de datos local está deshabilitada, le devolverá 0. Lo que puede ser un poco inesperado. Ahora esta API usa ProtoBuf y definitivamente se cambiará a gRPC en el futuro. Todavía no lo han hecho, porque gRPC requiere HTTP2. Y en la práctica tuvieron problemas con él.
La API de escritura se ve así. La solicitud tiene un conjunto de etiquetas. El conjunto de etiquetas identifica de forma exclusiva las series temporales. __name__ es realmente solo una etiqueta con un nombre especial. Y las muestras son un conjunto de tiempo y valores: int64 y float64. Al grabar, el pedido no es importante. Se supone que la base de datos que escribe esto en sí misma hará todo bien. Prometheus puede hacer una optimización y no volver a ordenarla. En consecuencia, una solicitud de escritura es solo una serie de tiempo.
La configuración de escritura tiene una configuración bastante flexible. Hay muchas opciones para configurar la concurrencia de escritura. Lo que Prometeo llama fragmentos son esencialmente solicitudes competitivas. Puede limitar el número máximo de muestras en una solicitud, el número máximo de solicitudes paralelas, el tiempo de espera, cómo repetir, qué retroceso. Para muchas bases de datos, 100 muestras a la vez, esto puede ser muy pequeño. Si usa ClickHouse, como lo hacemos nosotros, entonces, por supuesto, el valor debe aumentar considerablemente. De lo contrario, será muy ineficiente.
La API de lectura remota se ve así. Es solo un rango de tiempo de principio a fin y un conjunto de partidos.
La coincidencia es esencialmente una colección de pares de nombre y valor, una etiqueta regular y un tipo de condición. En comparación, hay igualdades, desigualdades o expresiones regulares. Este es el selector habitual de series de tiempo que ve en PromQL. No hay características aquí.
La respuesta son algunas series de tiempo que coinciden con esta consulta. Aquí las muestras deben clasificarse por tiempo. Una vez más, esto ayuda a Prometeo a ahorrar un poco de CPU, sin necesidad de ordenar. Pero se supone que su base de datos debería hacer esto. En la mayoría de los casos, será así porque, muy probablemente, habrá un índice a tiempo.
Prometheus 2.3 introdujo una pista de lectura. Que es esto Esta es una oportunidad para decirle a Prometheus qué función interna que funciona con la serie de tiempo que se solicita se aplicará. Esto puede ser una función o un operador de agregación. Puede ser tasa. Es decir, se llama func, pero de hecho puede ser una suma, que desde el punto de vista de PromQL en realidad no es una función en absoluto. Este es el operador. Y un paso En el ejemplo anterior, hubo una tasa de 1 minuto. Aquí la tasa es una función y un minuto en milisegundos como un paso. Esta sugerencia puede ser ignorada por la base de datos remota. Al mismo tiempo, no hay ninguna indicación en la respuesta sobre si se ignoró o no.
¿Cuál es la configuración de lectura?
En primer lugar, existe dicha configuración required_matchers. Esto le permite enviar una solicitud de Almacenamiento remoto que coincida con la expresión. Para leer datos agregados del almacenamiento remoto, debe usar una consulta que contenga dos puntos.
Hay una opción que le permite leer o no leer datos recientes del Almacenamiento remoto, que se encuentra en TSDB. Por lo general, en la configuración estándar hay una pequeña TSDB local que se escribe en el disco local. Ella almacena allí durante varias horas o varios días. Los datos que usa ahora, que se usan para alertas, que se usan para construir el tablero, se leen solo desde la TSDB local. Es rápido, pero no nos permite almacenar muchos datos.
Los datos históricos antiguos se leerán desde el almacenamiento remoto. Esto deja en claro cómo el almacenamiento local y el almacenamiento remoto se comunican entre sí. No hay deduplicación.
Esencialmente lo que está pasando. Los datos se toman del almacenamiento local, los datos se toman del almacenamiento remoto si read_recent está habilitado. Simplemente se fusionan. Parece que esto no es un problema. Si se supone que no hemos disminuido la muestra de datos recientes, estos son exactamente los mismos datos, coinciden completamente con los datos locales, tendremos el doble de muestras, no deberíamos afectar ninguna función. En realidad no Hay una función irate () y un par para el indicador, que nos devuelve la diferencia entre los dos últimos valores. Ella mira hacia atrás en el rango de tiempo indicado, pero solo usa los dos últimos valores. Si tenemos los dos últimos valores tienen el mismo tiempo, entonces la diferencia será cero. Esto es un error y es casi imposible encontrarlo. Fue reparado hace solo cuatro días. Este es un boleto para cualquier persona interesada.
Curiosamente, Prometheus ha implementado la lectura remota desde la versión 1.8. Esta es la forma que le permite leer los datos del antiguo Prometheus cuando migra a la versión 2.x. La forma oficial aconseja conectarlo como lectura remota. Los datos se restarán según sea necesario.
La lectura remota se puede utilizar para enrutar consultas sin un proxy. En una de las diapositivas anteriores, mostré que, dependiendo del tiempo, podemos hacer rutas en un Prometheus u otro. Del mismo modo, podemos evitar esto. Simplemente conecte el Prometheus a continuación, que es de lectura remota, y los datos se leerán desde allí. Pero hay una enmienda al hecho de que, por supuesto, se bombearán muchos datos. Especialmente si no está utilizando la sugerencia de consulta.
¿Por qué clickhouse?
Para nuestra solución de investigación, elegimos ClickHouse, porque lo hemos estado buscando durante mucho tiempo. Tenemos personas que se dedican constantemente al rendimiento de la base de datos, revisando constantemente nuevas bases de datos. Nuestra empresa se dedica a bases de datos de código abierto.
Realmente nos gusta su rendimiento en bruto. Su potencia en términos de CPU, tiempo, etc. es muy buena. La mayoría de estos sistemas hablan de escalabilidad infinita, pero hablan poco sobre la eficiencia para un solo servidor. Muchos de nuestros clientes almacenan métricas en un par de servidores.
Replicación incorporada, fragmentación.
GraphiteMergeTree es un motor especial para almacenar datos de grafito. Al principio estaba muy interesado en nosotros.
El motor está diseñado para el rollup (adelgazamiento y agregación / promedio) de datos de grafito.
Graphite almacena los datos completos en ClickHouse, y puede recibirlos, y dice además que con el adelgazamiento GraphiteMergeTree se usa, MergeTree se usa sin adelgazamiento. La sensación es que los datos siempre están llenos, no se sobrescriben, es solo una optimización de la lectura. Pero en general no está mal. Cuando hacemos la lectura, no bombeamos los datos, se agregan automáticamente, obtenemos un poco de datos, esto es bueno. La desventaja para nosotros es que todos los datos se almacenan.
Me estaba preparando a principios de mes para el informe. Alguien entra en un chat de telegramas y pregunta: "¿Muestra de datos de GraphiteMergeTree"? Ya escribo no. La documentación dice que no. Pero la otra persona en el chat responde "sí, debe llamar a optimizar". Corre, comprueba, sí, la verdad. La documentación es esencialmente un error. Luego leí el código fuente, comprobé, resulta que hay optimizar, optimizar final. Optimizar final se creó originalmente específicamente para GraphiteMergeTree. En realidad, la toma de muestras lo hace. Pero debe ser llamado con sus manos.
GraphiteMergeTree tiene un modelo de datos diferente. No tiene etiquetas. Efectivamente escribirlo todo en nombre de las métricas no funciona muy bien.
Las métricas de nombres se almacenan en una tabla. El nombre de las métricas tiene una longitud diferente. Esto lleva al hecho de que si hacemos una búsqueda de índice por el nombre de la métrica, porque la longitud es diferente, este índice no será tan efectivo como si este índice tuviera un valor de longitud fijo. Porque necesitas hacer una búsqueda de archivos. Es imposible especificar exactamente dónde aterrizar para hacer una búsqueda binaria.
Por lo tanto, hicieron su propio esquema. La diapositiva muestra cómo almacenamos series temporales en la base de datos. La fecha que ClickHouse necesita es una huella digital. Si observa las fuentes de Prometheus o TSDB, entonces sabe que la huella digital es esencialmente una suma de comprobación rápida y corta de la serie de tiempo de nombre completo. La huella digital es una combinación de todas las etiquetas, claves y valores. Un nombre es una etiqueta normal. Usamos el mismo algoritmo para compatibilidad. Debitar algo puede ser conveniente. La huella digital es la misma y se puede verificar en TSDB y en nuestro almacenamiento que son iguales. Las etiquetas se almacenan en un JSON especial, que permite a ClickHouse trabajar con sus funciones estándar. Este es JSON compacto sin espacios, con nombres ligeramente simplificados. Esta tabla no se usa durante la operación. Siempre se almacena en la memoria de nuestra solución real, que se llama PromHouse. Se usa solo cuando iniciamos el servidor para averiguar qué series de tiempo son. Ella es restada. A medida que llegan nuevas series de tiempo, las grabamos allí. Todas las instancias de PromHouse múltiples pueden leer la misma tabla. ReplacingMergeTree nos dice que estas series de tiempo, hay varias instancias diferentes, escriben la misma serie de tiempo. Ellos contendrán, y no habrá ningún problema aquí.
Almacenamos muestras en una mesa separada de manera muy eficiente. Con un valor de longitud fijo, esta huella digital es la misma, tiempo y valor. Obtenemos 24 bytes por muestra. Tiene una longitud estrictamente fija. Cada columna se almacena por separado. Una búsqueda de huellas digitales es efectiva porque sabemos que el tamaño es fijo. No hay tal problema como con GraphitmergeTree cuando es una cadena. Utilizamos particiones personalizadas. Índice primario de huellas digitales y por tiempo.
24 bytes es una versión simplificada. De hecho, se comprime bien. De hecho usa menos espacio. En nuestras últimas pruebas, la relación de compresión es de aproximadamente 1 a 42.
¿Cómo podemos hacer un muestreo manual si tenemos GraphiteMergeTree, pero no es lo mismo que quisiéramos? De hecho, podemos hacerlo a mano. Como se hizo anteriormente, particionamiento, cuando no había nada incorporado. Hacemos una nueva mesa con nuestras manos. Cuando nos llega una muestra de tiempo, determinamos a qué tabla estamos escribiendo.
Seleccionamos el tiempo de la consulta de qué tabla leer. Si la lectura ocurre en el borde, leemos varias tablas. A continuación tenemos estos datos. Se podría usar la vista para esto. Por ejemplo, cree una vista para varias tablas, lo que le permite leerse en una sola consulta. Pero hay un error en ClickHouse: el predicado de la vista no se sustituye en las consultas. Por lo tanto, si realiza una solicitud a la vista, se dirige a todas las tablas. Vista que no podemos usar.
¿Cómo hacemos la disminución de muestras? Creamos una tabla temporal. Copie el inserto en datos seleccionados usando las funciones correctas.
Hacemos renombrar que es atómico bajo el bloqueo global. Estamos cambiando el nombre de la tabla existente a la anterior. Nuevo a existente. Dejamos caer la vieja mesa. Tenemos datos de 148 días ya de muestreo. ¿Cuál es el problema aquí? Insertar en se ve hermosa. De hecho, necesitamos aplicar las funciones correctas, la agregación correcta para hacer. En la práctica, esto no se puede hacer con una gran solicitud. Incluso algunas solicitudes grandes no se pueden hacer. Esto tiene que hacerse desde el código. El código envía una gran cantidad de solicitudes pequeñas. Hicimos todo lo posible para hacer esto con solicitudes grandes, pero esto no es muy efectivo. La disminución de datos de un día hasta ahora lleva menos de un día. Dependiendo de la cantidad de datos, puede llevar mucho tiempo.
ClickHouse tendrá actualización / eliminación. Eliminar ya tiene la primera versión. Si la actualización / eliminación funciona, nuestro esquema de datos de disminución de muestreo puede simplificarse.
En segundo lugar, ClickHouse tiene la tarea de hacer una compresión personalizada (delta, delta a delta). Esto es lo que hace TSDB. Esto es muy adecuado para datos de series temporales. Esto es especialmente útil si podremos elegir el tipo de compresión dependiendo de los tipos de datos. Por ejemplo, counter, que solo está creciendo; para esto, la compresión delta-delta es adecuada. Un medidor que fluctúa alrededor de la magnitud, por lo que el delta funciona bien.
Hay otro almacenamiento que funciona. Hay InfluxDB que funciona fuera de la caja. Es costumbre regañarlo por la velocidad, pero lo que funciona de inmediato y no necesitas hacer nada es bueno.
Hay OpenTSDB y Graphite, que es de solo escritura. El adaptador estándar de Prometheus realmente no funciona.
Hay un CrateDB. Hay un TimescaleDB que bifurca PostgreSQL para bases de datos de series temporales. Dicen que funciona bien, pero nosotros mismos no lo hemos probado.
Está Cortex, también conocido como el proyecto Frankenstein. Esto lo describe muy bien. Estos son los chicos que intentan tomar una decisión basada en la federación Prometheus. Almacenan datos en S3.
Hay Thanos
- Tiene una arquitectura muy interesante. Hay Prometheus que usa TSDB local. Se crea un clúster entre ellos. Al lado de cada Prometheus hay un sidecar especial, que acepta solicitudes a través de API de lectura remota y escritura remota. Redirige estas solicitudes a Prometeo. Prometheus puede usar sus API de lectura remota y escritura remota. Todos los side-cars están interconectados y entre maestros API personalizados a través de gRPC, la replicación está disponible, hay un nuevo sombreado.
- Arquitectura sofisticada.
- Está bastante húmedo. Hace un par de meses, se estaba cayendo a pedazos de media patada cuando comenzó.
Usar el modelo de extracción no escribe muchos datos. Debe esperar todo un año para completar los datos anuales. Estamos tratando de escribirlos de alguna manera allí.
No hay escritura remota en Prometheus, por lo tanto, escribir muchos datos en la TSDB local no funcionará.
El segundo problema Si generamos datos para pruebas de estrés, a menudo se sacuden bien. Por ejemplo, si tomamos datos existentes y generamos 100 instancias, y estos son los mismos datos, entonces el coeficiente de compresión será tan hermoso que en realidad no sucederá.
Escribimos un exportador falso que se parece a un exportador regular que Prometheus puede mantener unido:
- Cuando llega la chatarra, se dirige a algún exportador ascendente. Toma datos de ella.
- Genera muchas instancias. Digamos que 1 es un scrapie, y obtenemos 100 en la salida.
- Cambia ligeramente los datos: más menos 10% para el contador y el indicador.
- No cambia los valores simples 0 o 1. Porque si hay una métrica UP que responde, muestra si el servicio se está ejecutando: sí - 1 o no - 0. Y no está muy claro qué significa 098 UP.
- No cambiamos los enteros por números reales y viceversa.
- Solo da datos en el formato de expfmt habitual.
Una herramienta de promload que carga datos. Lectura de datos:
- Puede leer archivos en su propio formato
- Tal vez de lectura remota
- Puede leer de algún exportador
Escribe en diferentes formatos. Incluyendo en / dev / null, si queremos probar exactamente cómo funciona la lectura rápidamente.
Ahora es una herramienta de prueba de carga no solo para PromHouse, sino también para cualquier solución que use lectura remota o Prometheus.
Queremos agregar el almacenamiento en caché de lectura, porque en nuestras pruebas el cuello de botella fue a menudo el exportador falso, que generó datos durante mucho tiempo. Podríamos guardarlos en caché. Deja que sean irrealmente buenos. Pero no vamos a frenar. No tuvimos que esperar días para realizar pruebas de estrés.
Algún tipo de filtrado sobre la marcha, algún tipo de modificación sobre la marcha.
Soporte nativo para TSDB. Para trabajar con la base de datos en el disco, y no a través de la API.
Centrarse en la precisión para la migración. Una vez pmmdemo.percona.com puso: conectado, recibí todas las métricas. Si hace esto de forma nativa, Prometheus abre TSDB, levanta todas las series de tiempo del disco, levanta índices, luego se arrastra a archivos fragmentados y se da cuenta de que realmente existen. En este punto, todo puede simplemente tumbarse.
El enfoque ingenuo es tomar toda la serie temporal y leer los datos antiguos a los nuevos. En ese momento se acostará. Necesitas hacer lo contrario. Primero debe obtener la lista de series de tiempo con algunas consultas con expresiones regulares. Por ejemplo, una serie de tiempo que comienza en A. Luego, dame una serie de tiempo que comience en B. Luego cárgalas exactamente por métricas, no por tiempo. Esto es ilógico, pero así es como funciona. Esto es un matiz si haces algo así. Si ves que OOM Killer sucedió allí, entonces sabrás que es por tu culpa.
Los resultados de las pruebas de carga, no habrá gráficos. La prueba de carga lleva mucho tiempo y, desafortunadamente, debido a un error de configuración, todo salió mal. Por lo tanto, los resultados no funcionaron.
Escribiremos en el blog de Percona cuando hagamos pruebas de carga.
Puedo decir los resultados sin gráficos. La grabación fue lineal. La lectura saltó y no fue muy rápido. Leer los datos actuales no es muy importante para nosotros. Se pueden acelerar mediante sugerencias de lectura. Puede habilitar read_recent para mejorar la lectura. Y para datos antiguos, esto funciona bien.
La gente quiere almacenamiento a largo plazo. Hay tal demanda. Hablamos sobre PromHouse en PromCon. Allí fue un tema muy candente. Thanos se está desarrollando activamente.
Ya es posible ahora. Hay una solución para esto. Hay una API Hay algunas integraciones. Pero todo esto debe finalizarse con un archivo. No hay soluciones listas para la producción.
Enlaces donde buscar. El primer enlace es el repositorio PromHouse. El segundo enlace es donde es probable que se mueva. Ahora en un repositorio hay varias cosas diferentes? No muy estrechamente relacionado. Por lo tanto, deberá transferirlos.
Nuestro blog contendrá información sobre el rendimiento y algunas novedades.
Preguntas:
Pregunta: ¿Has revisado los rumores sobre InfluxDB?
Respuesta: No fue muy bueno. Se volvió mucho mejor. Todas estas historias sobre el hecho de que InfluxDB es lento, se están desmoronando, se trata de la versión anterior. La versión actual es estable. Yo no diría? Que funciona rápido. Pero funciona de manera estable. Ventajas de InfluxDB en mi opinión:
- En primer lugar, no hay necesidad de hacer algo cerca, porque InfluxDB funciona de forma inmediata.
- En segundo lugar, en ClickHouse, como en otras soluciones basadas en bases de datos, pero no en TSDB, puede usar un lenguaje de consulta que le resulte más familiar. El lenguaje de consulta InfluxDB es similar a SQL. Puede hacer análisis en él, lo cual es difícil de hacer en PromQL. Si usa TimeScaleDB, hay SQL real.
Pregunta: ¿El motor GraphiteMergeTree solo sirve para grabar trabajos? Si queremos mostrar gráficos, ¿es necesario configurar Grafana en Graphite para mostrar el almacenamiento a largo plazo?
Respuesta: sí. La integración que se encuentra en Prometheus funciona solo para la grabación. Él solo escribe datos. Entonces, desde Grafana, vas a Graphite.
Pregunta: ¿Y pierde etiquetas cuando escribe?
Respuesta: Hay una configuración que dice qué hacer con ellos, cómo insertarlos, dónde insertarlos.
Información de la audiencia: Avito dijo que están escribiendo su solución para grabaciones de Prometheus a Graphite.
Pregunta: se llegó a la conclusión de que con la grabación todo está bien en un servidor de almacenamiento a largo plazo.
(5- 15-). raid 6 sata ?
: PMM — . downsampling c 14 1 . , . . . .
: IOPS ?
: .
:
: . , . , , .
: InfluxDB, InfluxDB?
: read_recent. , remote storage. InfluxDB . . read_recent , .
: , Prometheus. InfluxDB. Grafana Prometheus. Prometheus PromQL , InfluxDB?
: .
: Prometheus InfluxDB Grafana?
: . Prometheus 2.2 , .
PS : valyala gecube
, .