Ola a todos. Abaixo está a transcrición .
– un sistema de monitorización de varios sistemas e servizos, coa axuda do cal os administradores do sistema poden recoller información sobre os parámetros actuais dos sistemas e configurar alertas para recibir notificacións sobre desviacións no funcionamento dos sistemas.
O informe incluirá unha comparación и — proxectos de almacenamento a longo prazo de métricas de Prometheus.
En primeiro lugar, falareivos de Prometeo. Este é un sistema de seguimento que recolle métricas de obxectivos especificados e gárdaas no almacenamento local. Prometheus pode gravar métricas no almacenamento remoto e pode xerar alertas e regras de gravación.
Limitacións de Prometheus:
- Non ten unha vista de consulta global. Isto é cando tes varias instancias independentes de prometheus. Recollen métricas. E quere consultar todas estas métricas recollidas de diferentes instancias de prometheus. Prometheus non permite isto.
- Con prometheus, o rendemento está limitado a un só servidor. Prometheus non escala automaticamente en varios servidores. Só podes dividir manualmente os teus obxectivos entre varios Prometheus.
- O alcance das métricas en Prometheus está limitado a un só servidor polo mesmo motivo de que non pode escalar automaticamente en varios servidores.
- Non é tan sinxelo organizar a seguridade dos datos en Prometheus.
Solucións a estes problemas/retos?
As solucións son:
Todas estas solucións son para o almacenamento remoto dos datos recollidos por Prometheus. Resolven o problema de almacenamento remoto da diapositiva anterior de diferentes xeitos. Nesta presentación só falarei das dúas primeiras solucións: и .
Por primeira vez información sobre apareceu por . A arquitectura descríbese alí e como funciona.
Thanos toma os datos que Prometheus gardou no disco local e cópiaos no S3 ou a outro almacenamento de obxectos.
Así, Thanos ofrece unha vista de consulta global. Pode consultar os datos almacenados no almacenamento de obxectos desde varias instancias de Prometheus.
Thanos admite PromQL e .
Thanos usa código Prometheus para almacenar datos.
Thanos é desenvolvido polos mesmos desenvolvedores que Prometheus.
en ... Aquí , onde falamos por primeira vez .
VictoriaMetrics recibe datos de varios prometheus protocolo compatible con Prometheus.
VictoriaMetrics ofrece unha vista de consulta global, xa que varias instancias de Prometheus poden escribir datos nun VictoriaMetrics. En consecuencia, pode facer consultas sobre todos estes datos.
VictoriaMetrics tamén admite a API de consulta de Thanos, PromQL e Prometheus.
A diferenza de Thanos, o código fonte de VictoriaMetrics está escrito desde cero e está optimizado para a velocidade e o consumo de recursos.
VictoriaMetrics, a diferenza de Thanos, escala tanto vertical como horizontalmente. Comer , que escala verticalmente. Podes comezar cun procesador e 1 GB de memoria e crecer gradualmente ata chegar a centos de procesadores e 1 TB de memoria. VictoriaMetrics pode usar todos estes recursos. O seu rendemento aumentará unhas 100 veces en comparación cun sistema de 1 núcleo.
A historia de Thanos comezou en novembro de 2017, cando apareceu o primeiro compromiso público. Antes disto, Thanos desenvolveuse internamente .
En xuño de 2019 houbo unha versión histórica 0.5.0, na que protocolo. El foi retirado de Thanos porque non funcionou ben. Moitas veces, o clúster de Thanos non funcionaba correctamente, os nodos conectados a el incorrectamente debido ao protocolo de fofocas. Por iso, decidimos quitalo de alí. Creo que esta é a decisión correcta.
No mesmo xuño de 2019 enviaron o número de solicitude в .
E despois dun par de meses, Thanos foi aceptado , que inclúe Prometheus, Kubernetes e outros proxectos populares.
En xaneiro de 2018 comezou o desenvolvemento de VictoriaMetrics.
En setembro de 2018, mencionei publicamente VictoriaMetrics por primeira vez.
En decembro de 2018 publicouse unha versión dun só nodo.
En maio 2019 fontes tanto de versións de nodo único como de cluster.
En xuño de 2019, ao igual que Thanos, presentamos unha solicitude á fundación CNCF baixo o número . Solicitamos un día antes de que Thanos solicitase.
Pero, por desgraza, aínda non nos aceptaron alí. Necesítase axuda comunitaria.
Vexamos as diapositivas máis importantes que mostran a arquitectura de Thanos e VictoriaMetrics.
Comecemos por Thanos. Os compoñentes amarelos son compoñentes de Prometheus. Todo o demais son compoñentes de Thanos. Comecemos polo compoñente máis importante. Thanos Sidecar é un compoñente que se instala xunto a todos os Prometheus. Carga os datos de Prometheus do almacenamento local no S3 ou noutro Object Storage.
Tamén hai un compoñente chamado Thanos Store Gateway, que pode ler estes datos de Object Storage ás solicitudes entrantes de Thanos Query. Thanos Query implementa PromQL e Prometheus API. É dicir, desde fóra parece Prometeo. Recibe consultas de PromQL, envíaas a Thanos Store Gateway, Thanos Store Gateway recupera os datos necesarios de Object Storage e envíaos de volta.
Pero almacenamos os datos en Object Storage sen as dúas últimas horas debido a unha función da implementación de Thanos Sidecar, que non pode cargar as últimas dúas horas en Object Storage S3, xa que Prometheus aínda non creou ficheiros para estas dúas horas no almacenamento local.
Como decidiches sortear isto? Thanos Query, ademais das solicitudes ao Thanos Store Gateway, envía solicitudes paralelas a cada Thanos Sidecar, que está situado xunto a Prometheus.
E Thanos Sidecar, á súa vez, envía as solicitudes de proxy a Prometheus e recupera os datos das dúas últimas horas.
Ademais destes compoñentes, tamén hai un compoñente opcional sen o cal Thanos non funcionará ben. Trátase de Thanos Compact, que se encarga de fusionar ficheiros pequenos en Object Storage en ficheiros máis grandes que foron cargados aquí por Thanos Sidecars. Thanos Sidecar carga alí ficheiros de datos en dúas horas. Estes ficheiros, se non se fusionan en ficheiros máis grandes, entón o seu número pode crecer de forma moi significativa. Cantos máis ficheiros deste tipo, máis memoria se necesita para Thanos Store Gateway, máis recursos son necesarios para transferir datos a través da rede e metadatos. Thanos Store Gateway vólvese ineficaz. Polo tanto, é necesario executar Thanos Compact, que fusiona ficheiros pequenos noutros máis grandes, para que haxa menos ficheiros deste tipo e para reducir a sobrecarga na pasarela de Thanos Store.
Tamén hai un compoñente como Thanos Ruler. Executa as regras de alerta de Prometheus e pode avaliar as regras de gravación de Prometheus para escribir datos de novo no Object Storage. Pero non se recomenda o uso deste compoñente, porque... El .
Este é o esquema sinxelo de Thanos.
Agora comparémolo co esquema VictoriaMetrics.
VictoriaMetrics ten 2 versións: versión dun só nodo e versión cluster. Un só nodo execútase nun ordenador. Un único nodo non ten estes compoñentes, só un binario. Este binario da diapositiva parece este cadrado. Todo o que está dentro do cadrado é o contido do ficheiro binario para a versión Single-node. Non necesitas saber sobre el. Simplemente executa o binario e todo funciona para nós.
A versión do cluster é máis complicada. No seu interior hai tres compoñentes diferentes: vmselect, vminsert e vmstorage. Do seu nome debería quedar claro o que fai cada un deles. O compoñente Insert acepta datos en diferentes formatos: desde a API de escritura remota de Prometheus, o protocolo de liña Influx, o protocolo Graphite e o protocolo OpenTSDB. O compoñente Inserir acéptaos, analízaos e distribúeos entre os compoñentes de almacenamento existentes, onde os datos xa están almacenados. O compoñente Select, pola súa banda, acepta consultas PromQL. El aplica , así como a API de consulta de Prometheus, e pódese usar como substituto de Prometheus en Grafana ou noutros clientes da API de Prometheus. Select acepta unha solicitude promql, analízaa, le os datos necesarios para executar esta solicitude desde os nodos de almacenamento, procesa estes datos e devolve unha resposta.
Comparemos a complexidade da instalación de Thanos e VictoriaMetrics.
Comecemos por Thanos. Antes de comezar a traballar con Thanos, cómpre crear un depósito en Object Storage, como S3 ou GCS, para que Thanos Sidecar poida escribir datos nel.
Despois, para cada Prometheus, necesitas instalar Thanos Sidecar. Antes diso, cómpre lembrar de desactivar a compactación de datos en Prometheus. A compactación de datos comprime periodicamente os datos no almacenamento local de Prometheus para reducir o consumo de recursos.
Cando instales Thanos Sidecar no teu Prometheus, debes desactivar esta compactación de datos, porque Thanos Sidecar non funciona correctamente coa compactación de datos activada. Isto significa que o teu Prometheus comeza a gardar datos en bloques de dúas horas e deixa de fusionar eses bloques noutros máis grandes. En consecuencia, se realizas consultas que superan a duración das dúas últimas horas, non funcionarán tan eficientemente como poderían funcionar se se activase a compactación de datos.
Polo tanto, Thanos recomenda reducir o tempo de retención de datos no almacenamento local a 6-8 horas para reducir a sobrecarga dun gran número de pequenos bloques.
Unha vez que teñas instalado Thanos Sidecar, debes instalar dous compoñentes para cada balde de almacenamento de obxectos. Estes son Thanos Compactor e Thanos Store Gateway.
Despois diso, cómpre instalar Thanos Query e configuralo para que poida conectarse a todas as pasarelas de Thanos Store que teña e tamén se poida conectar a todos os Thanos Sidecars.
Pode haber un pequeno problema aquí.
Debe configurar unha conexión fiable e segura desde Thanos Query a estes compoñentes. E se o teu Prometheus está situado en diferentes centros de datos ou en diferentes VPC, as conexións con eles desde fóra están prohibidas. Pero para que Thanos Query funcione, cómpre configurar a conexión dalgún xeito e debes descubrir un xeito.
Se tes moitos centros de datos deste tipo, entón, en consecuencia, a fiabilidade de todo o sistema diminúe. Xa que Thanos Query debe manter conexións constantemente con todos os Sidecars de Thanos situados en diferentes centros de datos. Para cada solicitude entrante, enviará as solicitudes a todos os Sidecars de Thanos. Se a conexión se interrompe, recibirá un conxunto incompleto de datos ou recibirá unha resposta de "clúster caído".
En VictoriaMetrics todo é un pouco máis sinxelo. Para a versión de nodo único, só precisa executar un binario e todo funciona.
Na versión de clúster, abonda con executar os tres tipos de compoñentes anteriores en calquera cantidade que necesites ou uses para automatizar o lanzamento de compoñentes en Kubernetes. Tamén estamos planeando facer un operador de Kubernetes. O gráfico Helm non cobre algúns casos e permíteche disparar no pé. Por exemplo, permítelle reducir o número de nodos de almacenamento, o que levará á perda de datos.
Despois de lanzar unha versión binaria ou agrupada, só precisa engadir Prometheus á configuración para que comece a escribir datos en paralelo ao almacenamento local e ao almacenamento remoto. Como podes ver, esta configuración debería funcionar de forma moito máis fiable en comparación coa configuración de Thanos. Non necesitamos manter unha conexión de VictoriaMetrics a todos os Prometheus, porque os propios Prometheus se conectan a VictoriaMetrics e transmiten datos.
Consideremos o apoio de Thanos e VictoriaMetrics.
Thanos debe supervisar Sidecar para asegurarse de que non deixa de cargar datos no Object Storage. Poden deter esta descarga de datos debido a erros de descarga, por exemplo, a súa conexión de rede a Object Storage está temporalmente interrompida ou o Object Storage non está dispoñible temporalmente. Thanos Sidecar notará isto neste momento, informará dun erro, pode fallar e despois deixará de funcionar. Se non o supervisas, deixarás de transferir datos a Object Storage. Se o tempo de retención pasa (recoméndase de 6 a 8 horas), perderá os datos que non acabaron no Almacenamento de obxectos.
Os compactadores Thanos poden deixar de funcionar debido a . Os compactadores toman datos de Object Storage e combínaos en pezas de datos máis grandes. Dado que os compactadores non están sincronizados cos Sidecars, pode ocorrer o seguinte: Sidecar aínda non tivo tempo para completar o bloque, Compactor decide que este bloque foi completamente escrito. Compactor comeza a lelo. Non le o bloque completo e deixa de funcionar. Ver detalles .
Store Gateway pode devolver datos incoherentes debido a carreiras entre Compactor e Sidecars. O mesmo ocorre aquí, porque Store Gateway non está sincronizado de ningún xeito con Compactors e Sidecars. En consecuencia, as condicións de carreira poden ocorrer cando Store Gateway non ve parte dos datos ou ve datos innecesarios.
O compoñente Consulta en Thanos devolve un resultado parcial por defecto se algúns Sidecars ou pasarelas de tenda non están dispoñibles neste momento. Recibirás parte dos datos, e nin sequera saberás que non recibiches todos os datos. Así é como funciona por defecto. Nunha situación similar, VictoriaMetrics devolve os datos marcados como parciais.
A diferenza de Thanos, VictoriaMetrics raramente perde datos. Aínda que se interrompa a conexión de Prometheus a VictoriaMetrics, isto non é un problema, xa que Prometheus segue rexistrando novos datos entrantes no rexistro de escritura anticipada, cuxo tamaño é de 2 horas. Se restauras a túa conexión a VictoriaMetrics nun prazo de dúas horas, non se perderán os teus datos. Prometeo .
A diferenza de Thanos, que escribe datos no almacenamento de obxectos só despois de dúas horas, Prometheus replica automaticamente os datos mediante o protocolo de escritura remota no almacenamento remoto, como VictoriaMetrics. Non tes medo de perder o almacenamento local en Prometheus. Se de súpeto perdeu o almacenamento local, entón no peor dos casos perderá os últimos segundos de datos que non tiveron tempo para ser gravados no almacenamento remoto.
Kubernetes xestiona automaticamente o clúster, a diferenza de Thanos. É difícil colocar todos os compoñentes de Thanos nun clúster de Kubernetes, a diferenza dos compoñentes do clúster de VictoriaMetrics.
VictoriaMetrics ten unha actualización moi sinxela para a nova versión. Simplemente detén VictoriaMetrics, actualiza os binarios e lánzao. Cando se detén mediante un sinal SIGINT, todos os binarios de VictoriaMetrics realizan un apagado elegante. Gardan correctamente os datos necesarios, pechan as conexións entrantes correctamente para non perder nada. Polo tanto, non perderás nada ao actualizar.
VictoriaMetrics fai que sexa moi sinxelo expandir un clúster. Só ten que engadir os compoñentes necesarios e seguir traballando.
Sobre as trampas en Thanos e VictoriaMetrics.
Thanos ten as seguintes trampas. Prometheus debe almacenar os datos das últimas dúas horas. Se se perden, perderas por completo porque aínda non se escribiron en Object Storage como S3.
O compoñente Store Gateway e o compoñente compactador poden requirir moita memoria para traballar cun almacenamento de obxectos grande se hai moitos ficheiros pequenos almacenados alí. Canto maior sexa o número e o tamaño dos ficheiros, máis se necesitará Store Gateway e memoria RAM compactadora para almacenar metainformación. Thanos ten moitos problemas respecto diso .
Thanos anúnciase para escalar indefinidamente coa cantidade de Prometheus que tes. Isto en realidade non é certo. Dado que todas as solicitudes pasan polo compoñente Consulta, que debe sondear simultáneamente todos os compoñentes de Store Gateway e todos os compoñentes de Sidecar, extrae datos de alí e preprocesaos. Obviamente, a velocidade de solicitude está limitada polo enlace débil máis lento, a pasarela de tenda máis lenta ou o sidecar máis lento.
Estes compoñentes poden estar cargados de forma desigual. Por exemplo, tes Prometheus, que recolle millóns de métricas por segundo. E está Prometheus, que recolle miles de métricas por segundo. Prometheus, que recolle millóns de métricas por segundo, pon unha carga moito maior no servidor no que se executa. En consecuencia, Sidecar funciona máis lento alí. E, en xeral, todo funciona lentamente alí. E o compoñente Query extraerá datos de alí moi lentamente. En consecuencia, o rendemento de todo o teu clúster estará limitado por este lento Sidecar.
Por defecto, Thanos ofrece datos parciais se algúns Sidecars e a pasarela da tenda non están dispoñibles. Por exemplo, se os teus Sidecars están espallados polo mundo en diferentes centros de datos, a probabilidade de que se produza un fallo de conexión e a indisponibilidade dos compoñentes aumenta moito. En consecuencia, na maioría dos casos recibirá datos parciais sen sequera sabelo.
VictoriaMetrics tamén ten trampas. A primeira trampa é a opción que limita a cantidade de RAM utilizada para a caché de VictoriaMetrics. De xeito predeterminado, é igual ao 60 % da memoria RAM da máquina onde se está a executar VictoriaMetrics ou ao 60 % da RAM do pod VictoriaMetrics en Kubernetes.
Se cambias este valor incorrectamente, podes arruinar o rendemento de VictoriaMetrics. Por exemplo, se estableces o valor demasiado baixo, os datos poden deixar de caber na caché de VictoriaMetrics. Por iso, terá que facer un traballo extra e cargar o procesador e o disco. Se fai que esta opción sexa demasiado grande, aumenta, en primeiro lugar, a probabilidade de que VictoriaMetrics falle cun erro de memoria sen memoria e, en segundo lugar, provocará que quede moi pouca memoria RAM na memoria do sistema operativo para caché de ficheiros. E VictoriaMetrics confía nunha caché de ficheiros para o rendemento. Se non é suficiente, a carga do disco pode aumentar moito. Polo tanto, consello: non cambie o parámetro a non ser que sexa absolutamente necesario.
Segunda opción. Este é retentionPeriod: un período que se establece en 1 mes por defecto. Este é o período de tempo que VictoriaMetrics almacena os datos. Despois deste período, VictoriaMetrics elimina os datos.
Moitas persoas executan VictoriaMetrics sen este parámetro e rexistran datos durante un mes. E entón preguntan: por que desapareceron os datos do mes anterior? Porque o período de retención predeterminado é de 1 mes. Polo tanto, cómpre coñecer e establecer o período de retención correcto.
Vexamos as características únicas.
Thanos ten unha función chamada downsampling: intervalos de 5 minutos e horas, que moitas veces . Se buscas en Google e miras o seu problema en github, hai moitos problemas relacionados con esta redución de mostras, que ás veces non funciona correctamente ou non funciona como esperan os usuarios.
Thanos ten deduplicación de datos para os pares de Prometheus HA. Cando dous Prometheus recollen as mesmas métricas dos mesmos obxectivos e Thanos gárdaas en Object Storage. Thanos pode desduplicar correctamente estes datos, a diferenza de VictoriaMetrics.
Thanos ten un compoñente de alerta que estaba no esquema de Thanos. Pero el .
Thanos ten a vantaxe de que Thanos e Prometheus comparten o mesmo código. Thanos e Prometheus son desenvolvidos polos mesmos desenvolvedores. Con melloras para Thanos ou Prometheus, o outro bando gaña.
A característica principal de VictoriaMetrics é MetricsQL. Estas son extensións de VictoriaMetrics para PromQL, das que falei na anterior reunión de monitorización.
VictoriaMetrics admite a carga de datos mediante moitos protocolos diferentes. VictoriaMetrics non só pode aceptar datos de Prometheus, senón tamén a través dos protocolos Influx, OpenTSDB e Graphite.
Os datos de VictoriaMetrics ocupan moito menos espazo en comparación con Thanos e Prometheus.
Se gravas datos reais, os usuarios falan dunha redución de 2-5 veces no tamaño dos datos no disco en comparación con Prometheus e Thanos.
Outra vantaxe de VictoriaMetrics é que está optimizado para a velocidade.
Vexamos o custo das infraestruturas.
Unha das vantaxes de Thanos é que almacena datos en almacenamento de obxectos, que é relativamente barato.
Ao almacenar datos no almacenamento de obxectos, debes pagar por operacións de escritura e lectura de datos (10 dólares por millón de operacións). Cando escribes datos no almacenamento de obxectos, pagas os teus custos de hospedaxe por cargar datos a Internet; se o teu clúster non está en AWS, alí é gratuíto. Cando le os datos, paga entre 10 e 230 dólares por 1 TB. Isto pode ser significativo se consultas con frecuencia datos históricos do clúster de Thanos.
Para un clúster de Thanos, cómpre pagar por servidores Compact, Store Gateway, Query components que requiren moita memoria e CPU para grandes cantidades de datos.
VictoriaMetrics ten os seguintes gastos. Se almacenas datos en unidades de disco duro GCE, 40 TB custa 1 dólares. Para VictoriaMetrics, as unidades de disco duro comúns son suficientes; non se necesitan SSD, que custan cinco veces máis. VictoriaMetrics está optimizado para HDD.
VictoriaMetrics require servidores para compoñentes: compoñentes simples ou agrupados, que, a diferenza dos compoñentes de Thanos, requiren moito menos CPU e RAM e, en consecuencia, serán máis baratos.
Exemplos de implantación.
Thanos ten un exemplo de implementación en Gitlab. Gitlab funciona enteiramente con Thanos. Pero non todo é tan suave alí. Se os miras , entón podes ver que teñen constantemente algúns : Non hai memoria suficiente para os compoñentes da pasarela da tenda ou da consulta. Teñen que aumentar constantemente a cantidade de memoria.
Por iso, os custos de resolver estes problemas aumentan.
A segunda implementación, que pode ter máis éxito, é a empresa Improbable, que comezou a desenvolver Thanos. Publicaron o código fonte de Thanos. Improbable é unha empresa que desenvolve motores de xogos.
VictoriaMetrics ten exemplos de implementación pública:
- Creador de sitios web wix.com
- Adidas está implementando VictoriaMetrics e incluso fixo unha presentación na pasada PromCon 2019
- TrafficStars - rede publicitaria
- Seznam.cz é un popular buscador checo.
E despois había empresas sen nome que non podo nomear agora. Non consentiron.
- Un dos principais desenvolvedores de xogos. Máis grande que improbable.
- Principal desenvolvedor de software gráfico.
- Gran banco ruso.
- Fabricante europeo de aeroxeradores que probou con éxito VictoriaMetrics. Este fabricante está a implementar VictoriaMetrics para controlar os datos recollidos dos aeroxeradores a unha velocidade de 50 mostras por segundo por sensor. Cada aeroxerador ten varios centos de sensores. Teñen varios centos de aeroxeradores.
- Compañías aéreas rusas que queren implementar VictoriaMetrics, pero aínda non poden. Estamos en fase de contrato con eles.
Conclusións.
VictoriaMetrics e Thanos resolven problemas similares, pero de diferentes xeitos:
- Vista de consulta global
- escala horizontal
- retención arbitraria
Grazas.
Agardámoste no noso .
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Que usas como almacenamento a longo prazo para Prometheus?
35,3%Thanos 6
0,0%Corteza 0
0,0%M3DB0
41,2%VictoriaMetrics 7
23,5%outros 4
Votaron 17 usuarios. 16 usuarios abstivéronse.
Fonte: www.habr.com
