Hei kaikki! Hänen viimeinen artikkeli Kirjoitin modulaarisen valvontajärjestelmän järjestämisestä mikropalveluarkkitehtuurille. Mikään ei pysähdy, projektimme kasvaa jatkuvasti, samoin kuin tallennettujen mittareiden määrä. Kuinka organisoimme siirtymisen Graphite + Whisperista Graphite + ClickHouseen suuressa kuormituksessa, lue siihen kohdistuvista odotuksista ja leikkauksen alla tapahtuneen siirtymän tuloksista.

Ennen kuin kerron, kuinka järjestimme siirtymisen mittareiden tallentamisesta Graphite + Whisperissa Graphite + ClickHouseen, haluaisin kertoa syistä tällaiseen päätökseen ja Whisperin haitoista, joiden kanssa elimme pitkään.

Grafiitti+kuiskausongelmat

1. Suuri kuormitus levyalijärjestelmässä

Siirtymähetkellä meille lensi noin 1.5 miljoonaa mittaria minuutissa. Tällä virtauksella levyn käyttöaste palvelimilla oli ~30%. Yleisesti ottaen se oli varsin hyväksyttävää - kaikki toimi vakaasti, kirjoitettiin nopeasti, luettiin nopeasti ... Kunnes yksi kehitystiimistä otti käyttöön uuden ominaisuuden ja alkoi lähettää meille 10 miljoonaa mittaria minuutissa. Silloin levyalijärjestelmä kiristyi ja näimme 100 %:n käyttöasteen. Ongelma ratkesi nopeasti, mutta sedimentti jäi.

2. Replikoinnin ja johdonmukaisuuden puute

Todennäköisesti, kuten kaikki Graphite + Whisperiä käyttävät / käyttävät, kaadimme saman mittausvirran useille Graphite-palvelimille kerralla luodaksemme vikasietoisuuden. Ja tässä ei ollut erityisiä ongelmia - siihen asti, kun yksi palvelimista ei jostain syystä putoanut. Joskus onnistuimme saamaan pudonneen palvelimen esiin tarpeeksi nopeasti, ja carbon-c-relay onnistui täyttämään sen mittareilla välimuististaan, joskus ei. Ja sitten mittareissa oli reikä, jonka peitimme rsyncillä. Toimenpide oli melko pitkä. Pelasti vain se, että näin tapahtui hyvin harvoin. Otimme myös ajoittain satunnaisen joukon mittareita ja vertasimme niitä muihin vastaaviin klusterin naapurisolmuissa. Noin 5 prosentissa tapauksista useat arvot poikkesivat toisistaan, mikä ei tehnyt meitä kovin onnelliseksi.

3. Suuri määrä tilaa varattu

Koska kirjoitamme Graphitessa infrastruktuurin lisäksi myös liiketoimintamittareita (ja nyt myös Kubernetesin mittareita), tulee melko usein tilanne, jossa metriikassa on vain muutama arvo ja .wsp-tiedosto luodaan ottamalla ottaa huomioon koko säilytysajan ja vie ennalta varatun määrän tilaa, jota meillä oli ~ 2 Mt. Ongelmaa pahentaa se, että tällaisia tiedostoja on ajan mittaan paljon ja niistä raportteja laadittaessa tyhjien kohtien lukeminen vie paljon aikaa ja resursseja.

Haluaisin heti huomauttaa, että yllä kuvatut ongelmat voidaan käsitellä eri menetelmillä ja eri tehokkuusasteilla, mutta mitä enemmän tietoja alat vastaanottaa, sitä enemmän ne pahenevat.

Kun sinulla on kaikki yllä mainitut (ottaen huomioon edellinen Artikkeli), sekä vastaanotettujen mittareiden määrän jatkuva kasvu, halu siirtää kaikki mittarit 30 sekunnin tallennusväliin. (tarvittaessa 10 sekuntiin asti), päätimme kokeilla Graphite+ClickHousea lupaavana vaihtoehtona Whisperille.

Grafiitti+ClickHouse. odotuksia

