🥇 لاگ ان کبرنیٹس (اور نہ صرف) آج: توقعات اور حقیقت

یہ 2019 ہے، اور ہمارے پاس اب بھی Kubernetes میں لاگ اکھٹی کرنے کا کوئی معیاری حل نہیں ہے۔ اس مضمون میں، ہم حقیقی مشق سے مثالیں استعمال کرتے ہوئے، اپنی تلاشوں، درپیش مسائل اور ان کے حل کا اشتراک کرنا چاہیں گے۔

تاہم، سب سے پہلے، میں ایک ریزرویشن کروں گا کہ مختلف گاہک لاگز جمع کرکے بہت مختلف چیزوں کو سمجھتے ہیں:

کوئی سیکورٹی اور آڈٹ لاگ دیکھنا چاہتا ہے؛
کوئی - پورے انفراسٹرکچر کی مرکزی لاگنگ؛
اور کچھ کے لیے، مثال کے طور پر، بیلنسرز کو چھوڑ کر، صرف ایپلیکیشن لاگز کو جمع کرنا کافی ہے۔

ہم نے مختلف "خواہش کی فہرستوں" کو کیسے نافذ کیا اور ہمیں کن مشکلات کا سامنا کرنا پڑا اس کے بارے میں ذیل میں کٹ ہے۔

تھیوری: لاگنگ ٹولز کے بارے میں

لاگنگ سسٹم کے اجزاء کا پس منظر

لاگنگ نے ایک طویل فاصلہ طے کیا ہے، جس کے نتیجے میں نوشتہ جات کو جمع کرنے اور ان کا تجزیہ کرنے کے طریقے تیار کیے گئے ہیں، جو آج ہم استعمال کرتے ہیں۔ 1950 کی دہائی میں، فورٹران نے معیاری ان پٹ/آؤٹ پٹ اسٹریمز کا ایک اینالاگ متعارف کرایا، جس نے پروگرامر کو اپنے پروگرام کو ڈیبگ کرنے میں مدد کی۔ یہ پہلے کمپیوٹر لاگز تھے جنہوں نے اس وقت کے پروگرامرز کی زندگی کو آسان بنا دیا۔ آج ہم ان میں لاگنگ سسٹم کا پہلا جزو دیکھتے ہیں۔ لاگز کا ماخذ یا "پروڈیوسر".

کمپیوٹر سائنس ساکن نہیں ہوئی: کمپیوٹر نیٹ ورک نمودار ہوئے، پہلے کلسٹرز... متعدد کمپیوٹرز پر مشتمل پیچیدہ نظاموں نے کام کرنا شروع کیا۔ اب سسٹم ایڈمنسٹریٹرز کو کئی مشینوں سے لاگز جمع کرنے پر مجبور کیا گیا، اور خاص صورتوں میں وہ OS کرنل کے پیغامات شامل کر سکتے ہیں اگر انہیں سسٹم کی ناکامی کی تحقیقات کرنے کی ضرورت ہو۔ مرکزی لاگ جمع کرنے کے نظام کی وضاحت کے لیے، 2000 کی دہائی کے اوائل میں اسے شائع کیا گیا تھا۔ آر ایف سی 3164، جس نے remote_syslog کو معیاری بنایا۔ اس طرح ایک اور اہم جزو ظاہر ہوا: لاگ کلیکٹر اور ان کا ذخیرہ۔

لاگز کے حجم میں اضافے اور ویب ٹیکنالوجیز کے وسیع پیمانے پر تعارف کے ساتھ، یہ سوال پیدا ہوا کہ کن لاگز کو صارفین کو آسانی سے دکھانے کی ضرورت ہے۔ سادہ کنسول ٹولز (awk/sed/grep) کو مزید جدید آلات سے تبدیل کر دیا گیا ہے۔ لاگ ناظرین - تیسرا جزو۔

