لاگز سسٹم کا ایک اہم حصہ ہیں، جو آپ کو یہ سمجھنے کی اجازت دیتے ہیں کہ یہ توقع کے مطابق کام کر رہا ہے (یا کام نہیں کر رہا)۔ مائیکرو سرویس فن تعمیر میں، لاگز کے ساتھ کام کرنا خصوصی اولمپیاڈ کے لیے ایک الگ نظم بن جاتا ہے۔ سوالات کا ایک گروپ ایک ہی وقت میں حل کرنے کی ضرورت ہے:
- درخواست سے لاگ کیسے لکھیں؛
- نوشتہ جات کہاں لکھیں؛
- سٹوریج اور پروسیسنگ کے لیے لاگز کیسے ڈیلیور کریں؛
- لاگز پر کارروائی اور ذخیرہ کرنے کا طریقہ۔
فی الحال مقبول کنٹینرائزیشن ٹیکنالوجیز کا استعمال مسئلہ کو حل کرنے کے اختیارات کے میدان میں ریک کے اوپر ریت کا اضافہ کرتا ہے۔
یوری بشمیلیف کی رپورٹ "نوشتہ جمع کرنے اور پہنچانے کے میدان میں ریک کا نقشہ" کی نقل بالکل یہی ہے۔
کسی بھی دلچسپی کے لئے، براہ کرم بلی دیکھیں۔
میرا نام یوری بشمیلیف ہے۔ میں Lazada میں کام کرتا ہوں۔ آج میں اس بارے میں بات کروں گا کہ ہم نے اپنے نوشتہ جات کیسے بنائے، ہم نے انہیں کیسے جمع کیا، اور ہم وہاں کیا لکھتے ہیں۔
ہم کہاں سے ہیں؟ ہم کون ہیں؟ Lazada جنوب مشرقی ایشیا کے چھ ممالک میں نمبر 1 آن لائن خوردہ فروش ہے۔ یہ تمام ممالک ہمارے ڈیٹا سینٹرز میں تقسیم کیے گئے ہیں۔ اس وقت کل 4 ڈیٹا سینٹرز ہیں۔ یہ کیوں ضروری ہے؟ کیونکہ کچھ فیصلے اس وجہ سے ہوئے کہ مراکز کے درمیان بہت کمزور رابطہ ہے۔ ہمارے پاس ایک مائیکرو سروس فن تعمیر ہے۔ مجھے یہ جان کر حیرت ہوئی کہ ہمارے پاس پہلے ہی 80 مائیکرو سروسز ہیں۔ جب میں نے لاگز کے ساتھ کام شروع کیا تو ان میں سے صرف 20 تھے۔ اس کے علاوہ پی ایچ پی کی میراث کا ایک بڑا حصہ ہے، جس کے ساتھ مجھے بھی رہنا ہے اور اسے برداشت کرنا ہے۔ یہ سب فی الحال مجموعی طور پر سسٹم کے لیے 6 ملین سے زیادہ پیغامات فی منٹ پیدا کرتا ہے۔ اگلا میں دکھاؤں گا کہ ہم اس کے ساتھ کیسے جینے کی کوشش کر رہے ہیں، اور ایسا کیوں ہے۔
آپ کو کسی نہ کسی طرح ان 6 ملین پیغامات کے ساتھ رہنا ہوگا۔ ہم ان کے ساتھ کیا کریں؟ 6 ملین پیغامات جن کی آپ کو ضرورت ہے:
- ایپ سے بھیجیں۔
- ترسیل کے لئے قبول کریں
- تجزیہ اور ذخیرہ کرنے کے لیے فراہم کریں۔
- تجزیہ کریں
- اسے کسی طرح ذخیرہ کرو.
جب تیس لاکھ پیغامات نمودار ہوئے تو میں نے بھی ایسا ہی دیکھا۔ کیونکہ ہم نے صرف چند پیسوں سے شروعات کی۔ یہ واضح ہے کہ درخواست کے نوشتہ جات وہاں لکھے گئے ہیں۔ مثال کے طور پر، میں ڈیٹا بیس سے کنیکٹ نہیں ہو سکا، میں ڈیٹا بیس سے منسلک ہونے کے قابل تھا لیکن میں کچھ بھی نہیں پڑھ سکا۔ لیکن اس کے علاوہ، ہماری ہر مائیکرو سروسز ایک رسائی لاگ بھی لکھتی ہے۔ مائیکرو سروس پر آنے والی ہر درخواست لاگ میں ریکارڈ کی جاتی ہے۔ ہم ایسا کیوں کر رہے ہیں؟ ڈویلپرز ٹریس کرنے کے قابل ہونا چاہتے ہیں۔ ہر رسائی لاگ میں ایک ٹریسیڈ فیلڈ ہوتا ہے، جس کا استعمال کرتے ہوئے ایک خاص انٹرفیس پھر پوری چین کو کھولتا ہے اور خوبصورتی سے ٹریس کو ظاہر کرتا ہے۔ ٹریس سے پتہ چلتا ہے کہ درخواست کیسے ہوئی، اور اس سے ہمارے ڈویلپرز کو کسی بھی نامعلوم کوڑے سے فوری نمٹنے میں مدد ملتی ہے۔
اس کے ساتھ کیسے رہنا ہے؟ اب میں مختصراً آپشنز کے شعبے کی وضاحت کروں گا - یہ مسئلہ عام طور پر کیسے حل ہوتا ہے۔ نوشتہ جات کو جمع کرنے، منتقل کرنے اور ذخیرہ کرنے کے مسئلے کو کیسے حل کریں۔
درخواست سے کیسے لکھیں؟ یہ واضح ہے کہ مختلف طریقے ہیں. خاص طور پر، بہترین عمل ہے، جیسا کہ ہمارے فیشن ایبل ساتھی ہمیں بتاتے ہیں۔ پرانے اسکول کی دو قسمیں ہیں، جیسا کہ ہمارے دادا نے ہمیں بتایا تھا۔ اور بھی طریقے ہیں۔
نوشتہ جات جمع کرنے کی صورت حال تقریباً ایک جیسی ہے۔ اس خاص حصے کو حل کرنے کے لیے بہت سے اختیارات نہیں ہیں۔ ان میں سے پہلے ہی زیادہ ہیں، لیکن ابھی تک اتنے زیادہ نہیں ہیں۔
لیکن ترسیل اور اس کے بعد کے تجزیے کے ساتھ، تغیرات کی تعداد پھٹنا شروع ہو جاتی ہے۔ میں اب ہر آپشن کی وضاحت نہیں کروں گا۔ میرے خیال میں اہم اختیارات ہر اس شخص کو معلوم ہیں جو اس موضوع میں دلچسپی رکھتے ہیں۔
میں آپ کو دکھاؤں گا کہ ہم نے اسے لازادہ میں کیسے کیا، اور یہ سب حقیقت میں کیسے شروع ہوا۔
ایک سال پہلے میں لازادہ آیا تھا اور مجھے نوشتہ جات کے بارے میں ایک پروجیکٹ پر بھیجا گیا تھا۔ یہ کچھ اس طرح تھا۔ درخواست لاگ کو stdout اور stderr میں لکھا گیا تھا۔ سب کچھ فیشن کے انداز میں کیا گیا تھا۔ لیکن پھر ڈویلپرز نے اسے معیاری بہاؤ سے باہر پھینک دیا، اور پھر کسی نہ کسی طرح بنیادی ڈھانچے کے ماہرین اس کا پتہ لگائیں گے۔ انفراسٹرکچر کے ماہرین اور ڈویلپرز کے درمیان، ریلیز کرنے والے بھی موجود ہیں جنہوں نے کہا: "اوہ... ٹھیک ہے، آئیے انہیں صرف شیل کے ساتھ فائل میں لپیٹ دیں، اور بس۔" اور چونکہ یہ سب ایک کنٹینر میں تھا، اس لیے انہوں نے اسے کنٹینر میں ہی لپیٹا، کیٹلاگ کو اندر سے نقشہ بنا کر وہاں رکھ دیا۔ مجھے لگتا ہے کہ یہ سب کے لئے بالکل واضح ہے کہ اس سے کیا آیا ہے۔
آئیے ابھی تھوڑا آگے دیکھتے ہیں۔ ہم نے یہ نوشتہ کیسے پہنچایا؟ کسی نے td-agent کا انتخاب کیا، جو درحقیقت روانی ہے، لیکن بالکل روانی نہیں ہے۔ میں ابھی تک ان دونوں منصوبوں کے درمیان تعلق کو نہیں سمجھتا، لیکن لگتا ہے کہ وہ ایک ہی چیز کے بارے میں ہیں۔ اور یہ روانی، روبی میں لکھا گیا، لاگ فائلوں کو پڑھتا ہے، کسی قسم کی باقاعدگی کا استعمال کرتے ہوئے انہیں JSON میں پارس کرتا ہے۔ پھر میں نے انہیں کافکا کے پاس بھیج دیا۔ مزید یہ کہ، کافکا میں ہمارے پاس ہر API کے لیے 4 الگ الگ موضوعات تھے۔ کیوں 4؟ کیونکہ وہاں لائیو ہے، اسٹیجنگ ہے، اور کیونکہ وہاں stdout اور stderr ہے۔ ڈویلپرز انہیں تخلیق کرتے ہیں، اور انفراسٹرکچر ڈویلپرز کو انہیں کافکا میں تخلیق کرنا چاہیے۔ مزید یہ کہ کافکا کو ایک اور محکمے کے زیر کنٹرول تھا۔ اس لیے ٹکٹ بنانا ضروری تھا تاکہ وہ ہر اے پی آئی کے لیے 4 ٹاپکس بنائیں۔ سب اسے بھول گئے۔ عام طور پر کوڑا کرکٹ اور ہنگامہ آرائی تھی۔
اس کے بعد ہم نے کیا کیا؟ ہم نے اسے کافکا کو بھیجا۔ پھر کافکا کے آدھے نوشتہ جات Logstash کی طرف اڑ گئے۔ نوشتہ جات کا باقی آدھا حصہ تقسیم کیا گیا تھا۔ کچھ ایک گرےلوگ کی طرف اڑ گئے، کچھ دوسرے گرےلوگ کی طرف۔ نتیجے کے طور پر، یہ سب ایک Elasticsearch کلسٹر میں چلا گیا. یعنی یہ ساری گڑبڑ وہیں ختم ہو گئی۔ ایسا مت کرو!
اوپر سے دیکھیں تو ایسا ہی لگتا ہے۔ ایسا مت کرو! یہاں مسئلہ کے علاقوں کو فوری طور پر نمبروں کے ساتھ نشان زد کر دیا گیا ہے۔ درحقیقت ان میں سے اور بھی ہیں، لیکن 6 واقعی پریشانی والے ہیں جن کے بارے میں کچھ کرنے کی ضرورت ہے۔ اب میں آپ کو ان کے بارے میں الگ سے بتاتا ہوں۔
یہاں (1,2,3) ہم فائلیں لکھتے ہیں اور اس کے مطابق، یہاں ایک ساتھ تین ریک ہیں۔
پہلی (1) یہ ہے کہ ہمیں انہیں کہیں لکھنے کی ضرورت ہے۔ API کو کسی فائل میں براہ راست لکھنے کی صلاحیت دینا ہمیشہ مناسب نہیں ہوگا۔ یہ ضروری ہے کہ API کو ایک کنٹینر میں الگ تھلگ کیا جائے، یا اس سے بھی بہتر، کہ یہ صرف پڑھنے کے لیے ہو۔ میں ایک سسٹم ایڈمنسٹریٹر ہوں، اس لیے میرے پاس ان چیزوں کا تھوڑا سا متبادل نظریہ ہے۔
دوسرا نکتہ (2,3) یہ ہے کہ ہمارے پاس API میں بہت سی درخواستیں آرہی ہیں۔ API ایک فائل میں بہت زیادہ ڈیٹا لکھتا ہے۔ فائلیں بڑھ رہی ہیں۔ ہمیں انہیں گھمانے کی ضرورت ہے۔ کیونکہ بصورت دیگر آپ وہاں کسی بھی ڈسک پر ذخیرہ نہیں کر پائیں گے۔ ان کو گھمانا برا ہے کیونکہ وہ شیل کے ذریعے ڈائرکٹری میں ری ڈائریکٹ کرکے بنائے جاتے ہیں۔ اس پر نظر ثانی کرنے کا کوئی طریقہ نہیں ہے۔ آپ ایپلیکیشن کو ہینڈلز کو دوبارہ کھولنے کے لیے نہیں کہہ سکتے۔ کیونکہ ڈویلپرز آپ کو اس طرح دیکھیں گے جیسے آپ احمق ہیں: "کیا وضاحت کنندہ؟ ہم عام طور پر stdout کو لکھتے ہیں۔" انفراسٹرکچر ڈویلپرز نے لاگروٹیٹ کے لیے کاپی ٹرنکیٹ بنایا، جو فائل کی ایک کاپی بناتا ہے اور اصل کو نقل کرتا ہے۔ اس کے مطابق، ان کاپی کرنے کے عمل کے درمیان عام طور پر ڈسک کی جگہ ختم ہوجاتی ہے۔
(4) ہمارے پاس مختلف APIs میں مختلف فارمیٹس تھے۔ وہ قدرے مختلف تھے، لیکن regexp کو مختلف طریقے سے لکھنا پڑا۔ چونکہ یہ سب کچھ Puppet کے زیر کنٹرول تھا، اس لیے کلاسوں کا ایک بڑا گروپ تھا جس کے اپنے کاکروچ تھے۔ اس کے علاوہ، زیادہ تر وقت td-agent میموری کھا سکتا ہے، بیوقوف ہو سکتا ہے، یہ صرف دکھاوا کر سکتا ہے کہ یہ کام کر رہا ہے اور کچھ نہیں کر سکتا۔ باہر سے یہ سمجھنا ناممکن تھا کہ وہ کچھ نہیں کر رہا تھا۔ بہترین طور پر، وہ گر جائے گا اور بعد میں کوئی اسے اٹھا لے گا۔ مزید واضح طور پر، ایک انتباہ آئے گا، اور کوئی جائے گا اور اسے اپنے ہاتھوں سے اٹھائے گا۔
(6) اور سب سے زیادہ کچرا اور فضلہ لچکدار تلاش تھا۔ کیونکہ یہ پرانا ورژن تھا۔ کیونکہ اس وقت ہمارے پاس سرشار استاد نہیں تھے۔ ہمارے پاس متفاوت نوشتہ جات تھے جن کے فیلڈز اوورلیپ ہو سکتے تھے۔ مختلف ایپلی کیشنز کے مختلف لاگز کو ایک ہی فیلڈ کے ناموں سے لکھا جا سکتا ہے، لیکن اندر مختلف ڈیٹا ہو سکتا ہے۔ یعنی فیلڈ میں ایک لاگ انٹیجر کے ساتھ آتا ہے، مثال کے طور پر لیول۔ ایک اور لاگ لیول فیلڈ میں String کے ساتھ آتا ہے۔ جامد نقشہ سازی کی غیر موجودگی میں، یہ ایک ایسی شاندار چیز ہے. اگر، elasticsearch میں انڈیکس کو گھمانے کے بعد، سٹرنگ والا پیغام پہلے آتا ہے، تو ہم عام طور پر رہتے ہیں۔ لیکن اگر پہلا نمبر Integer سے آیا ہے، تو اس کے بعد کے تمام پیغامات جو String سے آئے ہیں، صرف رد کر دیے جائیں گے۔ کیونکہ فیلڈ کی قسم مماثل نہیں ہے۔
ہم نے یہ سوالات پوچھنا شروع کر دیے۔ ہم نے فیصلہ کیا کہ الزام لگانے والوں کی تلاش نہ کریں۔
لیکن کچھ کرنے کی ضرورت ہے! واضح بات یہ ہے کہ ہمیں معیارات قائم کرنے کی ضرورت ہے۔ ہمارے پاس پہلے سے ہی کچھ معیار تھے۔ ہم نے کچھ دیر بعد شروع کیا۔ خوش قسمتی سے، اس وقت تمام APIs کے لیے ایک ہی لاگ فارمیٹ پہلے ہی منظور ہو چکا تھا۔ یہ خدمات کے درمیان تعامل کے معیارات میں براہ راست لکھا جاتا ہے۔ اس کے مطابق، جو لوگ لاگ وصول کرنا چاہتے ہیں انہیں اس فارمیٹ میں لکھنا چاہیے۔ اگر کوئی اس فارمیٹ میں لاگز نہیں لکھتا ہے، تو ہم کسی چیز کی ضمانت نہیں دیتے۔
اگلا، میں ریکارڈنگ، ڈیلیور کرنے اور نوشتہ جمع کرنے کے طریقوں کے لیے ایک متفقہ معیار بنانا چاہوں گا۔ دراصل، انہیں کہاں لکھنا ہے، اور انہیں کیسے پہنچانا ہے۔ مثالی صورت حال وہ ہے جب منصوبے ایک ہی لائبریری کا استعمال کرتے ہیں۔ گو کے لیے الگ لاگنگ لائبریری ہے، اور پی ایچ پی کے لیے الگ لائبریری ہے۔ ہمارے پاس ہر ایک کو ان کا استعمال کرنا چاہئے۔ اس وقت میں کہوں گا کہ ہم اس میں 80 فیصد کامیاب ہیں۔ لیکن کچھ لوگ کیکٹی کھاتے رہتے ہیں۔
اور وہاں (سلائیڈ پر) "لاگز کی ترسیل کے لیے SLA" بمشکل ظاہر ہونا شروع ہوتا ہے۔ یہ ابھی موجود نہیں ہے، لیکن ہم اس پر کام کر رہے ہیں۔ کیونکہ یہ بہت آسان ہوتا ہے جب انفراسٹرکچر کہتا ہے کہ اگر آپ فلاں فلاں جگہ پر فلاں فارمیٹ میں لکھتے ہیں اور فی سیکنڈ N سے زیادہ پیغامات نہیں ہوتے ہیں، تو ہم اسے فلاں جگہ پہنچا دیں گے۔ اس سے سر کے درد میں کافی آرام آتا ہے۔ اگر کوئی SLA ہے، تو یہ بالکل شاندار ہے!
ہم نے مسئلہ کو کیسے حل کرنا شروع کیا؟ اہم مسئلہ td-agent کے ساتھ تھا۔ یہ واضح نہیں تھا کہ ہمارے نوشتہ جات کہاں گئے۔ کیا وہ پہنچا دیے گئے ہیں؟ کیا وہ جا رہے ہیں؟ وہ ویسے بھی کہاں ہیں؟ لہذا، پہلے نکتہ کو ٹی ڈی ایجنٹ کو تبدیل کرنے کا فیصلہ کیا گیا۔ میں نے مختصراً آپشنز کا خاکہ پیش کیا ہے کہ اسے یہاں کیا بدلنا ہے۔
روانی سب سے پہلے، میرا اس سے پچھلی نوکری پر سامنا ہوا، اور وہ بھی وقتاً فوقتاً وہاں گرتا رہا۔ دوسری بات، یہ وہی چیز ہے، صرف پروفائل میں۔
فائل بیٹ۔ یہ ہمارے لیے کتنا آسان تھا؟ کیونکہ یہ گو میں ہے، اور ہمارے پاس گو میں کافی مہارت ہے۔ اس کے مطابق، اگر کچھ ہوا، تو ہم کسی نہ کسی طرح اپنے لیے اس میں اضافہ کر سکتے ہیں۔ اس لیے ہم نے نہیں لیا۔ تاکہ اسے اپنے لیے دوبارہ لکھنا شروع کرنے کا کوئی لالچ بھی نہ ہو۔
سسٹم ایڈمنسٹریٹر کے لیے واضح حل اس مقدار میں ہر قسم کے syslogs ہیں (syslog-ng/rsyslog/nxlog)۔
یا اپنا کچھ لکھیں، لیکن ہم نے اس کے ساتھ ساتھ فائل بیٹ کو بھی مسترد کر دیا۔ اگر آپ کچھ لکھتے ہیں تو بہتر ہے کہ کاروبار کے لیے مفید کچھ لکھیں۔ نوشتہ جات کی فراہمی کے لیے بہتر ہے کہ کچھ ریڈی میڈ لیں۔
لہذا، انتخاب دراصل syslog-ng اور rsyslog کے درمیان انتخاب پر آیا۔ میں نے rsyslog کی طرف صرف اس لیے جھکایا کہ ہمارے پاس Puppet میں rsyslog کے لیے پہلے سے ہی کلاسز موجود ہیں، اور مجھے ان کے درمیان کوئی واضح فرق نہیں ملا۔ syslog کیا ہے، syslog کیا ہے. ہاں، کچھ کے پاس دستاویزات بدتر ہیں، کچھ کے پاس بہتر ہے۔ یہ اس طرح کر سکتا ہے، اور دوسرا اسے مختلف طریقے سے کر سکتا ہے۔
اور rsyslog کے بارے میں تھوڑا سا۔ سب سے پہلے، یہ ٹھنڈا ہے کیونکہ اس میں بہت سارے ماڈیول ہیں۔ اس میں انسانی پڑھنے کے قابل RainerScript (ایک جدید ترتیب کی زبان) ہے۔ یہ ایک زبردست بونس ہے کہ ہم معیاری ٹولز کا استعمال کرتے ہوئے td-agent کے رویے کی تقلید کر سکتے ہیں، اور ایپلیکیشنز کے لیے کچھ بھی نہیں بدلا۔ یعنی، ہم td-agent کو rsyslog میں تبدیل کرتے ہیں، اور باقی سب کچھ ابھی کے لیے چھوڑ دیتے ہیں۔ اور ہمیں فوری طور پر ورکنگ ڈیلیوری موصول ہوتی ہے۔ اگلا، mmnormalize rsyslog میں ایک زبردست چیز ہے۔ یہ آپ کو لاگز کو پارس کرنے کی اجازت دیتا ہے، لیکن Grok اور regexp کے ساتھ نہیں۔ یہ ایک تجریدی نحوی درخت بناتا ہے۔ یہ لاگز کو اسی طرح پارس کرتا ہے جس طرح ایک کمپائلر ذرائع کو پارس کرتا ہے۔ یہ آپ کو بہت تیزی سے کام کرنے، تھوڑا سا CPU استعمال کرنے کی اجازت دیتا ہے، اور عام طور پر، یہ واقعی ایک اچھی چیز ہے۔ دوسرے بونس کا ایک گروپ ہے۔ میں ان پر نہیں رہوں گا۔
rsyslog کے بہت سے دوسرے نقصانات ہیں۔ وہ بونس کے بارے میں ایک جیسے ہیں۔ اہم مسائل یہ ہیں کہ آپ کو یہ جاننے کی ضرورت ہے کہ اسے کیسے پکانا ہے، اور آپ کو ورژن منتخب کرنے کی ضرورت ہے۔
ہم نے فیصلہ کیا کہ ہم یونکس ساکٹ پر لاگ لکھیں گے۔ اور /dev/log میں نہیں، کیونکہ وہاں ہمارے پاس سسٹم لاگز کا گڑبڑ ہے، جرنلڈ اس پائپ لائن میں ہے۔ تو آئیے اپنی مرضی کے ساکٹ پر لکھتے ہیں۔ ہم اسے ایک علیحدہ قواعد کے ساتھ منسلک کریں گے۔ آئیے کسی چیز میں مداخلت نہ کریں۔ سب کچھ شفاف اور قابل فہم ہوگا۔ ہم نے بالکل ایسا ہی کیا۔ ان ساکٹ کے ساتھ ڈائریکٹری معیاری ہے اور تمام کنٹینرز کو بھیجی جاتی ہے۔ کنٹینرز اپنی ضرورت کی ساکٹ دیکھ سکتے ہیں، کھول سکتے ہیں اور اس پر لکھ سکتے ہیں۔
فائل کیوں نہیں؟ کیونکہ سب نے پڑھا ہے۔ ، جس نے ایک فائل کو docker کو بھیجنے کی کوشش کی، اور یہ پتہ چلا کہ rsyslog کو دوبارہ شروع کرنے کے بعد، فائل کا ڈسکرپٹر بدل گیا، اور docker نے یہ فائل کھو دی۔ یہ کچھ اور کھلا رکھتا ہے، لیکن ساکٹ نہیں جہاں وہ لکھ رہے ہیں۔ ہم نے فیصلہ کیا کہ ہم اس مسئلے کو حل کریں گے، اور ساتھ ہی، ہم مسدود کرنے کے مسئلے پر بھی کام کریں گے۔
Rsyslog سلائیڈ پر اشارہ کردہ اعمال انجام دیتا ہے اور ریلے یا کافکا کو لاگ بھیجتا ہے۔ کافکا پرانے راستے کی پیروی کرتا ہے۔ Relay - میں نے نوشتہ جات کی فراہمی کے لیے خالص rsyslog استعمال کرنے کی کوشش کی۔ پیغام کی قطار کے بغیر، معیاری rsyslog ٹولز کا استعمال کرتے ہوئے بنیادی طور پر، یہ کام کرتا ہے.
لیکن ان کو اس حصے میں کیسے دھکیلنا ہے اس کے بارے میں باریکیاں موجود ہیں (Logstash/Graylog/ES)۔ یہ حصہ (rsyslog-rsyslog) ڈیٹا سینٹرز کے درمیان استعمال ہوتا ہے۔ یہاں ایک کمپریسڈ tcp لنک ہے، جو ہمیں بینڈوتھ کو بچانے کی اجازت دیتا ہے اور، اس کے مطابق، کسی نہ کسی طرح اس امکان کو بڑھاتا ہے کہ چینل بند ہونے پر ہمیں کسی دوسرے ڈیٹا سینٹر سے کچھ لاگز موصول ہوں گے۔ کیونکہ ہمارے پاس انڈونیشیا ہے، جہاں سب کچھ خراب ہے۔ یہ وہ جگہ ہے جہاں مستقل مسئلہ رہتا ہے۔
ہم نے اس کے بارے میں سوچا کہ ہم حقیقت میں کس طرح نگرانی کر سکتے ہیں کہ اس بات کا کتنا امکان ہے کہ ہم نے درخواست سے جو لاگز ریکارڈ کیے ہیں وہ آخر تک پہنچ جائیں گے؟ ہم نے میٹرکس بنانے کا فیصلہ کیا۔ rsyslog کا اپنا شماریات جمع کرنے کا ماڈیول ہے، جس میں کچھ قسم کے کاؤنٹرز ہوتے ہیں۔ مثال کے طور پر، یہ آپ کو قطار کا سائز دکھا سکتا ہے، یا فلاں فلاں کارروائی میں کتنے پیغامات آئے ہیں۔ آپ ان سے پہلے ہی کچھ لے سکتے ہیں۔ اس کے علاوہ، اس میں حسب ضرورت کاؤنٹرز ہیں جنہیں ترتیب دیا جا سکتا ہے، اور یہ آپ کو دکھائے گا، مثال کے طور پر، کچھ API ریکارڈ کیے گئے پیغامات کی تعداد۔ اگلا، میں نے Python میں rsyslog_exporter لکھا، اور ہم نے یہ سب Prometheus کو بھیج دیا اور گراف بنائے۔ ہم واقعی Graylog میٹرکس چاہتے تھے، لیکن ہمارے پاس ابھی تک انہیں ترتیب دینے کا وقت نہیں ہے۔
مسائل کیا تھے؟ مسائل اس وقت پیدا ہوئے جب ہم نے دریافت کیا (اچانک!) کہ ہمارے Live APIs فی سیکنڈ 50k پیغامات لکھ رہے ہیں۔ یہ بغیر اسٹیج کے صرف ایک لائیو API ہے۔ اور Graylog ہمیں صرف 12 ہزار پیغامات فی سیکنڈ دکھاتا ہے۔ اور ایک معقول سوال پیدا ہوا: باقیات کہاں ہیں؟ جس سے ہم نے یہ نتیجہ اخذ کیا کہ Graylog آسانی سے مقابلہ نہیں کر سکتا۔ ہم نے دیکھا، اور، واقعی، Graylog اور Elasticsearch اس بہاؤ کو سنبھال نہیں سکے۔
اگلا، دوسری دریافتیں جو ہم نے راستے میں کیں۔
ساکٹ پر لکھنا مسدود ہے۔ یہ کیسے ممکن ہوا؟ جب میں ڈیلیوری کے لیے rsyslog استعمال کر رہا تھا، کسی وقت ڈیٹا سینٹرز کے درمیان چینل ٹوٹ گیا۔ ڈلیوری ایک جگہ رکی، دوسری جگہ ڈیلیوری رک گئی۔ یہ سب APIs کے ساتھ مشین تک پہنچ گیا ہے جو rsyslog ساکٹ پر لکھتے ہیں۔ وہاں ایک قطار لگی ہوئی تھی۔ پھر یونکس ساکٹ پر لکھنے کے لیے قطار، جو پہلے سے طے شدہ طور پر 128 پیکٹوں پر مشتمل ہے، بھر گئی۔ اور ایپلی کیشن میں اگلی تحریر () بلاک ہے۔ جب ہم نے اس لائبریری کو دیکھا جسے ہم گو ایپلی کیشنز میں استعمال کرتے ہیں تو وہاں لکھا تھا کہ ساکٹ پر لکھنا نان بلاکنگ موڈ میں ہوتا ہے۔ ہمیں یقین تھا کہ کچھ بھی بلاک نہیں کیا گیا تھا۔ کیونکہ ہم پڑھتے ہیں۔ جس نے اس کے بارے میں لکھا۔ لیکن ایک لمحہ ہے۔ اس کال کے ارد گرد ایک لامحدود لوپ بھی تھا، جس میں ایک پیغام کو ساکٹ میں دھکیلنے کی مسلسل کوشش تھی۔ ہم نے اسے نوٹس نہیں کیا۔ مجھے لائبریری کو دوبارہ لکھنا پڑا۔ اس کے بعد سے یہ کئی بار تبدیل ہو چکا ہے، لیکن اب ہم نے تمام سب سسٹمز میں بلاکنگ سے چھٹکارا حاصل کر لیا ہے۔ لہذا، آپ rsyslog کو روک سکتے ہیں، اور کچھ بھی کریش نہیں ہوگا۔
قطاروں کے سائز کی نگرانی کرنا ضروری ہے، جو اس ریک پر قدم رکھنے سے بچنے میں مدد کرتا ہے۔ سب سے پہلے، ہم نگرانی کر سکتے ہیں جب ہم پیغامات کو کھونا شروع کرتے ہیں۔ دوسرا، ہم نگرانی کر سکتے ہیں کہ ہمیں ترسیل کے ساتھ مسائل ہیں.
اور ایک اور ناخوشگوار لمحہ - مائکرو سروس فن تعمیر میں 10 گنا بڑھانا بہت آسان ہے۔ ہمارے پاس آنے والی بہت سی درخواستیں نہیں ہیں، لیکن اس گراف کی وجہ سے جس کے ساتھ یہ پیغامات مزید سفر کرتے ہیں، رسائی کے نوشتہ جات کی وجہ سے، ہم اصل میں لاگ لوڈ کو تقریباً دس گنا بڑھا دیتے ہیں۔ بدقسمتی سے، میرے پاس صحیح نمبروں کا حساب لگانے کا وقت نہیں تھا، لیکن مائیکرو سروسز وہی ہیں جو وہ ہیں۔ اس بات کو ذہن میں رکھنا چاہیے۔ یہ پتہ چلتا ہے کہ اس وقت لاگ کلیکشن سب سسٹم لازادہ میں سب سے زیادہ بھرا ہوا ہے۔
لچکدار تلاش کا مسئلہ کیسے حل کیا جائے؟ اگر آپ کو فوری طور پر ایک جگہ سے لاگز حاصل کرنے کی ضرورت ہے، تاکہ تمام مشینوں کی طرف بھاگ کر انہیں وہاں جمع نہ کریں، فائل اسٹوریج کا استعمال کریں۔ یہ کام کرنے کی ضمانت ہے۔ یہ کسی بھی سرور سے کیا جا سکتا ہے۔ آپ کو صرف وہاں ڈسکیں لگانے اور syslog انسٹال کرنے کی ضرورت ہے۔ اس کے بعد، آپ کو تمام لاگز ایک جگہ پر ہونے کی ضمانت دی جاتی ہے۔ پھر آپ آہستہ آہستہ elasticsearch، graylog، اور کچھ اور ترتیب دے سکتے ہیں۔ لیکن آپ کے پاس پہلے سے ہی تمام لاگز ہوں گے، اور اس کے علاوہ، آپ انہیں اس وقت تک ذخیرہ کر سکتے ہیں جہاں تک کافی ڈسک صفیں موجود ہوں۔
میری رپورٹ کے وقت یہ سکیم کچھ یوں نظر آنے لگی۔ ہم نے عملی طور پر فائل پر لکھنا چھوڑ دیا۔ اب، غالباً، ہم باقی کو بند کر دیں گے۔ API چلانے والی مقامی مشینوں پر، ہم فائلوں کو لکھنا بند کر دیں گے۔ سب سے پہلے، فائل اسٹوریج ہے، جو بہت اچھی طرح سے کام کرتا ہے. دوسری بات یہ کہ یہ مشینیں مسلسل جگہ ختم کر رہی ہیں، اس پر مسلسل نظر رکھنے کی ضرورت ہے۔
Logstash اور Graylog کے ساتھ یہ حصہ، یہ واقعی شروع ہوتا ہے. اس لیے ہمیں اس سے چھٹکارا حاصل کرنے کی ضرورت ہے۔ آپ کو ایک چیز کا انتخاب کرنا ہوگا۔
ہم نے Logstash اور Kibana کو باہر پھینکنے کا فیصلہ کیا۔ کیونکہ ہمارے پاس سیکورٹی کا محکمہ ہے۔ کیا کنکشن؟ کنکشن یہ ہے کہ کبانا ایکس پیک کے بغیر اور شیلڈ کے بغیر آپ کو لاگز تک رسائی کے حقوق میں فرق کرنے کی اجازت نہیں دیتا ہے۔ اسی لیے ہم نے Graylog لیا ہے۔ اس کے پاس یہ سب ہے۔ مجھے یہ پسند نہیں ہے، لیکن یہ کام کرتا ہے۔ ہم نے نیا ہارڈویئر خریدا، وہاں تازہ گرے لاگ انسٹال کیا اور سخت فارمیٹس والے تمام لاگز کو علیحدہ گرے لاگ میں منتقل کیا۔ ہم نے تنظیمی طور پر ایک جیسے شعبوں کی مختلف اقسام کے ساتھ مسئلہ کو حل کیا۔
نئے Graylog میں بالکل کیا شامل ہے۔ ہم نے صرف ڈوکر میں سب کچھ لکھا ہے۔ ہم نے سرورز کا ایک گروپ لیا، تین کافکا مثالیں تیار کیں، 7 گرے لاگ سرورز ورژن 2.3 (کیونکہ ہم Elasticsearch ورژن 5 چاہتے تھے)۔ یہ سب ایچ ڈی ڈی سے چھاپوں کے دوران اٹھایا گیا تھا۔ ہم نے فی سیکنڈ 100 ہزار پیغامات کی اشاریہ سازی کی شرح دیکھی۔ ہم نے اعداد و شمار کو دیکھا کہ فی ہفتہ 140 ٹیرا بائٹس ڈیٹا۔
اور پھر ریک! ہمارے پاس دو فروخت آرہی ہیں۔ ہم 6 ملین پیغامات سے آگے بڑھ گئے۔ گرے لاگ کے پاس چبانے کا وقت نہیں ہے۔ کسی نہ کسی طرح ہمیں دوبارہ زندہ رہنا ہے۔
اس طرح ہم بچ گئے۔ ہم نے کچھ اور سرورز اور SSDs شامل کیے۔ اس وقت ہم اس طرح رہتے ہیں۔ اب ہم پہلے ہی 160k پیغامات فی سیکنڈ چبا رہے ہیں۔ ہم نے ابھی حد تک نہیں پہنچی ہے، اس لیے یہ واضح نہیں ہے کہ ہم اس سے کتنا نکل سکتے ہیں۔
یہ مستقبل کے لیے ہمارے منصوبے ہیں۔ ان میں سے، سب سے اہم شاید زیادہ دستیابی ہے۔ ہمارے پاس ابھی تک نہیں ہے۔ کئی کاریں اسی طرح ترتیب دی گئی ہیں، لیکن اب تک سب کچھ ایک ہی کار سے ہو رہا ہے۔ ان کے درمیان فیل اوور قائم کرنے میں وقت لگتا ہے۔
Graylog سے میٹرکس جمع کریں۔
شرح کی حد بنائیں تاکہ ہمارے پاس ایک پاگل API ہے جو ہماری بینڈوتھ اور ہر چیز کو ختم نہیں کرتا ہے۔
اور آخر میں، ڈویلپرز کے ساتھ کسی قسم کے SLA پر دستخط کریں تاکہ ہم اتنی خدمت کر سکیں۔ اگر آپ مزید لکھیں تو معذرت خواہ ہوں۔
اور دستاویزات لکھیں۔
مختصراً، ہم نے جو کچھ بھی تجربہ کیا اس کے نتائج۔ سب سے پہلے، معیارات. دوسرا، syslog کیک ہے. تیسرا، rsyslog بالکل اسی طرح کام کرتا ہے جیسا کہ سلائیڈ پر لکھا ہے۔ اور آئیے سوالات کی طرف بڑھتے ہیں۔
آپ کے سوالات.
سوال: آپ نے نہ لینے کا فیصلہ کیوں کیا... (فائل بیٹ؟)
جواب: ہمیں ایک فائل پر لکھنے کی ضرورت ہے۔ میں واقعی نہیں چاہتا تھا۔ جب آپ کا API فی سیکنڈ ہزاروں پیغامات لکھتا ہے، چاہے آپ اسے گھنٹہ میں ایک بار گھمائیں، تب بھی یہ آپشن نہیں ہے۔ آپ پائپ میں لکھ سکتے ہیں۔ جس پر ڈویلپرز نے مجھ سے پوچھا: "اگر ہم جس عمل کو کریش کرنے کے لیے لکھ رہے ہیں تو کیا ہوگا؟" مجھے ابھی یہ نہیں ملا کہ ان کو کیا جواب دوں، اور کہا: "ٹھیک ہے، چلو ایسا نہیں کرتے۔"
سوال: آپ صرف HDFS پر لاگ کیوں نہیں لکھتے؟
جواب: یہ اگلا مرحلہ ہے۔ ہم نے شروع میں ہی اس کے بارے میں سوچا تھا، لیکن چونکہ اس وقت ایسا کرنے کے لیے وسائل نہیں ہیں، اس لیے یہ ہمارے طویل مدتی حل میں لٹکا ہوا ہے۔
سوال: کالم کی شکل زیادہ موزوں ہوگی۔
جواب: میں سمجھتا ہوں۔ ہم دونوں ہاتھوں سے اس کے لیے ہیں۔
سوال: آپ rsyslog پر لکھ رہے ہیں۔ وہاں آپ TCP اور UDP دونوں استعمال کر سکتے ہیں۔ لیکن اگر UDP، تو پھر آپ ترسیل کی ضمانت کیسے دیتے ہیں؟
جواب: دو نکات ہیں۔ سب سے پہلے، میں فوراً سب کو بتاتا ہوں کہ ہم لاگز کی ترسیل کی ضمانت نہیں دیتے۔ کیونکہ جب ڈویلپر آتے ہیں اور کہتے ہیں: "آئیے وہاں مالیاتی ڈیٹا لکھنا شروع کریں، اور کچھ ہونے کی صورت میں آپ اسے ہمارے لیے کہیں رکھ دیں گے،" ہم انہیں جواب دیتے ہیں، "بہت اچھا! آئیے ساکٹ پر لکھنے پر روکنا شروع کریں، اور یہ لین دین میں کریں، تاکہ آپ کو ضمانت دی جائے کہ آپ اسے ہمارے لیے ساکٹ پر رکھیں گے اور اس بات کو یقینی بنائیں کہ ہم اسے دوسری طرف سے وصول کریں۔ اور اس وقت، ہر ایک کو فوری طور پر اس کی ضرورت نہیں ہے. اگر یہ ضروری نہیں ہے تو پھر ہم کون سے سوالات پوچھیں؟ اگر آپ ساکٹ پر لکھنے کی ضمانت نہیں دینا چاہتے ہیں، تو ہمیں ترسیل کی ضمانت دینے کی کیا ضرورت ہے؟ ہم اپنی پوری کوشش کر رہے ہیں۔ ہم واقعی زیادہ سے زیادہ اور بہترین طریقے سے ڈیلیور کرنے کی کوشش کرتے ہیں، لیکن ہم 100% گارنٹی نہیں دیتے۔ اس لیے وہاں مالیاتی ڈیٹا لکھنے کی ضرورت نہیں ہے۔ اس کے لیے لین دین کے ساتھ ڈیٹا بیس موجود ہیں۔
سوال: جب API لاگ میں کچھ پیغام تیار کرتا ہے اور کنٹرول کو مائیکرو سروسز میں منتقل کرتا ہے، تو کیا آپ کو اس مسئلے کا سامنا کرنا پڑا ہے کہ مختلف مائیکرو سروسز سے پیغامات غلط ترتیب میں آتے ہیں؟ اس سے الجھن پیدا ہوتی ہے۔
جواب: یہ عام بات ہے کہ وہ مختلف ترتیبوں میں آتے ہیں۔ آپ کو اس کے لیے تیار رہنے کی ضرورت ہے۔ کیونکہ کوئی بھی نیٹ ورک ڈیلیوری آرڈر کی ضمانت نہیں دیتا، یا آپ کو اس پر خصوصی وسائل خرچ کرنے پڑتے ہیں۔ اگر ہم فائل اسٹوریج لیتے ہیں، تو ہر API لاگز کو اپنی فائل میں محفوظ کرتا ہے۔ یا اس کے بجائے، وہاں rsyslog انہیں ڈائریکٹریوں میں ترتیب دیتا ہے۔ ہر API کے اپنے لاگز ہوتے ہیں، جہاں آپ جا کر دیکھ سکتے ہیں، اور پھر آپ اس لاگ میں ٹائم سٹیمپ کا استعمال کرتے ہوئے ان کا موازنہ کر سکتے ہیں۔ اگر وہ Graylog میں دیکھتے ہیں، تو وہ وہاں ٹائم اسٹیمپ کے مطابق ترتیب دیے جاتے ہیں۔ وہاں سب ٹھیک ہو جائے گا۔
سوال: ٹائم اسٹیمپ ملی سیکنڈ کے لحاظ سے مختلف ہو سکتا ہے۔
جواب: ٹائم اسٹیمپ خود API کے ذریعہ تیار کیا جاتا ہے۔ یہ، حقیقت میں، پوری بات ہے. ہمارے پاس NTP ہے۔ API پیغام میں ہی ٹائم اسٹیمپ تیار کرتا ہے۔ rsyslog اسے شامل نہیں کرتا ہے۔
سوال: ڈیٹا سینٹرز کے درمیان تعامل بہت واضح نہیں ہے۔ ڈیٹا سینٹر کے اندر، یہ واضح ہے کہ لاگز کو کیسے جمع کیا گیا اور اس پر کارروائی کی گئی۔ ڈیٹا سینٹرز کے درمیان تعامل کیسے ہوتا ہے؟ یا کیا ہر ڈیٹا سینٹر اپنی زندگی گزارتا ہے؟
جواب: تقریبا. ہمارے ملک میں، ہر ملک ایک ڈیٹا سینٹر میں واقع ہے۔ اس وقت، ہمارے پاس اسپریڈ آؤٹ نہیں ہے کہ ایک ملک مختلف ڈیٹا سینٹرز میں واقع ہے۔ لہذا، ان کو یکجا کرنے کی ضرورت نہیں ہے. ہر مرکز کے اندر ایک لاگ ریلے ہوتا ہے۔ یہ ایک Rsyslog سرور ہے۔ اصل میں دو انتظامی مشینیں۔ ان کا بھی یہی رویہ ہے۔ لیکن ابھی کے لیے، ٹریفک صرف ان میں سے ایک سے گزرتی ہے۔ یہ تمام نوشتہ جات کو جمع کرتا ہے۔ اس کے پاس صرف اس صورت میں ڈسک کی قطار ہے۔ یہ لاگز کو ڈاؤن لوڈ کرتا ہے اور انہیں سینٹرل ڈیٹا سینٹر (سنگاپور) بھیجتا ہے، جہاں سے وہ گرے لاگ کو بھیجے جاتے ہیں۔ اور ہر ڈیٹا سینٹر کا اپنا فائل اسٹوریج ہوتا ہے۔ اگر ہمارا کنکشن منقطع ہو جائے تو ہمارے پاس تمام لاگز موجود ہیں۔ وہ وہیں رہیں گے۔ انہیں وہاں ذخیرہ کیا جائے گا۔
سوال: غیر معمولی حالات کی صورت میں، کیا آپ کو وہاں سے نوشتہ جات موصول ہوتے ہیں؟
جواب: آپ وہاں جا سکتے ہیں (فائل اسٹوریج میں) اور دیکھ سکتے ہیں۔
سوال: آپ کیسے مانیٹر کرتے ہیں کہ آپ لاگز نہیں کھو رہے ہیں؟
جواب: ہم دراصل انہیں کھو رہے ہیں، اور ہم اس کی نگرانی کر رہے ہیں۔ مانیٹرنگ کا آغاز ایک ماہ قبل کیا گیا تھا۔ لائبریری جو Go APIs استعمال کرتے ہیں اس میں میٹرکس ہوتے ہیں۔ وہ گن سکتی ہے کہ وہ کتنی بار ساکٹ پر لکھنے سے قاصر رہی۔ فی الحال وہاں ایک ہوشیار ہورسٹک ہے۔ وہاں ایک بفر ہے۔ یہ اس سے ساکٹ پر پیغام لکھنے کی کوشش کرتا ہے۔ اگر بفر اوور فلو ہوتا ہے، تو یہ انہیں گرانا شروع کر دیتا ہے۔ اور وہ شمار کرتا ہے کہ اس نے ان میں سے کتنے کو گرایا۔ اگر وہاں میٹر اوور فلو ہونے لگیں تو ہمیں اس کے بارے میں پتہ چل جائے گا۔ وہ اب پرومیٹیس کے پاس بھی آ رہے ہیں، اور آپ گرافانا میں گراف دیکھ سکتے ہیں۔ آپ الرٹس ترتیب دے سکتے ہیں۔ لیکن ابھی تک یہ واضح نہیں ہے کہ انہیں کس کو بھیجنا ہے۔
سوال: لچکدار تلاش میں آپ لاگز کو فالتو پن کے ساتھ اسٹور کرتے ہیں۔ آپ کے پاس کتنی نقلیں ہیں؟
جواب: ایک لکیر.
سوال: کیا یہ صرف ایک لائن ہے؟
جواب: یہ ماسٹر اور نقل ہے۔ ڈیٹا دو کاپیوں میں محفوظ ہے۔
سوال: کیا آپ نے کسی طرح rsyslog بفر سائز کو ایڈجسٹ کیا؟
جواب: ہم اپنی مرضی کے مطابق یونکس ساکٹ پر ڈیٹا گرام لکھتے ہیں۔ یہ فوری طور پر ہم پر 128 کلو بائٹس کی حد عائد کرتا ہے۔ ہم اس پر زیادہ نہیں لکھ سکتے۔ ہم نے اسے معیار میں لکھا ہے۔ جو لوگ اسٹوریج میں جانا چاہتے ہیں وہ 128 کلو بائٹ لکھیں۔ مزید برآں، لائبریریوں کو کاٹ دیا جاتا ہے، اور ایک جھنڈا لگایا جاتا ہے کہ پیغام کاٹ دیا جاتا ہے۔ پیغام کے لیے ہمارے معیار میں ہی ایک خاص فیلڈ ہے جو یہ ظاہر کرتی ہے کہ آیا یہ ریکارڈنگ کے دوران کٹ گیا تھا یا نہیں۔ لہذا ہمارے پاس اس لمحے کو بھی ٹریک کرنے کا موقع ہے۔
سوال: کیا آپ ٹوٹا ہوا JSON لکھتے ہیں؟
جواب: ٹوٹا ہوا JSON یا تو ریلے کے دوران ضائع کر دیا جائے گا کیونکہ پیکٹ بہت بڑا ہے۔ یا Graylog کو مسترد کر دیا جائے گا کیونکہ یہ JSON کو پارس نہیں کر سکتا۔ لیکن ایسی باریکیاں ہیں جن کو ٹھیک کرنے کی ضرورت ہے، اور وہ زیادہ تر rsyslog سے منسلک ہیں۔ میں وہاں پہلے ہی کئی مسائل کو پُر کر چکا ہوں، جن پر ابھی کام کرنے کی ضرورت ہے۔
سوال: کافکا کیوں؟ کیا آپ نے RabbitMQ کو آزمایا ہے؟ کیا گرے لاگ اس طرح کے بوجھ کے تحت ناکام ہوجاتا ہے؟
جواب: Graylog کے ساتھ یہ ہمارے لیے کام نہیں کر رہا ہے۔ اور Graylog ہمارے لیے شکل اختیار کر رہا ہے۔ وہ واقعی پریشانی کا شکار ہے۔ وہ ایک عجیب چیز ہے۔ اور، حقیقت میں، اس کی ضرورت نہیں ہے. میں rsyslog سے براہ راست elasticsearch پر لکھنے کو ترجیح دوں گا اور پھر Kibana کو دیکھوں گا۔ لیکن ہمیں سیکورٹی گارڈز کے ساتھ معاملہ طے کرنے کی ضرورت ہے۔ یہ ہماری ترقی کے لیے ایک ممکنہ آپشن ہے، جب ہم Graylog کو باہر پھینک دیتے ہیں اور Kibana استعمال کرتے ہیں۔ Logstash استعمال کرنے کا کوئی فائدہ نہیں ہے۔ کیونکہ میں rsyslog کے ساتھ بھی ایسا ہی کرسکتا ہوں۔ اور اس میں elasticsearch پر لکھنے کا ایک ماڈیول ہے۔ ہم کسی طرح Graylog کے ساتھ رہنے کی کوشش کر رہے ہیں۔ یہاں تک کہ ہم نے اسے تھوڑا سا ترتیب دیا۔ لیکن اب بھی بہتری کی گنجائش ہے۔
کافکا کے بارے میں۔ تاریخی طور پر ایسا ہی ہوا۔ جب میں پہنچا، تو وہ پہلے سے موجود تھا، اور اس پر نوشتہ جات پہلے ہی لکھے جا رہے تھے۔ ہم نے آسانی سے اپنے کلسٹر کو اٹھایا اور لاگ ان کو اس میں منتقل کیا۔ ہم اس کے انتظام ہیں، ہم جانتے ہیں کہ وہ کیسا محسوس کرتا ہے۔ جہاں تک RabbitMQ کا تعلق ہے... یہ RabbitMQ کے ساتھ ہمارے لیے کام نہیں کرتا ہے۔ اور RabbitMQ ہمارے لیے شکل اختیار کر رہا ہے۔ ہمارے پاس یہ پیداوار میں ہے، اور اس کے ساتھ مسائل تھے. اب، فروخت سے پہلے، وہ اسے دلکش بنائیں گے، اور وہ معمول کے مطابق کام کرنا شروع کر دے گا۔ لیکن اس سے پہلے میں اسے پروڈکشن میں ریلیز کرنے کے لیے تیار نہیں تھا۔ ایک نکتہ اور ہے۔ Graylog ورژن AMQP 0.9 پڑھ سکتا ہے، اور rsyslog ورژن AMQP 1.0 لکھ سکتا ہے۔ اور درمیان میں کوئی ایک بھی حل نہیں ہے جو دونوں کر سکے۔ یہ یا تو ایک ہے یا دوسرا۔ اس لیے اس وقت صرف کافکا۔ لیکن اس کی اپنی باریکیاں بھی ہیں۔ کیونکہ rsyslog کے ورژن کا omkafka جسے ہم استعمال کرتے ہیں وہ پورا پیغام بفر کھو سکتا ہے جو اس نے rsyslog سے نکالا تھا۔ ابھی کے لئے ہم اس کے ساتھ ڈال دیا.
سوال: کیا آپ کافکا استعمال کر رہے ہیں کیونکہ آپ کے پاس پہلے سے موجود تھا؟ اب کسی مقصد کے لیے استعمال نہیں کیا جاتا؟
جواب: کافکا، جو تھا، ڈیٹا سائنس ٹیم استعمال کرتی ہے۔ یہ ایک بالکل الگ منصوبہ ہے، جس کے بارے میں، بدقسمتی سے، میں کچھ نہیں کہہ سکتا۔ میں نہیں جانتا. اسے ڈیٹا سائنس ٹیم چلاتی تھی۔ جب نوشتہ جات بنائے گئے، ہم نے اسے استعمال کرنے کا فیصلہ کیا تاکہ ہمارے اپنے نصب نہ ہوں۔ اب ہم نے Graylog کو اپ ڈیٹ کر دیا ہے، اور ہم نے مطابقت کھو دی ہے کیونکہ اس میں کافکا کا پرانا ورژن ہے۔ ہمیں اپنی شروعات کرنی تھی۔ ایک ہی وقت میں، ہم نے ہر API کے لیے ان چار عنوانات سے چھٹکارا حاصل کیا۔ ہم نے تمام لائیو کے لیے ایک وسیع موضوع بنایا، تمام اسٹیجنگ کے لیے ایک وسیع موضوع بنایا اور بس وہاں سب کچھ رکھ دیا۔ گرے لاگ ان سب کو متوازی طور پر کھرچتا ہے۔
سوال: ہم ساکٹ کے ساتھ اس shamanism کی ضرورت کیوں ہے؟ کیا آپ نے کنٹینرز کے لیے syslog لاگ ڈرائیور استعمال کرنے کی کوشش کی ہے؟
جواب: جس وقت ہم نے یہ سوال پوچھا تھا اس وقت ڈاکر کے ساتھ ہمارے تعلقات کشیدہ تھے۔ یہ ڈاکر 1.0 یا 0.9 تھا۔ ڈوکر خود بھی عجیب تھا۔ دوم، اگر آپ لاگز کو بھی اس میں دھکیلتے ہیں... مجھے ایک غیر تصدیق شدہ شبہ ہے کہ یہ تمام لاگز کو خود سے، ڈوکر ڈیمون کے ذریعے منتقل کرتا ہے۔ اگر ایک API پاگل ہوجاتا ہے، تو باقی APIs اس حقیقت میں پھنس گئے ہیں کہ وہ stdout اور stderr نہیں بھیج سکتے ہیں۔ مجھے نہیں معلوم کہ یہ کہاں لے جائے گا۔ مجھے احساس کی سطح پر ایک شبہ ہے کہ اس جگہ پر Docker syslog ڈرائیور کو استعمال کرنے کی ضرورت نہیں ہے۔ ہمارے فنکشنل ٹیسٹنگ ڈیپارٹمنٹ کے پاس لاگز کے ساتھ اپنا گرے لاگ کلسٹر ہے۔ وہ ڈوکر لاگ ڈرائیور استعمال کرتے ہیں اور ایسا لگتا ہے کہ وہاں سب کچھ ٹھیک ہے۔ لیکن وہ فوری طور پر GELF کو Graylog لکھتے ہیں۔ اس وقت جب ہم نے یہ سب شروع کیا تھا، ہمیں صرف کام کرنے کی ضرورت تھی۔ شاید بعد میں جب کوئی آئے اور کہے کہ یہ سو سال سے ٹھیک کام کر رہا ہے تو ہم کوشش کریں گے۔
سوال: آپ rsyslog کا استعمال کرتے ہوئے ڈیٹا سینٹرز کے درمیان ڈیلیوری کرتے ہیں۔ کافکا کیوں نہیں؟
جواب: ہم حقیقت میں دونوں کرتے ہیں۔ دو وجوہات کی بنا پر۔ اگر چینل مکمل طور پر مر گیا ہے، تو ہمارے تمام لاگز، یہاں تک کہ کمپریسڈ شکل میں بھی، اس کے ذریعے نہیں رینگیں گے۔ اور کافکا آپ کو اس عمل میں انہیں کھونے کی اجازت دیتا ہے۔ اس طرح ہم پھنس جانے والے ان لاگز سے چھٹکارا حاصل کرتے ہیں۔ ہم اس معاملے میں کافکا کو براہ راست استعمال کر رہے ہیں۔ اگر ہمارے پاس ایک اچھا چینل ہے اور ہم اسے آزاد کرنا چاہتے ہیں، تو ہم ان کا rsyslog استعمال کرتے ہیں۔ لیکن درحقیقت، آپ اسے اس طرح ترتیب دے سکتے ہیں کہ یہ خود ہی اس چیز کو چھوڑ دے جو فٹ نہیں ہے۔ اس وقت، ہم صرف کہیں براہ راست rsyslog ڈیلیوری استعمال کرتے ہیں، اور کہیں کافکا۔
ماخذ: www.habr.com