کیا نگرانی ختم ہو گئی ہے؟ - طویل لائیو نگرانی

2008 سے، ہماری کمپنی بنیادی طور پر بنیادی ڈھانچے کے انتظام اور ویب پروجیکٹس کے لیے چوبیس گھنٹے تکنیکی معاونت میں مصروف ہے: ہمارے پاس 400 سے زیادہ کلائنٹس ہیں، جو کہ روسی ای کامرس کا تقریباً 15% ہے۔ اس کے مطابق، ایک بہت متنوع فن تعمیر کی حمایت کی جاتی ہے. اگر کوئی چیز گرتی ہے تو ہم اسے 15 منٹ کے اندر ٹھیک کرنے کے پابند ہیں۔ لیکن یہ سمجھنے کے لیے کہ حادثہ پیش آیا ہے، آپ کو اس منصوبے کی نگرانی کرنے اور واقعات کا جواب دینے کی ضرورت ہے۔ یہ کیسے کریں؟

میرا ماننا ہے کہ نگرانی کے مناسب نظام کو ترتیب دینے میں ایک مسئلہ ہے۔ اگر کوئی پریشانی نہ ہوتی تو میری تقریر ایک تھیسس پر مشتمل ہوتی: "براہ کرم Prometheus + Grafana اور plugins 1, 2, 3 انسٹال کریں۔" بدقسمتی سے، یہ اب اس طرح کام نہیں کرتا ہے۔ اور بنیادی مسئلہ یہ ہے کہ ہر کوئی سافٹ ویئر کے اجزاء کے لحاظ سے 2008 میں موجود کسی چیز پر یقین کرتا رہتا ہے۔

نگرانی کے نظام کی تنظیم کے بارے میں، میں یہ کہوں گا کہ... قابل نگرانی کے حامل منصوبے موجود نہیں ہیں۔ اور صورتحال اتنی خراب ہے کہ اگر کوئی چیز گرتی ہے تو اس بات کا خطرہ ہے کہ اس پر کسی کا دھیان نہیں جائے گا - آخرکار، سب کو یقین ہے کہ "ہر چیز کی نگرانی کی جاتی ہے۔"
شاید ہر چیز کی نگرانی ہو رہی ہے۔ لیکن کس طرح؟

ہم سب کو مندرجہ ذیل جیسی کہانی کا سامنا کرنا پڑا ہے: ایک مخصوص ڈیوپس، ایک مخصوص ایڈمن کام کر رہا ہے، ایک ڈویلپمنٹ ٹیم ان کے پاس آتی ہے اور کہتی ہے - "ہمیں رہا کر دیا گیا ہے، اب مانیٹر کریں۔" کیا مانیٹر؟ یہ کیسے کام کرتا ہے؟

ٹھیک ہے. ہم پرانے زمانے کے طریقے کی نگرانی کرتے ہیں۔ اور یہ پہلے ہی تبدیل ہو رہا ہے، اور یہ پتہ چلتا ہے کہ آپ نے سروس A کی نگرانی کی، جو سروس B بن گئی، جو سروس C کے ساتھ تعامل کرتی ہے۔ لیکن ترقیاتی ٹیم آپ کو بتاتی ہے: "سافٹ ویئر انسٹال کریں، اسے ہر چیز کی نگرانی کرنی چاہیے!"

تو کیا بدل گیا ہے؟ - سب کچھ بدل گیا ہے!

2008 سب کچھ ٹھیک ہے

ڈویلپرز کے ایک جوڑے ہیں، ایک سرور، ایک ڈیٹا بیس سرور. یہ سب یہاں سے جاتا ہے۔ ہمارے پاس کچھ معلومات ہیں، ہم zabbix، Nagios، cacti انسٹال کرتے ہیں۔ اور پھر ہم CPU پر، ڈسک کے آپریشن پر، اور ڈسک کی جگہ پر واضح الرٹس مرتب کرتے ہیں۔ ہم اس بات کو یقینی بنانے کے لیے کچھ دستی چیک بھی کرتے ہیں کہ سائٹ جواب دیتی ہے اور ڈیٹا بیس میں آرڈرز پہنچ رہے ہیں۔ اور یہ ہے - ہم کم و بیش محفوظ ہیں۔

