سلام و ټولو ته! په هغه کې وروستنی مقاله ما د مایکرو سرویس معمارۍ لپاره د ماډلر نظارت سیسټم تنظیم کولو په اړه لیکلي. هیڅ شی لاهم ولاړ نه دی، زموږ پروژه په دوامداره توګه وده کوي، او همدا ډول د ذخیره شوي میټریکونو شمیر دی. موږ څنګه د ګرافیت + ویسپر څخه ګرافیټ + کلیک هاؤس ته د لوړ بار شرایطو لاندې لیږد تنظیم کړ ، له دې څخه د توقعاتو او د کټ لاندې د مهاجرت پایلو په اړه ولولئ.

مخکې لدې چې زه تاسو ته ووایم چې موږ څنګه په ګرافیت + ویسپر کې د میټریکونو ذخیره کولو څخه ګرافیټ + کلیک هاؤس ته لیږد تنظیم کړ ، زه غواړم د داسې پریکړې کولو دلایلو او د ویسپر زیانونو په اړه معلومات ورکړم چې موږ یې د اوږدې مودې لپاره ژوند کاوه.

ګرافیت + ویسپر ستونزې

1. د ډیسک په فرعي سیسټم کې لوړ بار

د لیږد په وخت کې، نږدې 1.5 ملیون میټریکونه په یوه دقیقه کې موږ ته رسیدلي. د دې ډول جریان سره، په سرورونو کې د ډیسک کارول ~ 30٪ وو. په عموم کې، دا خورا د منلو وړ و - هر څه په ثابت ډول کار کاوه، په چټکۍ سره لیکل شوي، په چټکۍ سره لوستل شوي ... تر هغه چې د پراختیایي ټیمونو څخه یوه یوه نوې ځانګړتیا جوړه کړه او موږ ته یې په یوه دقیقه کې 10 ملیون میټریکونه لیږل پیل کړل. دا هغه وخت دی چې د ډیسک فرعي سیسټم سخت شو، او موږ د 100٪ کارول ولیدل. ستونزه په چټکۍ سره حل شوه، مګر پاتې شونی پاتې شو.

2. د تکرار او دوام نشتوالی

ډیری احتمال، د هر چا په څیر چې د ګرافیت + ویسپر کاروي / کاروي، موږ د غلطۍ زغم رامینځته کولو لپاره په یوځل کې په څو ګرافیټ سرورونو کې ورته میټریکونه واچول. او پدې کې کومه ځانګړې ستونزه شتون نلري - تر هغه وخته پورې چې یو سرور د کوم دلیل لپاره سقوط وکړ. ځینې وختونه موږ اداره کولی شو چې یو راټیټ شوی سرور په کافي اندازه په چټکۍ سره پورته کړو، او کاربن-سي-ریلي په دې کې د دې زیرمې څخه میټریکونو بارولو توان درلود، مګر ځینې وختونه نه. او بیا په میټریک کې یو سوری و، کوم چې موږ د rsync سره ډک کړ. کړنلاره خورا اوږده وه. د ژغورنې یوازینۍ فضل دا و چې دا خورا لږ پیښ شوي. موږ هم په دوره توګه د میټریکونو تصادفي سیټ اخیستو او د کلستر په ګاونډیو نوډونو کې د ورته ډول نورو سره پرتله کوو. په 5٪ قضیو کې، ډیری ارزښتونه توپیر درلود، کوم چې موږ یې په اړه ډیر خوښ نه یو.

3. لوی پښه نښه

له هغه ځایه چې موږ په ګرافیټ کې نه یوازې زیربنا لیکو ، بلکه د سوداګرۍ میټریکونه (او اوس د کوبرنیټس څخه میټریکونه هم) ، موږ ډیری وختونه داسې حالت ترلاسه کوو چې میټریک یوازې یو څو ارزښتونه لري ، او د .wsp فایل ټول ساتل په پام کې نیولو سره رامینځته کیږي. موده، او د مخکینۍ تخصیص اندازه ځای نیسي، کوم چې زموږ لپاره ~ 2MB و. ستونزه د دې حقیقت له امله نوره هم پراخه شوې چې د وخت په تیریدو سره ورته ډیری فایلونه څرګندیږي ، او کله چې په دوی باندې راپورونه رامینځته کوي ، د خالي ټکو لوستل ډیر وخت او سرچینې اخلي.

زه غواړم سمدلاسه یادونه وکړم چې پورته ذکر شوي ستونزې د مختلف میتودونو په کارولو او د تاثیر مختلف درجو سره معامله کیدی شي ، مګر هرڅومره چې تاسو ترلاسه کول پیل کړئ ، هومره یې خرابیږي.

د پورته ټولو درلودل (پخواني په پام کې نیولو سره مقالې) ، په بیله بیا د ترلاسه شوي میټریکونو شمیر کې دوامداره زیاتوالی ، د 30 ثانیو ذخیره کولو وقفې ته د ټولو میټریکونو لیږدولو هیله. (د اړتیا په صورت کې تر 10 ثانیو پورې)، موږ پریکړه وکړه چې د ویسپر لپاره د امید لرونکي بدیل په توګه ګرافیت + کلیک هاوس هڅه وکړو.

