Kamusta kayong lahat! Sa kanyang huling artikulo Sumulat ako tungkol sa pag-aayos ng isang modular monitoring system para sa microservice architecture. Walang tumitigil, patuloy na lumalaki ang aming proyekto, at gayundin ang bilang ng mga nakaimbak na sukatan. Kung paano namin inayos ang paglipat mula sa Graphite+Whisper patungo sa Graphite+ClickHouse sa ilalim ng mataas na kondisyon ng pag-load, basahin ang tungkol sa mga inaasahan mula dito at ang mga resulta ng paglipat sa ilalim ng cut.

Bago ko sabihin sa iyo kung paano namin inayos ang paglipat mula sa pag-iimbak ng mga sukatan sa Graphite+Whisper tungo sa Graphite+ClickHouse, gusto kong magbigay ng impormasyon tungkol sa mga dahilan ng paggawa ng ganoong desisyon at tungkol sa mga disadvantage ng Whisper na nabuhay kami sa mahabang panahon.

Mga problema sa Graphite+Whisper

1. Mataas na load sa disk subsystem

Sa panahon ng paglipat, humigit-kumulang 1.5 milyong sukatan ang dumarating sa amin bawat minuto. Sa ganoong daloy, ang paggamit ng disk sa mga server ay ~30%. Sa pangkalahatan, ito ay lubos na katanggap-tanggap - lahat ay gumana nang matatag, mabilis na naisulat, mabilis na nabasa... Hanggang sa ang isa sa mga development team ay naglunsad ng bagong feature at nagsimulang magpadala sa amin ng 10 milyong sukatan kada minuto. Iyon ay kapag ang disk subsystem ay humigpit, at nakita namin ang 100% na paggamit. Ang problema ay mabilis na nalutas, ngunit isang nalalabi ang nanatili.

2. Kakulangan ng pagtitiklop at pagkakapare-pareho

Malamang, tulad ng lahat ng gumagamit/gumamit ng Graphite+Whisper, ibinuhos namin ang parehong stream ng mga sukatan sa ilang Graphite server nang sabay-sabay upang makalikha ng fault tolerance. At walang mga espesyal na problema dito - hanggang sa sandaling nag-crash ang isa sa mga server para sa ilang kadahilanan. Minsan ay nakuha namin nang mabilis ang isang nahulog na server, at ang carbon-c-relay ay nakapag-load ng mga sukatan mula sa cache nito papunta dito, ngunit kung minsan ay hindi. At pagkatapos ay nagkaroon ng butas sa mga sukatan, na pinunan namin ng rsync. Medyo mahaba ang procedure. Ang tanging nakapagliligtas na biyaya ay na ito ay napakabihirang nangyari. Pana-panahon din kaming kumuha ng isang random na hanay ng mga sukatan at inihambing ang mga ito sa iba pang may parehong uri sa mga kalapit na node ng cluster. Sa humigit-kumulang 5% ng mga kaso, maraming mga halaga ang naiiba, na hindi namin masyadong ikinatuwa.

3. Malaking bakas ng paa

Dahil sumusulat kami sa Graphite hindi lamang sa imprastraktura, kundi pati na rin sa mga sukatan ng negosyo (at ngayon ay mga sukatan din mula sa Kubernetes), madalas kaming nakakakuha ng isang sitwasyon kung saan ang sukatan ay naglalaman lamang ng ilang mga halaga, at ang .wsp file ay nilikha na isinasaalang-alang ang lahat ng pagpapanatili period, at tumatagal ng paunang inilaan na halaga ng espasyo, na para sa amin ay ~2MB. Ang problema ay higit na pinalala ng katotohanan na maraming katulad na mga file ang lumilitaw sa paglipas ng panahon, at kapag bumubuo ng mga ulat sa mga ito, ang pagbabasa ng mga walang laman na punto ay nangangailangan ng maraming oras at mapagkukunan.

Nais kong agad na tandaan na ang mga problema na inilarawan sa itaas ay maaaring harapin gamit ang iba't ibang mga pamamaraan at may iba't ibang antas ng pagiging epektibo, ngunit ang mas maraming data na sinimulan mong matanggap, mas lumalala ang mga ito.

Ang pagkakaroon ng lahat ng nasa itaas (isinasaalang-alang ang nakaraang Artikulo), pati na rin ang patuloy na pagtaas sa bilang ng mga natanggap na sukatan, ang pagnanais na ilipat ang lahat ng sukatan sa pagitan ng storage na 30 segundo. (hanggang 10 segundo kung kinakailangan), nagpasya kaming subukan ang Graphite+ClickHouse bilang isang promising alternative sa Whisper.

