Saluton al ĉiuj! En lia lasta artikolo Mi skribis pri organizado de modula monitora sistemo por mikroserva arkitekturo. Nenio haltas, nia projekto senĉese kreskas, kaj ankaŭ la nombro da stokitaj metrikoj. Kiel ni organizis la transiron de Graphite + Whisper al Graphite + ClickHouse sub altaj ŝarĝaj kondiĉoj, legu pri la atendoj de ĝi kaj la rezultoj de la migrado sub la tranĉo.

Antaŭ ol mi rakontu al vi, kiel ni organizis la transiron de stokado de metrikoj en Graphite + Whisper al Graphite + ClickHouse, mi ŝatus doni informojn pri la kialoj por fari tian decidon kaj pri la malavantaĝoj de Whisper, kun kiu ni vivis dum longa tempo.

Problemoj de Grafito+Flustro

1. Alta ŝarĝo sur la disksubsistemo

En la momento de la transiro, proksimume 1.5 milionoj da metrikoj por minuto flugis al ni. Kun ĉi tiu fluo, disko utiligo sur la serviloj estis ~30%. Ĝenerale, ĝi estis sufiĉe akceptebla - ĉio funkciis stabile, estis skribita rapide, legita rapide ... Ĝis unu el la evoluigaj teamoj lanĉis novan funkcion kaj komencis sendi al ni 10 milionojn da metrikoj por minuto. Estis tiam kiam la disksubsistemo plifirmiĝis, kaj ni vidis 100% utiligon. La problemo estis rapide solvita, sed la sedimento restis.

2. Manko de reproduktado kaj konsistenco

Plej verŝajne, kiel ĉiuj, kiuj uzas / uzas Graphite + Whisper, ni verŝis la saman fluon de metrikoj al pluraj Graphite-serviloj samtempe por krei misfunkciadon. Kaj ne estis specialaj problemoj kun ĉi tio - ĝis la momento, kiam unu el la serviloj ne falis ial. Kelkfoje ni sukcesis aperigi la falintan servilon sufiĉe rapide, kaj carbon-c-relay sukcesis plenigi ĝin per metrikoj el ĝia kaŝmemoro, kaj foje ne. Kaj tiam estis truo en la metriko, kiun ni kovris per rsync. La proceduro estis sufiĉe longa. Savita nur pro tio, ke tio okazis tre malofte. Ni ankaŭ periode prenis hazardan aron de metrikoj kaj komparis ilin kun aliaj similaj sur najbaraj nodoj de la areto. En ĉirkaŭ 5% de kazoj, pluraj valoroj malsamis, kio ne tre ĝojigis nin.

3. Granda kvanto de spaco okupita

Ĉar ni skribas en Graphite ne nur infrastrukturon, sed ankaŭ komercajn metrikojn (kaj nun ankaŭ metrikojn de Kubernetes), ni sufiĉe ofte ricevas situacion, en kiu estas nur kelkaj valoroj en la metriko, kaj la .wsp-dosiero estas kreita prenante. konsideru la tutan retenperiodon, kaj okupas antaŭ-asignitan kvanton da spaco, kiun ni havis ~ 2 MB. La problemo estas pligravigita de la fakto, ke ekzistas multaj tiaj dosieroj laŭlonge de la tempo, kaj kiam oni konstruas raportojn pri ili, legi malplenajn punktojn postulas multan tempon kaj rimedojn.

Mi ŝatus rimarki tuj, ke la supre priskribitaj problemoj povas esti traktitaj per diversaj metodoj kaj kun diversaj gradoj de efikeco, sed ju pli da datumoj vi komencas ricevi, des pli ili pligraviĝas.

Havante ĉion supre (konsiderante la antaŭan artikoloj), same kiel konstanta kresko de la nombro da ricevitaj metrikoj, la deziro translokigi ĉiujn metrikojn al stokado-intervalo de 30 sekundoj. (ĝis 10 sekundoj se necese), ni decidis provi Graphite+ClickHouse kiel promesplena alternativo al Whisper.