Graphite+ClickHouse. توقعات

د Yandex څخه د هلکانو څو غونډو څخه لیدنه، لوستل د هابري په اړه یو څو مقالې، د اسنادو له لارې تیریدلو او د ګرافیټ لاندې د کلک هاوس د پابندولو لپاره سمې برخې وموندلې ، موږ پریکړه وکړه چې اقدام وکړو!

زه غواړم لاندې ترلاسه کړم:

د ډیسک فرعي سیسټم کارول له 30٪ څخه 5٪ ته راکم کړئ؛
د نیول شوي ځای مقدار له 1TB څخه 100GB ته کم کړئ؛
په سرور کې په هره دقیقه کې د 100 ملیون میټریک ترلاسه کولو وړتیا؛
د بکس څخه بهر د معلوماتو نقل او د خطا زغم؛
د یو کال لپاره په دې پروژه کې مه کېږئ او په مناسب وخت کې لیږد ترسره کړئ؛
پرته له ځنډ څخه بدل کړئ.

ډیر هوښیار، سمه ده؟

Graphite+ClickHouse. اجزا

د ګرافیټ پروتوکول له لارې د معلوماتو ترلاسه کولو لپاره او وروسته یې په کلیک هاوس کې ثبت کړئ ، ما غوره کړه د کاربن کلک هاؤس (ګولنګ).

د ClickHouse وروستی خپور شوی، مستحکم نسخه 1.1.54253، د وخت لړۍ ذخیره کولو لپاره د ډیټابیس په توګه غوره شوی. د دې سره د کار کولو په وخت کې ستونزې شتون درلود: د غلطیو غره په لوګو کې اچول شوي، او دا په بشپړه توګه روښانه نه وه چې د دوی سره څه وکړي. سره په خبرو اترو کې رومن لومونوسوف (د کاربن-کلک هاؤس لیکوال، ګرافیټ-کلک هاؤس او ډیری نور) زوړ غوره شوی و خوشې کول 1.1.54236. تېروتنې ورکې شوې - هرڅه د بنګ سره کار پیل کړ.

د کلیک هاوس څخه د معلوماتو لوستلو لپاره غوره شوی ګرافیت-سلیک هاؤس (ګولنګ). د ګرافیت لپاره د API په توګه - کاربوناپي (ګولنګ). ClickHouse د میزونو تر مینځ د نقل تنظیم کولو لپاره کارول کیده د ژوبڼ د. د روټینګ میټریکونو لپاره، موږ خپل محبوب پریښود کاربن-c-ریلی (سره) (پخوانۍ مقاله وګورئ).

Graphite+ClickHouse. د میز جوړښت

"ګرافائٹ" یو ډیټابیس دی چې موږ د څارنې میزونو لپاره رامینځته کړی.

"graphite.metrics" - جدول د ReplicatedReplacingMergeTree انجن سره (نقل شوی دMergeTree ځای په ځای کول). دا جدول د میټریکونو نومونه او دوی ته د لارو ذخیره کوي.

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" - جدول د ReplicatedGraphiteMergeTree انجن سره (نقل شوی GraphiteMergeTree). دا جدول میټریک ارزښتونه ذخیره کوي.

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" د ReplicatedReplacingMergeTree انجن سره په مشروط ډول ډک شوی جدول دی. دا جدول د ټولو میټریکونو نومونه ثبتوي چې د ورځې په اوږدو کې ورسره مخ شوي. د هغې د جوړولو لاملونه په برخه کې تشریح شوي "ستونزې" د دې مقالې په پای کې.

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" - یو جدول د حالت سره سم ډک شوی، د ReplicatedAggregatingMergeTree انجن سره (نقل شوی AggregatingMergeTree). دا جدول د راتلونکو میټریکونو شمیر ثبتوي، چې د 4 ځالې کچې ته ویشل شوي.

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. د اجزاو تعامل ډیاګرام

Graphite+ClickHouse. د معلوماتو مهاجرت

لکه څنګه چې موږ د دې پروژې څخه د توقعاتو څخه یادونه کوو، ClickHouse ته لیږد باید پرته له ځنډ څخه وي؛ په دې اساس، موږ باید په یو ډول زموږ د څارنې سیسټم نوي ذخیره ته واړوو څومره چې زموږ د کاروونکو لپاره په شفاف ډول ممکن وي.
دا موږ څنګه وکړل.