نوشتہ جات کے حجم میں اضافے کی وجہ سے، کچھ اور واضح ہو گیا: لاگز کی ضرورت ہے، لیکن ان سب کی نہیں۔ اور مختلف نوشتہ جات کو مختلف سطحوں کے تحفظ کی ضرورت ہوتی ہے: کچھ کو ایک دن میں ضائع کیا جا سکتا ہے، جبکہ دیگر کو 5 سال تک ذخیرہ کرنے کی ضرورت ہے۔ لہذا، لاگنگ سسٹم میں ڈیٹا فلو کو فلٹر کرنے اور روٹنگ کرنے کے لیے ایک جزو شامل کیا گیا تھا - آئیے اسے کہتے ہیں۔ فلٹر.

اسٹوریج نے بھی ایک بڑی چھلانگ لگائی ہے: باقاعدہ فائلوں سے لے کر متعلقہ ڈیٹا بیس تک، اور پھر دستاویز پر مبنی اسٹوریج تک (مثال کے طور پر، Elasticsearch)۔ چنانچہ ذخیرہ کو کلکٹر سے الگ کر دیا گیا۔

بالآخر، لاگ کا تصور ہی واقعات کی ایک قسم کے تجریدی سلسلے میں پھیل گیا ہے جسے ہم تاریخ کے لیے محفوظ کرنا چاہتے ہیں۔ یا اس کے بجائے، اگر آپ کو تحقیقات کرنے یا تجزیاتی رپورٹ تیار کرنے کی ضرورت ہو...

نتیجے کے طور پر، نسبتاً کم وقت میں، لاگ جمع کرنا ایک اہم ذیلی نظام میں تبدیل ہو گیا ہے، جسے بجا طور پر بگ ڈیٹا کے ذیلی حصوں میں سے ایک کہا جا سکتا ہے۔

اگر کسی زمانے میں عام پرنٹس "لاگنگ سسٹم" کے لیے کافی ہوتے ہیں، تو اب صورتحال بہت بدل چکی ہے۔

کبرنیٹس اور لاگز

جب Kubernetes انفراسٹرکچر پر آیا، تو لاگز جمع کرنے کا پہلے سے موجود مسئلہ بھی اسے نظرانداز نہیں کرتا تھا۔ کچھ طریقوں سے، یہ اور بھی تکلیف دہ ہو گیا: بنیادی ڈھانچے کے پلیٹ فارم کا انتظام نہ صرف آسان، بلکہ ایک ہی وقت میں پیچیدہ بھی۔ بہت سی پرانی سروسز نے مائیکرو سروسز میں منتقل ہونا شروع کر دیا ہے۔ لاگز کے تناظر میں، یہ لاگ ذرائع کی بڑھتی ہوئی تعداد، ان کے خصوصی لائف سائیکل، اور لاگز کے ذریعے سسٹم کے تمام اجزاء کے تعلقات کو ٹریک کرنے کی ضرورت سے ظاہر ہوتا ہے۔

آگے دیکھتے ہوئے، میں یہ کہہ سکتا ہوں کہ اب، بدقسمتی سے، Kubernetes کے لیے لاگنگ کا کوئی معیاری آپشن نہیں ہے جو دوسروں کے ساتھ سازگار طور پر موازنہ کرے۔ کمیونٹی میں سب سے زیادہ مقبول اسکیمیں مندرجہ ذیل ہیں:

کوئی اسٹیک کو کھولتا ہے۔ ای ایف کے (Elasticsearch, Fluentd, Kibana);
کوئی حال ہی میں جاری ہونے کی کوشش کر رہا ہے۔ لوکی یا استعمال کرتا ہے۔ لاگنگ آپریٹر;
ہم (اور شاید صرف ہم ہی نہیں؟...) میں اپنی ترقی سے کافی حد تک مطمئن ہوں - لاگ ہاؤس...

ایک اصول کے طور پر، ہم K8s کلسٹرز میں درج ذیل بنڈل استعمال کرتے ہیں (خود میزبانی کے حل کے لیے):