Grafito+ClickHouse. atendoj

Vizitinte plurajn renkontiĝojn de la uloj de Yandex, leginte kelkaj artikoloj pri Habré, ekzameninte la dokumentaron kaj trovinte prudentajn komponantojn por ligi ClickHouse sub Grafito, ni decidis agi!

Ŝatus ricevi la jenajn:

reduktu uzadon de disksubsistemo de 30% ĝis 5%;
redukti la kvanton de spaco okupita de 1TB al 100GB;
povi ricevi 100 milionojn da metrikoj por minuto al la servilo;
datumreproduktado kaj misfunkciado el la skatolo;
ne sidu en ĉi tiu projekto dum unu jaro kaj faru la transiron dum iu prudenta periodo;
ŝaltilo sen malfunkcio.

Sufiĉe ambicia, ĉu ne?

Grafito+ClickHouse. Komponentoj

Por ricevi datumojn per la Graphite-protokolo kaj poste skribi ilin al ClickHouse, mi elektis karbon-clickhouse (golang).

La lasta ClickHouse-eldono de la stabila versio 1.1.54253 estis elektita kiel la datumbazo por stokado de temposerio. Laborante kun ĝi, estis problemoj: monto da eraroj verŝis en la ŝtipojn, kaj ne estis tute klare, kion fari kun ili. En diskuto kun Roman Lomonosov (aŭtoro de karbono-clickhouse, grafito-clickhouse kaj multe pli) la pli malnova estis elektita eldono 1.1.54236. Eraroj malaperis - ĉio komencis funkcii kun bruo.

Por legi datumojn de ClickHouse estis elektita grafito-clickhouse (golang). Kiel API por Grafito − karbonapi (golang). Por organizi reproduktadon inter tabloj, ClickHouse estis uzita bestogardisto. Por vojaj metrikoj, ni lasis nian amaton karbono-c-relajso (C) (vidu antaŭan artikolon).

Grafito+ClickHouse. Tablostrukturo

"grafito" estas datumbazo, kiun ni kreis por monitori tabelojn.

"graphite.metrics" estas tabelo kun la ReplicatedReplacingMergeTree-motoro (reproduktita AnstataŭiganteMergeTree). Ĉi tiu tabelo konservas la nomojn de la metrikoj kaj la vojojn al ili.

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" estas tabelo kun la ReplicatedGraphiteMergeTree-motoro (reproduktita GraphiteMergeTree). Ĉi tiu tabelo konservas metrikajn valorojn.

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" estas kondiĉe plenigita tabelo kun la ReplicatedReplacingMergeTree-motoro. Ĉi tiu tabelo enhavas la nomojn de ĉiuj metrikoj kiuj estis renkontitaj dum la tago. La kialoj de la kreado estas priskribitaj en la sekcio "Problemoj" ĉe la fino de ĉi tiu artikolo.

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" estas kondiĉa tabelo kun la ReplicatedAggregatingMergeTree-motoro (reproduktita AgregatingMergeTree). Ĉi tiu tabelo registras la nombron da envenantaj metrikoj, dividitaj al 4 niveloj de nestado.

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

Grafito+ClickHouse. Skemo de interago de komponantoj

Grafito+ClickHouse. Migrado de datumoj

Kiel ni memoras de la atendoj de ĉi tiu projekto, la transiro al ClickHouse devus esti sen malfunkcio, respektive, ni devis iel ŝanĝi nian tutan monitoran sistemon al la nova stokado kiel eble plej travideble por niaj uzantoj.
Ni faris ĝin tiel.