Vieraillut useissa Yandexin kaverien tapaamisissa, lukenut pari artikkelia Habresta, käytyämme läpi dokumentaation ja löydettyämme järkeviä komponentteja ClickHousen sitomiseksi Grafiitin alle, päätimme toimia!

Haluaisin saada seuraavat:

vähentää levyn alijärjestelmän käyttöä 30 %:sta 5 %:iin;
pienennä varatun tilan määrää 1 Tt:sta 100 Gt:aan;
pystyä vastaanottamaan 100 miljoonaa mittaria minuutissa palvelimelle;
tietojen replikointi ja vikasietoisuus heti valmiina;
älä istu tässä projektissa vuotta ja tee siirtymä joksikin järkeväksi ajaksi;
kytkin ilman seisokkeja.

Aika kunnianhimoinen, eikö?

Grafiitti+ClickHouse. Komponentit

Päätin vastaanottaa tietoja Graphite-protokollan kautta ja kirjoittaa ne sitten ClickHouseen hiili-clickhouse (golang).

Aikasarjojen tallennuksen tietokannaksi valittiin vakaan version 1.1.54253 viimeisin ClickHouse-julkaisu. Sen kanssa työskennellessä oli ongelmia: lokeihin valui vuori virheitä, eikä ollut täysin selvää, mitä niille pitäisi tehdä. Keskustelussa kanssa Roman Lomonosov (hiili-clickhousen, grafiitti-clickhousen ja monen muun kirjoittaja) valittiin vanhempi julkaisu 1.1.54236. Virheet katosivat - kaikki alkoi toimia räjähdysmäisesti.

Datan lukeminen ClickHousesta valittiin grafiitti-clickhouse (golang). Grafiitin API:na − carbonapi (golang). Taulukoiden välisen replikoinnin järjestämiseen käytettiin ClickHousea eläintarhanhoitaja. Reititysmittareita varten jätimme rakkaamme hiili-c-rele (C) (katso edellinen artikkeli).

Grafiitti+ClickHouse. Taulukon rakenne

"grafiitti" on tietokanta, jonka loimme seurantataulukoita varten.

"graphite.metrics" on taulukko, jossa on ReplicatedReplacingMergeTree-moottori (replikoitu KorvaaMergeTree). Tämä taulukko tallentaa mittareiden nimet ja polut niihin.

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" on taulukko, jossa on ReplicatedGraphiteMergeTree-moottori (replikoitu GraphiteMergeTree). Tämä taulukko tallentaa mittausarvot.

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" on ehdollisesti täytetty taulukko ReplicatedReplacingMergeTree-moottorilla. Tämä taulukko sisältää kaikkien päivän aikana havaittujen mittareiden nimet. Luomisen syyt on kuvattu osiossa "Ongelmia" tämän artikkelin lopussa.

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" on ehdollinen taulukko, jossa on ReplicatedAggregatingMergeTree-moottori (replikoitu AggregatingMergeTree). Tämä taulukko tallentaa saapuvien mittareiden määrän neljään sisäkkäistasoon jaoteltuna.

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

Grafiitti+ClickHouse. Kaavio komponenttien vuorovaikutuksesta

Grafiitti+ClickHouse. Tiedonsiirto

Kuten tämän projektin odotuksista muistamme, ClickHouseen siirtymisen pitäisi tapahtua ilman seisokkeja, joten meidän piti jotenkin siirtää koko valvontajärjestelmämme uuteen tallennustilaan mahdollisimman läpinäkyvästi käyttäjillemme.
Teimme sen näin.

