نوٹ. ترجمہ: ہم گرافانا کے تخلیق کاروں کے زیر انتظام کلاؤڈ سروس میں حالیہ بند ہونے کی وجوہات کے بارے میں آپ کی توجہ کے لیے تکنیکی تفصیلات پیش کرتے ہیں۔ یہ ایک بہترین مثال ہے کہ کس طرح ایک نئی اور بظاہر انتہائی مفید خصوصیت جو بنیادی ڈھانچے کے معیار کو بہتر بنانے کے لیے بنائی گئی ہے... نقصان کا باعث بن سکتی ہے اگر آپ پیداوار کی حقیقتوں میں اس کے اطلاق کی متعدد باریکیوں کو فراہم نہیں کرتے ہیں۔ یہ بہت اچھا ہے جب اس طرح کے مواد ظاہر ہوتے ہیں جو آپ کو نہ صرف اپنی غلطیوں سے سیکھنے کی اجازت دیتے ہیں۔ تفصیلات گرافانا لیبز کے پروڈکٹ کے نائب صدر کے اس متن کے ترجمہ میں ہیں۔
جمعہ، 19 جولائی کو، Grafana Cloud میں میزبان Prometheus سروس نے تقریباً 30 منٹ تک کام کرنا بند کر دیا۔ میں بندش سے متاثر ہونے والے تمام صارفین سے معذرت خواہ ہوں۔ ہمارا کام مانیٹرنگ ٹولز فراہم کرنا ہے جس کی آپ کو ضرورت ہے، اور ہم سمجھتے ہیں کہ ان کا دستیاب نہ ہونا آپ کی زندگی کو مزید مشکل بنا سکتا ہے۔ ہم اس واقعے کو انتہائی سنجیدگی سے لیتے ہیں۔ یہ نوٹ بتاتا ہے کہ کیا ہوا، ہم نے کیسے جواب دیا، اور ہم اس بات کو یقینی بنانے کے لیے کیا کر رہے ہیں کہ ایسا دوبارہ نہ ہو۔
پس منظر
گرافانا کلاؤڈ ہوسٹڈ پرومیتھیس سروس پر مبنی ہے۔ CNCF پروجیکٹ افقی طور پر توسیع پذیر، انتہائی دستیاب، کثیر کرایہ دار پرومیتھیس سروس بنانے کے لیے۔ کارٹیکس فن تعمیر انفرادی مائیکرو سروسز کے ایک سیٹ پر مشتمل ہوتا ہے، جن میں سے ہر ایک اپنا کام انجام دیتا ہے: نقل، ذخیرہ، سوالات، وغیرہ۔ Cortex فعال ترقی کے تحت ہے اور مسلسل نئی خصوصیات شامل کر رہا ہے اور کارکردگی کو بہتر بنا رہا ہے۔ ہم باقاعدگی سے نئے Cortex ریلیز کو کلسٹرز میں تعینات کرتے ہیں تاکہ گاہک ان خصوصیات سے فائدہ اٹھا سکیں - خوش قسمتی سے، Cortex کو بغیر وقت کے اپ ڈیٹ کیا جا سکتا ہے۔
ہموار اپ ڈیٹس کے لیے، Ingester Cortex سروس کو اپ ڈیٹ کے عمل کے دوران ایک اضافی Ingester نقل کی ضرورت ہوتی ہے۔ (نوٹ. ترجمہ: - کارٹیکس کا بنیادی جزو۔ اس کا کام نمونوں کا ایک مستقل سلسلہ جمع کرنا ہے، انہیں پرومیتھیس کے ٹکڑوں میں گروپ کرنا ہے اور انہیں ڈائنامو ڈی بی، بگ ٹیبل یا کیسینڈرا جیسے ڈیٹا بیس میں محفوظ کرنا ہے۔) یہ پرانے Ingesters کو موجودہ ڈیٹا کو نئے Ingesters کو بھیجنے کی اجازت دیتا ہے۔ یہ بات قابل غور ہے کہ Ingesters وسائل کا مطالبہ کرتے ہیں۔ ان کے کام کرنے کے لیے، آپ کے پاس فی پوڈ 4 کور اور 15 جی بی میموری ہونا ضروری ہے، یعنی ہمارے Kubernetes کلسٹرز کے معاملے میں بیس مشین کی پروسیسنگ پاور اور میموری کا 25%۔ عام طور پر، ہمارے پاس عام طور پر کلسٹر میں 4 کور اور 15 جی بی میموری سے بہت زیادہ غیر استعمال شدہ وسائل ہوتے ہیں، لہذا ہم اپ گریڈ کے دوران ان اضافی انجیسٹرز کو آسانی سے گھما سکتے ہیں۔
تاہم، اکثر ایسا ہوتا ہے کہ عام آپریشن کے دوران کسی بھی مشین کے پاس یہ 25% غیر استعمال شدہ وسائل نہیں ہوتے۔ ہاں، ہم کوشش بھی نہیں کرتے: سی پی یو اور میموری ہمیشہ دوسرے عمل کے لیے کارآمد رہیں گے۔ اس مسئلے کو حل کرنے کے لیے، ہم نے استعمال کرنے کا فیصلہ کیا۔ . خیال یہ ہے کہ Ingesters کو دیگر (بے ریاست) مائیکرو سروسز کے مقابلے میں اعلیٰ ترجیح دی جائے۔ جب ہمیں ایک اضافی (N+1) Ingester چلانے کی ضرورت ہوتی ہے، تو ہم عارضی طور پر دوسری چھوٹی پھلیوں کو ہٹا دیتے ہیں۔ ان پوڈز کو دوسری مشینوں پر مفت وسائل میں منتقل کیا جاتا ہے، جس سے ایک اضافی انجسٹر چلانے کے لیے کافی بڑا "سوراخ" رہ جاتا ہے۔
جمعرات، 18 جولائی کو، ہم نے اپنے کلسٹرز کے لیے چار نئی ترجیحی سطحیں متعارف کروائیں: تنقیدی, اونچا, اوسط и کم. ان کا ایک اندرونی کلسٹر پر تجربہ کیا گیا جس میں کلائنٹ کی کوئی ٹریفک تقریباً ایک ہفتے تک نہیں تھی۔ پہلے سے طے شدہ طور پر، بغیر کسی مخصوص ترجیح کے پوڈ موصول ہوئے۔ اوسط ترجیح، کلاس Ingesters کے ساتھ مقرر کی گئی تھی۔ اونچا ترجیح تنقیدی نگرانی کے لیے مخصوص تھا (Prometheus، Alertmanager، node-exporter، kube-state-metrics، وغیرہ)۔ ہماری تشکیل کھلی ہے، اور آپ PR دیکھ سکتے ہیں۔ .
حادثہ
جمعہ، 19 جولائی کو، انجینئرز میں سے ایک نے ایک بڑے کلائنٹ کے لیے ایک نیا سرشار Cortex کلسٹر لانچ کیا۔ اس کلسٹر کی تشکیل میں پوڈ کی نئی ترجیحات شامل نہیں تھیں، اس لیے تمام نئے پوڈز کو پہلے سے طے شدہ ترجیح تفویض کی گئی تھی۔ اوسط.
Kubernetes کلسٹر کے پاس نئے Cortex کلسٹر کے لیے کافی وسائل نہیں تھے، اور موجودہ پروڈکشن Cortex کلسٹر کو اپ ڈیٹ نہیں کیا گیا تھا (Ingesters کو بغیر چھوڑ دیا گیا تھا اعلی ترجیح)۔ چونکہ نئے کلسٹر کے Ingesters پہلے سے طے شدہ تھے۔ اوسط ترجیح، اور پیداوار میں موجودہ پوڈز نے بالکل بھی ترجیح کے بغیر کام کیا، نئے کلسٹر کے Ingesters نے موجودہ Cortex پروڈکشن کلسٹر سے Ingesters کی جگہ لے لی۔
پروڈکشن کلسٹر میں بے دخل شدہ انجیسٹر کے لیے ReplicaSet نے بے دخل شدہ پوڈ کا پتہ لگایا اور کاپیوں کی مخصوص تعداد کو برقرار رکھنے کے لیے ایک نیا بنایا۔ نیا پوڈ بطور ڈیفالٹ تفویض کیا گیا تھا۔ اوسط ترجیح، اور پیداوار میں ایک اور "پرانا" انجیسٹر اپنے وسائل کھو بیٹھا۔ نتیجہ یہ نکلا۔ برفانی تودے کا عملجس کی وجہ سے Ingester for Cortex پروڈکشن کلسٹرز سے تمام پوڈز کی نقل مکانی ہوئی۔
انجسٹر اسٹیٹفول ہوتے ہیں اور پچھلے 12 گھنٹوں کا ڈیٹا اسٹور کرتے ہیں۔ یہ ہمیں طویل مدتی اسٹوریج پر لکھنے سے پہلے انہیں زیادہ مؤثر طریقے سے کمپریس کرنے کی اجازت دیتا ہے۔ اس کو حاصل کرنے کے لیے، Cortex ڈسٹری بیوٹڈ ہیش ٹیبل (DHT) کا استعمال کرتے ہوئے تمام سیریز کے ڈیٹا کو شارڈ کرتا ہے اور Dynamo طرز کورم کی مستقل مزاجی کا استعمال کرتے ہوئے ہر سیریز کو تین انجیسٹروں میں نقل کرتا ہے۔ Cortex Ingesters کو ڈیٹا نہیں لکھتا جو غیر فعال ہیں۔ اس طرح، جب Ingesters کی ایک بڑی تعداد DHT کو چھوڑ دیتی ہے، Cortex اندراجات کی کافی نقل فراہم نہیں کر سکتا، اور وہ کریش ہو جاتے ہیں۔
کھوج اور تدارک
"غلطی بجٹ" پر مبنی نئی پرومیتھیس اطلاعات (غلطی پر مبنی بجٹ — تفصیلات مستقبل کے مضمون میں ظاہر ہوں گی) نے شٹ ڈاؤن شروع ہونے کے 4 منٹ بعد الارم بجانا شروع کر دیا۔ اگلے پانچ منٹ یا اس سے زیادہ کے دوران، ہم نے کچھ تشخیصات چلائے اور نئے اور موجودہ دونوں پروڈکشن کلسٹروں کی میزبانی کے لیے بنیادی Kubernetes کلسٹر کو بڑھا دیا۔
مزید پانچ منٹ کے بعد، پرانے انجیسٹرز نے کامیابی کے ساتھ اپنا ڈیٹا لکھا، نئے شروع ہوئے، اور Cortex کلسٹر دوبارہ دستیاب ہو گئے۔
Cortex کے سامنے واقع توثیق ریورس پراکسیز سے آؤٹ آف میموری (OOM) کی غلطیوں کی تشخیص اور درست کرنے میں مزید 10 منٹ صرف کیے گئے۔ OOM کی غلطیاں QPS میں دس گنا اضافے کی وجہ سے ہوئیں (ہم سمجھتے ہیں کہ کلائنٹ کے Prometheus سرورز کی جانب سے حد سے زیادہ جارحانہ درخواستوں کی وجہ سے)۔
نتائج
کل ڈاؤن ٹائم 26 منٹ تھا۔ کوئی ڈیٹا ضائع نہیں ہوا۔ Ingesters کامیابی کے ساتھ تمام ان میموری ڈیٹا کو طویل مدتی اسٹوریج میں لوڈ کر چکے ہیں۔ شٹ ڈاؤن کے دوران، کلائنٹ Prometheus سرورز بفر کو حذف کر دیا گیا۔ (دور دراز) کا استعمال کرتے ہوئے ریکارڈنگ WAL پر مبنی (مصنف گرافانا لیبز سے) اور کریش کے بعد ناکام تحریروں کو دہرایا۔
پروڈکشن کلسٹر رائٹ آپریشنز
نتائج
اس واقعے سے سبق سیکھنا اور اس کے دوبارہ ہونے سے بچنے کے لیے ضروری اقدامات کرنا ضروری ہے۔
دور اندیشی میں، ہمیں ڈیفالٹ سیٹ نہیں کرنا چاہیے تھا۔ اوسط ترجیح اس وقت تک جب تک کہ پروڈکشن میں تمام انجسٹرز کو موصول نہ ہو جائے۔ اونچا ایک ترجیح اس کے علاوہ ان کا پہلے سے خیال رکھنا ضروری تھا۔ اعلی ترجیح اب سب کچھ ٹھیک ہے۔ ہم امید کرتے ہیں کہ ہمارا تجربہ دیگر تنظیموں کو Kubernetes میں پوڈ کی ترجیحات کے استعمال پر غور کرنے میں مدد کرے گا۔
ہم کسی بھی اضافی اشیاء کی تعیناتی پر کنٹرول کی ایک اضافی سطح شامل کریں گے جن کی ترتیب کلسٹر میں عالمی ہے۔ اب سے، اس طرح کی تبدیلیوں کا اندازہ لگایا جائے گا bоزیادہ لوگ. مزید برآں، حادثے کا سبب بننے والی ترمیم کو ایک علیحدہ پراجیکٹ دستاویز کے لیے بہت معمولی سمجھا جاتا تھا - اس پر صرف گٹ ہب کے مسئلے میں بات کی گئی تھی۔ اب سے، کنفیگرز میں ایسی تمام تبدیلیاں مناسب پروجیکٹ دستاویزات کے ساتھ ہوں گی۔
آخر میں، ہم اوورلوڈ OOM کو روکنے کے لیے توثیق ریورس پراکسی کے سائز کو خودکار بنائیں گے، اور مستقبل میں اسی طرح کے مسائل کو روکنے کے لیے فال بیک اور اسکیلنگ سے متعلق Prometheus ڈیفالٹ سیٹنگز کا جائزہ لیں گے۔
ناکامی کے کچھ مثبت نتائج بھی نکلے: ضروری وسائل حاصل کرنے کے بعد، Cortex بغیر کسی اضافی مداخلت کے خود بخود ٹھیک ہو گیا۔ ہم نے اس کے ساتھ کام کرنے کا قیمتی تجربہ بھی حاصل کیا۔ - ہمارا نیا لاگ ایگریگیشن سسٹم - جس نے اس بات کو یقینی بنانے میں مدد کی کہ تمام انجیسٹرز نے ناکامی کے دوران اور اس کے بعد صحیح برتاؤ کیا۔
مترجم سے PS
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com