Regulo estis aldonita al karbono-c-relajso por sendi plian fluon de metriko al la karbon-clickhouse de unu el la serviloj implikitaj en la reproduktado de ClickHouse-tabloj.
Ni skribis malgrandan python-skripton, kiu, uzante la flustro-dump-bibliotekon, legis ĉiujn .wsp-dosierojn el nia stokado kaj sendis ĉi tiujn datumojn al la karbono-clickhouse priskribita supre en 24 fadenoj. La nombro de akceptitaj metrikaj valoroj en karbono-clickhouse atingis 125 milionojn / min., kaj ClickHouse eĉ ne ŝvitis.
Ni kreis apartan Datumfonton en Grafana por sencimigi la funkciojn uzatajn en ekzistantaj paneloj. Malkaŝis liston de funkcioj, kiujn ni uzis, sed ili ne estis efektivigitaj en carbonapi. Ni finis ĉi tiujn funkciojn, kaj sendis PR-ojn al la aŭtoroj de carbonapi (specialan dankon al ili).
Por ŝanĝi la legan ŝarĝon en la ekvilibraj agordoj, ni ŝanĝis finpunktojn de grafito-api (API-interfaco por Graphite+Whisper) al carbonapi.

Grafito+ClickHouse. rezulto

reduktis la utiligon de la disksubsistemo de 30% al 1%;
reduktis la kvanton de spaco okupita de 1 TB al 300 GB;
ni havas la kapablon ricevi 125 milionojn da metrikoj po minuto per servilo (pintoj en la tempo de migrado);
transdonis ĉiujn metrikojn al tridek-sekunda stokadintervalo;
ricevita datuma reproduktado kaj faŭltoleremo;
ŝanĝita sen malfunkcio;
Por ĉio daŭris ĉirkaŭ 7 semajnoj.

Grafito+ClickHouse. Problemoj

En nia kazo, estis kelkaj kaptiloj. Jen kion ni renkontis post la transiro.

ClickHouse ne ĉiam relegas agordojn sur la flugo, foje ĝi devas esti reŝargita. Ekzemple, en la kazo de la priskribo de la zookeeper-grupo en la ClickHouse-agordo, ĝi ne estis aplikita ĝis la clickhouse-servilo estis rekomencita.
Ne estis grandaj petoj de ClickHouse, do en nia grafito-clickhouse, la ligŝnuro de ClickHouse aspektas jene:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse sufiĉe ofte eldonas novajn versiojn de stabilaj eldonoj, ili povas enhavi surprizojn: atentu.
Dinamike kreitaj ujoj en kubernetes sendas grandan nombron da metrikoj kun mallonga kaj hazarda vivdaŭro. Ne estas multaj punktoj laŭ tiaj metrikoj, kaj ne estas problemoj kun la loko. Sed kiam konstruas demandojn, ClickHouse levas grandegan nombron da ĉi tiuj samaj metrikoj de la 'metriko'-tabelo. En 90% de kazoj, ne ekzistas datumoj por ili ekster la fenestro (24 horoj). Sed la tempo elspezita serĉante ĉi tiujn datumojn en la 'datuma' tabelo estas elspezita, kaj finfine ripozas sur tempo-tempo. Por solvi ĉi tiun problemon, ni komencis konservi apartan vidon kun informoj pri la metrikoj kiuj estis renkontitaj dum la tago. Tiel, dum konstruado de raportoj (grafikaĵoj) por dinamike kreitaj ujoj, ni enketas nur tiujn metrikojn, kiuj estis renkontitaj ene de la specifita fenestro, kaj ne dum la tuta tempo, kio multe akcelis la kreadon de raportoj pri ili. Por la supra solvo estis kolektita grafita klakdomo (forko), kiu inkluzivas la efektivigon de laborado kun la date_metrics-tabelo.

Grafito+ClickHouse. etikedoj

Ekde versio 1.1.0 Grafito fariĝis oficiala subtenaj etikedoj. Kaj ni aktive pensas pri tio, kion kaj kiel fari por subteni ĉi tiun iniciaton en la grafito+clickhouse stako.

Grafito+ClickHouse. Detektilo de anomalioj

Surbaze de la infrastrukturo priskribita supre, ni efektivigis prototipan anomalian detektilon, kaj ĝi funkcias! Sed pri li - en la sekva artikolo.

Abonu, premu la supren-sagon kaj estu feliĉa!

fonto: www.habr.com

Metrika stokado: kiel ni transiris de Graphite+Whisper al Graphite+ClickHouse