VictoriaMetrics é un DBMS rápido e escalable para almacenar e procesar datos en forma de serie temporal (un rexistro consta de tempo e un conxunto de valores correspondentes a este tempo, por exemplo, obtidos mediante sondaxes periódicas do estado dos sensores ou colección de métricas).
Chámome Kolobaev Pavel. DevOps, SRE, LeroyMerlin, todo é como código: todo é sobre nós: sobre min e sobre outros empregados de LeroyMerlin.
Hai unha nube baseada en OpenStack. Hai unha pequena ligazón ao radar técnico.
Está construído no hardware Kubernetes, así como en todos os servizos relacionados para OpenStack e rexistro.
Este é o esquema que tiñamos en desenvolvemento. Cando estabamos a desenvolver todo isto, tiñamos un operador Prometheus que almacenaba datos dentro do propio clúster K8s. Automáticamente atopa o que hai que fregar e pono debaixo dos seus pés, grosso modo.
Teremos que mover todos os datos fóra do clúster de Kubernetes, porque se ocorre algo, debemos entender que e onde.
A primeira solución é que usamos a federación cando temos un Prometheus de terceiros, cando imos ao clúster de Kubernetes a través do mecanismo de federación.
Pero aquí hai algúns pequenos problemas. No noso caso, os problemas comezaron cando tiñamos 250 métricas, e cando había 000 métricas, decatámonos de que non podíamos traballar así. Aumentamos scrape_timeout a 400 segundos.
Por que tivemos que facer isto? Prometheus comeza a contar o tempo morto desde o inicio da cerca. Non importa que os datos sigan fluíndo. Se durante este período de tempo especificado os datos non se fusionan e a sesión non se pecha a través de http, entón considérase que a sesión fallou e os datos non entran no propio Prometheus.
Todo o mundo está familiarizado coas gráficas que obtemos cando faltan algúns datos. Os horarios están rasgados e non estamos contentos con isto.
A seguinte opción é a fragmentación baseada en dous Prometheus diferentes mediante o mesmo mecanismo de federación.
Por exemplo, só tes que collelos e dividilos polo seu nome. Isto tamén se pode usar, pero decidimos seguir adiante.
Agora teremos que procesar estes fragmentos dalgún xeito. Podes tomar promxy, que vai á área de fragmentos e multiplica os datos. Funciona con dous fragmentos como un único punto de entrada. Isto pódese implementar a través de promxy, pero aínda é demasiado difícil.
A primeira opción é que queremos abandonar o mecanismo federativo porque é moi lento.
Os desenvolvedores de Prometheus están dicindo claramente: "Rapaces, use un TimescaleDB diferente porque non admitiremos o almacenamento a longo prazo de métricas". Esta non é a súa tarefa.
Anotamos nun papel que aínda temos que descargar fóra, para non gardar todo nun só sitio.
O segundo inconveniente é o consumo de memoria. Si, entendo que moitos dirán que en 2020 un par de gigabytes de memoria custa un céntimo, pero aínda así.
Agora temos un ambiente de desenvolvemento e produción. En desenvolvemento son uns 9 gigabytes para 350 métricas. En prod son 000 gigabytes e algo máis de 14 métricas. Ao mesmo tempo, o noso tempo de retención é de só 780 minutos. Isto é malo. E agora explicarei por que.
Facemos un cálculo, é dicir, cun millón e medio de métricas, e xa estamos preto delas, na fase de deseño conseguimos 35-37 gigabytes de memoria. Pero xa 4 millóns de métricas requiren uns 90 gigabytes de memoria. É dicir, calculouse mediante a fórmula proporcionada polos desenvolvedores de Prometheus. Observamos a correlación e decatámonos de que non queriamos pagar un par de millóns por un servidor só para supervisar.
Non só aumentaremos o número de máquinas, tamén estamos monitorizando as propias máquinas virtuais. Polo tanto, cantas máis máquinas virtuais, máis métricas de varios tipos, etc. Teremos un crecemento especial do noso clúster en canto a métricas.
Co espazo no disco, aquí non todo está tan mal, pero gustaríame melloralo. Recibimos un total de 15 gigabytes en 120 días, dos cales 100 son datos comprimidos, 20 son datos sen comprimir, pero sempre queremos menos.
En consecuencia, anotamos un punto máis: este é un gran consumo de recursos, que aínda queremos aforrar, porque non queremos que o noso clúster de seguimento consuma máis recursos que o noso clúster, que xestiona OpenStack.
Hai un inconveniente máis de Prometheus, que identificamos por nós mesmos, isto é polo menos algún tipo de limitación da memoria. Con Prometheus, aquí todo é moito peor, porque non ten tales xiros. Usar un límite en docker tampouco é unha opción. Se de súpeto o teu RAF caeu e hai 20-30 gigabytes, tardará moito en aumentar.
Esta é outra razón pola que Prometheus non é axeitado para nós, é dicir, non podemos limitar o consumo de memoria.
Sería posible elaborar tal esquema. Necesitamos este esquema para organizar un clúster HA. Queremos que as nosas métricas estean dispoñibles sempre e en todas partes, aínda que o servidor que almacena estas métricas falla. E así teremos que construír tal esquema.
Este esquema di que teremos duplicación de fragmentos e, en consecuencia, duplicación dos custos dos recursos consumidos. Pódese escalar case horizontalmente, pero con todo o consumo de recursos será infernal.
Desvantaxes en orde na forma na que os anotamos por nós mesmos:
- Require carga externa de métricas.
- Alto consumo de recursos.
- Non hai forma de limitar o consumo de memoria.
- Implementación complexa e intensiva de recursos de HA.
Por nós mesmos, decidimos que nos afastamos de Prometheus como almacén.
Identificamos requisitos adicionais para nós que necesitamos. Isto:
- Isto é soporte de promql, porque xa se escribiron moitas cousas para Prometheus: consultas, alertas.
- E despois temos a Grafana, que xa está escrita exactamente do mesmo xeito para Prometheus como backend. Non quero reescribir os paneis.
- Queremos construír unha arquitectura HA normal.
- Queremos reducir o consumo de calquera recurso.
- Hai outro pequeno matiz. Non podemos utilizar varios tipos de sistemas de recollida de métricas na nube. Aínda non sabemos o que entrará nestas métricas. E como calquera cousa pode voar alí, temos que limitarnos á colocación local.
Había pouca elección. Recollemos todo o que tivemos experiencia. Miramos a páxina de Prometheus na sección de integración, lemos un montón de artigos e vimos o que había. E por nós mesmos, escollemos VictoriaMetrics como substituto de Prometheus.
Por que? Porque:
- Coñece promql.
- Hai unha arquitectura modular.
- Non require cambios en Grafana.
- E o máis importante, probablemente proporcionaremos o almacenamento de métricas dentro da nosa empresa como un servizo, polo que estamos mirando con antelación restricións de varios tipos para que os usuarios poidan utilizar todos os recursos do clúster dalgún xeito limitado, porque hai posibilidades. que será multitenencia.
Imos facer a primeira comparación. Tomamos o mesmo Prometeo dentro do cúmulo, Prometeo externo vai a el. Engadir mediante remoteWrite VictoriaMetrics.
Inmediatamente farei unha reserva de que aquí detectamos un lixeiro aumento no consumo de CPU de VictoriaMetrics. A wiki de VictoriaMetrics indícache cales son os mellores parámetros. Comprobámolos. Reduciron moi ben o consumo de CPU.
No noso caso, o consumo de memoria de Prometheus, que está situado no clúster de Kubernetes, non aumentou significativamente.
Comparamos dúas fontes de datos dos mesmos datos. En Prometheus vemos os mesmos datos que faltan. Todo está ben en VictoriaMetrics.
Resultados da proba de espazo no disco. En Prometheus recibimos 120 gigabytes en total. En VictoriaMetrics xa recibimos 4 gigabytes por día. Hai un mecanismo lixeiramente diferente ao que estamos acostumados a ver en Prometheus. É dicir, os datos xa están bastante ben comprimidos nun día, en media hora. Xa se colleitaron ben nun día, en media hora, a pesar de que os datos aínda se perderán despois. Como resultado, aforramos espazo no disco.
Tamén aforramos no consumo de recursos de memoria. No momento da proba, tiñamos Prometheus despregado nunha máquina virtual: 8 núcleos, 24 gigabytes. Prometeo come case de todo. Caeu sobre OOM Killer. Ao mesmo tempo, só se verteron nela 900 métricas activas. Trátase dunhas 000-25 métricas por segundo.
Executamos VictoriaMetrics nunha máquina virtual de dobre núcleo con 8 gigabytes de RAM. Conseguimos que VictoriaMetrics funcione ben xogando con algunhas cousas nunha máquina de 8 GB. Ao final, mantímolo en 7 gigabytes. Ao mesmo tempo, a velocidade de entrega de contidos, é dicir, as métricas, foi incluso superior á de Prometheus.
A CPU foi moito mellor en comparación con Prometheus. Aquí Prometheus consome 2,5 núcleos e VictoriaMetrics só consome 0,25 núcleos. Ao principio - 0,5 núcleos. A medida que se fusiona, chega a un núcleo, pero isto é extremadamente raro.
No noso caso, a elección recaeu en VictoriaMetrics por razóns obvias; queriamos aforrar cartos e así o fixemos.
Tachemos de inmediato dous puntos: a carga de métricas e o alto consumo de recursos. E só nos queda decidir dous puntos que aínda nos quedan para nós.
Aquí farei unha reserva de inmediato, consideramos VictoriaMetrics como un almacenamento de métricas. Pero como é moi probable que forneceremos VictoriaMetrics como almacenamento para todo Leroy, temos que limitar os que usarán este clúster para que non nolo dean.
Hai un parámetro marabilloso que che permite limitar por tempo, por volume de datos e por tempo de execución.
Tamén existe unha excelente opción que nos permite limitar o consumo de memoria, polo que podemos atopar o propio equilibrio que nos permitirá obter unha velocidade de funcionamento normal e un consumo de recursos adecuado.
Menos un punto máis, é dicir, tacha o punto: non podes limitar o consumo de memoria.
Nas primeiras iteracións, probamos VictoriaMetrics Single Node. A continuación pasamos á versión do clúster de VictoriaMetrics.
Aquí temos a man libre para separar os distintos servizos en VictoriaMetrics dependendo de con que funcionarán e de que recursos consumirán. Esta é unha solución moi flexible e cómoda. Usamos isto para nós mesmos.
Os compoñentes principais da versión do clúster de VictoriaMetrics son vmstsorage. Pode haber N número deles. No noso caso son 2 ata agora.
E hai vminsert. Este é un servidor proxy que nos permite: organizar o sharding entre todos os almacenamentos dos que lle falamos, e tamén permite unha réplica, é dicir, terá tanto o sharding como unha réplica.
Vminsert admite os protocolos OpenTSDB, Graphite, InfluxDB e remoteWrite de Prometheus.
Tamén hai vmselect. A súa tarefa principal é ir a vmstorage, recibir datos deles, deduplicar estes datos e entregalos ao cliente.
Hai unha cousa marabillosa chamada vmagent. Gústanos moito ela. Permítelle configurar exactamente como Prometheus e aínda facer todo exactamente como Prometheus. É dicir, recolle métricas de diferentes entidades e servizos e envíaas a vminsert. Entón todo depende de ti.
Outro gran servizo é vmalert, que che permite usar VictoriaMetrics como backend, recibir datos procesados de vminsert e envialos a vmselect. Procesa as propias alertas, así como as regras. No caso das alertas, recibimos a alerta a través de alertmanager.
Hai un compoñente wmauth. Podemos ou non (aínda non o decidimos) usalo como sistema de autorización para a versión multitenencia dos clústeres. Admite remoteWrite para Prometheus e pode autorizar en función da url, ou mellor dito na segunda parte dela, onde podes escribir ou non.
Tamén hai vmbackup, vmrestore. Esta é, en esencia, a restauración e copia de seguridade de todos os datos. Pode facer S3, GCS, arquivo.
A primeira iteración do noso clúster realizouse durante a corentena. Nese momento, non había réplica, polo que a nosa iteración consistía en dous clústeres diferentes e independentes nos que recibimos datos mediante remoteWrite.
Aquí farei unha reserva de que cando cambiamos de VictoriaMetrics Single Node a VictoriaMetrics Cluster Version, aínda nos quedamos cos mesmos recursos consumidos, é dicir, o principal é a memoria. Así é aproximadamente como se distribuíron os nosos datos, é dicir, o consumo de recursos.
Aquí xa se engadiu unha réplica. Combinamos todo isto nun clúster relativamente grande. Todos os nosos datos son fragmentados e replicados.
Todo o clúster ten N puntos de entrada, o que significa que Prometheus pode engadir datos a través de HAPROXY. Aquí temos este punto de entrada. E a través deste punto de entrada podes iniciar sesión desde Grafana.
No noso caso, HAPROXY é o único porto que proxy selecciona, insire e outros servizos dentro deste clúster. No noso caso, foi imposible facer un enderezo; tivemos que facer varios puntos de entrada, porque as propias máquinas virtuais nas que se executa o clúster VictoriaMetrics están situadas en diferentes zonas do mesmo provedor de nube, é dicir, non dentro da nosa nube, senón fóra. .
Temos alerta. Usámolo. Usamos alertmanager de Prometheus. Usamos Opsgenie e Telegram como canle de entrega de alertas. En Telegram chegan desde dev, quizais algo de prod, pero sobre todo algo estatístico, necesario polos enxeñeiros. E Opsgenie é crítico. Son chamadas, xestión de incidencias.
A eterna pregunta: "Quen supervisa o seguimento?" No noso caso, a monitorización monitoriza a propia monitorización, porque usamos vmagent en cada nodo. E dado que os nosos nodos están distribuídos en diferentes centros de datos do mesmo provedor, cada centro de datos ten a súa propia canle, son independentes e aínda que chegue un cerebro dividido, seguiremos recibindo alertas. Si, haberá máis, pero é mellor recibir máis alertas que ningunha.
Rematamos a nosa lista cunha implementación HA.
E ademais gustaríame destacar a experiencia de comunicación coa comunidade VictoriaMetrics. Resultou moi positivo. Os mozos responden. Tentan afondar en cada caso que se ofrece.
Comecei problemas en GitHub. Resolvéronse moi rápido. Hai un par de problemas máis que non están completamente pechados, pero xa podo ver polo código que se está a traballar nesta dirección.
A principal dor para min durante as iteracións foi que se pechaba un nodo, durante os primeiros 30 segundos vminsert non podía entender que non había backend. Isto xa está decidido. E, literalmente, nun ou dous segundos, os datos tómanse de todos os nodos restantes e a solicitude deixa de esperar por ese nodo que falta.
Nalgún momento quixemos que VictoriaMetrics fose un operador de VictoriaMetrics. Esperámolo. Agora estamos construíndo activamente un marco para que o operador VictoriaMetrics tome todas as regras previas ao cálculo, etc. Prometheus, porque estamos usando moi activamente as regras que veñen co operador Prometheus.
Existen propostas para mellorar a implantación do clúster. Esbocéinos arriba.
E realmente quero baixar a mostra. No noso caso, a submostraxe é necesaria exclusivamente para ver as tendencias. En liñas xerais, unha métrica é suficiente para min durante o día. Estas tendencias son necesarias durante un ano, tres, cinco, dez anos. E un valor métrico é suficiente.
- Coñecemos a dor, como algúns dos nosos colegas, ao usar Prometheus.
- Escollemos VictoriaMetrics para nós.
- Escala bastante ben tanto vertical como horizontalmente.
- Podemos distribuír diferentes compoñentes a diferentes números de nodos do clúster, limitalos por memoria, engadir memoria, etc.
Usaremos VictoriaMetrics na casa porque nos gustou moito. Isto é o que foi e o que se converteu.
Un par de códigos QR para o chat de VictoriaMetrics, os meus contactos, o radar técnico de LeroyMerlin.
Fonte: www.habr.com