هيلو سڀ! هن جي آخري مضمون مون مائڪرو سروس آرڪيٽيڪچر لاءِ ماڊلر مانيٽرنگ سسٽم کي منظم ڪرڻ بابت لکيو. ڪجھ به نه بيٺو آھي، اسان جو منصوبو مسلسل وڌي رھيو آھي، ۽ ائين ئي ذخيرو ٿيل ميٽرڪ جو تعداد آھي. ڪيئن اسان Graphite+Whisper کان Graphite+ClickHouse ڏانهن منتقلي کي تيز لوڊ حالتن ۾ منظم ڪيو، ان مان اميدن بابت پڙهو ۽ ڪٽ هيٺ لڏپلاڻ جا نتيجا.

ان کان اڳ جو مان توهان کي ٻڌايان ته ڪيئن اسان Graphite+Whisper کان Graphite+ClickHouse ۾ ميٽرڪ کي محفوظ ڪرڻ جي منتقلي کي منظم ڪيو، مان اهڙو فيصلو ڪرڻ جي سببن ۽ ويسپر جي نقصانن بابت معلومات ڏيڻ چاهيان ٿو جن سان اسان گهڻي وقت تائين رهندا هئاسين.

Graphite+Whisper مسئلا

1. ڊسڪ سب سسٽم تي اعلي لوڊ

منتقلي جي وقت، تقريبن 1.5 ملين ميٽرڪ في منٽ اسان وٽ پهچي رهيا هئا. اهڙي وهڪري سان، سرور تي ڊسڪ استعمال ڪيو ويو ~ 30٪. عام طور تي، اهو ڪافي قابل قبول هو - هر شيءِ مستحڪم طور تي ڪم ڪيو، جلدي لکيو ويو، جلدي پڙهيو ويو... تيستائين ترقي ٽيمن مان هڪ هڪ نئين خصوصيت کي رول آئوٽ ڪيو ۽ اسان کي 10 ملين ميٽرڪ في منٽ موڪلڻ شروع ڪيو. اھو آھي جڏھن ڊسڪ سب سسٽم سخت ٿي ويو، ۽ اسان ڏٺو 100٪ استعمال. مسئلو جلدي حل ڪيو ويو، پر باقي رهي.

2. نقل ۽ تسلسل جي کوٽ

گهڻو ڪري، هر ڪنهن وانگر، جيڪو Graphite+Whisper استعمال ڪري ٿو/استعمال ڪري ٿو، اسان هڪ ئي وقت ڪيترن ئي گرافائٽ سرورز تي ميٽرڪ جو ساڳيو وهڪرو وجهي ڇڏيو آهي ته جيئن غلطي رواداري پيدا ٿئي. ۽ ان سان گڏ ڪي خاص مسئلا نه هئا - ان وقت تائين جڏهن سرورن مان هڪ ڪنهن سبب ڪري تباهه ٿي ويو. ڪڏهن ڪڏهن اسان هڪ گريل سرور کي ڪافي جلدي کڻڻ جو انتظام ڪيو، ۽ ڪاربن-سي-رلي ان جي ڪيش مان ميٽرڪ لوڊ ڪرڻ ۾ منظم ڪيو، پر ڪڏهن ڪڏهن نه. ۽ پوءِ ميٽرڪ ۾ ھڪڙو سوراخ ھو، جنھن کي اسان rsync سان ڀريو. عمل ڪافي ڊگهو هو. صرف بچاءُ وارو فضل اهو هو ته اهو تمام گهٽ ٿيو. اسان وقتي طور تي ميٽرڪ جو هڪ بي ترتيب سيٽ پڻ ورتو ۽ انهن جي مقابلي ۾ ٻين ساڳين جي ڪلستر جي پاڙيسري نوڊس تي. اٽڪل 5٪ ڪيسن ۾، ڪيترائي قدر مختلف هئا، جن بابت اسان بلڪل خوش نه هئاسين.

3. وڏي پيرن جو نشان