په کاربن-سي-ریلي کې یو قاعده اضافه شوې ترڅو د یو سرور کاربن کلیک هاؤس ته د میټریک اضافي جریان واستوي چې د ClickHouse جدولونو په عکس العمل کې برخه اخلي.
موږ په python کې یو کوچنی سکریپټ ولیکه، کوم چې د whisper-dump کتابتون په کارولو سره، زموږ د ذخیره کولو څخه ټول .wsp فایلونه لوستل او دا ډاټا په 24 تارونو کې پورته تشریح شوي کاربن کلیک هاوس ته لیږل. په کاربن-کلک هاؤس کې د منل شوي میټریک ارزښتونو شمیر 125 ملیون / دقیقې ته رسیدلی ، او کلیک هاوس حتی خوله نه ماتوي.
موږ په ګرافانا کې یو جلا ډیټا سرچینه رامینځته کړې ترڅو په موجوده ډشبورډونو کې کارول شوي افعال ډیبګ کړي. موږ د دندو لیست په ګوته کړ چې موږ یې کاروو، مګر دوی په کاربوناپي کې ندي پلي شوي. موږ دا دندې اضافه کړې او د کاربونپي لیکوالانو ته یې PRs لیږلي (د دوی څخه ځانګړې مننه).
د توازن په ترتیباتو کې د لوستلو بار بدلولو لپاره، موږ پای ټکي د ګرافیت-api (د ګرافیت + ویسپر لپاره API انٹرفیس) څخه کاربوناپي ته بدل کړل.

Graphite+ClickHouse. پایلې

د ډیسک فرعي سیسټم کارول له 30٪ څخه 1٪ ته راټیټ شوي؛
د نیول شوي ځای مقدار له 1 TB څخه 300 GB ته راکم کړئ؛
موږ د دې وړتیا لرو چې سرور ته په یوه دقیقه کې 125 ملیون میټریکونه ترلاسه کړو (د مهاجرت په وخت کې لوړوالی)؛
ټول میټریکونه د دېرش ثانیې ذخیره کولو وقفې ته لیږدول شوي؛
د معلوماتو نقل او د خطا زغم ترلاسه کړی؛
پرته له ځنډ څخه بدل شوی؛
د هرڅه بشپړولو لپاره شاوخوا 7 اونۍ وخت ونیو.

Graphite+ClickHouse. ستونزې

زموږ په قضیه کې، ځینې نیمګړتیاوې وې. دا هغه څه دي چې موږ د لیږد وروسته ورسره مخ شو.

ClickHouse تل په الوتنه کې تشکیلات بیا نه لوستل کیږي؛ ځینې وختونه دا اړتیا لري چې ریبوټ شي. د مثال په توګه، په ClickHouse ترتیب کې د زوکیپر کلستر د توضیح په صورت کې، دا تر هغه وخته پورې نه کارول کیده چې د کلک هاؤس سرور ریبوټ شوی وي.
د کلک هاؤس لویې غوښتنې نه دي تیر شوي، نو په ګرافیټ-کلک هاؤس کې زموږ د کلیک هاوس پیوستون تار داسې ښکاري:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ClickHouse ډیری وختونه د مستحکم ریلیزونو نوې نسخې خپروي؛ دوی ممکن حیرانتیا ولري: محتاط اوسئ.
په کبرنیټس کې په متحرک ډول جوړ شوي کانټینرونه د لنډ او تصادفي ژوند سره لوی شمیر میټریکونه لیږي. د داسې میترونو لپاره ډیری ټکي شتون نلري، او د ځای سره کومه ستونزه شتون نلري. مګر کله چې د پوښتنو رامینځته کول، کلیک هاوس د ورته میټریکونو لوی شمیر د 'میټریک' میز څخه غوره کوي. په 90٪ قضیو کې، د کړکۍ (24 ساعتونو) څخه وروسته د دوی په اړه هیڅ معلومات شتون نلري. مګر وخت په 'ډیټا' جدول کې د دې ډیټا په لټون کې تیریږي ، او په نهایت کې د وخت پای ته رسیږي. د دې ستونزې د حل لپاره، موږ د میټریکونو معلوماتو سره چې د ورځې په جریان کې ورسره مخ شوي یو جلا لید ساتل پیل کړل. په دې توګه، کله چې په متحرک ډول جوړ شوي کانټینرونو لپاره راپورونه (ګرافونه) جوړ کړئ، موږ یوازې هغه میټریکونه پوښو چې په یوه کړکۍ کې ورسره مخ شوي، نه د ټول وخت لپاره، کوم چې په دوی باندې د راپورونو جوړول د پام وړ چټک کړي. د پورته بیان شوي حل لپاره، ما راټول کړل ګرافیت-کلک هاوس (فورک)، کوم چې د date_metrics جدول سره د کار کولو پلي کول شامل دي.

Graphite+ClickHouse. ټګونه

د 1.1.0 نسخه سره ګرافیټ رسمي شو د ملاتړ ټګونه. او موږ په فعاله توګه د دې په اړه فکر کوو چې څه او څنګه د دې نوښت ملاتړ کولو لپاره په ګرافیټ + کلیک هاوس سټیک کې.

Graphite+ClickHouse. د بې نظمۍ کشف کونکی

د پورته بیان شوي زیربنا پراساس ، موږ د انومالي کشف کونکي پروټوټایپ پلي کړی ، او دا کار کوي! مګر په راتلونکی مقاله کې د هغه په اړه نور.

ګډون وکړئ، پورته تیر فشار ورکړئ او خوشحاله اوسئ!

سرچینه: www.habr.com

د میټریک ذخیره: څنګه موږ له ګرافیت + ویسپر څخه ګرافیټ + کلیک هاوس ته بدل شو