اگر ہم اس کام کی مقدار کا موازنہ کریں جو منتظم نے اس وقت نگرانی فراہم کرنے کے لیے کیا تھا، تو اس کا 98% خودکار تھا: جو شخص مانیٹرنگ کرتا ہے اسے یہ سمجھنا چاہیے کہ Zabbix کو کس طرح انسٹال کرنا ہے، اسے کس طرح ترتیب دینا ہے اور انتباہات کو کیسے ترتیب دینا ہے۔ اور 2% - بیرونی جانچ پڑتال کے لیے: کہ سائٹ جواب دیتی ہے اور ڈیٹا بیس سے درخواست کرتی ہے، کہ نئے آرڈر آچکے ہیں۔

2010 بوجھ بڑھ رہا ہے۔

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

مزید یہ کہ انفراسٹرکچر سے وابستہ ادارہ اب بھی مینیجر کے سر میں سب سے بڑا ہے۔ میرے ذہن میں اب بھی ایک خیال ہے کہ نگرانی کرنے والا وہ شخص ہے جو زبکس انسٹال کرے گا اور اسے ترتیب دینے کے قابل ہوگا۔

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

نوٹ: میں نے "اسکرپٹ کا ایک سیٹ" 3 بار لکھا۔ یعنی، نگرانی کے لیے ذمہ دار شخص اب وہ نہیں ہے جو صرف زبکس انسٹال کرتا ہے۔ یہ وہ شخص ہے جو کوڈنگ شروع کرتا ہے۔ لیکن ٹیم کے ذہنوں میں ابھی تک کچھ نہیں بدلا۔

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

لیکن شاذ و نادر ہی کوئی 10 سال تک کسی پروجیکٹ کے ساتھ جاتا ہے۔

مانیٹرنگ مین کا دوبارہ شروع

فرض کریں کہ آپ ایک نئے سٹارٹ اپ پر آئے ہیں جس نے فوری طور پر 20 ڈویلپرز کی خدمات حاصل کیں، 15 مائیکرو سروسز لکھیں، اور آپ ایک ایڈمن ہیں جن سے کہا جاتا ہے: "CI/CD بنائیں۔ برائے مہربانی." آپ نے CI/CD بنایا ہے اور اچانک آپ نے سنا: "ہمارے لیے "کیوب" میں پروڈکشن کے ساتھ کام کرنا مشکل ہے، یہ سمجھے بغیر کہ ایپلیکیشن اس میں کیسے کام کرے گی۔ ہمیں اسی "کیوب" میں ایک سینڈ باکس بنائیں۔
آپ اس کیوب میں ایک سینڈ باکس بنائیں۔ وہ فوری طور پر آپ کو بتاتے ہیں: "ہم ایک اسٹیج ڈیٹا بیس چاہتے ہیں جو ہر روز پروڈکشن سے اپ ڈیٹ ہوتا ہے، تاکہ ہم سمجھیں کہ یہ ڈیٹا بیس پر کام کرتا ہے، لیکن ساتھ ہی پروڈکشن ڈیٹا بیس کو خراب نہ کریں۔"

آپ اس سب میں رہتے ہیں۔ ریلیز میں 2 ہفتے باقی ہیں، وہ آپ کو بتاتے ہیں: "اب آئیے اس سب کی نگرانی کریں..." یعنی۔ کلسٹر انفراسٹرکچر کی نگرانی کریں، مائیکرو سروس فن تعمیر کی نگرانی کریں، بیرونی خدمات کے ساتھ کام کی نگرانی کریں...

اور میرے ساتھی معمول کی اسکیم کو اپنے سر سے نکالتے ہیں اور کہتے ہیں: "ٹھیک ہے، یہاں سب کچھ واضح ہے! ایک پروگرام انسٹال کریں جو اس سب کی نگرانی کرے گا۔ ہاں، ہاں: Prometheus + Grafana + plugins۔
اور انہوں نے مزید کہا: "آپ کے پاس دو ہفتے ہیں، یقینی بنائیں کہ سب کچھ محفوظ ہے۔"