جيئن ته اسان گرافائٽ ۾ لکون ٿا نه رڳو انفراسٽرڪچر، پر ڪاروباري ميٽرڪس (۽ هاڻي پڻ ڪبرنيٽس مان ميٽرڪ)، اسان کي اڪثر اهڙي صورتحال ملندي آهي جنهن ۾ ميٽرڪ صرف چند قدرن تي مشتمل هوندي آهي، ۽ .wsp فائل ٺاهي ويندي آهي سڀني برقرار رکڻ کي مدنظر رکندي. عرصو، ۽ اڳ ۾ مختص ڪيل جاءِ وٺي ٿو، جيڪا اسان لاءِ ~ 2MB هئي. مسئلو اڃا به وڌيڪ بگڙيل آهي حقيقت اها آهي ته ڪيتريون ئي فائلون وقت سان گڏ ظاهر ٿيندا آهن، ۽ جڏهن انهن تي رپورٽون ٺاهي رهيا آهن، خالي پوائنٽ پڙهڻ ۾ گهڻو وقت ۽ وسيلا لڳن ٿا.

مان فوري طور تي نوٽ ڪرڻ چاهيان ٿو ته مٿي بيان ڪيل مسئلن کي مختلف طريقن سان استعمال ڪندي ۽ اثر جي مختلف درجي سان حل ڪري سگهجي ٿو، پر وڌيڪ ڊيٽا توهان کي حاصل ڪرڻ شروع ڪيو، وڌيڪ اهي وڌيڪ خراب ٿيندا.

مٿين سڀني کي حاصل ڪرڻ (اڳوڻي حساب سان مضمون)، انهي سان گڏ حاصل ڪيل ميٽرڪ جي تعداد ۾ مسلسل اضافو، سڀني ميٽرڪ کي 30 سيڪنڊن جي اسٽوريج وقفي تائين منتقل ڪرڻ جي خواهش. (جيڪڏهن ضروري هجي ته 10 سيڪنڊن تائين)، اسان ڪوشش ڪرڻ جو فيصلو ڪيو Graphite+ClickHouse کي ويسپر لاءِ هڪ پرعزم متبادل طور.

Graphite+ClickHouse. اميدون

Yandex جي ماڻهن جي ڪيترن ئي ملاقاتن جو دورو ڪيو، پڙهڻ کان پوء Habré تي ڪجهه مضمون, دستاويزن جي ذريعي وڃڻ ۽ Graphite جي تحت ClickHouse کي پابند ڪرڻ لاء سمجھدار اجزاء مليو، اسان قدم کڻڻ جو فيصلو ڪيو!

مان ھيٺ ڏنل حاصل ڪرڻ چاھيان ٿو:

ڊسڪ سب سسٽم جي استعمال کي 30٪ کان 5٪ تائين گھٽايو؛
1TB کان 100GB تائين قبضي واري جاء جي مقدار کي گھٽايو؛
حاصل ڪرڻ جي قابل ٿي 100 ملين ميٽرڪ في منٽ سرور ۾؛
ڊيٽا جي نقل ۽ دٻي کان ٻاهر غلطي رواداري؛
هڪ سال تائين هن منصوبي تي نه ويهڻ ۽ هڪ مناسب وقت جي فريم اندر منتقلي ڪر؛
بغير دير جي وقت کي تبديل ڪريو.

ڪافي امڪاني، صحيح؟

Graphite+ClickHouse. اجزاء

Graphite پروٽوڪول ذريعي ڊيٽا حاصل ڪرڻ ۽ بعد ۾ ان کي ClickHouse ۾ رڪارڊ ڪرڻ لاءِ، مون چونڊيو ڪاربان-ڪلڪ هائوس (گولنگ).

ClickHouse جو تازو رليز، مستحڪم نسخو 1.1.54253، چونڊيو ويو ڊيٽابيس جي طور تي اسٽوريج ٽائيم سيريز لاءِ. ان سان گڏ ڪم ڪرڻ وقت مسئلا هئا: غلطين جو هڪ جبل لاگ ان ۾ داخل ٿيو، ۽ اهو مڪمل طور تي واضح ناهي ته انهن سان ڇا ڪجي. سان بحث ۾ رومن Lomonosov (ڪاربن-ڪلڪ هاؤس، گرافائٽ-ڪلڪ هاؤس ۽ گھڻن، گھڻن جو ليکڪ) پراڻو چونڊيو ويو ڇڏڻ 1.1.54236. غلطيون غائب ٿي - سڀڪنھن شيء کي هڪ ڌماڪي سان ڪم ڪرڻ لڳو.