Graphite+ClickHouse. Mga inaasahan

Ang pagbisita sa ilang mga pagkikita-kita ng mga lalaki mula sa Yandex, na nabasa ilang mga artikulo sa Habré, nang dumaan sa dokumentasyon at nakahanap ng matino na mga bahagi para sa pagbubuklod ng ClickHouse sa ilalim ng Graphite, nagpasya kaming kumilos!

Nais kong matanggap ang mga sumusunod:

bawasan ang paggamit ng disk subsystem mula 30% hanggang 5%;
bawasan ang dami ng puwang na inookupahan mula 1TB hanggang 100GB;
makatanggap ng 100 milyong sukatan kada minuto sa server;
pagtitiklop ng data at pagpapahintulot sa kasalanan sa labas ng kahon;
huwag umupo sa proyektong ito sa loob ng isang taon at gawin ang paglipat sa loob ng makatwirang takdang panahon;
lumipat nang walang downtime.

Medyo ambisyoso, tama?

Graphite+ClickHouse. Mga bahagi

Upang makatanggap ng data sa pamamagitan ng Graphite protocol at pagkatapos ay itala ito sa ClickHouse, pinili ko carbon-clickhouse (golang).

Ang pinakabagong release ng ClickHouse, stable na bersyon 1.1.54253, ay pinili bilang database para sa pag-iimbak ng time series. May mga problema kapag nagtatrabaho dito: isang bundok ng mga error ang ibinuhos sa mga log, at hindi ito lubos na malinaw kung ano ang gagawin sa kanila. Sa pakikipagtalakayan sa Roman Lomonosov (may-akda ng carbon-clickhouse, graphite-clickhouse at marami, marami pa) ang mas matanda ay napili release 1.1.54236. Ang mga pagkakamali ay nawala - ang lahat ay nagsimulang gumana nang malakas.

Pinili upang basahin ang data mula sa ClickHouse graphite-сlickhouse (golang). Bilang isang API para sa Graphite − carbonapi (golang). Ang ClickHouse ay ginamit upang ayusin ang pagtitiklop sa pagitan ng mga talahanayan zookeeper. Para sa mga sukatan ng pagruruta, iniwan namin ang aming minamahal carbon-c-relay (C) (tingnan ang nakaraang artikulo).

Graphite+ClickHouse. Istraktura ng talahanayan

Ang "graphite" ay isang database na ginawa namin para sa pagsubaybay sa mga talahanayan.

"graphite.metrics" - talahanayan na may ReplicatedReplacingMergeTree engine (replicated Pinapalitan angMergeTree). Iniimbak ng talahanayang ito ang mga pangalan ng mga sukatan at mga landas patungo sa kanila.

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" - talahanayan na may ReplicatedGraphiteMergeTree engine (replicated GraphiteMergeTree). Ang talahanayang ito ay nag-iimbak ng mga halaga ng sukatan.

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')

Ang "graphite.date_metrics" ay isang talahanayang may kondisyon na puno ng ReplicatedReplacingMergeTree engine. Itinatala ng talahanayang ito ang mga pangalan ng lahat ng sukatan na nakatagpo sa araw. Ang mga dahilan para sa paglikha nito ay inilarawan sa seksyon "Mga problema" sa dulo ng artikulong ito.

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” - isang talahanayan na puno ayon sa kundisyon, gamit ang ReplicatedAggregatingMergeTree engine (replicated Pinagsasama-sama angMergeTree). Itinatala ng talahanayang ito ang bilang ng mga papasok na sukatan, na pinaghiwa-hiwalay sa 4 na antas ng nesting.

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

Graphite+ClickHouse. Diagram ng pakikipag-ugnayan ng bahagi

Graphite+ClickHouse. Paglipat ng data

Tulad ng naaalala namin mula sa mga inaasahan mula sa proyektong ito, ang paglipat sa ClickHouse ay dapat na walang mga downtime; nang naaayon, kailangan naming ilipat ang aming buong sistema ng pagsubaybay sa bagong imbakan nang malinaw hangga't maaari para sa aming mga gumagamit.
Ito ay kung paano namin ito ginawa.