ہم دیکھتے ہیں کہ بہت سے منصوبوں میں، ایک شخص کو نگرانی کے لیے مختص کیا جاتا ہے۔ تصور کریں کہ ہم 2 ہفتوں کے لیے مانیٹرنگ کے لیے ایک شخص کی خدمات حاصل کرنا چاہتے ہیں، اور ہم اس کے لیے ایک ریزیومے لکھتے ہیں۔ ہم نے اب تک جو کچھ کہا ہے اس کو دیکھتے ہوئے اس شخص میں کیا مہارت ہونی چاہیے؟

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

آئیے ایک بالکل نارمل کیس یاد رکھیں: کچھ سروسز پی ایچ پی میں ہیں، کچھ سروسز گو میں ہیں، کچھ سروسز جے ایس میں ہیں۔ وہ کسی نہ کسی طرح ایک دوسرے کے ساتھ کام کرتے ہیں۔ یہ وہ جگہ ہے جہاں سے "مائیکرو سرویس" کی اصطلاح آتی ہے: بہت سارے انفرادی نظام ہیں کہ ڈویلپر اس منصوبے کو مجموعی طور پر نہیں سمجھ سکتے۔ ٹیم کا ایک حصہ جے ایس میں خدمات لکھتا ہے جو اپنے طور پر کام کرتی ہے اور نہیں جانتا کہ باقی سسٹم کیسے کام کرتا ہے۔ دوسرا حصہ Python میں خدمات لکھتا ہے اور اس میں مداخلت نہیں کرتا کہ دوسری سروسز کیسے کام کرتی ہیں؛ وہ اپنے علاقے میں الگ تھلگ ہیں۔ تیسرا پی ایچ پی میں خدمات لکھ رہا ہے یا کچھ اور۔
ان تمام 20 افراد کو 15 سروسز میں تقسیم کیا گیا ہے، اور صرف ایک ایڈمن ہے جسے یہ سب سمجھنا چاہیے۔ رکو! ہم نے سسٹم کو صرف 15 مائیکرو سروسز میں تقسیم کیا ہے کیونکہ 20 لوگ پورے سسٹم کو نہیں سمجھ سکتے۔

لیکن اسے کسی نہ کسی طرح مانیٹر کرنے کی ضرورت ہے...

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

میں کیا کہہ سکتا ہوں... ہیوسٹن، ہمیں مسائل ہیں۔

جدید سافٹ ویئر پروجیکٹ کی نگرانی کرنا اپنے آپ میں ایک سافٹ ویئر پروجیکٹ ہے۔

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

مثال کے طور پر، ایسی کئی خدمات ہیں جو کافکا کے ذریعے ایک دوسرے سے رابطہ کرتی ہیں۔ آرڈر پہنچ گیا، ہم نے کافکا کو آرڈر کے بارے میں پیغام بھیجا۔ ایک سروس ہے جو آرڈر کے بارے میں معلومات سنتی ہے اور سامان بھیجتی ہے۔ ایک خدمت ہے جو آرڈر کے بارے میں معلومات سنتی ہے اور صارف کو خط بھیجتی ہے۔ اور پھر ایک گروپ اور خدمات ظاہر ہوتی ہیں، اور ہم الجھنے لگتے ہیں۔

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

تو شروع سے شروع ہونے والے پروجیکٹ کی نگرانی کیسے کی جائے، اور اگر آپ کو کوئی ایسا پروجیکٹ مل جائے جس کی نگرانی کرنے کی ضرورت ہے، لیکن آپ نہیں جانتے کہ کہاں سے شروع کرنا ہے تو کیا کریں؟

سب سے پہلے، آپ کو منصوبہ بندی کرنے کی ضرورت ہے.

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

سب سے پہلے، فیصلہ کریں کہ آپ کیا اور کیسے مانیٹر کرنا چاہتے ہیں، اور پھر ایک ٹول منتخب کریں، کیونکہ دوسرے لوگ آپ کے لیے نہیں سوچ سکتے۔ اور انہیں چاہئے؟ دوسرے لوگوں نے اپنے آپ سے، ایک عالمگیر نظام کے بارے میں سوچا - یا یہ پلگ ان کب لکھا گیا تھا، بالکل نہیں سوچا۔ اور صرف اس لیے کہ اس پلگ ان کے 5 ہزار صارفین ہیں اس کا مطلب یہ نہیں کہ یہ کسی کام کا ہے۔ شاید آپ 5001 ویں بن جائیں گے کیونکہ وہاں پہلے ہی 5000 لوگ موجود تھے۔

