Dag Allemaal! In zijn laatste artikel Ik schreef over het organiseren van een modulair monitoringsysteem voor microservice-architectuur. Niets staat stil, ons project groeit voortdurend, en dat geldt ook voor het aantal opgeslagen statistieken. Hoe we de transitie van Graphite+Whisper naar Graphite+ClickHouse onder hoge belasting hebben georganiseerd, lees over de verwachtingen ervan en de resultaten van de migratie onder de bezuiniging.

Voordat ik vertel hoe we de transitie van het opslaan van metrics in Graphite+Whisper naar Graphite+ClickHouse hebben georganiseerd, wil ik graag informatie geven over de redenen voor het nemen van een dergelijke beslissing en over de nadelen van Whisper waar we lang mee hebben geleefd.

Grafiet+Whisper-problemen

1. Hoge belasting van het schijfsubsysteem

Op het moment van de transitie kwamen er ongeveer 1.5 miljoen meetgegevens per minuut bij ons binnen. Met een dergelijke stroom bedroeg het schijfgebruik op servers ~30%. Over het algemeen was dit heel acceptabel: alles werkte stabiel, werd snel geschreven, snel gelezen... Totdat een van de ontwikkelingsteams een nieuwe functie uitrolde en ons 10 miljoen statistieken per minuut begon te sturen. Toen werd het schijfsubsysteem strakker en zagen we een benutting van 100%. Het probleem was snel opgelost, maar er bleef een residu achter.

2. Gebrek aan replicatie en consistentie

Hoogstwaarschijnlijk hebben we, net als iedereen die Graphite+Whisper gebruikt/gebruikte, dezelfde stroom metrieken tegelijk naar meerdere Graphite-servers gegoten om fouttolerantie te creëren. En hier waren geen speciale problemen mee - tot het moment waarop een van de servers om de een of andere reden crashte. Soms slaagden we erin om een defecte server snel genoeg op te pikken, en carbon-c-relay slaagde erin om statistieken uit de cache erin te laden, maar soms niet. En toen zat er een gat in de statistieken, die we opvulden met rsync. De procedure duurde behoorlijk lang. De enige goedmaker was dat dit zeer zelden gebeurde. We hebben ook periodiek een willekeurige reeks statistieken genomen en deze vergeleken met andere van hetzelfde type op aangrenzende knooppunten van het cluster. In ongeveer 5% van de gevallen waren meerdere waarden verschillend, waar wij niet zo blij mee waren.

3. Grote voetafdruk

Omdat we in Graphite niet alleen infrastructuur, maar ook bedrijfsstatistieken schrijven (en nu ook statistieken van Kubernetes), krijgen we vrij vaak een situatie waarin de metriek slechts een paar waarden bevat en het .wsp-bestand wordt gemaakt rekening houdend met alle retentie periode, en neemt een vooraf toegewezen hoeveelheid ruimte in beslag, wat voor ons ~2 MB was. Het probleem wordt nog verergerd door het feit dat er in de loop van de tijd veel vergelijkbare bestanden verschijnen, en als er rapporten over worden gemaakt, kost het lezen van lege punten veel tijd en middelen.

Ik zou meteen willen opmerken dat de hierboven beschreven problemen kunnen worden aangepakt met behulp van verschillende methoden en met verschillende mate van effectiviteit, maar hoe meer gegevens u begint te ontvangen, hoe meer ze verergeren.

Met al het bovenstaande (rekening houdend met het voorgaande Artikel), evenals een constante toename van het aantal ontvangen statistieken, de wens om alle statistieken over te dragen naar een opslaginterval van 30 seconden. (indien nodig maximaal 10 seconden), besloten we Graphite+ClickHouse te proberen als een veelbelovend alternatief voor Whisper.

Grafiet+ClickHouse. Verwachtingen