تاہم، میں ان کی تنصیب اور ترتیب کے لیے ہدایات پر غور نہیں کروں گا۔ اس کے بجائے، میں ان کی کوتاہیوں اور عمومی طور پر لاگ کے ساتھ صورتحال کے بارے میں مزید عالمی نتائج پر توجہ دوں گا۔

K8s میں لاگ کے ساتھ مشق کریں۔

"روزانہ لاگز"، آپ میں سے کتنے ہیں؟...

کافی بڑے انفراسٹرکچر سے لاگز کی مرکزی جمع کرنے کے لیے کافی وسائل کی ضرورت ہوتی ہے، جو لاگز کو جمع کرنے، ذخیرہ کرنے اور پروسیسنگ پر خرچ کیے جائیں گے۔ مختلف منصوبوں کے آپریشن کے دوران ہمیں مختلف ضروریات اور ان سے پیدا ہونے والے آپریشنل مسائل کا سامنا کرنا پڑا۔

آئیے کلک ہاؤس کو آزماتے ہیں۔

آئیے ایک ایسی ایپلی کیشن کے ساتھ پروجیکٹ پر مرکزی اسٹوریج کو دیکھیں جو لاگز کو کافی فعال طور پر تیار کرتا ہے: فی سیکنڈ 5000 سے زیادہ لائنیں۔ آئیے اس کے نوشتہ جات کے ساتھ کام شروع کریں، انہیں ClickHouse میں شامل کریں۔

جیسے ہی زیادہ سے زیادہ ریئل ٹائم کی ضرورت ہوگی، کلک ہاؤس والا 4 کور سرور پہلے ہی ڈسک کے سب سسٹم پر اوورلوڈ ہو جائے گا:

اس قسم کی لوڈنگ اس حقیقت کی وجہ سے ہے کہ ہم جلد سے جلد ClickHouse میں لکھنے کی کوشش کر رہے ہیں۔ اور ڈیٹا بیس اس پر ڈسک کے بڑھتے ہوئے بوجھ کے ساتھ ردعمل ظاہر کرتا ہے، جو درج ذیل خرابیوں کا سبب بن سکتا ہے۔

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

حقیقت یہ ہے کہ ہے MergeTree ٹیبلز ClickHouse میں (ان میں لاگ ڈیٹا ہوتا ہے) تحریری کارروائیوں کے دوران ان کی اپنی مشکلات ہوتی ہیں۔ ان میں داخل کردہ ڈیٹا ایک عارضی پارٹیشن بناتا ہے، جسے پھر مین ٹیبل کے ساتھ ملا دیا جاتا ہے۔ نتیجے کے طور پر، ریکارڈنگ ڈسک پر بہت زیادہ مطالبہ کرتی ہے، اور یہ اس حد سے بھی مشروط ہے جس کے بارے میں ہمیں اوپر نوٹس موصول ہوا ہے: 1 سیکنڈ میں 300 سے زیادہ ذیلی پارٹیشنز کو ضم نہیں کیا جا سکتا (حقیقت میں، یہ 300 انسرٹس ہیں۔ فی سیکنڈ).

اس رویے سے بچنے کے لیے، کلک ہاؤس کو لکھنا چاہئے۔ زیادہ سے زیادہ بڑے ٹکڑوں میں اور ہر 1 سیکنڈ میں 2 بار سے زیادہ نہیں۔ تاہم، بڑے برسٹ میں لکھنا تجویز کرتا ہے کہ ہمیں ClickHouse میں کم لکھنا چاہیے۔ یہ، بدلے میں، بفر اوور فلو اور لاگز کے نقصان کا باعث بن سکتا ہے۔ حل یہ ہے کہ Fluentd بفر کو بڑھایا جائے، لیکن پھر میموری کی کھپت بھی بڑھ جائے گی۔