اگر آپ انفراسٹرکچر کی نگرانی شروع کر دیتے ہیں اور آپ کی ایپلیکیشن کا بیک اینڈ جواب دینا بند کر دیتا ہے، تو تمام صارفین کا موبائل ایپلیکیشن سے رابطہ ختم ہو جائے گا۔ ایک خرابی ظاہر ہوگی۔ وہ آپ کے پاس آئیں گے اور کہیں گے "ایپلی کیشن کام نہیں کر رہی، آپ یہاں کیا کر رہے ہیں؟" - "ہم نگرانی کر رہے ہیں۔" - "اگر آپ نہیں دیکھتے ہیں کہ ایپلی کیشن کام نہیں کر رہی ہے تو آپ کیسے نگرانی کریں گے؟!"

1. مجھے یقین ہے کہ آپ کو صارف کے داخلے کے مقام سے بالکل نگرانی شروع کرنے کی ضرورت ہے۔ اگر صارف یہ نہیں دیکھتا ہے کہ ایپلی کیشن کام کر رہی ہے، تو یہ ہے، یہ ایک ناکامی ہے۔ اور نگرانی کے نظام کو پہلے اس بارے میں خبردار کرنا چاہیے۔
2. اور تب ہی ہم انفراسٹرکچر کی نگرانی کر سکتے ہیں۔ یا اسے متوازی طور پر کریں۔ بنیادی ڈھانچے کے ساتھ یہ آسان ہے - یہاں ہم آخر کار زبکس انسٹال کر سکتے ہیں۔
3. اور اب آپ کو یہ سمجھنے کے لیے ایپلی کیشن کی جڑوں تک جانے کی ضرورت ہے کہ چیزیں کہاں کام نہیں کر رہی ہیں۔

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

سطحوں کے لحاظ سے سب کچھ

اس طرح میں نگرانی کے نظام کی تنظیم کو دیکھتا ہوں۔

1) درخواست کی سطح:

• مانیٹرنگ ایپلی کیشن بزنس منطق؛
• خدمات کی صحت کی پیمائش کی نگرانی؛
• انضمام کی نگرانی.

2) بنیادی ڈھانچے کی سطح:

• آرکیسٹریشن کی سطح کی نگرانی؛
• سسٹم سافٹ ویئر کی نگرانی؛
• لوہے کی سطح کی نگرانی.

3) دوبارہ درخواست کی سطح - لیکن بطور انجینئرنگ پروڈکٹ:

• ایپلیکیشن لاگز کو جمع کرنا اور ان کی نگرانی کرنا؛
• اے پی ایم؛
• ٹریسنگ

4) تنبیہ:

• انتباہی نظام کی تنظیم؛
• ڈیوٹی کے نظام کی تنظیم؛
• ایک "علم کی بنیاد" کی تنظیم اور واقعہ کی کارروائی کے لیے ورک فلو۔

یہ ضروری ہے: ہم اس کے بعد نہیں بلکہ فوراً الرٹ ہو جاتے ہیں! نگرانی شروع کرنے اور "کسی نہ کسی طرح بعد میں" یہ معلوم کرنے کی ضرورت نہیں ہے کہ کس کو الرٹس موصول ہوں گے۔ آخر، نگرانی کا کام کیا ہے: یہ سمجھنا کہ سسٹم میں کہاں کچھ غلط کام کر رہا ہے، اور صحیح لوگوں کو اس کے بارے میں بتانا۔ اگر آپ اسے آخر تک چھوڑ دیتے ہیں، تو صحیح لوگوں کو پتہ چل جائے گا کہ کچھ غلط ہو رہا ہے صرف "ہمارے لیے کچھ کام نہیں کر رہا ہے۔"

ایپلیکیشن لیئر - بزنس لاجک مانیٹرنگ

