Hola a tots! En el seu últim article Vaig escriure sobre l'organització d'un sistema de monitorització modular per a l'arquitectura de microserveis. Res no s'atura, el nostre projecte està en constant creixement, i el nombre de mètriques emmagatzemades també. Com vam organitzar la transició de Graphite+Whisper a Graphite+ClickHouse en condicions de càrrega elevada, llegiu-ne les expectatives i els resultats de la migració sota el tall.

Abans d'explicar-vos com hem organitzat la transició de l'emmagatzematge de mètriques a Graphite+Whisper a Graphite+ClickHouse, m'agradaria donar-vos informació sobre els motius per prendre aquesta decisió i sobre els inconvenients de Whisper amb els quals vam conviure durant molt de temps.

Problemes de grafit+xiuxiueig

1. Alta càrrega al subsistema de disc

En el moment de la transició, ens arribaven aproximadament 1.5 milions de mètriques per minut. Amb aquest flux, la utilització del disc als servidors era d'un 30%. En general, això era bastant acceptable: tot funcionava de manera estable, es va escriure ràpidament, es va llegir ràpidament... Fins que un dels equips de desenvolupament va llançar una funció nova i va començar a enviar-nos 10 milions de mètriques per minut. Va ser llavors quan el subsistema de disc es va endurir i vam veure una utilització del 100%. El problema es va resoldre ràpidament, però va quedar un residu.

2. Manca de replicació i consistència

El més probable és que, com tothom que utilitza/utilitza Graphite+Whisper, hem abocat el mateix flux de mètriques a diversos servidors de Graphite alhora per crear tolerància a errors. I no hi va haver problemes especials amb això, fins al moment en què un dels servidors es va estavellar per algun motiu. De vegades vam aconseguir recollir un servidor caigut amb prou rapidesa i carbon-c-relay va aconseguir carregar-hi mètriques de la seva memòria cau, però de vegades no. I després hi va haver un forat en les mètriques, que vam omplir amb rsync. El procediment va ser força llarg. L'única gràcia salvadora va ser que això passava molt poques vegades. També vam agafar periòdicament un conjunt de mètriques aleatòries i les vam comparar amb altres de les mateixes als nodes veïns del clúster. En aproximadament un 5% dels casos, diversos valors eren diferents, cosa que no estàvem molt contents.

3. Gran petjada

Com que escrivim a Graphite no només la infraestructura, sinó també mètriques empresarials (i ara també mètriques de Kubernetes), sovint ens trobem amb una situació en què la mètrica només conté uns quants valors i el fitxer .wsp es crea tenint en compte tota la retenció. període i ocupa una quantitat d'espai assignada prèviament, que per a nosaltres era igual a ~2MB. El problema s'agreuja encara més pel fet que apareixen molts fitxers similars amb el pas del temps i, quan es construeixen informes sobre ells, la lectura de punts buits requereix molt de temps i recursos.

M'agradaria assenyalar immediatament que els problemes descrits anteriorment es poden resoldre amb diversos mètodes i amb diferents graus d'eficàcia, però com més dades comenceu a rebre, més empitjoren.

Tenint tot l'anterior (tenint en compte l'anterior Article), així com un augment constant en el nombre de mètriques rebudes, el desig de transferir totes les mètriques a un interval d'emmagatzematge de 30 segons. (fins a 10 segons si cal), vam decidir provar Graphite+ClickHouse com a alternativa prometedora a Whisper.

Grafit+ClickHouse. Expectatives

Després d'haver visitat diverses trobades dels nois de Yandex, després d'haver llegit un parell d'articles sobre Habré, després de revisar la documentació i trobar components correctes per enquadernar ClickHouse a Graphite, vam decidir prendre mesures!

M'agradaria rebre el següent:

reduir la utilització del subsistema de disc del 30% al 5%;
reduir la quantitat d'espai ocupat d'1 TB a 100 GB;
poder rebre 100 milions de mètriques per minut al servidor;
replicació de dades i tolerància a errors fora de la caixa;
no us asseureu en aquest projecte durant un any i feu la transició en un termini raonable;
canviar sense temps d'inactivitat.

Bastant ambiciós, oi?

Grafit+ClickHouse. Components

He seleccionat per rebre dades mitjançant el protocol Graphite i gravar-les posteriorment a ClickHouse carbon-clickhouse (golang).

La darrera versió de ClickHouse, la versió estable 1.1.54253, va ser escollida com a base de dades per emmagatzemar sèries temporals. Hi va haver problemes en treballar-hi: una muntanya d'errors es va abocar als registres i no estava del tot clar què fer-hi. En discussió amb Roman Lomonosov (autor de carbon-clickhouse, graphite-clickhouse i molts, molts més) es va triar el més antic versió 1.1.54236. Els errors van desaparèixer: tot va començar a funcionar amb una explosió.

Seleccionat per llegir dades de ClickHouse casa de clic de grafit (golang). Com a API de Graphite − carbonapi (golang). ClickHouse es va utilitzar per organitzar la replicació entre taules guardià de zoològic. Per a les mètriques d'encaminament, hem deixat el nostre estimat relé de carboni-c (C) (veure article anterior).

Grafit+ClickHouse. Estructura de la taula

"grafit" és una base de dades que hem creat per controlar taules.