نوٹ: ClickHouse کے ساتھ ہمارے حل کا ایک اور مشکل پہلو اس حقیقت سے متعلق تھا کہ ہمارے کیس (لاگ ہاؤس) میں تقسیم کو منسلک بیرونی میزوں کے ذریعے لاگو کیا جاتا ہے۔ میز کو ضم کریں۔. یہ اس حقیقت کی طرف جاتا ہے کہ جب بڑے وقت کے وقفوں کا نمونہ لیتے ہیں تو ضرورت سے زیادہ RAM کی ضرورت ہوتی ہے، کیونکہ میٹیٹیبل تمام پارٹیشنز کے ذریعے اعادہ ہوتا ہے - یہاں تک کہ وہ بھی جو ظاہر ہے کہ ضروری ڈیٹا پر مشتمل نہیں ہیں۔ تاہم، اب اس نقطہ نظر کو ClickHouse کے موجودہ ورژن (c 18.16).

نتیجے کے طور پر، یہ واضح ہو جاتا ہے کہ ہر پروجیکٹ کے پاس اتنے وسائل نہیں ہوتے کہ وہ ClickHouse میں حقیقی وقت میں لاگز جمع کر سکیں (مزید واضح طور پر، ان کی تقسیم مناسب نہیں ہوگی)۔ اس کے علاوہ، آپ کو استعمال کرنے کی ضرورت ہوگی аккумуляторجس پر ہم بعد میں واپس آئیں گے۔ اوپر بیان کیا گیا معاملہ حقیقی ہے۔ اور اس وقت ہم ایک قابل اعتماد اور مستحکم حل پیش کرنے سے قاصر تھے جو گاہک کے مطابق ہو اور ہمیں کم سے کم تاخیر کے ساتھ نوشتہ جات جمع کرنے کی اجازت دیتا ہو...

Elasticsearch کے بارے میں کیا خیال ہے؟

Elasticsearch بھاری کام کے بوجھ کو سنبھالنے کے لیے جانا جاتا ہے۔ آئیے اسے اسی پروجیکٹ میں آزماتے ہیں۔ اب بوجھ اس طرح لگتا ہے:

Elasticsearch ڈیٹا سٹریم کو ہضم کرنے کے قابل تھا، تاہم، اس پر ایسی جلدیں لکھنا CPU کو بہت زیادہ استعمال کرتا ہے۔ اس کا فیصلہ کلسٹر کو منظم کرکے کیا جاتا ہے۔ تکنیکی طور پر، یہ کوئی مسئلہ نہیں ہے، لیکن یہ پتہ چلتا ہے کہ صرف لاگ جمع کرنے کے نظام کو چلانے کے لیے ہم پہلے ہی تقریباً 8 کور استعمال کر رہے ہیں اور سسٹم میں ایک اضافی انتہائی بھری ہوئی جز ہے...

پایان لائن: اس اختیار کو جائز قرار دیا جا سکتا ہے، لیکن صرف اس صورت میں جب پروجیکٹ بڑا ہو اور اس کا انتظام مرکزی لاگنگ سسٹم پر اہم وسائل خرچ کرنے کے لیے تیار ہو۔

پھر ایک فطری سوال پیدا ہوتا ہے:

کیا لاگ واقعی ضرورت ہے؟

آئیے اپنے نقطہ نظر کو تبدیل کرنے کی کوشش کریں: نوشتہ جات بیک وقت معلوماتی ہونے چاہئیں نہ کہ احاطہ کرنے والے ہر نظام میں واقعہ.

ہم کہتے ہیں کہ ہمارے پاس ایک کامیاب آن لائن اسٹور ہے۔ کون سے نوشتہ جات اہم ہیں؟ زیادہ سے زیادہ معلومات جمع کرنا، مثال کے طور پر، ادائیگی کے گیٹ وے سے، ایک بہترین خیال ہے۔ لیکن پروڈکٹ کیٹلاگ میں امیج سلائسنگ سروس کے تمام لاگز ہمارے لیے اہم نہیں ہیں: صرف غلطیاں اور جدید نگرانی ہی کافی ہے (مثال کے طور پر، 500 غلطیوں کا فیصد جو یہ جزو پیدا کرتا ہے)۔