ClickHouse مان ڊيٽا پڙهڻ لاءِ چونڊيو ويو graphite-clickhouse (گولنگ). Graphite - لاء API جي طور تي ڪاربنپي (گولنگ). ClickHouse ٽيبل جي وچ ۾ نقل کي منظم ڪرڻ لاء استعمال ڪيو ويو جانورن جو ڪاروبار. رستي جي ميٽرڪ لاء، اسان پنهنجي محبوب کي ڇڏي ڏنو ڪاربان-سي-رلي (سان) (اڳيون مضمون ڏسو).

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

ReplicatedReplacingMergeTree انجڻ سان "graphite.date_metrics" شرطن سان ڀريل ٽيبل آھي. هي ٽيبل انهن سڀني ميٽرڪ جا نالا رڪارڊ ڪري ٿو جيڪي ڏينهن دوران سامهون آيا هئا. ان جي پيدائش جا سبب هن حصي ۾ بيان ڪيا ويا آهن "مسئلا" هن مضمون جي آخر ۾.

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 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. اجزاء جي رابطي جو خاڪو

Graphite+ClickHouse. ڊيٽا جي منتقلي

جيئن ته اسان کي ياد آهي ته هن پروجيڪٽ جي اميدن کان، ClickHouse ڏانهن منتقلي بغير وقت جي ٿيڻ گهرجي؛ ان جي مطابق، اسان کي ڪنهن نه ڪنهن طرح اسان جي استعمال ڪندڙن لاء شفاف طور تي نئين اسٽوريج ڏانهن اسان جي نگراني سسٽم کي تبديل ڪرڻو پوندو.
اسان اهو ڪيئن ڪيو.

هڪ قاعدو ڪاربن-سي-رلي ۾ شامل ڪيو ويو آهي ميٽرڪس جو اضافي وهڪرو ڪاربان-ڪلڪ هائوس ڏانهن موڪلڻ لاءِ هڪ سرور جي ڪلڪ هاؤس ٽيبل جي نقل ۾ حصو وٺندڙ.
اسان python ۾ هڪ ننڍڙو اسڪرپٽ لکيو، جيڪو، ويسپر-ڊمپ لائبريري استعمال ڪندي، اسان جي اسٽوريج مان سڀني .wsp فائلن کي پڙهي ۽ هن ڊيٽا کي 24 موضوعن ۾ مٿي بيان ڪيل ڪاربان-ڪلڪ هائوس ڏانهن موڪليو. ڪاربان-ڪلڪ هاؤس ۾ قبول ٿيل ميٽرڪ ويلن جو تعداد 125 ملين/منٽ تائين پهچي ويو، ۽ ClickHouse هڪ پسي به نه ڇڏيو.
اسان موجوده ڊيش بورڊز ۾ استعمال ٿيندڙ ڪمن کي ڊيبگ ڪرڻ لاءِ Grafana ۾ هڪ الڳ ڊيٽا سورس ٺاهيو. اسان ھڪڙي فهرست جي نشاندهي ڪئي آھي جيڪي اسان استعمال ڪيا آھن، پر انھن کي ڪاربنپي ۾ لاڳو نه ڪيو ويو آھي. اسان انهن ڪمن کي شامل ڪيو ۽ ڪاربنپي جي ليکڪن ڏانهن پي آر موڪليا (انهن لاء خاص مهرباني).
توازن واري سيٽنگن ۾ پڙهڻ واري لوڊ کي تبديل ڪرڻ لاءِ، اسان graphite-api (Graphite+Whisper لاءِ API انٽرفيس) کان ڪاربنپي ۾ آخري پوائنٽون تبديل ڪيون.

Graphite+ClickHouse. نتيجا

ڊسڪ سب سسٽم جي استعمال کي 30٪ کان 1٪ تائين گھٽايو؛
1 TB کان 300 GB تائين قبضي واري جاء جي مقدار کي گھٽايو؛
اسان وٽ سرور ۾ 125 ملين ميٽرڪ في منٽ وصول ڪرڻ جي صلاحيت آهي (لڏپلاڻ جي وقت جي چوٽي)؛
سڀني ميٽرڪ کي ٽيٽي سيڪنڊ اسٽوريج وقفي تي منتقل ڪيو؛
حاصل ڪيل ڊيٽا نقل ۽ غلطي رواداري؛
بند ٿيڻ کان سواءِ تبديل ٿيل؛
اهو سڀ ڪجهه مڪمل ڪرڻ ۾ اٽڪل 7 هفتا لڳا.