May idinagdag na panuntunan sa carbon-c-relay upang magpadala ng karagdagang stream ng mga sukatan sa carbon-clickhouse ng isa sa mga server na kalahok sa pagtitiklop ng mga talahanayan ng ClickHouse.
Sumulat kami ng maliit na script sa python, na, gamit ang whisper-dump library, binabasa ang lahat ng .wsp file mula sa aming storage at ipinadala ang data na ito sa carbon-clickhouse na inilarawan sa itaas sa 24 na mga thread. Ang bilang ng mga tinatanggap na halaga ng sukatan sa carbon-clickhouse ay umabot sa 125 milyon/min, at ang ClickHouse ay hindi man lang nagpawis.
Gumawa kami ng hiwalay na DataSource sa Grafana para i-debug ang mga function na ginagamit sa mga kasalukuyang dashboard. Natukoy namin ang isang listahan ng mga function na ginamit namin, ngunit hindi sila ipinatupad sa carbonapi. Idinagdag namin ang mga function na ito at nagpadala ng mga PR sa mga may-akda ng carbonapi (espesyal na pasasalamat sa kanila).
Para ilipat ang reading load sa mga setting ng balancer, binago namin ang mga endpoint mula sa graphite-api (API interface para sa Graphite+Whisper) patungo sa carbonapi.

Graphite+ClickHouse. resulta

nabawasan ang paggamit ng disk subsystem mula 30% hanggang 1%;
binawasan ang dami ng puwang na inookupahan mula 1 TB hanggang 300 GB;
mayroon kaming kakayahang makatanggap ng 125 milyong sukatan kada minuto sa server (mga peak sa oras ng paglipat);
inilipat ang lahat ng sukatan sa tatlumpu't segundong pagitan ng imbakan;
nakatanggap ng pagtitiklop ng data at pagpapahintulot sa kasalanan;
lumipat nang walang downtime;
Tumagal ng humigit-kumulang 7 linggo upang makumpleto ang lahat.

Graphite+ClickHouse. Mga problema

Sa aming kaso, mayroong ilang mga pitfalls. Ito ang na-encounter namin pagkatapos ng transition.

Hindi palaging binabasa ng ClickHouse ang mga config nang mabilisan; minsan kailangan itong i-reboot. Halimbawa, sa kaso ng paglalarawan ng cluster ng zookeeper sa ClickHouse config, hindi ito ginamit hanggang sa na-reboot ang clickhouse-server.
Hindi natuloy ang malalaking kahilingan sa ClickHouse, kaya sa graphite-clickhouse ang aming ClickHouse connection string ay ganito ang hitsura:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
Ang ClickHouse ay madalas na naglalabas ng mga bagong bersyon ng mga stable na release; maaaring naglalaman ang mga ito ng mga sorpresa: mag-ingat.
Ang mga dynamic na ginawang container sa kubernetes ay nagpapadala ng malaking bilang ng mga sukatan na may maikli at random na panghabambuhay. Walang maraming puntos para sa mga naturang sukatan, at walang mga problema sa espasyo. Ngunit kapag gumagawa ng mga query, kumukuha ang ClickHouse ng malaking bilang ng mga parehong sukatan mula sa talahanayan ng 'mga sukatan'. Sa 90% ng mga kaso, walang data sa mga ito sa labas ng window (24 na oras). Ngunit ang oras ay ginugugol sa paghahanap para sa data na ito sa talahanayan ng 'data', at sa huli ay napupunta sa isang timeout. Upang malutas ang problemang ito, nagsimula kaming magpanatili ng isang hiwalay na view na may impormasyon sa mga sukatan na nakatagpo sa araw. Kaya, kapag gumagawa ng mga ulat (mga graph) para sa mga dynamic na ginawang container, itatanong lang namin ang mga sukatan na nakatagpo sa loob ng isang partikular na window, at hindi sa buong panahon, na makabuluhang nagpabilis sa pagbuo ng mga ulat sa mga ito. Para sa solusyon na inilarawan sa itaas, nakolekta ko graphite-clickhouse (tinidor), na kinabibilangan ng pagpapatupad ng pagtatrabaho sa talahanayan ng date_metrics.

Graphite+ClickHouse. Mga tag

Sa bersyon 1.1.0 naging opisyal ang Graphite mga tag ng suporta. At kami ay aktibong nag-iisip tungkol sa kung ano at paano gawin upang suportahan ang inisyatiba sa graphite+clickhouse stack.

Graphite+ClickHouse. Detektor ng anomalya

Batay sa imprastraktura na inilarawan sa itaas, nagpatupad kami ng prototype ng isang anomaly detector, at gumagana ito! Ngunit higit pa tungkol sa kanya sa susunod na artikulo.

Mag-subscribe, pindutin ang pataas na arrow at maging masaya!

Pinagmulan: www.habr.com

Imbakan ng mga sukatan: kung paano kami lumipat mula sa Graphite+Whisper patungo sa Graphite+ClickHouse