تو ہم اس نتیجے پر پہنچے ہیں کہ مرکزی لاگنگ ہمیشہ جائز نہیں ہے۔. اکثر کلائنٹ تمام لاگز کو ایک جگہ جمع کرنا چاہتا ہے، حالانکہ درحقیقت، پورے لاگ سے، صرف ایک مشروط 5% پیغامات جو کاروبار کے لیے اہم ہیں:

بعض اوقات یہ صرف کنٹینر لاگ کے سائز اور ایرر کلیکٹر (مثال کے طور پر، سنٹری) کو ترتیب دینا کافی ہوتا ہے۔
غلطی کی اطلاع اور خود ایک بڑا مقامی لاگ اکثر واقعات کی تفتیش کے لیے کافی ہو سکتا ہے۔
ہمارے پاس ایسے منصوبے تھے جو خصوصی طور پر فعال ٹیسٹوں اور غلطیوں کو جمع کرنے کے نظام کے ساتھ بنائے گئے تھے۔ ڈویلپر کو اس طرح لاگز کی ضرورت نہیں تھی - انہوں نے غلطی کے نشانات سے سب کچھ دیکھا۔

زندگی سے مثال

ایک اور کہانی اچھی مثال کے طور پر کام کر سکتی ہے۔ ہمیں اپنے ایک کلائنٹ کی سیکیورٹی ٹیم کی طرف سے ایک درخواست موصول ہوئی جو پہلے ہی ایک تجارتی حل استعمال کر رہی تھی جو Kubernetes کے متعارف ہونے سے بہت پہلے تیار کیا گیا تھا۔

کارپوریٹ مسئلہ کا پتہ لگانے والے سینسر - QRadar کے ساتھ سنٹرلائزڈ لاگ کلیکشن سسٹم کے "دوست بنانا" ضروری تھا۔ یہ سسٹم syslog پروٹوکول کے ذریعے لاگ وصول کر سکتا ہے اور انہیں FTP سے بازیافت کر سکتا ہے۔ تاہم، اسے fluentd کے لیے remote_syslog پلگ ان کے ساتھ ضم کرنا فوری طور پر ممکن نہیں تھا۔ (پتا یہ چلا کہ، ہم اکیلے نہیں ہیں). QRadar کو ترتیب دینے میں مسائل کلائنٹ کی سیکیورٹی ٹیم کی طرف سے نکلے۔

نتیجے کے طور پر، کاروباری اہم لاگز کا ایک حصہ FTP QRadar پر اپ لوڈ کیا گیا، اور دوسرے حصے کو براہ راست نوڈس سے ریموٹ syslog کے ذریعے ری ڈائریکٹ کیا گیا۔ اس کے لیے ہم نے لکھا بھی سادہ چارٹ - شاید اس سے کسی کو اسی طرح کے مسئلے کو حل کرنے میں مدد ملے گی... نتیجے میں آنے والی اسکیم کی بدولت، کلائنٹ نے خود تنقیدی لاگز حاصل کیے اور ان کا تجزیہ کیا (اپنے پسندیدہ ٹولز کا استعمال کرتے ہوئے)، اور ہم لاگنگ سسٹم کی لاگت کو کم کرنے میں کامیاب رہے، صرف پچھلے مہینے.

ایک اور مثال اس بات کی کافی نشاندہی کرتی ہے کہ کیا نہیں کرنا چاہیے۔ پروسیسنگ کے لئے ہمارے گاہکوں میں سے ایک ہر ایک صارف سے آنے والے واقعات، ملٹی لائن بنائے گئے۔ غیر ساختہ پیداوار لاگ میں معلومات. جیسا کہ آپ اندازہ لگا سکتے ہیں، اس طرح کے نوشتہ جات پڑھنے اور ذخیرہ کرنے دونوں کے لیے انتہائی تکلیف دہ تھے۔

نوشتہ جات کے لیے معیار

