مضمون جو ترجمو خاص طور تي ڪورس جي شاگردن لاء تيار ڪيو ويو .
هڪ سافٽ ويئر ڊولپر آهي، گو جنوني، ۽ مسئلو حل ڪندڙ. هو هڪ پروميٿيس سنڀاليندڙ ۽ ڪبرنيٽس SIG اوزار جو ڪو باني پڻ آهي. ماضي ۾، هو SoundCloud تي هڪ پيداوار انجنيئر هو ۽ CoreOS تي نگراني ٽيم جي اڳواڻي ڪئي. في الحال گوگل تي ڪم ڪري ٿو.
- Improbable تي انفراسٽرڪچر انجنيئر. هن نئين ٽيڪنالاجي ۽ تقسيم نظام جي مسئلن ۾ دلچسپي آهي. هن وٽ Intel تي گهٽ سطحي پروگرامنگ جو تجربو، Mesos ۾ مددگار تجربو، ۽ Improbable تي عالمي سطح جي SRE پيداوار جو تجربو آهي. مائڪرو سروسز جي دنيا کي بهتر بڻائڻ لاءِ وقف. سندس ٽي پيار: گولانگ، اوپن سورس ۽ والي بال.
اسان جي پرچم بردار پراڊڪٽ SpatialOS کي ڏسي، توهان اندازو لڳائي سگهو ٿا ته Improbable کي ڪيترن ئي ڪبرنيٽس ڪلسٽرن سان گڏ انتهائي متحرڪ، عالمي سطح تي ڪلائوڊ انفراسٽرڪچر جي ضرورت آهي. اسان هڪ مانيٽرنگ سسٽم استعمال ڪرڻ وارن مان هئاسين . Prometheus حقيقي وقت ۾ لکين ميٽرڪس کي ٽريڪ ڪرڻ جي قابل آهي ۽ هڪ طاقتور سوال جي ٻولي سان گڏ اچي ٿو جيڪا توهان کي گهربل معلومات ڪڍڻ جي اجازت ڏئي ٿي.
Prometheus جي سادگي ۽ reliability ان جي مکيه فائدن مان هڪ آهي. بهرحال، هڪ دفعو اسان هڪ خاص پيماني تي گذري ويا، اسان ڪيترن ئي خرابين کي منهن ڪيو. انهن مسئلن کي حل ڪرڻ لاءِ اسان ترقي ڪئي آهي ھڪڙو اوپن سورس پروجيڪٽ آھي جيڪو Improbable پاران ٺاھيو ويو آھي موجوده Prometheus ڪلسٽرز کي لامحدود تاريخي ڊيٽا اسٽوريج سان گڏ ھڪڙي نگراني نظام ۾ تبديل ڪرڻ لاءِ. Thanos Github تي موجود آهي .
Thanos سان اسان جا مقصد
هڪ خاص پيماني تي، مسئلا پيدا ٿين ٿا جيڪي وينلا پروميٿيس جي صلاحيتن کان ٻاهر آهن. تاريخي ڊيٽا جي پيٽابائيٽس کي معتبر ۽ اقتصادي طور تي ڪيئن محفوظ ڪجي؟ ڇا اهو ٿي سگهي ٿو بغير جوابي وقت جي سمجهوتو ڪرڻ کان؟ ڇا اهو ممڪن آهي ته هڪ واحد API درخواست سان مختلف Prometheus سرورز تي واقع سڀني ميٽرڪ تائين رسائي حاصل ڪجي؟ ڇا Prometheus HA استعمال ڪندي گڏ ڪيل نقل ڪيل ڊيٽا کي گڏ ڪرڻ جو ڪو طريقو آهي؟
انهن مسئلن کي حل ڪرڻ لاء، اسان Thanos ٺاهي. هيٺيان حصا بيان ڪري ٿو ته اسان انهن مسئلن کي ڪيئن پهچايو ۽ اسان جي مقصدن کي بيان ڪيو.
ڪيترن ئي Prometheus مثالن کان ڊيٽا پڇڻ (عالمي سوال)
Prometheus شارڊنگ لاء هڪ فنڪشنل طريقو پيش ڪري ٿو. ايستائين جو هڪ واحد پرومٿيوس سرور استعمال ڪندڙن کي افقي شارڊنگ جي پيچيدگين کان آزاد ڪرڻ لاءِ ڪافي اسڪيبلٽي فراهم ڪري ٿو تقريبن سڀني استعمال جي ڪيسن ۾.
جڏهن ته هي هڪ بهترين ڊيپلائيمينٽ ماڊل آهي، اهو اڪثر ڪري هڪ واحد API يا UI ذريعي مختلف Prometheus سرورز تي ڊيٽا تائين رسائي ڪرڻ ضروري آهي - هڪ عالمي ڏيک. يقينا، هڪ گرافانا پينل ۾ ڪيترن ئي سوالن کي ظاهر ڪرڻ ممڪن آهي، پر هر سوال صرف هڪ پروميٿيس سرور تي عمل ڪري سگهجي ٿو. ٻئي طرف، Thanos سان توهان سوال ڪري سگهو ٿا ۽ ڊيٽا گڏ ڪري سگهو ٿا ڪيترن ئي Prometheus سرورن کان ڇاڪاڻ ته اهي سڀئي هڪ واحد آخري نقطي کان رسائي لائق آهن.
اڳي، Improbable ۾ عالمي ڏيک حاصل ڪرڻ لاءِ، اسان پنهنجي Prometheus مثالن کي ڪيترن ئي سطحن ۾ منظم ڪيو . ان جو مطلب هڪ Prometheus ميٽا سرور ٺاهڻ آهي جيڪو هر ليف سرور مان ڪجهه ميٽرڪ گڏ ڪري ٿو.
اهو طريقو مسئلو ثابت ٿيو. ان جي نتيجي ۾ وڌيڪ پيچيده ٺاھ جوڙ، ناڪامي جي اضافي امڪاني نقطي جو اضافو، ۽ پيچيده ضابطن جي ايپليڪيشن کي يقيني بڻائڻ لاءِ ته وفاق جي آخري پوائنٽ صرف ڊيٽا حاصل ڪري ٿي جيڪا ان جي ضرورت آھي. ان کان علاوه، هن قسم جي فيڊريشن توهان کي هڪ حقيقي عالمي ڏيک حاصل ڪرڻ جي اجازت نه ڏيندو آهي، ڇاڪاڻ ته سڀ ڊيٽا هڪ واحد API درخواست کان دستياب ناهي.
هن سان ويجهي سان لاڳاپيل آهي اعلي دستيابي (HA) Prometheus سرورز تي گڏ ڪيل ڊيٽا جو هڪ متحد منظر. Prometheus'HA ماڊل آزاديءَ سان ٻه ڀيرا ڊيٽا گڏ ڪري ٿو، جيڪو ايترو سادو آهي، اهو آسان نه ٿي سگهي. بهرحال، ٻنهي اسٽريمز جي گڏيل ۽ نقل ٿيل ڏيک استعمال ڪرڻ تمام گهڻو آسان هوندو.
يقينا، ضرورت آهي انتهائي دستياب پروميٿيوس سرورز جي. Improbable تي، اسان منٽ في منٽ ڊيٽا جي نگراني کي واقعي سنجيدگي سان وٺون ٿا، پر هر ڪلستر ۾ هڪ پروميٿيوس مثال هجڻ ناڪامي جو هڪ واحد نقطو آهي. ڪنهن به ترتيب جي غلطي يا هارڊويئر ناڪامي ممڪن طور تي اهم ڊيٽا جي نقصان جي ڪري سگھي ٿي. جيتوڻيڪ هڪ سادي تعیناتي ميٽرڪ گڏ ڪرڻ ۾ معمولي رڪاوٽون پيدا ڪري سگهي ٿي ڇاڪاڻ ته ٻيهر شروع ٿي سگهي ٿو خاص طور تي اسڪراپنگ وقفي کان وڌيڪ.
تاريخي ڊيٽا جي قابل اعتماد اسٽوريج
سستا، تيز، ڊگھي مدت جي ميٽرڪ اسٽوريج اسان جو خواب آهي (گهڻا Prometheus استعمال ڪندڙن طرفان حصيداري ڪئي وئي). Improbable ۾، اسان کي مجبور ڪيو ويو ته ميٽرڪ برقرار رکڻ واري مدت کي نو ڏينهن تائين ترتيب ڏيو (پروميٿيس 1.8 لاءِ). اهو واضح حدون وڌائي ٿو ته اسان ڪيترو پوئتي ڏسي سگهون ٿا.
Prometheus 2.0 هن سلسلي ۾ بهتر ٿي چڪو آهي، ڇاڪاڻ ته ٽائيم سيريز جو تعداد هاڻي سرور جي مجموعي ڪارڪردگي تي اثر انداز نٿو ڪري (ڏسو. ). بهرحال، Prometheus ڊيٽا کي مقامي ڊسڪ تي ذخيرو ڪري ٿو. جيتوڻيڪ اعلي ڪارڪردگي ڊيٽا ڪمپريشن مقامي SSD استعمال کي خاص طور تي گهٽائي سگھي ٿو، آخرڪار اڃا تائين تاريخي ڊيٽا جي مقدار جي حد آهي جيڪا ذخيرو ٿي سگهي ٿي.
اضافي طور تي، Improbable تي اسان اعتماد، سادگي ۽ قيمت جو خيال رکون ٿا. وڏي مقامي ڊسڪ کي هلائڻ ۽ بيڪ اپ ڪرڻ وڌيڪ ڏکيو آهي. اهي وڌيڪ خرچ ڪن ٿا ۽ وڌيڪ بيڪ اپ اوزار جي ضرورت آهي، نتيجي ۾ غير ضروري پيچيدگي.
گھٽائڻ
هڪ دفعو اسان تاريخي ڊيٽا سان ڪم ڪرڻ شروع ڪيو، اسان محسوس ڪيو ته بگ-O سان بنيادي مشڪلاتون آهن جيڪي سوالن کي سست ۽ سست بڻائيندا آهن جيئن اسان ڊيٽا جي هفتن، مهينن ۽ سالن سان ڪم ڪندا آهيون.
ان مسئلي جو معياري حل هوندو (downsampling) - سگنل جي نموني جي تعدد کي گھٽائڻ. گھٽ نموني سان، اسان "اسڪيل ھيٺ" ڪري سگھون ٿا ھڪڙي وڏي وقت جي حد تائين ۽ ساڳين نمونن کي برقرار رکون ٿا، سوالن کي جواب ڏيڻ سان.
پراڻي ڊيٽا کي گھٽائڻ ڪنهن به ڊگهي مدي واري اسٽوريج حل جي هڪ ناگزير ضرورت آهي ۽ وينلا پروميٿيس جي دائري کان ٻاهر آهي.
اضافي مقصد
ٿانوس پروجيڪٽ جي اصل مقصدن مان هڪ هو ته ڪنهن به موجوده پروميٿيوس تنصيب سان بيحد ضم ٿي وڃي. ٻيو مقصد آسانيءَ سان آپريشن ۾ داخل ٿيڻ لاءِ گهٽ ۾ گهٽ رڪاوٽون هو. ڪنهن به انحصار کي ٻنهي ننڍن ۽ وڏن صارفين لاء آساني سان مطمئن ٿيڻ گهرجي، جنهن جو مطلب پڻ گهٽ بنيادي قيمت آهي.
Thanos فن تعمير
پوئين حصي ۾ اسان جي مقصدن کي لسٽ ڪرڻ کان پوء، اچو ته انهن ذريعي ڪم ڪريون ۽ ڏسو ته Thanos انهن مسئلن کي ڪيئن حل ڪري ٿو.
عالمي ڏيک
موجوده Prometheus مثالن جي چوٽي تي عالمي ڏيک حاصل ڪرڻ لاء، اسان کي سڀني سرورن لاء هڪ واحد درخواست داخلا پوائنٽ کي ڳنڍڻ جي ضرورت آهي. اھو اھو آھي جيڪو Thanos جزو ڪندو آھي. . اهو هر Prometheus سرور جي اڳيان لڳايو ويو آهي ۽ هڪ پراڪسي طور ڪم ڪري ٿو، مقامي Prometheus ڊيٽا کي gRPC اسٽور API ذريعي پيش ڪري ٿو، ٽائيم سيريز ڊيٽا کي ٽيگ ۽ وقت جي حد ذريعي ٻيهر حاصل ڪرڻ جي اجازت ڏئي ٿو.
ٻئي پاسي اسڪيل-آئوٽ، بي رياست Querier جزو آهي، جيڪو صرف معياري Prometheus HTTP API ذريعي PromQL سوالن جو جواب ڏيڻ کان ٿورو وڌيڪ آهي. Querier، Sidecar ۽ ٻين Thanos اجزاء ذريعي ڳالھ ٻولھ .
- Querier، هڪ درخواست حاصل ڪرڻ تي، لاڳاپيل اسٽور API سرور سان ڳنڍي ٿو، اهو آهي، اسان جي Sidecars سان ۽ لاڳاپيل Prometheus سرورز کان ٽائيم سيريز ڊيٽا حاصل ڪري ٿو.
- ان کان پوء، اهو جوابن کي گڏ ڪري ٿو ۽ انهن تي هڪ PromQL سوال تي عمل ڪري ٿو. Querier Prometheus HA سرورز کان ڌار ڌار ڊيٽا ۽ نقل ٿيل ڊيٽا ٻنهي کي ضم ڪري سگھي ٿو.
هي اسان جي پزل جو هڪ اهم ٽڪرو حل ڪري ٿو - الڳ ٿيل Prometheus سرورز مان ڊيٽا کي هڪ واحد ڏيک ۾ گڏ ڪرڻ. حقيقت ۾، Thanos صرف هن خصوصيت لاء استعمال ڪري سگهجي ٿو. موجوده Prometheus سرورز ۾ ڪا به تبديلي نه ڪرڻ جي ضرورت آهي!
لامحدود شيلف زندگي!
بهرحال، جلد يا بعد ۾ اسان ڊيٽا کي ذخيرو ڪرڻ چاهيون ٿا عام پروميٿيس برقرار رکڻ واري وقت کان ٻاهر. اسان تاريخي ڊيٽا کي ذخيرو ڪرڻ لاء اعتراض اسٽوريج چونڊيو. اهو وڏي پئماني تي موجود آهي ڪنهن به ڪلائوڊ سان گڏو گڏ آن-پريمسس ڊيٽا سينٽرن ۾ ۽ تمام قيمتي اثرائتو آهي. ان کان سواء، تقريبا ڪنهن به اعتراض اسٽوريج موجود آهي معروف S3 API ذريعي.
Prometheus تقريباً هر ٻن ڪلاڪن ۾ ريم کان ڊسڪ تائين ڊيٽا لکي ٿو. ذخيرو ٿيل ڊيٽا بلاڪ سڀني ڊيٽا تي مشتمل آهي هڪ مقرر وقت لاءِ ۽ غير بدلائيندڙ آهي. اهو تمام آسان آهي ڇاڪاڻ ته Thanos Sidecar صرف پروميٿيس ڊيٽا ڊاريڪٽري کي ڏسي سگهي ٿو ۽، جيئن نوان بلاڪ موجود آهن، انهن کي اعتراض اسٽوريج بالٽ ۾ لوڊ ڪريو.
ڊسڪ تي لکڻ کان پوء فوري طور تي اعتراض اسٽوريج ۾ لوڊ ڪرڻ پڻ توهان کي اسڪراپر جي سادگي کي برقرار رکڻ جي اجازت ڏئي ٿو (Prometheus ۽ Thanos Sidecar). جيڪو سپورٽ، قيمت ۽ سسٽم ڊيزائن کي آسان بڻائي ٿو.
توهان ڏسي سگهو ٿا ته جيئن، ڊيٽا بيڪ اپ تمام سادو آهي. پر اعتراض جي اسٽوريج ۾ ڊيٽا جي سوال بابت ڇا؟
Thanos اسٽور جزو هڪ پراکسي طور ڪم ڪري ٿو اعتراض جي اسٽوريج مان ڊيٽا حاصل ڪرڻ لاء. Thanos Sidecar وانگر، اهو گپ شپ ڪلستر ۾ حصو وٺندو آهي ۽ اسٽور API کي لاڳو ڪري ٿو. هن طريقي سان، موجوده Querier ان کي هڪ سائڊڪار وانگر علاج ڪري سگهي ٿو، ٽائيم سيريز ڊيٽا جو هڪ ٻيو ذريعو - ڪا خاص ترتيب جي ضرورت ناهي.
ٽائيم سيريز ڊيٽا بلاڪ ڪيترن ئي وڏي فائلن تي مشتمل آهي. انهن کي گهربل لوڊ ڪرڻ ڪافي غير موثر هوندو، ۽ انهن کي مقامي طور تي ڪيش ڪرڻ لاءِ وڏي مقدار ۾ ميموري ۽ ڊسڪ اسپيس جي ضرورت هوندي.
ان جي بدران، اسٽور گيٽ وي ڄاڻي ٿو ته پروميٿيس اسٽوريج فارميٽ کي ڪيئن سنڀاليو. هڪ سمارٽ سوال شيڊولر جي مهرباني ۽ صرف بلاڪ جي ضروري انڊيڪس حصن کي ڪيش ڪرڻ، اهو ممڪن آهي ته پيچيده سوالن کي گهٽ ۾ گهٽ HTTP درخواستن جي گهٽ ۾ گهٽ تعداد ۾ اعتراض اسٽوريج فائلن لاء. هن طريقي سان، توهان درخواستن جي تعداد کي گھٽائي سگهو ٿا چار کان ڇهه آرڊرن جي شدت ۽ حاصل ڪري سگهو ٿا جوابي وقت جيڪي عام طور تي مقامي SSD تي ڊيٽا جي درخواستن کان فرق ڪرڻ ڏکيو آهي.
جيئن مٿي ڏنل ڊراگرام ۾ ڏيکاريو ويو آهي، ٿانوس ڪوئرر خاص طور تي قيمت گھٽائي ٿو في سوال اعتراض جي اسٽوريج ڊيٽا جي پروميٿيوس اسٽوريج فارميٽ کي استعمال ڪندي ۽ لاڳاپيل ڊيٽا کي پاسي تي رکڻ سان. هن طريقي کي استعمال ڪندي، اسان ڪيترن ئي واحد درخواستن کي گڏ ڪري سگهون ٿا گهٽ ۾ گهٽ بلڪ آپريشنز ۾.
Compaction ۽ downsampling
هڪ دفعو ٽائيم سيريز ڊيٽا جو هڪ نئون بلاڪ ڪاميابي سان اعتراض اسٽوريج ۾ لوڊ ڪيو ويو آهي، اسان ان کي "تاريخي" ڊيٽا طور سمجهون ٿا، جيڪو فوري طور تي اسٽور گيٽ وي ذريعي دستياب آهي.
بهرحال، ڪجهه وقت کان پوء، بلاڪ هڪ ذريعن کان (پرومٿيوس سان سائڊڪار) گڏ ڪري ٿو ۽ هاڻي مڪمل انڊيڪسنگ جي صلاحيت کي استعمال نٿو ڪري. هن مسئلي کي حل ڪرڻ لاء، اسان هڪ ٻيو حصو متعارف ڪرايو جنهن کي Compactor سڏيو ويندو آهي. اهو صرف Prometheus جي مقامي ڪمپيڪشن انجڻ کي تاريخي ڊيٽا کي اعتراض جي اسٽوريج ۾ لاڳو ڪري ٿو ۽ هڪ سادي دوراني بيچ نوڪري جي طور تي هلائي سگهجي ٿو.
موثر ڪمپريشن جي مهرباني، ڊگهي عرصي دوران اسٽوريج جي سوال کي ڊيٽا جي سائيز جي لحاظ کان ڪو مسئلو ناهي. بهرحال، هڪ بلين قدرن کي پيڪ ڪرڻ ۽ انهن کي هڪ سوال پروسيسر ذريعي هلائڻ جي امڪاني قيمت ناگزير طور تي سوال جي عمل جي وقت ۾ ڊرامائي اضافو ٿيندو. ٻئي طرف، ڇاڪاڻ ته اسڪرين تي في پکسل ۾ سوين ڊيٽا پوائنٽون آهن، اهو ناممڪن ٿي سگهي ٿو ته مڪمل ريزوليوشن تي ڊيٽا کي ڏسڻ لاء. اهڙيء طرح، نموني کي گهٽائڻ نه رڳو ممڪن آهي، پر اهو پڻ نه ٿيندو ته درستگی جي قابل نقصان جي سبب.
ڊيٽا کي گھٽائڻ لاء، Compactor مسلسل پنجن منٽن ۽ هڪ ڪلاڪ جي قرارداد تي ڊيٽا گڏ ڪري ٿو. TSDB XOR ڪمپريشن استعمال ڪندي انڪوڊ ٿيل هر خام حصي لاءِ، مجموعي ڊيٽا جا مختلف قسم محفوظ ڪيا ويندا آهن، جهڙوڪ هڪ بلاڪ لاءِ منٽ، وڌ ۾ وڌ يا رقم. هي Querier کي اجازت ڏئي ٿو ته خودڪار طور تي هڪ مجموعي چونڊيو جيڪو ڏنل PromQL سوال لاءِ مناسب هجي.
استعمال ڪندڙ کي گھٽ سڌائي واري ڊيٽا استعمال ڪرڻ لاءِ ڪا خاص تشڪيل جي ضرورت نه آھي. Querier خودڪار طريقي سان مختلف قراردادن ۽ خام ڊيٽا جي وچ ۾ سوئچ ڪري ٿو جيئن صارف زوم ان ۽ آئوٽ ڪري ٿو. جيڪڏهن گهربل هجي، صارف هن کي سڌو سنئون ڪنٽرول ڪري سگهي ٿو درخواست ۾ "قدم" پيٽرولر ذريعي.
جيئن ته هڪ GB اسٽوريج جي قيمت گهٽ آهي، ڊفالٽ طور Thanos خام ڊيٽا، پنج منٽ ۽ هڪ ڪلاڪ جي ريزوليوشن ڊيٽا کي محفوظ ڪري ٿو. اصل ڊيٽا کي ختم ڪرڻ جي ڪا ضرورت ناهي.
رڪارڊنگ جا ضابطا
جيتوڻيڪ Thanos سان گڏ، رڪارڊنگ ضابطا مانيٽرنگ اسٽيڪ جو هڪ لازمي حصو آهن. اهي پيچيدگي، ويڪرائي، ۽ سوالن جي قيمت گھٽائي ٿي. اهي پڻ آسان آهن صارفين لاءِ ميٽرڪ ذريعي مجموعي ڊيٽا حاصل ڪرڻ لاءِ. Thanos vanilla Prometheus مثالن تي مبني آهي، تنهنڪري اهو مڪمل طور تي قابل قبول آهي رڪارڊنگ قاعدن کي ذخيرو ڪرڻ ۽ موجوده Prometheus سرور تي قاعدن کي خبردار ڪرڻ. بهرحال، ڪجهه حالتن ۾ اهو ڪافي نه ٿي سگهي ٿو:
- عالمي خبرداري ۽ ضابطو (مثال طور، هڪ خبرداري جڏهن خدمت ڪم نه ڪندي آهي ٽن مان ٻن کان وڌيڪ ڪلستر).
- مقامي اسٽوريج کان ٻاهر ڊيٽا لاء ضابطو.
- سڀني قاعدن ۽ خبردارين کي ھڪڙي جڳھ ۾ ذخيرو ڪرڻ جي خواهش.
انهن سڀني ڪيسن لاءِ، Thanos ۾ هڪ الڳ جزو شامل آهي جنهن کي Ruler سڏيو ويندو آهي، جيڪو Thanos Queries ذريعي قاعدي ۽ خبرداري کي گڏ ڪري ٿو. هڪ معروف StoreAPI مهيا ڪرڻ سان، سوال نوڊ تازو ٺهيل ميٽرڪ تائين رسائي ڪري سگهي ٿو. بعد ۾ اهي شيون اسٽوريج ۾ پڻ ذخيرو ٿيل آهن ۽ اسٽور گيٽ وي ذريعي دستياب ڪيا ويا آهن.
Thanos جي طاقت
Thanos ڪافي لچڪدار آھي توھان جي ضرورتن مطابق ترتيب ڏيڻ لاءِ. اهو خاص طور تي مفيد آهي جڏهن سادي Prometheus کان لڏپلاڻ. اچو ته هڪ تڪڙي مثال سان گڏ ٿانوس جي اجزاء بابت جيڪو اسان سکيو آهي ان جو تذڪرو ڪريون. هتي آهي توهان جي وينلا پروميٿيوس کي ”لامحدود ميٽرڪ اسٽوريج“ جي دنيا ۾ ڪيئن وٺي وڃي:
- شامل ڪريو ٿانوس سائڊڪر پنھنجي پروميٿيوس سرورز ۾ - مثال طور، ڪبرنيٽس پوڊ ۾ ھڪڙو سائڊ ڪار ڪنٽينر.
- ڊيٽا کي ڏسڻ جي قابل ٿيڻ لاءِ ڪيترن ئي Thanos Querier replicas کي ترتيب ڏيو. هن مرحلي تي، اسڪراپر ۽ Querier جي وچ ۾ گپ شپ قائم ڪرڻ آسان آهي. اجزاء جي رابطي کي جانچڻ لاء، 'thanos_cluster_members' ميٽرڪ استعمال ڪريو.
صرف اهي ٻه قدم عالمي ڏيک مهيا ڪرڻ لاءِ ڪافي آهن ۽ امڪاني Prometheus HA replicas مان بيحد ڊيٽا ڊيڊپليڪيشن! بس پنهنجي ڊيش بورڊز کي Querier HTTP آخر پوائنٽ سان ڳنڍيو يا سڌو Thanos UI استعمال ڪريو.
تنهن هوندي، جيڪڏهن توهان کي ميٽرڪ بيڪ اپ ۽ ڊگهي مدت اسٽوريج جي ضرورت آهي، توهان کي ٽي وڌيڪ قدم مڪمل ڪرڻ جي ضرورت پوندي:
- AWS S3 يا GCS بالٽ ٺاهيو. انهن بالٽ ۾ ڊيٽا کي نقل ڪرڻ لاء سائڊ ڪار کي ترتيب ڏيو. مقامي ڊيٽا اسٽوريج هاڻي گهٽ ۾ گهٽ ٿي سگهي ٿو.
- اسٽور گيٽ وي کي ترتيب ڏيو ۽ ان کي پنھنجي موجوده گپ شپ ڪلستر سان ڳنڍيو. ھاڻي توھان پڇي سگھوٿا بيڪ اپ ڪيل ڊيٽا!
- ڊگھي عرصي دوران پڇا ڳاڇا جي ڪارڪردگي کي بهتر ڪرڻ لاءِ ڪمپيڪٽر کي ترتيب ڏيو compaction ۽ downsampling استعمال ڪندي.
جيڪڏھن توھان وڌيڪ ڄاڻڻ چاھيو ٿا، اسان کي ڏسڻ لاء سنکوڪ نه ڪريو и !
صرف پنجن قدمن ۾، اسان Prometheus کي هڪ قابل اعتماد مانيٽرنگ سسٽم ۾ تبديل ڪيو، عالمي ڏيک، لامحدود اسٽوريج وقت ۽ ميٽرڪ جي امڪاني اعلي دستيابي سان.
ڇڪڻ جي درخواست: اسان کي توهان جي ضرورت آهي!
شروع کان ئي هڪ اوپن سورس پروجيڪٽ رهيو آهي. Prometheus سان بيحد انضمام ۽ Thanos جو صرف هڪ حصو استعمال ڪرڻ جي صلاحيت ان کي توهان جي نگراني واري نظام کي آسانيءَ سان اسڪيل ڪرڻ لاءِ هڪ بهترين انتخاب بڻائي ٿي.
اسان هميشه خوش آمديد آهيون GitHub پل درخواستون ۽ مسئلا. ساڳئي وقت ۾، اسان سان رابطو ڪرڻ لاء آزاد محسوس ڪريو Github مسئلن يا سست ذريعيجيڪڏهن توهان وٽ سوال يا موٽ آهي، يا ان کي استعمال ڪندي پنهنجو تجربو حصيداري ڪرڻ چاهيو ٿا! جيڪڏھن توھان پسند ڪندا آھيو جيڪو اسان ڪريون Improbable تي، اسان سان رابطو ڪرڻ ۾ سنکوڪ نه ڪريو - !
جو ذريعو: www.habr.com