زيبڪس هڪ نگراني نظام آهي. ڪنهن ٻئي سسٽم وانگر، اهو سڀني مانيٽرنگ سسٽم جي ٽن مکيه مسئلن کي منهن ڏئي ٿو: ڊيٽا گڏ ڪرڻ ۽ پروسيسنگ، تاريخ کي محفوظ ڪرڻ، ۽ ان کي صاف ڪرڻ.
ڊيٽا حاصل ڪرڻ، پروسيسنگ ۽ رڪارڊ ڪرڻ جا مرحلا وقت وٺن ٿا. گهڻو نه، پر هڪ وڏي سسٽم لاءِ اهو نتيجو ٿي سگهي ٿو وڏي دير. اسٽوريج مسئلو ڊيٽا جي رسائي جو مسئلو آهي. اهي رپورٽون، چيڪ ۽ ٽارگيٽ لاء استعمال ڪيا ويا آهن. ڊيٽا جي رسائي ۾ دير سان ڪارڪردگي پڻ متاثر ڪري ٿي. جڏهن ڊيٽابيس وڌندا آهن، غير لاڳاپيل ڊيٽا کي ختم ڪرڻو پوندو. هٽائڻ هڪ مشڪل آپريشن آهي جيڪو پڻ ڪجهه وسيلن کي کائي ٿو.
زبڪس ۾ گڏ ڪرڻ ۽ اسٽوريج دوران دير جا مسئلا ڪيشنگ ذريعي حل ڪيا ويا آهن: ڪيش جا ڪيترائي قسم، ڊيٽابيس ۾ ڪيشنگ. ٽيون مسئلو حل ڪرڻ لاء، ڪيشنگ مناسب نه آهي، تنهنڪري Zabbix استعمال ڪيو TimescaleDB. هو توهان کي ان بابت ٻڌائيندو آندري گوشچين - ٽيڪنيڪل سپورٽ انجنيئر . اينڊريو زيبڪس کي 6 سالن کان وڌيڪ مدد ڪري رهيو آهي ۽ هن کي ڪارڪردگي سان سڌو تجربو آهي.
TimescaleDB ڪيئن ڪم ڪندو آهي، باقاعده PostgreSQL جي مقابلي ۾ اها ڪهڙي ڪارڪردگي ڏئي سگهي ٿي؟ Zabbix TimescaleDB ڊيٽابيس لاءِ ڪهڙو ڪردار ادا ڪندو آهي؟ شروع کان ڪيئن شروع ڪجي ۽ PostgreSQL مان لڏپلاڻ ڪيئن ڪجي ۽ ڪهڙي ترتيب ۾ بهتر ڪارڪردگي آهي؟ هن جي باري ۾ سڀ ڪٽ هيٺ.
پيداواري چئلينجز
هر نگراني نظام کي مخصوص ڪارڪردگي جي چئلينج کي منهن ڏيڻو پوي ٿو. مان انهن مان ٽن بابت ڳالهائيندس: ڊيٽا گڏ ڪرڻ ۽ پروسيسنگ، اسٽوريج، ۽ تاريخ صاف ڪرڻ.
فاسٽ ڊيٽا گڏ ڪرڻ ۽ پروسيسنگ. هڪ سٺي مانيٽرنگ سسٽم کي تمام ڊيٽا جلدي حاصل ڪرڻ گهرجي ۽ ان کي ٽرگر ايڪسپريس جي مطابق پروسيس ڪرڻ گهرجي - ان جي معيار مطابق. پروسيسنگ کان پوء، سسٽم کي پڻ جلدي هن ڊيٽا کي ڊيٽابيس ۾ بعد ۾ استعمال لاء محفوظ ڪرڻ گهرجي.
تاريخ جو ذخيرو. هڪ سٺي مانيٽرنگ سسٽم کي تاريخ کي ڊيٽابيس ۾ ذخيرو ڪرڻ گهرجي ۽ ميٽرڪ تائين آسان رسائي فراهم ڪرڻ گهرجي. رپورٽن ۾ استعمال ٿيڻ لاء تاريخ جي ضرورت آهي, گراف, triggers, thresholds, ۽ حساب جي خبرداري ڊيٽا شيون.
تاريخ کي صاف ڪرڻ. ڪڏهن ڪڏهن هڪ ڏينهن ايندو آهي جڏهن توهان کي ميٽرڪ کي ذخيرو ڪرڻ جي ضرورت ناهي. توهان کي ڊيٽا جي ضرورت ڇو آهي جيڪا 5 سال اڳ گڏ ڪئي وئي هئي، هڪ يا ٻه مهينا: ڪجهه نوڊس ڊاهيا ويا آهن، ڪجهه ميزبان يا ميٽرڪ هاڻي گهربل نه آهن ڇو ته اهي پراڻي آهن ۽ هاڻي گڏ نه ڪيا ويا آهن. هڪ سٺي مانيٽرنگ سسٽم کي گهرجي ته تاريخي ڊيٽا کي محفوظ ڪري ۽ ان کي وقت بوقت ختم ڪري ڇڏي ته جيئن ڊيٽابيس نه وڌي.
اسٽيل ڊيٽا کي صاف ڪرڻ هڪ نازڪ مسئلو آهي جيڪو ڊيٽابيس جي ڪارڪردگي کي تمام گهڻو متاثر ڪري ٿو.
Zabbix ۾ ڪيشنگ
Zabbix ۾، پهرين ۽ سيڪنڊ ڪالون ڪيشنگ استعمال ڪندي حل ڪيا ويا آهن. رام ڊيٽا گڏ ڪرڻ ۽ پروسيس ڪرڻ لاء استعمال ڪيو ويندو آهي. اسٽوريج لاءِ - تاريخ ۾ ٽارگيٽ، گراف ۽ حساب ڪيل ڊيٽا عناصر. ڊيٽابيس جي پاسي تي بنيادي چونڊ لاء ڪيشنگ آهي، مثال طور، گراف.
زبڪس سرور جي پاسي تي ڪيشنگ پاڻ آهي:
- ConfigurationCache؛
- ValueCache؛
- تاريخ ڪيچ؛
- TrendsCache.
انهن کي وڌيڪ تفصيل ڏي.
ConfigurationCache
هي مکيه ڪيش آهي جتي اسان ميٽرڪ، ميزبان، ڊيٽا آئٽمز، ٽريگرز ذخيرو ڪندا آهيون - هر شيءِ جنهن جي اسان کي ضرورت آهي PreProcessing ۽ ڊيٽا گڏ ڪرڻ لاءِ.
اهو سڀ ڪجهه ConfigurationCache ۾ محفوظ ڪيو ويو آهي ته جيئن ڊيٽابيس ۾ غير ضروري سوال پيدا نه ٿين. سرور شروع ٿيڻ کان پوء، اسان هن ڪيش کي تازه ڪاري ڪريون ٿا، ترتيب ڏيو ۽ وقتي طور تي تازه ڪاري ترتيب ڏيو.
ڊيٽا گڏ ڪرڻ
ڊراگرام ڪافي وڏو آهي، پر ان ۾ بنيادي شيء آهي جمع ڪندڙ. اهي مختلف آهن "پولرز" - اسيمبليء جا عمل. اهي مختلف قسم جي اسيمبليءَ جا ذميوار آهن: اهي SNMP، IPMI ذريعي ڊيٽا گڏ ڪن ٿا، ۽ ان کي منتقل ڪن ٿا سڀني کي PreProcessing.
جمع ڪندڙ نارنگي ۾ بيان ڪيا ويا آهن.
Zabbix ڳڻپ ڪئي آهي مجموعي شيون جيڪي مجموعي چيڪ ڪرڻ لاء گهربل آهن. جيڪڏهن اسان وٽ اهي آهن، اسان انهن لاء ڊيٽا سڌو سنئون ValueCache مان آڻيون ٿا.
اڳي پروسيسنگ تاريخ ڪيچ
سڀئي جمع ڪندڙ استعمال ڪن ٿا ConfigurationCache نوڪريون حاصل ڪرڻ لاءِ. پوء اھي انھن کي منتقلي PreProcessing ڏانھن.
PreProcessing استعمال ڪري ٿو ConfigurationCache PreProcessing قدم حاصل ڪرڻ لاءِ. اهو هن ڊيٽا کي مختلف طريقن سان پروسيس ڪري ٿو.
PreProcessing استعمال ڪندي ڊيٽا کي پروسيس ڪرڻ کان پوء، اسان ان کي پروسيسنگ لاء HistoryCache ۾ محفوظ ڪندا آهيون. اهو ڊيٽا گڏ ڪرڻ کي ختم ڪري ٿو ۽ اسان Zabbix ۾ مکيه عمل ڏانهن وڃو. تاريخ هم وقت ساز, ڇاڪاڻ ته اهو هڪ monolithic فن تعمير آهي.
نوٽ: PreProcessing ڪافي ڏکيو آپريشن آهي. v 4.2 کان وٺي پراکسي ڏانهن منتقل ڪيو ويو آهي. جيڪڏهن توهان وٽ تمام وڏو زيبڪس آهي وڏي تعداد ۾ ڊيٽا عناصر ۽ گڏ ڪرڻ جي تعدد سان، پوء اهو ڪم تمام آسان بڻائي ٿو.
ValueCache، تاريخ ۽ رجحانات ڪيش
تاريخ هم وقت سازي بنيادي عمل آهي جيڪو ايٽمي طور تي هر ڊيٽا عنصر کي پروسيس ڪري ٿو، اهو آهي، هر قيمت.
تاريخ جي هم وقت سازي تاريخ ڪيچ مان قيمتون وٺندي آهي ۽ حسابن لاءِ محرڪن جي موجودگي لاءِ ڪنفيگريشن چيڪ ڪري ٿي. جيڪڏهن اهي موجود آهن، اهو حساب ڪري ٿو.
تاريخ جي هم وقت ساز هڪ واقعو ٺاهي ٿو، ترتيب ڏيڻ، ۽ رڪارڊز جي ضرورت هجي ته خبرداري ٺاهڻ لاءِ واڌارو. جيڪڏهن ايندڙ پروسيسنگ لاءِ محرڪ موجود آهن، پوءِ اهو هن قيمت کي ValueCache ۾ محفوظ ڪري ٿو ته جيئن تاريخ جي ٽيبل تائين رسائي نه ٿئي. اهو ڪيئن آهي ValueCache ڊيٽا سان ڀريو ويو آهي جيڪو ڳڻپ ڪرڻ لاءِ ضروري آهي ٽريگرز ۽ ڳڻپيوڪر عناصر.
تاريخ جي هم وقت سازي سڀني ڊيٽا کي ڊيٽابيس ۾ لکي ٿو، ۽ اهو ڊسڪ ڏانهن لکي ٿو. پروسيسنگ جو عمل هتي ختم ٿئي ٿو.
ڊيٽابيس ۾ ڪيشنگ
ڊيٽابيس جي پاسي تي مختلف ڪيشون آھن جڏھن توھان چاھيو ٿا گرافس يا واقعن تي رپورٽون:
Innodb_buffer_poolMySQL پاسي تي؛shared_buffersPostgreSQL پاسي تي؛effective_cache_sizeOracle پاسي تي؛shared_poolDB2 پاسي تي.
اتي ٻيا به ڪيترائي ڪيش آھن، پر اھي ئي آھن مکيه آھن سڀني ڊيٽابيس لاءِ. اهي توهان کي ريم ۾ ڊيٽا ذخيرو ڪرڻ جي اجازت ڏين ٿيون جيڪي اڪثر سوالن جي ضرورت هونديون آهن. ان لاءِ انهن وٽ پنهنجون ٽيڪنالاجيون آهن.
ڊيٽابيس جي ڪارڪردگي اهم آهي
Zabbix سرور مسلسل ڊيٽا گڏ ڪري ٿو ۽ ان کي لکي ٿو. جڏهن ٻيهر شروع ڪيو ويو، اهو پڻ تاريخ مان پڙهي ٿو ValueCache ڀرڻ لاءِ. اسڪرپٽ ۽ رپورٽون استعمال ڪري ٿو Zabbix API، جيڪو ويب انٽرفيس تي ٺهيل آهي. Zabbix API ڊيٽابيس تائين رسائي ڪري ٿو ۽ گرافس، رپورٽون، واقعن جي فهرستن ۽ تازي مسئلن لاء ضروري ڊيٽا حاصل ڪري ٿو.
ڏسڻ لاء - گرافانا. هي اسان جي استعمال ڪندڙن جي وچ ۾ هڪ مشهور حل آهي. اهو سڌو سنئون درخواستون موڪلي سگھي ٿو Zabbix API ذريعي ۽ ڊيٽابيس ڏانهن، ۽ ڊيٽا حاصل ڪرڻ لاءِ هڪ خاص مقابلو پيدا ڪري ٿو. تنهن ڪري، نتيجن ۽ ٽيسٽ جي تيز ترسيل سان ملائڻ لاءِ ڊيٽابيس جي بهتر ۽ بهتر ترتيب جي ضرورت آهي.
گهريلواري
زيبڪس ۾ ٽيون ڪارڪردگي چيلنج آهي تاريخ کي صاف ڪرڻ هائوس ڪيپر استعمال ڪندي. اهو سڀني سيٽنگن جي پيروي ڪري ٿو - ڊيٽا عناصر ظاهر ڪن ٿا ته ڪيتري وقت تائين تبديلين جي متحرڪ (رجحانات) کي ڏينهن ۾ ذخيرو ڪرڻ لاء.
اسان اڏام تي TrendsCache حساب ڪندا آهيون. جڏهن ڊيٽا اچي ٿي، اسان ان کي هڪ ڪلاڪ لاءِ گڏ ڪريون ٿا ۽ ان کي جدولن ۾ رڪارڊ ڪيون ٿا رجحان تبديلين جي متحرڪ لاءِ.
هائوس ڪيپر عام طور تي "چونڊ" استعمال ڪندي ڊيٽابيس مان معلومات شروع ڪري ۽ حذف ڪري ٿو. اهو هميشه اثرائتو ناهي، جيئن اندروني عملن جي ڪارڪردگي گراف مان ڏسي سگهجي ٿو.
ڳاڙهو گراف ڏيکاري ٿو ته تاريخ هم وقت ساز مسلسل مصروف آهي. مٿي تي نارنگي گراف هائوس ڪيپر آهي، جيڪو مسلسل هلندڙ آهي. هو ڊيٽابيس جي سڀني قطارن کي ختم ڪرڻ جو انتظار ڪري ٿو جيڪو هن بيان ڪيو آهي.
جڏهن توهان کي گهر جي سنڀاليندڙ کي بند ڪرڻ گهرجي؟ مثال طور، اتي هڪ "آئٽم ID" آهي ۽ توهان کي ختم ڪرڻ جي ضرورت آهي آخري 5 هزار قطارون هڪ خاص وقت اندر. يقينا، اهو انڊيڪس طرفان ٿئي ٿو. پر عام طور تي ڊيٽا سيٽ تمام وڏو آهي، ۽ ڊيٽابيس اڃا تائين ڊسڪ مان پڙهي ٿو ۽ ان کي ڪيش ۾ وجهي ٿو. اهو هميشه ڊيٽابيس لاء هڪ تمام مهانگو آپريشن آهي ۽، ڊيٽابيس جي سائيز تي منحصر ڪري، ڪارڪردگي مسئلا پيدا ڪري سگهي ٿو.
گهر جي مالڪ کي معذور ڪرڻ آسان آهي. ويب انٽرفيس ۾ هڪ سيٽنگ آهي "ايڊمنسٽريشن جنرل" هائوس ڪيپر لاءِ. اسان اندروني رجحان جي تاريخ لاءِ اندروني هائوس ڪيپنگ کي غير فعال ڪريون ٿا ۽ اهو هاڻي ان کي منظم نٿو ڪري.
گھر جي سنڀاليندڙ کي بند ڪيو ويو، گرافس برابر ٿي ويا - هن معاملي ۾ ڪهڙا مسئلا ٿي سگهن ٿا ۽ ٽئين ڪارڪردگي چئلينج کي حل ڪرڻ ۾ ڪهڙي مدد ڪري سگهي ٿي؟
ورهاڱي- ورهاڱي يا ورهاڱي
عام طور تي، ورهاڱي کي مختلف طريقي سان ترتيب ڏنو ويو آهي هر تعلقي ڊيٽابيس تي جيڪو مون درج ڪيو آهي. هر هڪ پنهنجي ٽيڪنالاجي آهي، پر اهي عام طور تي ساڳيا آهن. نئين ورهاڱي کي ٺاهڻ اڪثر ڪري ڪجهه مسئلن جي ڪري ٿي.
عام طور تي، "سيٽ اپ" جي بنياد تي ورهاڱي کي ترتيب ڏني وئي آهي - ڊيٽا جي مقدار جيڪا هڪ ڏينهن ۾ ٺاهي وئي آهي. ضابطي جي طور تي، ورهاڱي هڪ ڏينهن ۾ جاري ڪئي وئي آهي، اهو گهٽ ۾ گهٽ آهي. نئين بيچ جي رجحانات لاء - 1 مهينو.
قدر تبديل ٿي سگھي ٿو جيڪڏھن ”سيٽ اپ“ تمام وڏو آھي. جيڪڏهن هڪ ننڍڙو "سيٽ اپ" 5 nvps (نئين قيمت في سيڪنڊ) تائين آهي، هڪ وچولي هڪ 000 کان 5 تائين آهي، پوء هڪ وڏو 000 nvps کان مٿي آهي. اهي وڏا ۽ تمام وڏا تنصيب آهن جيڪي ڊيٽابيس جي محتاط ترتيب جي ضرورت هونديون آهن.
تمام وڏي تنصيب تي، هڪ ڏينهن جو عرصو بهتر نه ٿي سگھي. مون ڏٺو آهي MySQL ڊويزنون 40 GB يا وڌيڪ في ڏينهن. هي ڊيٽا جو هڪ تمام وڏو مقدار آهي جيڪو مسئلا پيدا ڪري سگهي ٿو ۽ گهٽ ڪرڻ جي ضرورت آهي.
ورهاڱي ڇا ڏئي ٿو؟
ورهاڱي جي ٽيبل. گهڻو ڪري اهي ڊسڪ تي الڳ فائلون آهن. سوال جو منصوبو هڪ ورهاڱي کي وڌيڪ بهتر طور تي چونڊيندو آهي. عام طور تي ورهاڱي جي حد تائين استعمال ڪيو ويندو آهي - اهو پڻ Zabbix لاء صحيح آهي. اسان اتي "ٽائم اسٽيمپ" استعمال ڪندا آهيون - وقت جي شروعات کان وٺي. اهي اسان لاءِ عام انگ آهن. توهان ڏينهن جي شروعات ۽ آخر مقرر ڪيو - هي هڪ ورهاڱي آهي.
تڪڙو هٽائڻ - DELETE. ھڪڙي فائل / ذيلي ٽيبل کي منتخب ڪيو ويو آھي، بجاء ختم ڪرڻ لاء قطار جي چونڊ کان.
خاص طور تي ڊيٽا جي بحالي کي تيز ڪري ٿو SELECT - سڄي ٽيبل جي بجاءِ هڪ يا وڌيڪ ورهاڱي کي استعمال ڪري ٿو. جيڪڏهن توهان ڊيٽا تائين رسائي ڪري رهيا آهيو جيڪا ٻه ڏينهن پراڻي آهي، اهو ڊيٽابيس مان تيزيء سان حاصل ڪيو ويندو آهي ڇو ته توهان کي صرف هڪ فائل کي ڪيش ۾ لوڊ ڪرڻ ۽ ان کي واپس ڪرڻ جي ضرورت آهي، وڏي ٽيبل نه.
گهڻو ڪري ڪيترائي ڊيٽابيس پڻ تيز ٿي ويا آهن INSERT - ٻار جي ٽيبل ۾ داخل ڪرڻ.
ٽائم اسڪيل ڊي بي
v 4.2 لاءِ، اسان اسان جو ڌيان TimescaleDB ڏانھن ڪيو. هي هڪ واڌارو آهي PostgreSQL لاءِ هڪ ڏيهي انٽرفيس سان. توسيع موثر طريقي سان ڪم ڪري ٿي ٽائيم سيريز ڊيٽا سان، بغير لاڳاپي واري ڊيٽابيس جي فائدن کي وڃائڻ جي. TimescaleDB خود بخود ورهاڱي ڪري ٿو.
TimescaleDB هڪ تصور آهي هائپر ٽيبل (hypertable) جيڪو توهان ٺاهيندا آهيو. ان تي مشتمل آهي ٽڪرا - ورهاڱي. ٽڪڙا خود بخود منظم ٿيل هائپر ٽيبل ٽڪرا آهن جيڪي ٻين ٽڪرن تي اثر انداز نٿا ڪن. هر ٽڪري جي پنهنجي وقت جي حد آهي.
TimescaleDB بمقابلہ PostgreSQL
TimescaleDB واقعي ڪارائتو ڪم ڪري ٿو. واڌ جي ٺاهيندڙن جي دعوي آهي ته اهي هڪ وڌيڪ صحيح سوال پروسيسنگ الگورتھم استعمال ڪن ٿا، خاص طور تي inserts ۾. جيئن ته ڊيٽا سيٽ داخل ڪرڻ جي سائيز وڌندي آهي، الورورٿم مسلسل ڪارڪردگي برقرار رکندو آهي.
200 ملين قطارن کان پوءِ، PostgreSQL عام طور تي خاص طور تي ساڙڻ شروع ڪري ٿو ۽ ڪارڪردگي کي 0 تائين وڃائي ٿو. TimescaleDB توهان کي اجازت ڏئي ٿو ته ڪنهن به مقدار جي ڊيٽا لاءِ موثر انداز ۾ ”انسرٽس“ داخل ڪريو.
تنصيب
انسٽال ڪرڻ TimescaleDB ڪنهن به پيڪيج لاءِ بلڪل آسان آهي. IN سڀ ڪجھ تفصيل سان بيان ڪيو ويو آھي - اھو منحصر آھي سرڪاري PostgreSQL پيڪيجز تي. TimescaleDB پڻ دستي طور تي تعمير ۽ مرتب ڪري سگھجي ٿو.
Zabbix ڊيٽابيس لاءِ اسان صرف ايڪسٽينشن کي چالو ڪريون ٿا:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
توھان چالو ڪريو extension ۽ ان کي ٺاهيو Zabbix ڊيٽابيس لاءِ. آخري قدم هڪ هائپر ٽيبل ٺاهڻ آهي.
تاريخ جي جدولن کي TimescaleDB ڏانهن منتقل ڪرڻ
هن لاء هڪ خاص فنڪشن آهي create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
فنڪشن ۾ ٽي پيٽرول آهن. پهريون - ڊيٽابيس ۾ ٽيبل، جنهن لاءِ توهان کي هڪ هائپر ٽيبل ٺاهڻ جي ضرورت آهي. ٻيون - ميدان، جنهن جي مطابق توهان کي ٺاهڻ جي ضرورت آهي chunk_time_interval - ورهاڱي جي حصن جو وقفو استعمال ڪيو وڃي. منهنجي حالت ۾، وقفو هڪ ڏينهن آهي - 86.
ٽيون پيٽرول - migrate_data. جيڪڏهن توهان مقرر ڪيو true، پوءِ سڀ موجوده ڊيٽا اڳ ۾ ٺهيل حصن ڏانهن منتقل ڪئي وئي آهي. مون ان کي پاڻ استعمال ڪيو migrate_data. مون کي اٽڪل 1 ٽي بي هئي، جيڪا هڪ ڪلاڪ کان مٿي ٿي وئي. جيتوڻيڪ ڪجھ ڪيسن ۾، جاچ دوران، مون ڪردارن جي قسمن جي تاريخي ڊيٽا کي حذف ڪيو جيڪي اسٽوريج لاء گهربل نه هئا، انهي ڪري ته انهن کي منتقل نه ڪيو وڃي.
آخري قدم - UPDATE: تي db_extension رکڻ timescaledbته جيئن ڊيٽابيس سمجهي ته هي ايڪسٽينشن موجود آهي. Zabbix ان کي چالو ڪري ٿو ۽ صحيح طريقي سان استعمال ڪري ٿو نحو ۽ سوالن کي ڊيٽابيس ۾ - اهي خاصيتون جيڪي ضروري آهن TimescaleDB لاءِ.
هارڊويئر جي ٺاھ جوڙ
مون ٻه سرور استعمال ڪيا. پهريون - VMware مشين. اهو تمام ننڍڙو آهي: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz پروسيسرز، 16 GB جي رام ۽ 200 GB SSD.
مون انسٽال ڪيو PostgreSQL 10.8 ان تي Debian 10.8-1.pgdg90+1 OS ۽ xfs فائل سسٽم سان. مون هن خاص ڊيٽابيس کي استعمال ڪرڻ لاءِ هر شي کي گهٽ ۾ گهٽ ترتيب ڏني آهي، مائنس جيڪو زيبڪس پاڻ استعمال ڪندو.
ساڳئي مشين تي هڪ Zabbix سرور، PostgreSQL ۽ لوڊ ايجنٽ. مون وٽ 50 فعال ايجنٽ هئا جيڪي استعمال ڪري رهيا هئا LoadableModuleتمام جلدي مختلف نتيجا پيدا ڪرڻ لاءِ: انگ، تار. مون ڊيٽابيس کي تمام گھڻي ڊيٽا سان ڀريو.
شروعات ۾ ٺاھ جوڙ تي مشتمل 5 عناصر ڊيٽا في ميزبان. لڳ ڀڳ هر عنصر هڪ ٽرڪ تي مشتمل آهي ان کي حقيقي تنصيب سان ملندڙ جلندڙ. ڪجهه حالتن ۾ اتي هڪ کان وڌيڪ محرڪ هئا. هڪ نيٽ ورڪ نوڊ لاء اتي هئا 3-000 ٽرگرز.
ڊيٽا آئٽم تازه ڪاري جو وقفو - 4-7 سيڪنڊ. مون نه رڳو 50 ايجنٽ استعمال ڪندي لوڊ پاڻ کي منظم ڪيو، پر وڌيڪ شامل ڪيو. انهي سان گڏ، ڊيٽا عناصر استعمال ڪندي، مون متحرڪ طور تي لوڊ کي ترتيب ڏنو ۽ اپڊيٽ جي وقفي کي 4 s تائين گھٽايو.
PostgreSQL. 35 nvps
هن هارڊويئر تي منهنجو پهريون رن خالص PostgreSQL تي هو - 35 هزار قيمتون في سيڪنڊ. جئين توهان ڏسي سگهو ٿا، ڊيٽا داخل ڪرڻ هڪ سيڪنڊ جو حصو وٺندو آهي - هر شيء سٺو ۽ تيز آهي. صرف اها آهي ته هڪ 200 GB SSD ڊسڪ جلدي ڀريندو آهي.
هي هڪ معياري زيبڪس سرور ڪارڪردگي ڊيش بورڊ آهي.
پهريون نيرو گراف في سيڪنڊ جي قيمتن جو تعداد آهي. ساڄي پاسي جو ٻيو گراف تعميراتي عملن جي لوڊشيڊنگ آهي. ٽيون لوڊ ڪري رهيو آهي اندروني تعميراتي عمل: تاريخ جي هم وقت ساز ۽ هائوس ڪيپر، جيڪو هتي ڪافي عرصي کان هلي رهيو آهي.
چوٿون گراف ڏيکاري ٿو HistoryCache استعمال. هي ڊيٽابيس ۾ داخل ڪرڻ کان اڳ بفر جو هڪ قسم آهي. سائو پنجون گراف ڏيکاري ٿو ValueCache جو استعمال، يعني، ڪيترا ValueCache ٽاريندڙن لاءِ ھٽندا آھن - ھي آھي ڪيترائي ھزار قدر في سيڪنڊ.
PostgreSQL. 50 nvps
ان کان پوء مون ساڳئي هارڊويئر تي 50 هزار ويلز في سيڪنڊ تائين لوڊ وڌايو.
جڏهن هائوس ڪيپر کان لوڊ ڪندي، 10 هزار ويلز داخل ڪرڻ ۾ 2-3 سيڪنڊن جو وقت لڳي ويو.
گهر جي مالڪ اڳ ۾ ئي ڪم ۾ مداخلت ڪرڻ شروع ڪيو آهي.
ٽيون گراف ڏيکاري ٿو ته، عام طور تي، ٽراپرز ۽ تاريخ جي هم وقت سازي تي لوڊ اڃا تائين 60٪ تي آهي. چوٿين گراف ۾، HistoryCache اڳ ۾ ئي گھربل آپريشن دوران ڪافي فعال طور تي ڀرڻ شروع ڪيو آھي. اهو 20٪ مڪمل آهي، جيڪو اٽڪل 0,5 GB آهي.
PostgreSQL. 80 nvps
پوءِ مون لوڊ وڌائي 80 هزار ويلز في سيڪنڊ تائين. اهو لڳ ڀڳ 400 هزار ڊيٽا عناصر ۽ 280 هزار ٽرگرز آهي.
XNUMX تاريخ synchers جي لوڊشيڊنگ جي قيمت اڳ ۾ ئي ڪافي آهي.
مون مختلف پيٽرولر پڻ وڌايو: تاريخ جي هم وقت سازي، ڪيچ.
منهنجي هارڊويئر تي، تاريخ جي هم وقت سازي جي لوڊشيڊنگ وڌ ۾ وڌ وڌي وئي. تاريخ ڪيچ جلدي ڊيٽا سان ڀريل - پروسيسنگ لاءِ ڊيٽا بفر ۾ جمع ٿي چڪي هئي.
اهو سڄو وقت مون ڏٺو ته پروسيسر، رام ۽ ٻيا سسٽم پيٽرولر ڪيئن استعمال ڪيا ويا، ۽ ڏٺم ته ڊسڪ استعمال ان جي وڌ ۾ وڌ هئي.
مون استعمال حاصل ڪيو وڌ ۾ وڌ ڊسڪ صلاحيتون هن هارڊويئر تي ۽ هن ورچوئل مشين تي. اهڙي شدت سان، PostgreSQL ڊيٽا کي فعال طور تي فلش ڪرڻ شروع ڪيو، ۽ ڊسڪ کي هاڻي لکڻ ۽ پڙهڻ جو وقت نه هو.
ٻيو سرور
مون هڪ ٻيو سرور ورتو، جنهن ۾ اڳ ۾ ئي 48 پروسيسر ۽ 128 GB جي رام هئي. مون ان کي ٽيون ڪيو - ان کي 60 تاريخ جي هم وقت سازي تي سيٽ ڪيو، ۽ قابل قبول ڪارڪردگي حاصل ڪئي.
حقيقت ۾، هي اڳ ۾ ئي پيداوار جي حد آهي جتي ڪجهه ڪرڻ جي ضرورت آهي.
ٽائيم اسڪيل ڊي بي. 80 nvps
منهنجو مکيه ڪم زبڪس لوڊ جي خلاف TimescaleDB جي صلاحيتن کي جانچڻ آهي. 80 هزار قدر في سيڪنڊ تمام گهڻو آهي، ميٽرڪ گڏ ڪرڻ جي تعدد (سواء Yandex جي، يقينا) ۽ ڪافي وڏي "سيٽ اپ".
هر گراف ۾ هڪ ڊپ آهي - اهو صحيح طور تي ڊيٽا لڏپلاڻ آهي. زببڪس سرور ۾ ناڪامي کان پوء، تاريخ جي هم وقت سازي جي لوڊشيڊنگ پروفائل تمام گهڻو تبديل ٿي ويو - اهو ٽي ڀيرا گهٽجي ويو.
TimescaleDB توهان کي ڊيٽا داخل ڪرڻ جي اجازت ڏئي ٿي تقريباً 3 ڀيرا تيز ۽ استعمال ڪريو گھٽ HistoryCache.
انهي جي مطابق، توهان بروقت طريقي سان ڊيٽا حاصل ڪندا.
ٽائيم اسڪيل ڊي بي. 120 nvps
پوءِ مون ڊيٽا عنصرن جو تعداد وڌائي 500 ھزار ڪيو. بنيادي ڪم ٽائم اسڪيل ڊي بي جي صلاحيتن کي جانچڻ ھو - مون کي 125 ھزار ويلز في سيڪنڊ جي حساب سان ملي.
هي هڪ ڪم ڪندڙ "سيٽ اپ" آهي جيڪو ڊگهي وقت تائين ڪم ڪري سگهي ٿو. پر جيئن ته منهنجي ڊسڪ صرف 1,5 ٽي بي هئي، مون ان کي ڪجهه ڏينهن ۾ ڀريو.
سڀ کان اهم شيء اها آهي ته ساڳئي وقت نئين TimescaleDB ورهاڱي ٺاهي وئي.
اهو ڪارڪردگي لاء مڪمل طور تي غير معمولي آهي. جڏهن پارٽيشنون MySQL ۾ ٺاهيا ويا آهن، مثال طور، هر شيء مختلف آهي. اهو عام طور تي رات جو ٿئي ٿو ڇاڪاڻ ته اهو عام داخل ٿيڻ کي روڪي ٿو، ٽيبل سان ڪم ڪري ٿو ۽ خدمت جي تباهي پيدا ڪري سگهي ٿي. اهو معاملو TimescaleDB سان ناهي.
مثال طور، مان هڪ گراف ڏيکاريندس ڪميونٽي ۾ گھڻن مان. تصوير ۾، TimescaleDB فعال آهي، جنهن جي مهرباني پروسيسر تي io.weight استعمال ڪرڻ تي لوڊ گهٽجي ويو آهي. اندروني عمل جي عناصر جو استعمال پڻ گھٽجي ويو. ان کان علاوه، هي هڪ عام مجازي مشين آهي عام پينڪڪ ڊسڪ تي، نه هڪ SSD.
پهچڻ
TimescaleDB ننڍي "سيٽ اپ" لاء هڪ سٺو حل آهي.، جيڪو ڊسڪ جي ڪارڪردگي کي متاثر ڪري ٿو. اهو توهان کي چڱي طرح ڪم جاري رکڻ جي اجازت ڏيندو جيستائين ڊيٽابيس کي جلدي ممڪن طور تي هارڊويئر ڏانهن منتقل ڪيو وڃي.
TimescaleDB ترتيب ڏيڻ آسان آهي، ڪارڪردگي حاصلات ڏئي ٿو، زيبڪس ۽ سان گڏ ڪم ڪري ٿو PostgreSQL تي فائدا آھن.
جيڪڏهن توهان PostgreSQL استعمال ڪريو ٿا ۽ ان کي تبديل ڪرڻ جو منصوبو نه ڪريو، مان سفارش ڪريان ٿو استعمال ڪريو PostgreSQL TimescaleDB واڌ سان گڏ Zabbix سان گڏ. اهو حل مؤثر طريقي سان ڪم ڪري ٿو هڪ وچولي "سيٽ اپ" تائين.
جڏهن اسان چئون ٿا "اعلي ڪارڪردگي" اسان جو مطلب آهي . توهان کي انهن ٽيڪنالاجيز ۽ عملن جي باري ۾ سکڻ لاءِ گهڻو انتظار نه ڪرڻو پوندو جيڪي خدمتن کي لکين صارفين جي خدمت ڪرڻ جي قابل بڻائين ٿيون. فهرست نومبر 7 ۽ 8 لاء اسان اڳ ۾ ئي مرتب ڪيو آهي، پر هتي وڌيڪ تجويز ڪري سگهجي ٿو.
اسان جي رڪنيت حاصل ڪريو и ، جنهن ۾ اسان ايندڙ ڪانفرنس جي خاصيتن کي ظاهر ڪريون ٿا، ۽ معلوم ڪيو ته ان مان تمام گهڻو فائدو ڪيئن حاصل ڪجي.
جو ذريعو: www.habr.com