اس طرح کی مثالیں اس نتیجے پر پہنچتی ہیں کہ لاگ جمع کرنے کے نظام کو منتخب کرنے کے علاوہ، آپ کو یہ کرنے کی ضرورت ہے۔ نوشتہ جات خود بھی ڈیزائن کریں۔! یہاں کیا تقاضے ہیں؟

لاگز مشین کے پڑھنے کے قابل فارمیٹ میں ہونے چاہئیں (مثال کے طور پر، JSON)۔
لاگز کمپیکٹ اور ممکنہ مسائل کو ڈیبگ کرنے کے لیے لاگنگ کی ڈگری کو تبدیل کرنے کی صلاحیت کے ساتھ ہونا چاہیے۔ ایک ہی وقت میں، پیداواری ماحول میں آپ کو لاگنگ لیول جیسے سسٹمز کو چلانا چاہیے۔ انتباہ یا خرابی.
لاگز کو نارملائز کیا جانا چاہیے، یعنی لاگ آبجیکٹ میں، تمام لائنوں میں ایک ہی فیلڈ کی قسم ہونی چاہیے۔

غیر ساختہ لاگز لاگز کو اسٹوریج میں لوڈ کرنے اور ان کی پروسیسنگ کو مکمل طور پر روکنے میں مسائل کا باعث بن سکتے ہیں۔ ایک مثال کے طور پر، یہاں غلطی 400 کے ساتھ ایک مثال ہے، جس کا سامنا بہت سے لوگوں کو یقینی طور پر روانی والے نوشتہ جات میں ہوا ہے:

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

غلطی کا مطلب یہ ہے کہ آپ ایک فیلڈ بھیج رہے ہیں جس کی قسم ریڈی میڈ میپنگ کے ساتھ انڈیکس میں غیر مستحکم ہے۔ سب سے آسان مثال nginx لاگ میں متغیر کے ساتھ ایک فیلڈ ہے۔ $upstream_status. اس میں یا تو نمبر یا تار ہو سکتا ہے۔ مثال کے طور پر:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"} { "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

نوشتہ جات سے پتہ چلتا ہے کہ سرور 10.100.0.10 نے 404 غلطی کے ساتھ جواب دیا اور درخواست کو مواد کے دوسرے اسٹوریج کو بھیج دیا گیا۔ نتیجے کے طور پر، نوشتہ جات میں قدر اس طرح بن گئی:

"upstream_response_time": "0.001, 0.007"

یہ صورت حال اتنی عام ہے کہ یہ الگ سے بھی مستحق ہے۔ دستاویزات میں حوالہ جات.

کیا وشوسنییتا کے بارے میں؟

ایسے اوقات ہوتے ہیں جب تمام لاگز بغیر کسی استثناء کے اہم ہوتے ہیں۔ اور اس کے ساتھ، K8s کے لیے مخصوص لاگ اکٹھا کرنے کی اسکیموں میں جن پر اوپر بحث کی گئی ہے ان میں مسائل ہیں۔

مثال کے طور پر، fluentd مختصر مدت کے کنٹینرز سے لاگ جمع نہیں کر سکتا۔ ہمارے ایک پروجیکٹ میں، ڈیٹا بیس کی منتقلی کا کنٹینر 4 سیکنڈ سے بھی کم وقت تک زندہ رہا اور پھر اسے حذف کر دیا گیا - متعلقہ تشریح کے مطابق:

"helm.sh/hook-delete-policy": hook-succeeded

اس کی وجہ سے، مائیگریشن ایگزیکیوشن لاگ کو اسٹوریج میں شامل نہیں کیا گیا تھا۔ اس معاملے میں سیاست مدد کر سکتی ہے۔ before-hook-creation.

ایک اور مثال ڈوکر لاگ روٹیشن ہے۔ ہم کہتے ہیں کہ ایک ایسی ایپلی کیشن ہے جو لاگز کو فعال طور پر لکھتی ہے۔ عام حالات میں، ہم تمام لاگز پر کارروائی کرنے کا انتظام کرتے ہیں، لیکن جیسے ہی کوئی مسئلہ ظاہر ہوتا ہے - مثال کے طور پر، جیسا کہ اوپر ایک غلط فارمیٹ کے ساتھ بیان کیا گیا ہے - پروسیسنگ رک جاتی ہے، اور Docker فائل کو گھماتا ہے۔ نتیجہ یہ ہے کہ کاروبار کے لیے اہم لاگز ضائع ہو سکتے ہیں۔