یہاں ہم اس حقیقت کو جانچنے کے بارے میں بات کر رہے ہیں کہ ایپلی کیشن صارف کے لیے کام کرتی ہے۔

یہ سطح ترقی کے مرحلے کے دوران کیا جانا چاہئے. مثال کے طور پر، ہمارے پاس ایک مشروط Prometheus ہے: یہ سرور پر جاتا ہے جو چیک کرتا ہے، اینڈ پوائنٹ کو کھینچتا ہے، اور اینڈ پوائنٹ جاتا ہے اور API کو چیک کرتا ہے۔

جب اکثر ہوم پیج کو مانیٹر کرنے کے لیے کہا جاتا ہے تاکہ یہ یقینی بنایا جا سکے کہ سائٹ کام کر رہی ہے، پروگرامرز ایک ہینڈل دیتے ہیں جسے ہر بار کھینچا جا سکتا ہے تاکہ یہ یقینی بنایا جا سکے کہ API کام کر رہا ہے۔ اور پروگرامرز اس وقت بھی /api/test/helloworld لیتے اور لکھتے ہیں۔
یہ یقینی بنانے کا واحد طریقہ ہے کہ سب کچھ کام کرتا ہے؟ - نہیں!

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

تکنیکی تجاویز:

• چیکس کو منظم کرنے کے لیے ایک بیرونی سرور کو منظم کرنا یقینی بنائیں - آپ کو اس بات کا یقین ہونا چاہیے کہ آپ کا پروجیکٹ بیرونی دنیا کے لیے قابل رسائی ہے۔
• پورے API پروٹوکول میں چیکس کو منظم کریں، نہ صرف انفرادی اختتامی پوائنٹس۔
• ٹیسٹ کے نتائج کے ساتھ ایک prometheus-endpoint بنائیں۔

درخواست کی پرت - صحت کی پیمائش کی نگرانی

اب ہم خدمات کی بیرونی صحت کی پیمائش کے بارے میں بات کر رہے ہیں۔

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

اس کو تکنیکی طور پر صحیح طریقے سے کیسے نافذ کیا جائے: ہر سروس اپنی موجودہ کارکردگی کے بارے میں ایک اختتامی نقطہ ظاہر کرتی ہے، اور گرافانا (یا کوئی اور ایپلی کیشن) کے گراف میں ہم تمام خدمات کی حیثیت دیکھتے ہیں۔

• ہر API تبدیلی کو چیک میں تبدیلی کا باعث بننا چاہیے۔
• ہیلتھ میٹرکس کے ساتھ فوراً ایک نئی سروس بنائیں۔
• ایک منتظم ڈویلپرز کے پاس آ کر پوچھ سکتا ہے کہ "مجھے کچھ خصوصیات شامل کریں تاکہ میں سب کچھ سمجھوں اور اس کے بارے میں معلومات اپنے مانیٹرنگ سسٹم میں شامل کروں۔" لیکن ڈویلپرز عام طور پر جواب دیتے ہیں، "ہم ریلیز سے دو ہفتے پہلے کچھ بھی شامل نہیں کریں گے۔"
  ڈویلپمنٹ مینیجرز کو بتائیں کہ ایسے نقصانات ہوں گے، ڈویلپمنٹ مینیجرز کی انتظامیہ کو بھی بتائیں۔ کیونکہ جب سب کچھ گر جاتا ہے، تب بھی کوئی فون کرے گا اور "مسلسل گرتی ہوئی سروس" کی نگرانی کا مطالبہ کرے گا (c)
• ویسے، ڈیولپرز کو گرافانا کے لیے پلگ ان لکھنے کے لیے مختص کریں - یہ ایڈمنز کے لیے ایک اچھی مدد ہوگی۔

ایپلیکیشن لیئر - انٹیگریشن مانیٹرنگ

انضمام کی نگرانی کاروبار کے اہم نظاموں کے درمیان مواصلات کی نگرانی پر مرکوز ہے۔