Na verschillende bijeenkomsten van de jongens van Yandex te hebben bezocht, na gelezen te hebben een paar artikelen over HabréNadat we de documentatie hadden doorgenomen en goede componenten hadden gevonden voor het binden van ClickHouse onder Graphite, besloten we actie te ondernemen!

Ik wil graag het volgende ontvangen:

het gebruik van schijfsubsystemen terugbrengen van 30% naar 5%;
verminder de hoeveelheid ingenomen ruimte van 1TB naar 100GB;
in staat zijn om 100 miljoen statistieken per minuut op de server te ontvangen;
datareplicatie en fouttolerantie out-of-the-box;
blijf niet een jaar op dit project zitten en maak de overstap binnen een redelijk tijdsbestek;
overstappen zonder downtime.

Best ambitieus, toch?

Grafiet+ClickHouse. Componenten

Ik heb gekozen voor het ontvangen van gegevens via het Graphite-protocol en deze vervolgens in ClickHouse vast te leggen koolstof-klikhuis (golang).

Als database voor het opslaan van tijdreeksen werd gekozen voor de nieuwste release van ClickHouse, stabiele versie 1.1.54253. Er waren problemen bij het werken ermee: er stroomde een berg fouten in de logboeken en het was niet helemaal duidelijk wat ermee te doen. In gesprek met Roman Lomonosov (auteur van carbon-clickhouse, graphite-clickhouse en nog veel, veel meer) de oudere werd gekozen versie 1.1.54236. De fouten verdwenen - alles begon met een knal te werken.

Geselecteerd om gegevens van ClickHouse te lezen grafiet-klikhuis (golang). Als API voor Grafiet − carbonapi (golang). ClickHouse werd gebruikt om de replicatie tussen tabellen te organiseren dierentuinmedewerker. Voor routeringsstatistieken hebben we onze geliefde verlaten koolstof-c-relais (C) (zie vorig artikel).

Grafiet+ClickHouse. Tabelstructuur

“grafiet” is een database die we hebben gemaakt voor het monitoren van tabellen.

"graphite.metrics" - tabel met ReplicatedReplacingMergeTree-engine (gerepliceerd MergeTree vervangen). In deze tabel worden de namen van de metrieken en de paden ernaartoe opgeslagen.

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" - tabel met ReplicatedGraphiteMergeTree-engine (gerepliceerd GrafietMergeBoom). In deze tabel worden metrische waarden opgeslagen.

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” is een voorwaardelijk gevulde tabel met de ReplicatedReplacingMergeTree-engine. In deze tabel worden de namen vastgelegd van alle statistieken die gedurende de dag zijn aangetroffen. De redenen voor de oprichting ervan worden beschreven in de sectie "Problemen" aan het einde van dit artikel.

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” - een tabel gevuld volgens voorwaarde, met de ReplicatedAggregatingMergeTree-engine (gerepliceerd SamenvoegenMergeTree). In deze tabel wordt het aantal binnenkomende statistieken geregistreerd, opgesplitst in vier nestingniveaus.

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

Grafiet+ClickHouse. Component-interactiediagram

Grafiet+ClickHouse. Data migratie

Zoals we ons herinneren uit de verwachtingen van dit project, zou de overgang naar ClickHouse zonder downtime moeten verlopen; daarom moesten we op de een of andere manier ons hele monitoringsysteem zo transparant mogelijk overzetten naar de nieuwe opslag voor onze gebruikers.
Dit is hoe wij het deden.