Graphite+ClickHouse. مسئلا

اسان جي معاملي ۾، اتي ڪجهه نقصان هئا. اھو اھو آھي جيڪو اسان کي منتقلي کان پوء سامھون ٿيو.

ڪلڪ هائوس هميشه اڏام تي ترتيبن کي ٻيهر نه ٿو پڙهي؛ ڪڏهن ڪڏهن ان کي ريبوٽ ڪرڻ جي ضرورت آهي. مثال طور، ClickHouse config ۾ زوڪيپر ڪلستر جي وضاحت جي صورت ۾، اهو استعمال نه ڪيو ويو جيستائين ڪلڪ هاؤس-سرور کي ريبوٽ ڪيو ويو.
وڏي ClickHouse درخواستون نه ٿيون گذريون، تنهنڪري graphite-clickhouse ۾ اسان جي ClickHouse ڪنيڪشن جي تار هن طرح نظر اچي ٿي:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
ڪلڪ هاؤس اڪثر ڪري مستحڪم رليز جا نوان ورزن جاري ڪري ٿو؛ انهن ۾ حيران ٿي سگھي ٿو: محتاط رھو.
kubernetes ۾ متحرڪ طور تي ٺاهيل ڪنٽينرز هڪ مختصر ۽ بي ترتيب واري زندگي سان گڏ ميٽرڪس جو وڏو تعداد موڪلي ٿو. اهڙا ڪيترائي نقطا نه آهن انهن ميٽرڪس لاء، ۽ نه ئي خلا سان ڪو مسئلو آهي. پر جڏهن سوالن جي تعمير ڪريو، ڪلڪ هائوس 'ميٽرڪس' ٽيبل مان انهن ساڳين ميٽرن جو وڏو تعداد کڻندو آهي. 90٪ ڪيسن ۾، ونڊو (24 ڪلاڪ) کان ٻاهر انهن تي ڪوبه ڊيٽا ناهي. پر وقت هن ڊيٽا کي 'ڊيٽا' جدول ۾ ڳولڻ ۾ خرچ ڪيو ويندو آهي، ۽ آخرڪار هڪ وقت ختم ٿي ويندو آهي. هن مسئلي کي حل ڪرڻ لاء، اسان ميٽرڪ تي معلومات سان گڏ هڪ الڳ نظر برقرار رکڻ شروع ڪيو جيڪي ڏينهن جي دوران سامهون آيا هئا. اهڙيءَ طرح، جڏهن متحرڪ طور تي ٺاهيل ڪنٽينرز لاءِ رپورٽون (گرافس) ٺاهيندا آهيون، اسان صرف انهن ميٽرڪس بابت سوال ڪندا آهيون جيڪي هڪ ڏنل ونڊو ۾ سامهون آيا هئا، ۽ نه پوري وقت لاءِ، جن انهن تي رپورٽن جي تعمير کي خاص طور تي تيز ڪيو. مٿي بيان ڪيل حل لاء، مون گڏ ڪيو گرافائٽ-ڪلڪ هائوس (ڪنڊو)، جنهن ۾ شامل آهي تاريخ_ميٽرڪس ٽيبل سان ڪم ڪرڻ جو عمل.

Graphite+ClickHouse. ٽيگ

نسخو 1.1.0 سان Graphite سرڪاري ٿيو سپورٽ ٽيگ. ۽ اسان فعال طور تي سوچي رهيا آهيون ته ڇا ڪجي ۽ ڪيئن ڪجي انهي شروعات کي سپورٽ ڪرڻ لاءِ graphite+clickhouse اسٽيڪ ۾.

Graphite+ClickHouse. انمولي ڊيڪٽر

مٿي بيان ڪيل بنيادي ڍانچي جي بنياد تي، اسان هڪ پروٽوٽائپ لاڳو ڪيو آهي هڪ انوملي ڊيڪٽر جو، ۽ اهو ڪم ڪري ٿو! پر ايندڙ مضمون ۾ هن جي باري ۾ وڌيڪ.

رڪنيت حاصل ڪريو، مٿي تير کي دٻايو ۽ خوش ٿيو!

جو ذريعو: www.habr.com

ميٽرڪ اسٽوريج: اسان ڪيئن تبديل ڪيو Graphite+Whisper کان Graphite+ClickHouse