Carbon-c-relayyn lisättiin sääntö, joka lähettää ylimääräisen mittausvirran yhden ClickHouse-taulukoiden replikointiin osallistuvan palvelimen hiili-clickhouseen.
Kirjoitimme pienen python-komentosarjan, joka luki kaikki .wsp-tiedostot tallennustilastamme käyttämällä whisper-dump-kirjastoa ja lähetti nämä tiedot edellä kuvattuun 24 säikeeseen. Hyväksyttyjen metriarvojen määrä hiili-clickhousessa saavutti 125 miljoonaa / min, eikä ClickHouse edes hikoillut.
Loimme Grafanaan erillisen tietolähteen olemassa olevien hallintapaneelien toimintojen virheenkorjausta varten. Paljastimme luettelon käyttämistämme ominaisuuksista, mutta niitä ei otettu käyttöön carbonapissa. Saimme nämä toiminnot valmiiksi ja lähetimme PR:t carbonapin tekijöille (erityinen kiitos heille).
Lukukuorman vaihtamiseksi tasapainottimen asetuksissa vaihdoimme päätepisteet graphite-apista (API-liittymä Graphite+Whisperille) carbonapiksi.

Grafiitti+ClickHouse. tuloksia

laski levyalijärjestelmän käyttöastetta 30 %:sta 1 %:iin;
pienensi käytetyn tilan määrää 1 Tt:sta 300 Gt:iin;
pystymme vastaanottamaan 125 miljoonaa mittaria minuutissa per palvelin (huippuja siirron aikana);
siirsi kaikki mittarit XNUMX sekunnin tallennusväliin;
vastaanotetun tiedon replikointi ja vikasietoisuus;
kytketty ilman seisokkeja;
Kaikkeen kesti noin 7 viikkoa.

Grafiitti+ClickHouse. Ongelmia

Meidän tapauksessamme oli joitain sudenkuoppia. Tässä on se, mitä kohtasimme siirtymän jälkeen.

ClickHouse ei aina lue konfiguraatioita uudelleen lennossa, joskus se on ladattava uudelleen. Esimerkiksi ClickHouse-kokoonpanon zookeeper-klusterin kuvauksen tapauksessa sitä ei sovellettu ennen kuin clickhouse-palvelin käynnistettiin uudelleen.
Suuria ClickHouse-pyyntöjä ei ollut, joten grafiitti-clickhousessamme ClickHouse-yhteysmerkkijono näyttää tältä:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse julkaisee melko usein uusia versioita vakaasta julkaisusta, ne voivat sisältää yllätyksiä: ole varovainen.
Kubernetesissa dynaamisesti luodut säilöt lähettävät suuren määrän mittareita lyhyellä ja satunnaisella käyttöiällä. Tällaisten mittareiden mukaan pisteitä ei ole paljon, eikä paikan kanssa ole ongelmia. Mutta kyselyjä tehdessään ClickHouse kerää valtavan määrän näitä samoja mittareita "mittarit"-taulukosta. 90 %:ssa tapauksista ei ole tietoja ikkunan ulkopuolella (24 tuntia). Mutta aika, joka kuluu näiden tietojen etsimiseen "data"-taulukosta, kuluu, ja se perustuu lopulta aikakatkaisuun. Tämän ongelman ratkaisemiseksi aloimme ylläpitää erillistä näkymää, joka sisältää tiedot päivän aikana havaituista mittareista. Näin ollen, kun rakennamme raportteja (kaavioita) dynaamisesti luotuihin säilöihin, kyselystämme vain ne mittarit, jotka havaittiin määritetyn ikkunan sisällä, emme koko ajan, mikä nopeutti suuresti raporttien luomista niistä. Yllä olevaa liuosta varten kerättiin grafiitti-clickhouse (haarukka), joka sisältää date_metrics-taulukon kanssa työskentelyn toteutuksen.

Grafiitti+ClickHouse. tunnisteet

Versiosta 1.1.0 lähtien Graphite on tullut viralliseksi tukitunnisteet. Ja mietimme aktiivisesti, mitä ja miten voisimme tehdä tukeaksemme tätä aloitetta grafiitti+clickhouse-pinossa.

Grafiitti+ClickHouse. Anomalian ilmaisin

Yllä kuvatun infrastruktuurin pohjalta olemme toteuttaneet poikkeavuusilmaisimen prototyypin ja se toimii! Mutta hänestä - seuraavassa artikkelissa.

Tilaa, paina ylänuolta ja ole onnellinen!

Lähde: will.com

Metrinen tallennus: kuinka siirryimme Graphite+Whisperistä Graphite+ClickHouseen