Er is een regel toegevoegd aan carbon-c-relay om een extra stroom metrieken naar het carbon-clickhouse van een van de servers te sturen die deelnemen aan de replicatie van ClickHouse-tabellen.
We schreven een klein script in Python, dat, met behulp van de fluisterdumpbibliotheek, alle .wsp-bestanden uit onze opslag las en deze gegevens in 24 threads naar het hierboven beschreven carbon-clickhouse stuurde. Het aantal geaccepteerde metrische waarden in Carbon-Clickhouse bereikte 125 miljoen/min, en ClickHouse zweette niet eens.
We hebben een aparte DataSource in Grafana gemaakt om fouten op te sporen in functies die in bestaande dashboards worden gebruikt. We hebben een lijst met functies geïdentificeerd die we hebben gebruikt, maar deze zijn niet geïmplementeerd in carbonapi. We hebben deze functies toegevoegd en PR's naar de auteurs van carbonapi gestuurd (met speciale dank aan hen).
Om de leesbelasting in de balancer-instellingen te wijzigen, hebben we de eindpunten gewijzigd van graphite-api (API-interface voor Graphite+Whisper) naar carbonapi.

Grafiet+ClickHouse. resultaten

verminderd gebruik van schijfsubsystemen van 30% naar 1%;
de hoeveelheid ingenomen ruimte teruggebracht van 1 TB naar 300 GB;
we hebben de mogelijkheid om 125 miljoen statistieken per minuut op de server te ontvangen (pieken op het moment van migratie);
alle statistieken overgebracht naar een opslaginterval van dertig seconden;
replicatie van ontvangen gegevens en fouttolerantie;
geschakeld zonder downtime;
Het duurde ongeveer 7 weken om alles af te ronden.

Grafiet+ClickHouse. Problemen

In ons geval waren er enkele valkuilen. Dit is wat we na de transitie tegenkwamen.

ClickHouse herleest de configuraties niet altijd meteen; soms moet het opnieuw worden opgestart. In het geval van de beschrijving van het zookeeper-cluster in de ClickHouse-configuratie werd deze bijvoorbeeld pas gebruikt nadat de clickhouse-server opnieuw was opgestart.
Grote ClickHouse-verzoeken zijn niet doorgekomen, dus in graphite-clickhouse ziet onze ClickHouse-verbindingsreeks er als volgt uit:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse brengt regelmatig nieuwe versies uit van stabiele releases; deze kunnen verrassingen bevatten: wees voorzichtig.
Dynamisch gemaakte containers in kubernetes verzenden een groot aantal statistieken met een korte en willekeurige levensduur. Er zijn niet veel punten voor dergelijke statistieken, en er zijn geen problemen met de ruimte. Maar bij het samenstellen van zoekopdrachten haalt ClickHouse een groot aantal van dezelfde statistieken op uit de tabel 'Metrieken'. In 90% van de gevallen zijn er buiten het venster (24 uur) geen gegevens over beschikbaar. Maar er wordt tijd besteed aan het zoeken naar deze gegevens in de 'data'-tabel, en uiteindelijk komt er een time-out voor. Om dit probleem op te lossen, zijn we begonnen een aparte weergave te behouden met informatie over statistieken die we gedurende de dag tegenkwamen. Bij het bouwen van rapporten (grafieken) voor dynamisch gemaakte containers vragen we dus alleen die statistieken op die binnen een bepaald venster zijn aangetroffen, en niet gedurende de hele tijd, wat de constructie van rapporten daarover aanzienlijk heeft versneld. Voor de hierboven beschreven oplossing heb ik verzameld grafiet-clickhouse (vork), inclusief de implementatie van het werken met de date_metrics-tabel.

Grafiet+ClickHouse. Labels

Met versie 1.1.0 werd Graphite officieel ondersteuningstags. En we denken actief na over wat en hoe we dit initiatief in de graphite+clickhouse-stack kunnen ondersteunen.

Grafiet+ClickHouse. Anomaliedetector

Op basis van de hierboven beschreven infrastructuur hebben we een prototype van een anomaliedetector geïmplementeerd, en het werkt! Maar meer over hem in het volgende artikel.

Abonneer je, druk op de pijl omhoog en wees blij!

Bron: www.habr.com

Opslag van statistieken: hoe we zijn overgestapt van Graphite+Whisper naar Graphite+ClickHouse