مثال کے طور پر، 15 خدمات ہیں جو ایک دوسرے سے رابطہ کرتی ہیں۔ یہ اب الگ الگ سائٹس نہیں ہیں۔ وہ. ہم سروس کو خود سے نہیں کھینچ سکتے، /helloworld حاصل کریں اور سمجھیں کہ سروس چل رہی ہے۔ کیونکہ آرڈر دینے والی ویب سروس کو بس کو آرڈر کے بارے میں معلومات بھیجنی چاہیے - بس سے، گودام سروس کو یہ پیغام موصول ہونا چاہیے اور اس کے ساتھ مزید کام کرنا چاہیے۔ اور ای میل ڈسٹری بیوشن سروس کو اس پر کسی نہ کسی طرح مزید کارروائی کرنی چاہیے، وغیرہ۔

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

میں کیا کرنے کی سفارش کرتا ہوں:

• ہم آہنگ مواصلات کے لیے: اختتامی نقطہ متعلقہ خدمات سے درخواست کرتا ہے۔ وہ. ہم اس اختتامی نقطہ کو لیتے ہیں، سروس کے اندر ایک اسکرپٹ کھینچتے ہیں، جو تمام پوائنٹس پر جاتا ہے اور کہتا ہے "میں وہاں کھینچ سکتا ہوں، اور وہاں کھینچ سکتا ہوں، میں وہاں کھینچ سکتا ہوں..."
• غیر مطابقت پذیر مواصلات کے لیے: آنے والے پیغامات - اختتامی نقطہ امتحانی پیغامات کے لیے بس کو چیک کرتا ہے اور پروسیسنگ کی حیثیت کو ظاہر کرتا ہے۔
• غیر مطابقت پذیر مواصلات کے لیے: باہر جانے والے پیغامات - اختتامی نقطہ بس کو ٹیسٹ پیغامات بھیجتا ہے۔

جیسا کہ عام طور پر ہوتا ہے: ہمارے پاس ایک سروس ہے جو ڈیٹا کو بس میں ڈالتی ہے۔ ہم اس سروس پر آتے ہیں اور آپ سے کہتے ہیں کہ ہمیں اس کے انضمام کی صحت کے بارے میں بتائیں۔ اور اگر سروس کو کہیں آگے (WebApp) پیغام تیار کرنے کی ضرورت ہے، تو وہ یہ ٹیسٹ پیغام تیار کرے گی۔ اور اگر ہم آرڈر پروسیسنگ سائیڈ پر کوئی سروس چلاتے ہیں، تو یہ سب سے پہلے پوسٹ کرتا ہے کہ وہ کیا پوسٹ کر سکتا ہے، اور اگر کچھ منحصر چیزیں ہیں، تو یہ بس سے ٹیسٹ پیغامات کا ایک سیٹ پڑھتا ہے، سمجھتا ہے کہ وہ ان پر کارروائی کر سکتا ہے، رپورٹ کر سکتا ہے اور ، اگر ضروری ہو تو، انہیں مزید پوسٹ کریں، اور اس کے بارے میں وہ کہتے ہیں - سب کچھ ٹھیک ہے، میں زندہ ہوں.

اکثر ہم یہ سوال سنتے ہیں کہ "ہم اسے جنگی ڈیٹا پر کیسے جانچ سکتے ہیں؟" مثال کے طور پر، ہم اسی آرڈرنگ سروس کے بارے میں بات کر رہے ہیں۔ آرڈر گودام کو پیغامات بھیجتا ہے جہاں سامان لکھا جاتا ہے: ہم اسے جنگی اعداد و شمار پر نہیں جانچ سکتے، کیونکہ "میرا سامان لکھا جائے گا!" حل: اس پورے ٹیسٹ کی منصوبہ بندی شروع میں کریں۔ آپ کے پاس یونٹ ٹیسٹ بھی ہیں جو مذاق بناتے ہیں۔ لہذا، اسے ایک گہری سطح پر کریں جہاں آپ کے پاس ایک مواصلاتی چینل ہے جو کاروبار کے آپریشن کو نقصان نہیں پہنچاتا ہے۔

انفراسٹرکچر کی سطح

بنیادی ڈھانچے کی نگرانی ایک ایسی چیز ہے جسے طویل عرصے سے خود نگرانی سمجھا جاتا ہے۔

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

کاروباری یونٹ کے طور پر درخواست کی سطح

اہم نکات:

