La traducció de l'article s'ha elaborat expressament per als alumnes del curs .
és un desenvolupador de programari, Go fanatic i solucionador de problemes. També és mantenidor de Prometheus i cofundador de la instrumentació SIG de Kubernetes. En el passat, va ser enginyer de producció a SoundCloud i va dirigir l'equip de supervisió de CoreOS. Actualment treballa a Google.
- Enginyer d'infraestructures a Improbable. Està interessat en les noves tecnologies i els problemes dels sistemes distribuïts. Té experiència de programació de baix nivell a Intel, experiència de col·laborador a Mesos i experiència de producció SRE de primer nivell a Improbable. Dedicat a millorar el món dels microserveis. Els seus tres amors: Golang, codi obert i voleibol.
Mirant el nostre producte emblemàtic SpatialOS, podeu endevinar que Improbable requereix una infraestructura de núvol a escala global altament dinàmica amb desenes de clústers de Kubernetes. Vam ser dels primers a utilitzar un sistema de seguiment . Prometheus és capaç de fer un seguiment de milions de mètriques en temps real i inclou un potent llenguatge de consulta que us permet extreure la informació que necessiteu.
La senzillesa i fiabilitat de Prometheus és un dels seus principals avantatges. Tanmateix, un cop superem una certa escala, ens trobem amb diversos inconvenients. Per resoldre aquests problemes hem desenvolupat és un projecte de codi obert creat per Improbable per transformar perfectament els clústers de Prometheus existents en un únic sistema de monitorització amb emmagatzematge de dades històriques il·limitades. Thanos està disponible a Github .
Els nostres objectius amb Thanos
A certa escala, sorgeixen problemes que van més enllà de les capacitats de Prometheus de vainilla. Com emmagatzemar de manera fiable i econòmica petabytes de dades històriques? Es pot fer això sense comprometre el temps de resposta? És possible accedir a totes les mètriques ubicades en diferents servidors Prometheus amb una única sol·licitud d'API? Hi ha alguna manera de combinar les dades replicades recollides amb Prometheus HA?
Per solucionar aquests problemes, vam crear Thanos. Les seccions següents descriuen com vam abordar aquests problemes i expliquem els nostres objectius.
Consulta de dades de diverses instàncies de Prometheus (consulta global)
Prometheus ofereix un enfocament funcional de la fragmentació. Fins i tot un únic servidor Prometheus ofereix prou escalabilitat per alliberar els usuaris de les complexitats de la fragmentació horitzontal en gairebé tots els casos d'ús.
Tot i que aquest és un gran model de desplegament, sovint és necessari accedir a les dades de diferents servidors Prometheus mitjançant una única API o IU, una visió global. Per descomptat, és possible mostrar diverses consultes en un panell de Grafana, però cada consulta només es pot executar en un servidor Prometheus. D'altra banda, amb Thanos podeu consultar i agregar dades de diversos servidors Prometheus, ja que tots són accessibles des d'un únic punt final.
Anteriorment, per obtenir una visió global a Improbable, vam organitzar les nostres instàncies de Prometheus en un multinivell. . Això significava crear un metaservidor Prometheus que reculli algunes de les mètriques de cada servidor full.
Aquest enfocament va resultar problemàtic. Això ha donat lloc a configuracions més complexes, l'addició d'un punt potencial de fallada addicional i l'aplicació de regles complexes per garantir que el punt final federat només rebi les dades que necessita. A més, aquest tipus de federació no permet obtenir una visió global real, ja que no totes les dades estan disponibles a partir d'una sol·licitud d'API única.
Molt relacionada amb això hi ha una visió unificada de les dades recollides en servidors Prometheus d'alta disponibilitat (HA). El model HA de Prometheus recull dades de manera independent dues vegades, cosa que és tan senzilla que no podria ser més senzill. Tanmateix, utilitzar una vista combinada i desduplicada d'ambdós fluxos seria molt més convenient.
Per descomptat, hi ha una necessitat de servidors Prometheus d'alta disponibilitat. A Improbable, ens prenem molt seriosament la supervisió de dades minut a minut, però tenir una instància de Prometheus per clúster és un únic punt de fallada. Qualsevol error de configuració o fallada del maquinari pot provocar la pèrdua de dades importants. Fins i tot un simple desplegament pot causar interrupcions menors en la recollida de mètriques perquè els reinicis poden ser molt més llargs que l'interval de raspat.
Emmagatzematge fiable de dades històriques
L'emmagatzematge de mètriques barat, ràpid i a llarg termini és el nostre somni (compartit per la majoria dels usuaris de Prometheus). A Improbable, ens vam veure obligats a configurar el període de retenció de mètriques a nou dies (per a Prometheus 1.8). Això afegeix límits evidents a fins a quin punt podem mirar enrere.
Prometheus 2.0 ha millorat en aquest sentit, ja que el nombre de sèries temporals ja no afecta el rendiment global del servidor (vegeu. ). Tanmateix, Prometheus emmagatzema dades al disc local. Tot i que la compressió de dades altament eficient pot reduir significativament l'ús de SSD local, en última instància, encara hi ha un límit a la quantitat de dades històriques que es poden emmagatzemar.
A més, a Improbable ens preocupem per la fiabilitat, la simplicitat i el cost. Els discos locals grans són més difícils d'utilitzar i de fer còpies de seguretat. Costen més i requereixen més eines de còpia de seguretat, el que resulta en una complexitat innecessària.
Reducció de mostreig
Un cop vam començar a treballar amb dades històriques, ens vam adonar que hi ha dificultats fonamentals amb big-O que fan que les consultes siguin cada cop més lentes a mesura que treballem amb setmanes, mesos i anys de dades.
La solució estàndard a aquest problema seria (reducció de mostreig) - reduint la freqüència de mostreig del senyal. Amb la reducció de mostres, podem "reduir" a un interval de temps més gran i mantenir el mateix nombre de mostres, mantenint les consultes responsives.
La reducció de mostres de dades antigues és un requisit inevitable de qualsevol solució d'emmagatzematge a llarg termini i està fora de l'abast de Vanilla Prometheus.
Objectius addicionals
Un dels objectius originals del projecte Thanos era integrar-se perfectament amb qualsevol instal·lació de Prometheus existent. El segon objectiu era la facilitat d'operació amb un mínim de barreres d'entrada. Qualsevol dependència s'hauria de satisfer fàcilment tant per a usuaris petits com grans, la qual cosa també significa un baix cost base.
Arquitectura de Thanos
Després d'enumerar els nostres objectius a la secció anterior, anem a treballar-los i veure com Thanos resol aquests problemes.
Visió global
Per obtenir una visió global de les instàncies de Prometheus existents, hem d'enllaçar un únic punt d'entrada de sol·licitud a tots els servidors. Això és exactament el que fa el component Thanos. . Es desplega al costat de cada servidor Prometheus i actua com a servidor intermediari, donant servei a les dades locals de Prometheus a través de l'API gRPC Store, permetent que les dades de sèries temporals es recuperin per etiqueta i interval de temps.
A l'altra banda hi ha el component de consulta sense estat d'escala, que no fa més que respondre les consultes de PromQL mitjançant l'API HTTP estàndard de Prometheus. Querier, Sidecar i altres components de Thanos es comuniquen mitjançant .
- Querier, en rebre una sol·licitud, es connecta al servidor API Store corresponent, és a dir, als nostres Sidecars i rep dades de sèries temporals dels servidors Prometheus corresponents.
- Després d'això, combina les respostes i executa una consulta PromQL sobre elles. Querier pot combinar dades discongudes i dades duplicades dels servidors Prometheus HA.
Això resol una peça important del nostre trencaclosques: combinar dades de servidors Prometheus aïllats en una única vista. De fet, Thanos només es pot utilitzar per a aquesta funció. No cal fer cap canvi als servidors Prometheus existents!
Vida útil il·limitada!
Tanmateix, tard o d'hora voldrem emmagatzemar dades més enllà del temps de retenció normal de Prometheus. Hem escollit l'emmagatzematge d'objectes per emmagatzemar dades històriques. Està àmpliament disponible en qualsevol núvol, així com en centres de dades locals i és molt rendible. A més, gairebé qualsevol emmagatzematge d'objectes està disponible a través de la coneguda API S3.
Prometheus escriu dades de la memòria RAM al disc aproximadament cada dues hores. El bloc de dades emmagatzemats conté totes les dades durant un període de temps determinat i és immutable. Això és molt convenient perquè Thanos Sidecar només pot mirar el directori de dades de Prometheus i, a mesura que hi hagi nous blocs disponibles, carregar-los als cubs d'emmagatzematge d'objectes.
La càrrega a l'emmagatzematge d'objectes immediatament després d'escriure al disc també us permet mantenir la senzillesa del rascador (Prometheus i Thanos Sidecar). El que simplifica el suport, el cost i el disseny del sistema.
Com podeu veure, la còpia de seguretat de dades és molt senzilla. Però, què passa amb la consulta de dades a l'emmagatzematge d'objectes?
El component Thanos Store actua com a intermediari per recuperar dades de l'emmagatzematge d'objectes. Igual que Thanos Sidecar, participa en el clúster de xafarderies i implementa l'API Store. D'aquesta manera, el Querier existent pot tractar-lo com un Sidecar, com una altra font de dades de sèries temporals, sense necessitat de configuració especial.
Els blocs de dades de sèries temporals consisteixen en diversos fitxers grans. Carregar-los sota demanda seria bastant ineficient i guardar-los a la memòria cau localment requeriria una gran quantitat de memòria i espai de disc.
En canvi, Store Gateway sap com gestionar el format d'emmagatzematge de Prometheus. Gràcies a un programador de consultes intel·ligent i a la memòria cau només les parts d'índex necessàries dels blocs, és possible reduir les consultes complexes a un nombre mínim de peticions HTTP als fitxers d'emmagatzematge d'objectes. D'aquesta manera, podeu reduir el nombre de sol·licituds entre quatre i sis ordres de magnitud i aconseguir temps de resposta que generalment són difícils de distingir de les sol·licituds a les dades d'un SSD local.
Com es mostra al diagrama anterior, Thanos Querier redueix significativament el cost per consulta de dades d'emmagatzematge d'objectes aprofitant el format d'emmagatzematge de Prometheus i col·locant les dades relacionades una al costat de l'altra. Amb aquest enfocament, podem combinar moltes sol·licituds individuals en un nombre mínim d'operacions massives.
Compactació i rebaixa de mostres
Un cop s'ha carregat correctament un nou bloc de dades de sèries temporals a l'emmagatzematge d'objectes, el tractem com a dades "històriques", que estan disponibles immediatament a través de Store Gateway.
Tanmateix, després d'un temps, els blocs d'una font (Prometeu amb Sidecar) s'acumulen i ja no utilitzen tot el potencial d'indexació. Per resoldre aquest problema, hem introduït un altre component anomenat Compactor. Simplement aplica el motor de compactació local de Prometheus a les dades històriques a l'emmagatzematge d'objectes i es pot executar com un simple treball periòdic per lots.
Gràcies a una compressió eficient, consultar l'emmagatzematge durant un llarg període de temps no suposa cap problema pel que fa a la mida de les dades. Tanmateix, el cost potencial de desempaquetar mil milions de valors i executar-los a través d'un processador de consultes provocarà inevitablement un augment espectacular del temps d'execució de la consulta. D'altra banda, com que hi ha centenars de punts de dades per píxel a la pantalla, es fa impossible ni tan sols visualitzar les dades a resolució completa. Així, la reducció de mostres no només és possible, sinó que tampoc comportarà una pèrdua notable de precisió.
Per reduir les dades, Compactor agrega dades contínuament a una resolució de cinc minuts i una hora. Per a cada fragment en brut codificat mitjançant la compressió TSDB XOR, s'emmagatzemen diferents tipus de dades agregades, com ara el mínim, el màxim o la suma per a un bloc. Això permet a Querier seleccionar automàticament un agregat adequat per a una consulta PromQL determinada.
No es requereix cap configuració especial perquè l'usuari utilitzi dades de precisió reduïda. Querier canvia automàticament entre diferents resolucions i dades en brut a mesura que l'usuari amplia i allunya. Si ho desitja, l'usuari pot controlar-ho directament mitjançant el paràmetre "pas" de la sol·licitud.
Com que el cost d'emmagatzemar un GB és baix, Thanos emmagatzema de manera predeterminada dades en brut, dades de resolució de cinc minuts i d'una hora. No cal esborrar les dades originals.
Normes de gravació
Fins i tot amb Thanos, les regles de gravació són una part essencial de la pila de seguiment. Redueixen la complexitat, la latència i el cost de les consultes. També són convenients per als usuaris per obtenir dades agregades per mètriques. Thanos es basa en instàncies de Prometheus de vainilla, de manera que és perfectament acceptable emmagatzemar regles d'enregistrament i regles d'alertes en un servidor Prometheus existent. Tanmateix, en alguns casos això pot no ser suficient:
- Alerta i regla globals (per exemple, una alerta quan un servei no funciona en més de dos dels tres clústers).
- Regla per a dades fora de l'emmagatzematge local.
- El desig d'emmagatzemar totes les regles i alertes en un sol lloc.
Per a tots aquests casos, Thanos inclou un component separat anomenat Ruler, que calcula la regla i l'alerta mitjançant les consultes de Thanos. En proporcionar una StoreAPI coneguda, el node Query pot accedir a mètriques recentment calculades. Més tard també s'emmagatzemen a l'emmagatzematge d'objectes i estan disponibles a través de Store Gateway.
El poder de Thanos
Thanos és prou flexible per ser personalitzat per adaptar-se a les vostres necessitats. Això és especialment útil quan es migra des de la plana Prometeu. Resumim ràpidament el que hem après sobre els components de Thanos amb un exemple ràpid. A continuació s'explica com portar el vostre Prometheus de vainilla al món de l'"emmagatzematge il·limitat de mètriques":
- Afegiu Thanos Sidecar als vostres servidors Prometheus, per exemple, un contenidor sidecar en un pod de Kubernetes.
- Desplegueu diverses rèpliques de Thanos Querier per poder veure les dades. En aquesta etapa, és fàcil establir xafarderies entre Scraper i Querier. Per comprovar la interacció dels components, utilitzeu la mètrica "thanos_cluster_members".
Només aquests dos passos són suficients per proporcionar una visió global i una desduplicació de dades perfecta de les rèpliques potencials de Prometheus HA! Simplement connecteu els vostres taulers al punt final de Querier HTTP o utilitzeu directament la interfície d'usuari de Thanos.
Tanmateix, si necessiteu una còpia de seguretat de mètriques i emmagatzematge a llarg termini, haureu de completar tres passos més:
- Creeu un cub AWS S3 o GCS. Configureu Sidecar per copiar dades a aquests dipòsits. Ara es pot minimitzar l'emmagatzematge local de dades.
- Desplegueu Store Gateway i connecteu-lo al vostre clúster de xafarderies existent. Ara podeu consultar les dades amb còpia de seguretat!
- Desplegueu Compactor per millorar l'eficiència de les consultes durant llargs períodes de temps mitjançant la compactació i la reducció de mostres.
Si vols saber-ne més, no dubtis a fer una ullada al nostre и !
En només cinc passos, hem convertit Prometheus en un sistema de monitorització fiable amb visió global, temps d'emmagatzematge il·limitat i una possible alta disponibilitat de mètriques.
Sol·licitud de tirada: et necessitem!
ha estat un projecte de codi obert des del principi. La integració perfecta amb Prometheus i la capacitat d'utilitzar només una part de Thanos el converteixen en una opció excel·lent per escalar el vostre sistema de monitorització sense esforç.
Sempre donem la benvinguda a les sol·licituds i problemes d'extracció de GitHub. Mentrestant, no dubteu a contactar amb nosaltres mitjançant Github Issues o Slacksi teniu preguntes o comentaris, o voleu compartir la vostra experiència utilitzant-lo! Si t'agrada el que fem a Improbable, no dubtis a contactar amb nosaltres - !
Font: www.habr.com