لہذا لاگ اسٹریمز کو الگ کرنا ضروری ہے۔ان کی حفاظت کو یقینی بنانے کے لیے سب سے قیمتی چیزوں کو براہ راست ایپلی کیشن میں بھیجنا۔ اس کے علاوہ، کچھ بنانے کے لئے یہ ضرورت سے زیادہ نہیں ہو گا نوشتہ جات کا "جمع کرنے والا"، جو اہم پیغامات کو محفوظ کرتے ہوئے مختصر اسٹوریج کی عدم دستیابی سے بچ سکتا ہے۔

آخر میں، ہمیں یہ نہیں بھولنا چاہئے کسی بھی ذیلی نظام کی مناسب نگرانی کرنا ضروری ہے۔. بصورت دیگر، ایسی صورت حال کا سامنا کرنا آسان ہے جس میں روانی ایک حالت میں ہو۔ CrashLoopBackOff اور کچھ بھی نہیں بھیجتا، اور یہ اہم معلومات کے ضائع ہونے کا وعدہ کرتا ہے۔

نتائج

اس مضمون میں، ہم Datadog جیسے SaaS حل نہیں دیکھ رہے ہیں۔ یہاں بیان کردہ بہت سے مسائل کو پہلے ہی کسی نہ کسی طریقے سے تجارتی کمپنیوں کے ذریعے حل کیا جا چکا ہے جو نوشتہ جات جمع کرنے میں مہارت رکھتے ہیں، لیکن ہر کوئی مختلف وجوہات کی بنا پر SaaS کا استعمال نہیں کر سکتا۔ (اہم قیمتیں اور 152-FZ کے ساتھ تعمیل ہیں).

سنٹرلائزڈ لاگ جمع کرنا پہلے تو ایک آسان کام لگتا ہے، لیکن ایسا بالکل نہیں ہے۔ یہ یاد رکھنا ضروری ہے کہ:

صرف اہم اجزاء کو تفصیل سے لاگ ان کرنے کی ضرورت ہے، جبکہ نگرانی اور غلطیوں کو جمع کرنا دوسرے سسٹمز کے لیے ترتیب دیا جا سکتا ہے۔
لاگ ان پروڈکشن کو کم سے کم رکھا جائے تاکہ غیر ضروری بوجھ نہ پڑے۔
لاگز مشین سے پڑھنے کے قابل، نارملائزڈ اور سخت فارمیٹ ہونے چاہئیں۔
واقعی تنقیدی نوشتہ جات کو الگ سٹریم میں بھیجا جانا چاہیے، جسے اہم سے الگ کیا جانا چاہیے۔
یہ لاگ جمع کرنے والے پر غور کرنے کے قابل ہے، جو آپ کو زیادہ بوجھ کے پھٹنے سے بچا سکتا ہے اور اسٹوریج پر بوجھ کو مزید یکساں بنا سکتا ہے۔

یہ آسان اصول، اگر ہر جگہ لاگو ہوتے ہیں، تو اوپر بیان کردہ سرکٹس کام کرنے کی اجازت دیں گے - حالانکہ ان میں اہم اجزاء (بیٹری) غائب ہیں۔ اگر آپ اس طرح کے اصولوں پر عمل نہیں کرتے ہیں، تو یہ کام آسانی سے آپ کو اور انفراسٹرکچر کو نظام کے دوسرے انتہائی بھاری بھرکم (اور اسی وقت غیر موثر) جزو کی طرف لے جائے گا۔

PS

ہمارے بلاگ پر بھی پڑھیں:

ماخذ: www.habr.com

Kubernetes میں لاگ ان (اور نہ صرف) آج: توقعات اور حقیقت