• ELK یہ صنعت کا معیار ہے۔ اگر کسی وجہ سے آپ لاگز کو جمع نہیں کر رہے ہیں، تو فوری طور پر ایسا کرنا شروع کریں۔
• اے پی ایم بیرونی APMs درخواست کی نگرانی کو فوری طور پر بند کرنے کے طریقے کے طور پر (NewRelic، BlackFire، Datadog)۔ آپ اس چیز کو عارضی طور پر انسٹال کر سکتے ہیں تاکہ کم از کم یہ سمجھ سکیں کہ آپ کے ساتھ کیا ہو رہا ہے۔
• ٹریسنگ درجنوں مائیکرو سروسز میں، آپ کو ہر چیز کا سراغ لگانا پڑتا ہے، کیونکہ درخواست اب خود نہیں رہتی۔ بعد میں شامل کرنا بہت مشکل ہے، اس لیے بہتر ہے کہ فوری طور پر ڈیولپمنٹ میں ٹریسنگ کو شیڈول کیا جائے - یہ ڈویلپرز کا کام اور افادیت ہے۔ اگر آپ نے ابھی تک اسے نافذ نہیں کیا ہے، تو اسے لاگو کریں! Jaeger/Zipkin دیکھیں

خبردار کرنا

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

ٹیکنالوجی اسٹیک

آئیے تصور کریں کہ ہمارا اسٹیک اس طرح ہے:

• ڈیٹا اکٹھا کرنا - Prometheus + Grafana؛
• لاگ تجزیہ - ELK؛
• APM یا ٹریسنگ کے لیے - Jaeger (Zipkin)۔

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

کچھ تکنیکی نکات جو میں نے حال ہی میں ہر جگہ دیکھے ہیں:

پرومیتھیس کو کبرنیٹس کے اندر دھکیلا جا رہا ہے - اس کے ساتھ کون آیا؟! اگر آپ کا کلسٹر کریش ہو جائے تو آپ کیا کریں گے؟ اگر آپ کے اندر ایک پیچیدہ کلسٹر ہے، تو کلسٹر کے اندر کچھ قسم کا مانیٹرنگ سسٹم ہونا چاہیے، اور کچھ باہر، جو کلسٹر کے اندر سے ڈیٹا اکٹھا کرے گا۔

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

نتائج

• ترقی کی نگرانی افادیت کی تنصیب نہیں ہے، لیکن ایک سافٹ ویئر کی مصنوعات کی ترقی ہے. آج کی نگرانی کا 98% کوڈنگ ہے۔ خدمات میں کوڈنگ، بیرونی چیک کوڈ کرنا، بیرونی خدمات کی جانچ کرنا، اور بس۔
• نگرانی پر اپنے ڈویلپرز کا وقت ضائع نہ کریں: یہ ان کے کام کا 30% تک لے سکتا ہے، لیکن یہ اس کے قابل ہے۔
• ڈیوپس، پریشان نہ ہوں کہ آپ کسی چیز کی نگرانی نہیں کر سکتے، کیونکہ کچھ چیزیں سوچنے کا بالکل مختلف طریقہ ہیں۔ آپ پروگرامر نہیں تھے، اور نگرانی کا کام بالکل ان کا کام ہے۔
• اگر پروجیکٹ پہلے سے چل رہا ہے اور اس کی نگرانی نہیں کی گئی ہے (اور آپ مینیجر ہیں)، تو نگرانی کے لیے وسائل مختص کریں۔
• اگر پروڈکٹ پہلے سے ہی پروڈکشن میں ہے، اور آپ ڈیوپس ہیں جنہیں "مانیٹرنگ سیٹ اپ" کرنے کے لیے کہا گیا تھا - انتظامیہ کو یہ سمجھانے کی کوشش کریں کہ میں نے یہ سب کیا لکھا ہے۔

یہ سینٹ ہائی لوڈ++ کانفرنس میں رپورٹ کا ایک توسیعی ورژن ہے۔

اگر آپ اس پر میرے خیالات اور خیالات اور متعلقہ موضوعات میں دلچسپی رکھتے ہیں، تو آپ یہاں کر سکتے ہیں۔ چینل پڑھیں 🙂

ماخذ: www.habr.com