“graphite.metrics” - taula amb el motor ReplicatedReplacingMergeTree (replicat SubstituintMergeTree). Aquesta taula emmagatzema els noms de les mètriques i els camins per accedir-hi.

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

“graphite.data” - taula amb el motor ReplicatedGraphiteMergeTree (replicat GraphiteMergeTree). Aquesta taula emmagatzema els valors mètrics.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

"graphite.date_metrics" és una taula emplenada condicionalment amb el motor ReplicatedReplacingMergeTree. Aquesta taula registra els noms de totes les mètriques que s'han trobat durant el dia. Els motius de la seva creació es descriuen a l'apartat "Problemes" al final d'aquest article.

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

“graphite.data_stat”: una taula emplenada per condició, amb el motor ReplicatedAggregatingMergeTree (replicat AggregatingMergeTree). Aquesta taula registra el nombre de mètriques entrants, desglossat en 4 nivells d'imbricació.

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

Grafit+ClickHouse. Diagrama d'interacció de components

Grafit+ClickHouse. Migració de dades

Com recordem per les expectatives d'aquest projecte, la transició a ClickHouse hauria de ser sense temps d'inactivitat; en conseqüència, vam haver de canviar d'alguna manera tot el nostre sistema de monitorització al nou emmagatzematge de la manera més transparent possible per als nostres usuaris.
Així ho hem fet.

S'ha afegit una regla a carbon-c-relay per enviar un flux addicional de mètriques al carbon-clickhouse d'un dels servidors que participen en la replicació de les taules ClickHouse.
Vam escriure un petit script en python, que, utilitzant la biblioteca whisper-dump, va llegir tots els fitxers .wsp del nostre emmagatzematge i va enviar aquestes dades al carbon-clickhouse descrit anteriorment en 24 fils. El nombre de valors mètrics acceptats a carbon-clickhouse va arribar als 125 milions/min, i ClickHouse ni tan sols va suar.
Hem creat una font de dades independent a Grafana per depurar les funcions utilitzades als taulers de control existents. Vam identificar una llista de funcions que vam utilitzar, però no es van implementar a carbonapi. Hem afegit aquestes funcions i hem enviat PR als autors de carbonapi (especial gràcies a ells).
Per canviar la càrrega de lectura a la configuració de l'equilibrador, hem canviat els punts finals de graphite-api (interfície API per a Graphite + Whisper) a carbonapi.

Grafit+ClickHouse. resultats

reducció de l'ús del subsistema de disc del 30% a l'1%;
va reduir la quantitat d'espai ocupat d'1 TB a 300 GB;
tenim la capacitat de rebre 125 milions de mètriques per minut al servidor (pics en el moment de la migració);
transferit totes les mètriques a un interval d'emmagatzematge de trenta segons;
replicació de dades rebudes i tolerància a errors;
canviat sense temps d'inactivitat;
Va trigar unes 7 setmanes a completar-ho tot.

Grafit+ClickHouse. Problemes

En el nostre cas, hi va haver algunes trampes. Això és el que ens vam trobar després de la transició.

ClickHouse no sempre rellegeix les configuracions sobre la marxa; de vegades s'ha de reiniciar. Per exemple, en el cas de la descripció del clúster de zookeeper a la configuració de ClickHouse, no es va utilitzar fins que es va reiniciar el servidor de clickhouse.
Les sol·licituds de ClickHouse grans no s'han realitzat, de manera que a grafit-clickhouse la nostra cadena de connexió ClickHouse té aquest aspecte:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse publica sovint noves versions de versions estables; poden contenir sorpreses: aneu amb compte.
Els contenidors creats dinàmicament a kubernetes envien un gran nombre de mètriques amb una vida útil curta i aleatòria. No hi ha molts punts per a aquestes mètriques i no hi ha problemes amb l'espai. Però en crear consultes, ClickHouse recull un gran nombre d'aquestes mateixes mètriques de la taula "mètriques". En el 90% dels casos, no hi ha dades més enllà de la finestra (24 hores). Però el temps es dedica a la recerca d'aquestes dades a la taula "dades" i, finalment, s'espera un temps d'espera. Per solucionar aquest problema, vam començar a mantenir una visió separada amb informació sobre les mètriques que es van trobar durant el dia. Així, quan es creen informes (gràfics) per a contenidors creats dinàmicament, consultem només aquelles mètriques que es van trobar dins d'una finestra determinada, i no durant tot el temps, la qual cosa va accelerar significativament la construcció d'informes sobre ells. Per a la solució descrita anteriorment, vaig recopilar grafit-clickhouse (forquilla), que inclou la implementació del treball amb la taula date_metrics.

Grafit+ClickHouse. Etiquetes

Amb la versió 1.1.0 Graphite es va fer oficial etiquetes de suport. I estem pensant activament què i com fer per donar suport a aquesta iniciativa a la pila de grafit+clickhouse.

Grafit+ClickHouse. Detector d'anomalies

A partir de la infraestructura descrita anteriorment, hem implementat un prototip de detector d'anomalies i funciona! Però més sobre ell al següent article.

Subscriu-te, prem la fletxa amunt i sigues feliç!

Font: www.habr.com

Emmagatzematge mètric: com vam passar de Graphite+Whisper a Graphite+ClickHouse