{"id":94153,"date":"2020-09-13T19:42:30","date_gmt":"2020-09-13T17:42:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev"},"modified":"2020-09-13T19:42:30","modified_gmt":"2020-09-13T17:42:30","slug":"victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/victoriametrics-i-monitoring-privatnyh-oblakov-pavel-kolobaev","title":{"rendered":"VictoriaMetrics y la monitorizaci\u00f3n de nubes privadas. Pavel Kolobaev","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"VictoriaMetrics<\/p>\n

<\/p>\n

VictoriaMetrics: una base de datos r\u00e1pida y escalable para el almacenamiento y procesamiento de datos en forma de series temporales (una entrada consiste en un tiempo y un conjunto de valores correspondientes a ese tiempo, por ejemplo, obtenidos a trav\u00e9s de la supervisi\u00f3n peri\u00f3dica del estado de los sensores o la recolecci\u00f3n de m\u00e9tricas).<\/p>\n

<\/a><\/noindex>
\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Me llamo Pavel Kolobayev. DevOps, SRE, LeroyMerlin, todo como c\u00f3digo - esto es de lo que se trata: de m\u00ed y de otros empleados de LeroyMerlin.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

https:\/\/bit.ly\/3jf1fIK<\/a><\/noindex><\/p>\n

<\/p>\n

Hay un nube basada en OpenStack. Aqu\u00ed hay un peque\u00f1o enlace al radar tecnol\u00f3gico. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Est\u00e1 construido sobre hardware de Kubernetes, as\u00ed como en todos los servicios asociados a OpenStack y registro. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

El esquema que ten\u00edamos durante el desarrollo era el siguiente. Cuando desarroll\u00e1bamos todo esto, ten\u00edamos un operador Prometheus que almacenaba datos dentro del propio cl\u00faster de K8s. Autom\u00e1ticamente encuentra lo que necesita ser rastreado y lo almacena, por as\u00ed decirlo. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Todos los datos deben ser extra\u00eddos del cl\u00faster de Kubernetes, porque si algo sucede, debemos entender qu\u00e9 y d\u00f3nde. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La primera soluci\u00f3n es que utilizamos federation, cuando tenemos un Prometheus externo, al que accedemos al cl\u00faster de Kubernetes a trav\u00e9s del mecanismo de federation.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Pero aqu\u00ed surgen peque\u00f1os problemas. En nuestro caso, los problemas comenzaron cuando ten\u00edamos 250,000 m\u00e9tricas, y cuando llegamos a 400,000 m\u00e9tricas, nos dimos cuenta de que no pod\u00edamos trabajar as\u00ed. Aumentamos el scrape_timeout a 25 segundos.<\/p>\n

<\/p>\n

\u00bfPor qu\u00e9 tuvimos que hacer esto? Prometheus comienza a contar el tiempo de espera desde el inicio de la recolecci\u00f3n. Y no importa que los datos todav\u00eda se est\u00e9n transmitiendo. Si en ese intervalo de tiempo especificado no se han transmitido datos y la sesi\u00f3n no se ha cerrado por http, se considera que la sesi\u00f3n fall\u00f3 y los datos no llegan a Prometheus.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Todos conocen las gr\u00e1ficas que obtenemos cuando faltan algunos datos. Las gr\u00e1ficas est\u00e1n rotas y eso no nos satisface. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La siguiente opci\u00f3n es el sharding basado en dos Prometheus diferentes a trav\u00e9s del mismo mecanismo de federation.<\/p>\n

<\/p>\n

Por ejemplo, simplemente tomar y hacer sharding por nombre. Esto tambi\u00e9n se puede usar, pero decidimos avanzar m\u00e1s. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Ahora tendremos que procesar estos shards de alguna manera. Se puede utilizar promxy, que accede al \u00e1rea del shard, multiplica los datos. Funciona con dos shards como un \u00fanico punto de entrada. Esto se puede implementar a trav\u00e9s de promxy, pero por ahora es demasiado complicado. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

La primera opci\u00f3n es que queremos deshacernos del mecanismo de federation, porque es muy lento. <\/p>\n

<\/p>\n

Los desarrolladores de Prometheus dicen claramente: \u00abChicos, usen otras TimescaleDB, porque no vamos a soportar un almacenamiento prolongado de m\u00e9tricas\u00bb. No es su tarea. \"VictoriaMetrics<\/p>\n

<\/p>\n

Anotamos en papel que necesitamos una exportaci\u00f3n externa para no almacenar todo en un solo lugar. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

El segundo inconveniente es el consumo de memoria. S\u00ed, entiendo que muchos dir\u00e1n que en 2020 un par de gigabytes de memoria es barato, pero aun as\u00ed. <\/p>\n

<\/p>\n

Ahora tenemos un entorno de desarrollo y producci\u00f3n. En desarrollo, ocupamos alrededor de 9 gigabytes para 350,000 m\u00e9tricas. En producci\u00f3n, son 14 gigabytes con un poco m\u00e1s para 780,000 m\u00e9tricas. Adem\u00e1s, nuestro tiempo de retenci\u00f3n es de solo 30 minutos. Eso es un problema, y voy a explicar por qu\u00e9.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Hacemos un c\u00e1lculo, es decir, con un mill\u00f3n y medio de m\u00e9tricas, que ya estamos alcanzando, en la etapa de dise\u00f1o obtenemos 35-37 gigabytes de memoria. Pero ya para 4 millones de m\u00e9tricas se necesitan alrededor de 90 gigabytes de memoria. Es decir, esto fue calculado seg\u00fan la f\u00f3rmula que proporcionan los desarrolladores de Prometheus. Observamos la correlaci\u00f3n y entendimos que no queremos pagar un par de millones por un servidor solo para monitorear. <\/p>\n

<\/p>\n

No solo aumentar\u00e1 la cantidad de m\u00e1quinas, sino que tambi\u00e9n monitoreamos las propias m\u00e1quinas virtuales. Por lo tanto, cuanto m\u00e1s virtuales sean las m\u00e1quinas, m\u00e1s m\u00e9tricas de diferentes tipos habr\u00e1, etc. Tendremos un crecimiento especial de nuestro cl\u00faster en t\u00e9rminos de m\u00e9tricas.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

En cuanto al espacio en disco, aqu\u00ed no est\u00e1 tan mal, pero nos gustar\u00eda mejorarlo. En 15 d\u00edas, hemos acumulado 120 gigabytes, de los cuales 100 son datos comprimidos y 20 son datos sin comprimir, pero siempre queremos menos. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Por lo tanto, anotamos otro punto: es un alto consumo de recursos, que queremos seguir economizando, porque no queremos que nuestro cl\u00faster de monitoreo consuma m\u00e1s recursos que nuestro cl\u00faster que gestiona OpenStack.<\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Hay otro inconveniente con Prometheus que hemos identificado: hay alguna limitaci\u00f3n en la memoria. Con Prometheus es mucho peor, porque no tiene tales configuraciones. Usar limitaciones en Docker tampoco es una opci\u00f3n. Si su RAF falla y hay 20-30 gigabytes, tardar\u00e1 mucho en levantarse. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Esta es otra raz\u00f3n por la que Prometheus no nos sirve, es decir, no se puede limitar el consumo de memoria. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Se podr\u00eda llegar a un esquema as\u00ed. Este esquema lo necesitamos para organizar un cl\u00faster HA. Queremos que nuestras m\u00e9tricas est\u00e9n disponibles siempre y en cualquier lugar, incluso en caso de ca\u00edda del servidor que almacena estas m\u00e9tricas. Por lo tanto, tendremos que construir un esquema as\u00ed. <\/p>\n

<\/p>\n

Este esquema indica que tendremos duplicaci\u00f3n de shards y, por ende, duplicaci\u00f3n de los recursos consumidos. Se puede escalar horizontalmente casi, pero a\u00fan as\u00ed el consumo de recursos ser\u00e1 enorme. <\/p>\n

<\/p>\n

\"VictoriaMetrics<\/p>\n

<\/p>\n

Los inconvenientes en el orden que los hemos enumerado son:<\/p>\n

<\/p>\n