میرا نام Anton Baderin ہے۔ میں ہائی ٹیکنالوجی سینٹر میں کام کرتا ہوں اور سسٹم ایڈمنسٹریشن کرتا ہوں۔ ایک ماہ قبل، ہماری کارپوریٹ کانفرنس ختم ہوئی، جہاں ہم نے اپنے شہر کی IT کمیونٹی کے ساتھ اپنے جمع شدہ تجربے کو شیئر کیا۔ میں نے ویب ایپلیکیشنز کی نگرانی کے بارے میں بات کی۔ مواد جونیئر یا درمیانی سطح کے لیے تھا، جنہوں نے اس عمل کو شروع سے نہیں بنایا۔
کسی بھی نگرانی کے نظام کی بنیاد کاروباری مسائل کو حل کرنا ہے۔ مانیٹرنگ کی خاطر مانیٹرنگ کرنا کسی کے مفاد میں نہیں۔ کاروبار کیا چاہتا ہے؟ تاکہ سب کچھ تیزی سے اور غلطیوں کے بغیر کام کرے۔ کاروبار فعال ہونا چاہتے ہیں، تاکہ ہم خود سروس میں مسائل کی نشاندہی کریں اور انہیں جلد از جلد حل کریں۔ یہ، درحقیقت، وہ مسائل ہیں جو میں نے پچھلے سال اپنے ایک صارفین کے لیے ایک پروجیکٹ پر حل کیے تھے۔
منصوبے کے بارے میں
یہ منصوبہ ملک کے سب سے بڑے لائلٹی پروگراموں میں سے ایک ہے۔ ہم مختلف مارکیٹنگ ٹولز جیسے بونس کارڈز کے ذریعے سیلز کی فریکوئنسی بڑھانے میں ریٹیل چینز کی مدد کرتے ہیں۔ مجموعی طور پر، پروجیکٹ میں 14 ایپلی کیشنز شامل ہیں جو دس سرورز پر چلتی ہیں۔
انٹرویو کے عمل کے دوران، میں نے بار بار دیکھا کہ ایڈمنز ہمیشہ ویب ایپلیکیشنز کی نگرانی کے لیے صحیح طریقے سے رجوع نہیں کرتے: بہت سے لوگ اب بھی آپریٹنگ سسٹم میٹرکس پر توجہ دیتے ہیں اور کبھی کبھار خدمات کی نگرانی کرتے ہیں۔
میرے معاملے میں، کسٹمر کا مانیٹرنگ سسٹم پہلے Icinga پر مبنی تھا۔ اس سے مندرجہ بالا مسائل کسی بھی طرح حل نہیں ہوئے۔ اکثر موکل خود ہمیں مسائل کے بارے میں مطلع کرتا تھا، اور اکثر و بیشتر، ہمارے پاس اس وجہ کی تہہ تک پہنچنے کے لیے کافی ڈیٹا نہیں تھا۔
اس کے علاوہ، اس کی مزید ترقی کی فضولیت کا واضح ادراک تھا۔ مجھے لگتا ہے کہ جو لوگ Icinga سے واقف ہیں وہ مجھے سمجھیں گے۔ لہذا، ہم نے پروجیکٹ کے لیے ویب ایپلیکیشن مانیٹرنگ سسٹم کو مکمل طور پر دوبارہ ڈیزائن کرنے کا فیصلہ کیا۔
Prometheus
ہم نے تین اہم اشارے کی بنیاد پر پرومیتھیس کا انتخاب کیا:
- دستیاب میٹرکس کی ایک بڑی تعداد۔ ہمارے معاملے میں ان میں سے 60 ہزار ہیں۔ یقیناً، یہ بات قابل توجہ ہے کہ ہم ان میں سے زیادہ تر استعمال نہیں کرتے (شاید تقریباً 95%)۔ دوسری طرف، وہ سب نسبتا سستے ہیں. ہمارے لیے، یہ پہلے استعمال شدہ Icinga کے مقابلے میں دوسری انتہا ہے۔ اس میں، میٹرکس کو شامل کرنا ایک خاص تکلیف تھی: موجودہ والے مہنگے تھے (صرف کسی بھی پلگ ان کا سورس کوڈ دیکھیں)۔ کوئی بھی پلگ ان Bash یا Python میں ایک اسکرپٹ تھا، جس کا لانچ وسائل کے استعمال کے لحاظ سے مہنگا ہے۔
- یہ نظام نسبتاً کم وسائل استعمال کرتا ہے۔ 600 MB RAM، 15% ایک کور اور دو درجن IOPS ہمارے تمام میٹرکس کے لیے کافی ہیں۔ بلاشبہ، آپ کو میٹرکس ایکسپورٹرز چلانا ہوں گے، لیکن وہ سب گو میں لکھے ہوئے ہیں اور زیادہ طاقت کے بھوکے بھی نہیں ہیں۔ مجھے نہیں لگتا کہ جدید حقائق میں یہ کوئی مسئلہ ہے۔
- Kubernetes میں ہجرت کرنے کی صلاحیت فراہم کرتا ہے۔ گاہک کے منصوبوں پر غور کرتے ہوئے، انتخاب واضح ہے۔
ELK
پہلے، ہم لاگز کو اکٹھا یا پروسیس نہیں کرتے تھے۔ کوتاہیاں سب پر عیاں ہیں۔ ہم نے ELK کا انتخاب کیا کیونکہ ہمیں پہلے ہی اس سسٹم کا تجربہ تھا۔ ہم وہاں صرف ایپلیکیشن لاگز اسٹور کرتے ہیں۔ بنیادی انتخاب کا معیار مکمل متن کی تلاش اور اس کی رفتار تھا۔
کلک ہاؤس
ابتدائی طور پر، انتخاب InfluxDB پر پڑا۔ ہمیں Nginx لاگز، pg_stat_statements سے اعداد و شمار جمع کرنے اور Prometheus کے تاریخی ڈیٹا کو ذخیرہ کرنے کی ضرورت کا احساس ہوا۔ ہمیں انفلکس پسند نہیں تھا کیونکہ اس نے وقتاً فوقتاً بڑی مقدار میں میموری استعمال کرنا شروع کر دی اور کریش ہو گیا۔ اس کے علاوہ، میں remote_addr کے ذریعے سوالات کو گروپ کرنا چاہتا تھا، لیکن اس DBMS میں گروپ بندی صرف ٹیگز کے ذریعے ہے۔ ٹیگز مہنگے ہیں (میموری)، ان کی تعداد مشروط طور پر محدود ہے۔
ہم نے دوبارہ تلاش شروع کی۔ جس چیز کی ضرورت تھی وہ کم سے کم وسائل کی کھپت کے ساتھ ایک تجزیاتی ڈیٹا بیس کی تھی، ترجیحاً ڈسک پر ڈیٹا کمپریشن کے ساتھ۔
کلک ہاؤس ان تمام معیارات پر پورا اترتا ہے، اور ہمیں اپنے انتخاب پر کبھی افسوس نہیں ہوا۔ ہم اس میں ڈیٹا کی کوئی غیر معمولی مقدار نہیں لکھتے ہیں (انصاف کی تعداد صرف پانچ ہزار فی منٹ ہے)۔
نیو ریلک
NewRelic تاریخی طور پر ہمارے ساتھ رہا ہے کیونکہ یہ گاہک کی پسند تھی۔ ہم اسے بطور اے پی ایم استعمال کرتے ہیں۔
زبیبس
ہم مختلف APIs کے بلیک باکس کی نگرانی کے لیے خصوصی طور پر Zabbix کا استعمال کرتے ہیں۔
مانیٹرنگ اپروچ کی تعریف
ہم کام کو ختم کرنا چاہتے تھے اور اس طرح نگرانی کے نقطہ نظر کو منظم کرنا چاہتے تھے۔
ایسا کرنے کے لیے، میں نے اپنے نظام کو درج ذیل سطحوں میں تقسیم کیا:
- ہارڈ ویئر اور VMS؛
- آپریٹنگ سسٹم؛
- سسٹم سروسز، سافٹ ویئر اسٹیک؛
- درخواست؛
- کاروباری منطق.
یہ نقطہ نظر کیوں آسان ہے:
- ہم جانتے ہیں کہ ہر سطح کے کام کا ذمہ دار کون ہے اور، اس کی بنیاد پر، ہم الرٹ بھیج سکتے ہیں۔
- انتباہات کو دباتے وقت ہم ڈھانچے کا استعمال کر سکتے ہیں - جب مجموعی طور پر ورچوئل مشین دستیاب نہ ہو تو ڈیٹا بیس کی عدم دستیابی کے بارے میں الرٹ بھیجنا عجیب ہوگا۔
چونکہ ہمارا کام نظام کے عمل میں ہونے والی خلاف ورزیوں کی نشاندہی کرنا ہے، اس لیے ہمیں ہر سطح پر میٹرکس کے ایک مخصوص سیٹ کو نمایاں کرنا چاہیے جو الرٹ کرنے کے قواعد لکھتے وقت توجہ دینے کے قابل ہیں۔ اس کے بعد، آئیے "VMS"، "آپریٹنگ سسٹم" اور "سسٹم سروسز، سافٹ ویئر اسٹیک" کی سطحوں سے گزرتے ہیں۔
ورچوئل مشینیں۔
ہوسٹنگ ہمیں پروسیسر، ڈسک، میموری اور نیٹ ورک مختص کرتی ہے۔ اور ہمیں پہلے دو کے ساتھ مسائل تھے۔ تو، میٹرکس:
CPU چوری کا وقت - جب آپ Amazon (t2.micro، مثال کے طور پر) پر ایک ورچوئل مشین خریدتے ہیں، تو آپ کو سمجھنا چاہیے کہ آپ کو پورا پروسیسر کور نہیں دیا گیا ہے، بلکہ اس کے وقت کا صرف ایک کوٹہ ہے۔ اور جب آپ اسے ختم کردیں گے تو پروسیسر آپ سے چھین لیا جائے گا۔
یہ میٹرک آپ کو ایسے لمحات کو ٹریک کرنے اور فیصلے کرنے کی اجازت دیتا ہے۔ مثال کے طور پر، کیا موٹا ٹیرف لینا یا بیک گراؤنڈ ٹاسک اور API کی درخواستوں کی پروسیسنگ کو مختلف سرورز میں تقسیم کرنا ضروری ہے؟
IOPS + CPU iowait time - کسی وجہ سے، بہت سے کلاؤڈ ہوسٹنگ کافی IOPS فراہم نہ کر کے گناہ کرتے ہیں۔ مزید یہ کہ کم IOPS والا شیڈول ان کے لیے دلیل نہیں ہے۔ لہذا، یہ CPU iowait کو جمع کرنے کے قابل ہے. گراف کے اس جوڑے کے ساتھ - کم IOPS اور اعلی I/O انتظار کے ساتھ - آپ پہلے ہی ہوسٹنگ سے بات کر سکتے ہیں اور مسئلہ حل کر سکتے ہیں۔
آپریٹنگ سسٹم
آپریٹنگ سسٹم میٹرکس:
- % میں دستیاب میموری کی مقدار؛
- تبادلہ استعمال کی سرگرمی: vmstat swapin، swapout؛
- % میں فائل سسٹم پر دستیاب انوڈس اور خالی جگہ کی تعداد
- اوسط بوجھ؛
- دو ریاستوں میں کنکشن کی تعداد؛
- contrack ٹیبل پرپورنتا؛
- نیٹ ورک کے معیار کو ss یوٹیلیٹی، iproute2 پیکیج کا استعمال کرتے ہوئے مانیٹر کیا جا سکتا ہے - اس کے آؤٹ پٹ سے RTT کنکشن کا انڈیکیٹر حاصل کریں اور اسے ڈیسٹ پورٹ کے ذریعے گروپ کریں۔
نیز آپریٹنگ سسٹم کی سطح پر ہمارے پاس عمل جیسی ایک ہستی ہے۔ سسٹم میں عمل کے ایک سیٹ کی نشاندہی کرنا ضروری ہے جو اس کے آپریشن میں اہم کردار ادا کرتے ہیں۔ اگر، مثال کے طور پر، آپ کے پاس کئی pgpools ہیں، تو آپ کو ان میں سے ہر ایک کے لیے معلومات جمع کرنے کی ضرورت ہے۔
میٹرکس کا سیٹ اس طرح ہے:
- سی پی یو؛
- میموری بنیادی طور پر رہائشی ہے؛
- IO - ترجیحا IOPS میں؛
- فائل ایف ڈی - کھلا اور حد؛
- اہم صفحہ کی ناکامیاں - اس طرح آپ سمجھ سکتے ہیں کہ کس عمل کو تبدیل کیا جا رہا ہے۔
ہم تمام مانیٹرنگ کو Docker میں تعینات کرتے ہیں، اور ہم میٹرکس ڈیٹا اکٹھا کرنے کے لیے ایڈوائزر کا استعمال کرتے ہیں۔ دوسری مشینوں پر ہم پروسیس ایکسپورٹر استعمال کرتے ہیں۔
سسٹم سروسز، سافٹ ویئر اسٹیک
ہر ایپلیکیشن کی اپنی خصوصیات ہیں، اور میٹرکس کے مخصوص سیٹ کو اکٹھا کرنا مشکل ہے۔
عالمگیر سیٹ یہ ہے:
- درخواست کی شرح؛
- غلطیوں کی تعداد؛
- تاخیر؛
- سنترپتی
اس سطح پر نگرانی کی ہماری سب سے نمایاں مثالیں Nginx اور PostgreSQL ہیں۔
ہمارے سسٹم میں سب سے زیادہ بھری ہوئی سروس ڈیٹا بیس ہے۔ ماضی میں، ہمیں اکثر یہ جاننے میں دشواری ہوتی تھی کہ ڈیٹا بیس کیا کر رہا ہے۔
ہم نے ڈسکوں پر زیادہ بوجھ دیکھا، لیکن سست لاگز نے واقعی کچھ نہیں دکھایا۔ ہم نے اس مسئلے کو pg_stat_statements کا استعمال کرتے ہوئے حل کیا، ایک ایسا منظر جو استفسار کے اعداد و شمار جمع کرتا ہے۔
بس ایڈمن کی ضرورت ہے۔
ہم پڑھنے اور لکھنے کی درخواستوں کی سرگرمی کا گراف بناتے ہیں:
سب کچھ سادہ اور واضح ہے، ہر درخواست کا اپنا رنگ ہے۔
اسی طرح کی حیرت انگیز مثال Nginx لاگز ہے۔ یہ حیرت کی بات نہیں ہے کہ بہت کم لوگ ان کی تجزیہ کرتے ہیں یا ان کا ذکر ضروری اشیاء کی فہرست میں کرتے ہیں۔ معیاری شکل زیادہ معلوماتی نہیں ہے اور اسے وسعت دینے کی ضرورت ہے۔
ذاتی طور پر، میں نے request_time، upstream_response_time، body_bytes_sent، request_length، request_id شامل کیا۔ ہم جوابی وقت اور غلطیوں کی تعداد کی منصوبہ بندی کرتے ہیں:
ہم جوابی وقت اور غلطیوں کی تعداد کا گراف بناتے ہیں۔ یاد ہے؟ کیا میں نے کاروباری کاموں کے بارے میں بات کی؟ جلدی اور غلطیوں کے بغیر؟ ہم پہلے ہی دو چارٹ کے ساتھ ان مسائل کا احاطہ کر چکے ہیں۔ اور آپ ان کا استعمال کرتے ہوئے پہلے ہی منتظمین کو ڈیوٹی پر کال کر سکتے ہیں۔
لیکن ایک اور مسئلہ باقی ہے - واقعے کی وجوہات کے تیزی سے خاتمے کو یقینی بنانا۔
واقعہ کا حل
کسی مسئلے کی شناخت سے لے کر حل کرنے تک کے پورے عمل کو کئی مراحل میں تقسیم کیا جا سکتا ہے:
- مسئلہ کی شناخت؛
- ڈیوٹی ایڈمنسٹریٹر کو اطلاع؛
- ایک واقعہ کا جواب؛
- وجوہات کا خاتمہ.
یہ ضروری ہے کہ ہمیں یہ کام جلد از جلد کرنا چاہیے۔ اور اگر کسی مسئلے کی نشاندہی کرنے اور اطلاع بھیجنے کے مراحل میں ہم زیادہ وقت حاصل نہیں کر سکتے ہیں - کسی بھی صورت میں ان پر دو منٹ صرف کیے جائیں گے، تو اس کے بعد والے صرف بہتری کے لیے خالی کھیت ہیں۔
ذرا تصور کریں کہ ڈیوٹی آفیسر کے فون کی گھنٹی بجی۔ وہ کیا کرے گا؟ سوالوں کے جوابات تلاش کریں - کیا ٹوٹا، کہاں ٹوٹا، کیسے رد عمل ظاہر کیا؟ یہاں ہم ان سوالات کا جواب کیسے دیتے ہیں:
ہم صرف یہ تمام معلومات نوٹیفکیشن کے متن میں شامل کرتے ہیں، اسے ایک ویکی پیج کا لنک دیتے ہیں جس میں بتایا گیا ہے کہ اس مسئلے کا جواب کیسے دیا جائے، اسے کیسے حل کیا جائے اور اسے کیسے بڑھایا جائے۔
میں نے ابھی تک درخواست کی پرت اور کاروباری منطق کے بارے میں کچھ نہیں کہا ہے۔ بدقسمتی سے، ہماری ایپلیکیشنز ابھی تک میٹرکس کے مجموعہ کو نافذ نہیں کرتی ہیں۔ ان سطحوں سے کسی بھی معلومات کا واحد ذریعہ نوشتہ جات ہیں۔
ایک دو پوائنٹس۔
سب سے پہلے، ساختی نوشتہ جات لکھیں۔ پیغام کے متن میں سیاق و سباق کو شامل کرنے کی ضرورت نہیں ہے۔ اس سے انہیں گروپ بندی اور تجزیہ کرنا مشکل ہو جاتا ہے۔ Logstash کو اس سب کو معمول پر لانے میں کافی وقت لگتا ہے۔
دوم، شدت کی سطح کو صحیح طریقے سے استعمال کریں۔ ہر زبان کا اپنا ایک معیار ہے۔ ذاتی طور پر، میں چار سطحوں میں فرق کرتا ہوں:
- کوئی غلطی نہیں؛
- کلائنٹ کی طرف کی غلطی؛
- غلطی ہماری طرف سے ہے، ہم پیسے نہیں کھوتے، ہم خطرات برداشت نہیں کرتے؛
- غلطی ہماری طرف سے ہے، ہم پیسے کھو دیتے ہیں۔
مجھے خلاصہ کرنے دو۔ آپ کو کاروباری منطق کی بنیاد پر مانیٹرنگ بنانے کی کوشش کرنی ہوگی۔ ایپلیکیشن کی خود نگرانی کرنے کی کوشش کریں اور سیلز کی تعداد، نئے صارف کے رجسٹریشن کی تعداد، فی الحال فعال صارفین کی تعداد، وغیرہ جیسے میٹرکس کے ساتھ کام کریں۔
اگر آپ کا پورا کاروبار براؤزر میں ایک بٹن ہے، تو آپ کو نگرانی کرنے کی ضرورت ہے کہ آیا یہ کلک کرتا ہے اور ٹھیک سے کام کرتا ہے۔ باقی سب سے کوئی فرق نہیں پڑتا۔
اگر آپ کے پاس یہ نہیں ہے، تو آپ اسے ایپلیکیشن لاگز، Nginx لاگز وغیرہ میں پکڑنے کی کوشش کر سکتے ہیں، جیسا کہ ہم نے کیا تھا۔ آپ کو درخواست کے زیادہ سے زیادہ قریب ہونا چاہئے۔
آپریٹنگ سسٹم میٹرکس یقیناً اہم ہیں، لیکن کاروبار کو ان میں کوئی دلچسپی نہیں، ہمیں ان کے لیے ادائیگی نہیں کی جاتی۔
ماخذ: www.habr.com