A tradución do artigo foi elaborada expresamente para o alumnado do curso .
é un programador de software, fanático de Go e solucionador de problemas. Tamén é mantedor de Prometheus e cofundador da instrumentación SIG de Kubernetes. No pasado, foi enxeñeiro de produción en SoundCloud e dirixiu o equipo de seguimento de CoreOS. Actualmente traballa en Google.
- Enxeñeiro de Infraestruturas en Improbable. Interésanlle as novas tecnoloxías e os problemas dos sistemas distribuídos. Ten experiencia en programación de baixo nivel en Intel, experiencia de colaborador en Mesos e experiencia de produción de SRE de clase mundial en Improbable. Dedicado a mellorar o mundo dos microservizos. Os seus tres amores: Golang, código aberto e voleibol.
Mirando o noso produto emblemático SpatialOS, podes adiviñar que Improbable require unha infraestrutura de nube a escala global altamente dinámica e con decenas de clústeres de Kubernetes. Fomos dos primeiros en utilizar un sistema de vixilancia . Prometheus é capaz de rastrexar millóns de métricas en tempo real e inclúe unha potente linguaxe de consulta que che permite extraer a información que necesitas.
A sinxeleza e fiabilidade de Prometheus é unha das súas principais vantaxes. Non obstante, unha vez que superamos unha determinada escala, atopamos varios inconvenientes. Para resolver estes problemas desenvolvemos é un proxecto de código aberto creado por Improbable para transformar perfectamente os clústeres existentes de Prometheus nun único sistema de seguimento con almacenamento de datos históricos ilimitado. Thanos está dispoñible en Github .
Os nosos obxectivos con Thanos
A certa escala, xorden problemas que superan as capacidades de Prometheus de vainilla. Como almacenar de forma fiable e económica petabytes de datos históricos? Pódese facer isto sen comprometer o tempo de resposta? É posible acceder a todas as métricas situadas en diferentes servidores Prometheus cunha única solicitude de API? Hai algunha forma de combinar os datos replicados recollidos usando Prometheus HA?
Para solucionar estes problemas, creamos Thanos. As seguintes seccións describen como abordamos estas cuestións e explican os nosos obxectivos.
Consulta de datos de varias instancias de Prometheus (consulta global)
Prometheus ofrece un enfoque funcional para a fragmentación. Incluso un único servidor Prometheus ofrece escalabilidade suficiente para liberar aos usuarios das complexidades da fragmentación horizontal en case todos os casos de uso.
Aínda que este é un excelente modelo de implantación, moitas veces é necesario acceder aos datos de diferentes servidores Prometheus a través dunha única API ou IU, unha visión global. Por suposto, é posible mostrar varias consultas nun panel de Grafana, pero cada consulta só se pode executar nun servidor Prometheus. Por outra banda, con Thanos pode consultar e agregar datos de varios servidores Prometheus xa que todos son accesibles desde un único punto final.
Anteriormente, para obter unha visión global en Improbable, organizamos as nosas instancias de Prometheus en varios niveis. . Isto significaba crear un metaservidor de Prometheus que recolla algunhas das métricas de cada servidor folla.
Este enfoque resultou problemático. Isto deu lugar a configuracións máis complexas, á adición dun punto potencial de fallo adicional e á aplicación de regras complexas para garantir que o punto final federado só reciba os datos que necesita. Ademais, este tipo de federación non permite obter unha verdadeira visión global, xa que non todos os datos están dispoñibles a partir dunha única solicitude de API.
Estreitamente relacionada con isto está unha vista unificada dos datos recollidos en servidores Prometheus de alta dispoñibilidade (HA). O modelo HA de Prometheus recolle datos de forma independente dúas veces, o que é tan sinxelo que non podería ser máis sinxelo. Non obstante, sería moito máis conveniente usar unha vista combinada e deduplicada de ambos fluxos.
Por suposto, hai unha necesidade de servidores Prometheus de alta dispoñibilidade. En Improbable, tomamos moi en serio o seguimento dos datos minuto a minuto, pero ter unha instancia de Prometheus por clúster é un único punto de falla. Calquera erro de configuración ou falla de hardware pode provocar a perda de datos importantes. Incluso unha simple implantación pode causar pequenas interrupcións na recollida de métricas porque os reinicios poden ser significativamente máis longos que o intervalo de raspado.
Almacenamento fiable de datos históricos
O almacenamento de métricas barato, rápido e a longo prazo é o noso soño (compartido pola maioría dos usuarios de Prometheus). En Improbable, vímonos obrigados a configurar o período de retención de métricas en nove días (para Prometheus 1.8). Isto engade límites obvios ao lonxe que podemos mirar.
Prometheus 2.0 mellorou neste sentido, xa que o número de series temporais xa non afecta o rendemento global do servidor (ver. ). Non obstante, Prometheus almacena datos no disco local. Aínda que a compresión de datos de alta eficiencia pode reducir significativamente o uso da SSD local, aínda hai un límite para a cantidade de datos históricos que se poden almacenar.
Ademais, en Improbable preocúpanos a fiabilidade, a sinxeleza e o custo. Os discos locais grandes son máis difíciles de operar e facer copias de seguridade. Custan máis e requiren máis ferramentas de copia de seguridade, o que resulta nunha complexidade innecesaria.
Submostraxe
Unha vez que comezamos a traballar con datos históricos, decatámonos de que hai dificultades fundamentais con big-O que fan que as consultas sexan cada vez máis lentas a medida que traballamos con semanas, meses e anos de datos.
A solución estándar a este problema sería (downsampling) - reducindo a frecuencia de mostraxe do sinal. Coa mostraxe inferior, podemos "reducir" a un intervalo de tempo maior e manter o mesmo número de mostras, mantendo as consultas receptivas.
A redución da mostra de datos antigos é un requisito inevitable de calquera solución de almacenamento a longo prazo e está fóra do alcance de Prometheus de vainilla.
Obxectivos adicionais
Un dos obxectivos orixinais do proxecto Thanos era integrarse perfectamente con calquera instalación existente de Prometheus. O segundo obxectivo era a facilidade de operación con mínimas barreiras de entrada. Calquera dependencia debe satisfacerse facilmente tanto para os usuarios pequenos como para os grandes, o que tamén significa un baixo custo base.
Arquitectura Thanos
Despois de enumerar os nosos obxectivos na sección anterior, imos traballar con eles e ver como Thanos resolve estes problemas.
Visión global
Para obter unha visión global sobre as instancias existentes de Prometheus, necesitamos ligar un único punto de entrada de solicitude a todos os servidores. Isto é exactamente o que fai o compoñente Thanos. . Desprégase xunto a cada servidor Prometheus e actúa como un proxy, que serve de datos locais de Prometheus a través da API de gRPC Store, o que permite recuperar datos de series temporais por etiqueta e intervalo de tempo.
Por outro lado está o compoñente de consulta sen estado e escalable, que non fai máis que responder ás consultas de PromQL a través da API HTTP estándar de Prometheus. Querier, Sidecar e outros compoñentes de Thanos comunícanse a través .
- Querier, ao recibir unha solicitude, conéctase ao servidor API Store correspondente, é dicir, aos nosos Sidecars e recibe datos de series temporais dos servidores Prometheus correspondentes.
- Despois diso, combina as respostas e executa unha consulta PromQL nelas. Querier pode combinar tanto datos inconxuntos como datos duplicados dos servidores Prometheus HA.
Isto resolve unha peza importante do noso crebacabezas: combinar datos de servidores Prometheus illados nunha única vista. De feito, Thanos só se pode usar para esta función. Non é necesario facer cambios nos servidores Prometheus existentes.
Vida útil ilimitada!
Non obstante, tarde ou cedo quereremos almacenar datos máis aló do tempo de retención normal de Prometheus. Escollemos o almacenamento de obxectos para almacenar datos históricos. Está amplamente dispoñible en calquera nube, así como nos centros de datos locais e é moi rendible. Ademais, case calquera almacenamento de obxectos está dispoñible a través da coñecida API S3.
Prometheus escribe datos da memoria RAM ao disco aproximadamente cada dúas horas. O bloque de datos almacenados contén todos os datos durante un período de tempo fixo e é inmutable. Isto é moi cómodo porque Thanos Sidecar pode simplemente mirar o directorio de datos de Prometheus e, a medida que estean dispoñibles novos bloques, cargalos en baldes de almacenamento de obxectos.
A carga no almacenamento de obxectos inmediatamente despois de escribir no disco tamén permite manter a sinxeleza do rascador (Prometheus e Thanos Sidecar). O que simplifica o soporte, o custo e o deseño do sistema.
Como podes ver, a copia de seguridade de datos é moi sinxela. Pero que pasa coa consulta de datos no almacenamento de obxectos?
O compoñente Thanos Store actúa como un proxy para recuperar datos do almacenamento de obxectos. Do mesmo xeito que Thanos Sidecar, participa no clúster de fofocas e implementa a API Store. Deste xeito, o Querier existente pode tratalo como un Sidecar, como outra fonte de datos de series temporais, sen necesidade de configuración especial.
Os bloques de datos de series temporais consisten en varios ficheiros grandes. Cargalos baixo demanda sería bastante ineficiente e almacenalos localmente en caché requiriría unha gran cantidade de memoria e espazo no disco.
En cambio, Store Gateway sabe como manexar o formato de almacenamento Prometheus. Grazas a un programador de consultas intelixente e a almacenar en caché só as partes de índice necesarias dos bloques, é posible reducir as consultas complexas a un número mínimo de solicitudes HTTP aos ficheiros de almacenamento de obxectos. Deste xeito, pode reducir o número de solicitudes entre catro e seis ordes de magnitude e conseguir tempos de resposta que xeralmente son difíciles de distinguir das solicitudes aos datos nun SSD local.
Como se mostra no diagrama anterior, Thanos Querier reduce significativamente o custo por consulta dos datos de almacenamento de obxectos ao aproveitar o formato de almacenamento de Prometheus e colocar os datos relacionados xuntos. Usando este enfoque, podemos combinar moitas solicitudes únicas nun número mínimo de operacións masivas.
Compactación e submostraxe
Unha vez que un novo bloque de datos de series temporais se carga con éxito no almacenamento de obxectos, tratámolo como datos "históricos", que están inmediatamente dispoñibles a través da pasarela da tenda.
Non obstante, despois dun tempo, os bloques dunha fonte (Prometheus con Sidecar) acumúlanse e xa non utilizan todo o potencial de indexación. Para resolver este problema, introducimos outro compoñente chamado Compactor. Simplemente aplica o motor de compactación local de Prometheus aos datos históricos no almacenamento de obxectos e pódese executar como un simple traballo por lotes periódico.
Grazas á compresión eficiente, consultar o almacenamento durante un longo período de tempo non supón ningún problema en canto ao tamaño dos datos. Non obstante, o custo potencial de desempaquetar mil millóns de valores e executalos a través dun procesador de consultas provocará inevitablemente un aumento espectacular do tempo de execución da consulta. Por outra banda, dado que hai centos de puntos de datos por píxel na pantalla, faise imposible sequera visualizar os datos a máxima resolución. Así, a submostraxe non só é posible, senón que tampouco levará a unha perda notable de precisión.
Para reducir a mostra de datos, Compactor agrega datos continuamente cunha resolución de cinco minutos e unha hora. Para cada fragmento en bruto codificado mediante a compresión TSDB XOR, gárdanse diferentes tipos de datos agregados, como mínimo, máximo ou suma para un bloque. Isto permite que Querier seleccione automaticamente un agregado que sexa apropiado para unha determinada consulta PromQL.
Non se precisa ningunha configuración especial para que o usuario utilice datos de precisión reducida. Querier cambia automaticamente entre diferentes resolucións e datos en bruto a medida que o usuario fai zoom. Se o desexa, o usuario pode controlalo directamente a través do parámetro "paso" da solicitude.
Dado que o custo de almacenar un GB é baixo, Thanos almacena de forma predeterminada datos en bruto, datos de resolución de cinco minutos e dunha hora. Non é necesario eliminar os datos orixinais.
Regras de gravación
Mesmo con Thanos, as regras de gravación son unha parte esencial da pila de seguimento. Reducen a complexidade, a latencia e o custo das consultas. Tamén son convenientes para que os usuarios obteñan datos agregados por métricas. Thanos baséase en instancias de Prometheus de vainilla, polo que é perfectamente aceptable almacenar regras de gravación e de alerta nun servidor Prometheus existente. Non obstante, nalgúns casos isto pode non ser suficiente:
- Alerta e regra global (por exemplo, unha alerta cando un servizo non funciona en máis de dous dos tres grupos).
- Regra para os datos fóra do almacenamento local.
- O desexo de almacenar todas as regras e alertas nun só lugar.
Para todos estes casos, Thanos inclúe un compoñente separado chamado Ruler, que calcula a regra e a alerta mediante Consultas de Thanos. Ao proporcionar unha StoreAPI coñecida, o nodo Query pode acceder a métricas recentemente calculadas. Máis tarde tamén se almacenan no almacenamento de obxectos e están dispoñibles a través da Pasarela da tenda.
O poder de Thanos
Thanos é o suficientemente flexible como para adaptalo ás túas necesidades. Isto é especialmente útil cando se migra desde o Prometheus simple. Recapitulemos rapidamente o que aprendemos sobre os compoñentes de Thanos cun exemplo rápido. Aquí tes como levar o teu Prometheus de vainilla ao mundo do "almacenamento de métricas ilimitado":
- Engade Thanos Sidecar aos teus servidores Prometheus, por exemplo, un contenedor sidecar nun pod de Kubernetes.
- Implementa varias réplicas de Thanos Querier para poder ver os datos. Nesta fase é fácil configurar fofocas entre Scraper e Querier. Para comprobar a interacción dos compoñentes, utiliza a métrica "thanos_cluster_members".
Só estes dous pasos son suficientes para proporcionar unha visión global e unha desduplicación perfecta de datos das posibles réplicas de Prometheus HA. Simplemente conecte os seus paneis ao punto final de Querier HTTP ou use a IU de Thanos directamente.
Non obstante, se precisas unha copia de seguridade de métricas e almacenamento a longo prazo, terás que completar tres pasos máis:
- Cree un depósito de AWS S3 ou GCS. Configura Sidecar para copiar datos nestes depósitos. Agora pódese minimizar o almacenamento local de datos.
- Implementa Store Gateway e conéctao ao teu clúster de fofocas existente. Agora podes consultar os datos da copia de seguranza!
- Implementa Compactor para mellorar a eficiencia das consultas durante longos períodos de tempo mediante a compactación e a redución de mostras.
Se queres saber máis, non dubides en botarlle unha ollada ao noso и !
En só cinco pasos, convertimos a Prometheus nun sistema de vixilancia fiable con visión global, tempo de almacenamento ilimitado e alta dispoñibilidade potencial de métricas.
Pull request: necesitámoste!
foi un proxecto de código aberto dende o principio. A integración perfecta con Prometheus e a capacidade de usar só unha parte de Thanos convérteno nunha excelente opción para escalar o seu sistema de monitorización sen esforzo.
Sempre damos a benvida ás solicitudes e problemas de extracción de GitHub. Mentres tanto, póñase en contacto connosco a través de Github Issues ou slackse tes preguntas ou comentarios, ou queres compartir a túa experiencia co uso del! Se che gusta o que facemos en Improbable, non dubides en contactar connosco - !
Fonte: www.habr.com