نگرانی اور مشاہدہ: اے پی ایم، لاگنگ اور الرٹنگ بہترین پریکٹسز

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

اہم ٹیک ویز

• مشاہدے کے تین ستون -- میٹرکس، لاگز اور ٹریس -- ہر ایک مختلف سوالات کا جواب دیتا ہے اور نظام کی مکمل تفہیم فراہم کرنے کے لیے مل کر کام کرتا ہے
• علامات پر انتباہ (صارف کا سامنا کرنے والا اثر) انتباہی تھکاوٹ کو کم کرنے اور ناول ناکامی کے طریقوں کو پکڑنے کا سبب نہیں بنتا (اندرونی میٹرکس)
• ارتباطی IDs کے ساتھ سٹرکچرڈ JSON لاگنگ تمام سروسز میں تلاش کرنے اور درخواست کے بہاؤ کی تشکیل نو کے قابل بناتی ہے۔
• SLOs (سروس لیول کے مقاصد) نگرانی کو "کیا کچھ ٹوٹا ہوا ہے" سے "کیا ہم صارفین کے ساتھ اپنے وعدوں کو پورا کرتے ہیں" میں تبدیل کر رہے ہیں

---

مشاہدے کے تین ستون

مشاہدہ کرنے کی صلاحیت تین تکمیلی ڈیٹا کی اقسام پر بنائی گئی ہے۔ ہر ستون آپ کے سسٹم کے رویے کے بارے میں مختلف سوالات کا جواب دیتا ہے۔

میٹرکس

میٹرکس عددی پیمائش ہیں جو باقاعدہ وقفوں پر جمع کی جاتی ہیں۔ وہ "کیا ہو رہا ہے" سوالات کا جواب دیتے ہیں: فی سیکنڈ کتنی درخواستیں؟ اوسط جوابی وقت کیا ہے؟ کتنی میموری استعمال میں ہے؟

خصوصیات:

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

** کلیدی میٹرک اقسام:**

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

لاگز

لاگز مجرد واقعات کے ٹائم اسٹیمپڈ ٹیکسٹ ریکارڈ ہیں۔ وہ "کیا ہوا" سوالات کا جواب دیتے ہیں: صارف نے غلطی کا کون سا پیغام دیکھا؟ ناکام فنکشن میں کون سے پیرامیٹرز پاس کیے گئے؟ جب مسئلہ ہوا تو نظام کی کیا حالت تھی؟

خصوصیات:

• بھرپور سیاق و سباق - انفرادی واقعات کے بارے میں صوابدیدی تفصیل
• پیمانے پر مہنگا -- ہائی ٹریفک سسٹم فی گھنٹہ گیگا بائٹس لاگ تیار کرتے ہیں
• قابل تلاش - مکمل متن کی تلاش کے ساتھ مخصوص واقعات تلاش کریں۔
• ساخت کی ضرورت ہے -- غیر ساختہ لاگ لائنوں کو پارس کرنا اور باہم مربوط کرنا مشکل ہے۔

نشانات

نشانات متعدد خدمات میں ایک ہی درخواست کی پیروی کرتے ہیں۔ وہ "وقت کہاں گزارا" سوالات کے جوابات دیتے ہیں: کون سی سروس کال سست ہے؟ درخواست کا راستہ کہاں بدل جاتا ہے؟ کون سا ڈیٹا بیس استفسار رکاوٹ ہے؟

خصوصیات:

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

---

مشاہداتی ٹول ایکو سسٹم

اسٹیک کا انتخاب کرنا

زیادہ تر بڑھتے ہوئے کاروباروں کے لیے، ہم ان کے ساتھ شروع کرنے کی تجویز کرتے ہیں:

1. غلطی سے باخبر رہنے کے لیے سینٹری -- مکمل اسٹیک ٹریس، سورس میپس، اور ریلیز ٹریکنگ کے ساتھ مستثنیات کیچ کرتا ہے
2. Prometheus + Grafana میٹرکس کے لیے -- اوپن سورس، جنگ کا تجربہ، وسیع انضمام ماحولیاتی نظام
3. منظم سروس میں سٹرکچرڈ لاگنگ -- آپ کے کلاؤڈ فراہم کنندہ کے لحاظ سے ڈیٹا ڈاگ لاگز، AWS CloudWatch، یا گرافانا لوکی
4. OpenTelemetry آلات سازی کے لیے -- وینڈر غیر جانبدار معیار جو کسی بھی بیک اینڈ کے ساتھ کام کرتا ہے

ان ٹیموں کے لیے جو ایک وینڈر چاہتے ہیں، Datadog سب سے بہترین تجربہ فراہم کرتا ہے لیکن بڑے پیمانے پر قیمت پر۔ گرافانا کا اوپن سورس اسٹیک (Prometheus, Loki, Tempo) لائسنس کی کم لاگت لیکن زیادہ آپریشنل بوجھ کے ساتھ مساوی صلاحیتیں فراہم کرتا ہے۔

---

سٹرکچرڈ لاگنگ کے بہترین طریقے

غیر ساختہ لاگ لائنیں جیسے Error processing order 12345 for user [email protected] انسان کے پڑھنے کے قابل لیکن مشین مخالف ہیں۔ سٹرکچرڈ JSON لاگز مخصوص فیلڈز پر تلاش، فلٹرنگ، ایگریگیٹنگ اور الرٹنگ کو فعال کرتے ہیں۔

لاگ ڈھانچہ

ہر لاگ انٹری میں شامل ہونا چاہئے:

ارتباطی IDs

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

عمل درآمد: API گیٹ وے یا لوڈ بیلنس پر UUID بنائیں، اسے X-Request-ID ہیڈر میں پاس کریں، اور اسے ہر لاگ انٹری میں شامل کریں۔ NestJS میں، ایک مڈل ویئر کا استعمال کریں جو ارتباطی ID کو نکالتا یا تیار کرتا ہے اور اسے async لوکل اسٹوریج سیاق و سباق میں اسٹور کرتا ہے۔

لاگ لیولز

لاگ سطحوں کو مستقل طور پر استعمال کریں:

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

لاگ برقرار رکھنے اور لاگت کا انتظام

لاگز ذخیرہ کرنے کے لیے سب سے مہنگا مشاہداتی ڈیٹا ہیں۔ ٹائرڈ برقراری کو لاگو کریں:

• ہاٹ اسٹوریج (30 دن) -- مکمل متن تلاش کرنے کے قابل، تیز سوالات، زیادہ قیمت
• گرم اسٹوریج (90 دن) -- کمپریسڈ، سست سوالات، معتدل قیمت
• کولڈ اسٹوریج (1 سال+) -- آرکائیو شدہ، طلب پر سوال، کم قیمت
• ڈیبگ لاگز -- پروڈکشن میں ذخیرہ نہ کریں جب تک کہ فعال طور پر ٹربل شوٹنگ نہ ہو۔

---

الرٹنگ ڈیزائن

خراب انتباہ الرٹ تھکاوٹ پیدا کرتا ہے -- ٹیمیں الرٹس کا جواب دینا بند کر دیتی ہیں کیونکہ زیادہ تر غلط مثبت یا کم ترجیحی شور ہوتے ہیں۔ اچھا انتباہ حقیقی مسائل کو ظاہر کرتا ہے جن میں انسانی مداخلت کی ضرورت ہوتی ہے۔

علامات پر الرٹ، وجوہات نہیں۔

علامت پر مبنی الرٹ (اچھا): "/api/ آرڈرز پر خرابی کی شرح 5 منٹ کے لیے 1% سے تجاوز کر گئی" -- یہ بنیادی وجہ سے قطع نظر صارف کے اثرات کی براہ راست نشاندہی کرتا ہے۔

وجہ پر مبنی الرٹ (خراب): "ڈیٹا بیس CPU 90% سے تجاوز کر گیا" -- یہ صارفین کو متاثر کر سکتا ہے یا نہیں بھی۔ ڈیٹا بیس 95% CPU کو ٹھیک ہینڈل کر سکتا ہے، یا یہ 50% CPU پر ہو سکتا ہے لیکن مکمل طور پر تعطل کا شکار ہے۔

وجہ پر مبنی میٹرکس تحقیقات کے لیے ڈیش بورڈز پر ہیں، الرٹ کرنے والے قوانین میں نہیں۔

الرٹ کی شدت کی سطح

الرٹ شور کو کم کرنا

1. گروپ سے متعلق انتباہات -- اگر ڈیٹا بیس نیچے چلا جاتا ہے، تو آپ کو ایک "ڈیٹا بیس غیر دستیاب" الرٹ ملتا ہے، ہر اس سروس سے 50 الرٹس نہیں جو اس پر منحصر ہوتی ہے۔
2. مستقل خلاف ورزی کی ضرورت ہے -- عارضی اسپائکس سے بچنے کے لیے "5 منٹ کے لیے 90% سے اوپر CPU" نہیں "1 سیکنڈ کے لیے 90% سے اوپر CPU"
3. خودکار حل -- حالت کے حل ہونے پر الرٹس خود بخود صاف ہو جائیں گے۔
4. ہفتہ وار انتباہ کا جائزہ -- ان تمام انتباہات کا جائزہ لیں جنہوں نے فائر کیا، ان کی شناخت اور درست یا خاموشی اختیار کی جن کے لیے انسانی کارروائی کی ضرورت نہیں تھی۔
5. آن کال فیڈ بیک لوپ -- ہر آن کال روٹیشن کے بعد، انجینئر دستاویزات جو انتباہات قابل عمل تھے اور جن کو ٹیوننگ کی ضرورت ہے

---

SLOs: سروس لیول کے مقاصد

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

SLOs کی تعریف

ایک SLO کسی سروس کے لیے ہدف کی وشوسنییتا کی وضاحت کرتا ہے۔ اس پر مشتمل ہے:

• SLI (سروس لیول انڈیکیٹر) -- پیمائش کی جا رہی میٹرک (درخواست کامیابی کی شرح، تاخیر کا فیصد)
• ٹارگٹ -- وہ حد جو قابل قبول کارکردگی کی وضاحت کرتی ہے (99.9% کامیابی کی شرح، P95 200ms سے کم)
• ونڈو -- وقت کی مدت جس میں ہدف کا اندازہ لگایا جاتا ہے (30 دن چل رہا ہے)

ای کامرس پلیٹ فارم کے لیے SLOs کی مثال

خرابی کے بجٹ

خرابی کا بجٹ آپ کے SLO ہدف کا الٹا ہے۔ ایک 99.9% SLO 0.1% غلطیوں کی اجازت دیتا ہے -- ہر ماہ تقریباً 43 منٹ کا ڈاؤن ٹائم۔ جب خرابی کا بجٹ ختم ہو جاتا ہے، تو ٹیم خصوصیات سے بھروسے کے کام کی طرف توجہ مرکوز کر دیتی ہے۔

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

---

اکثر پوچھے گئے سوالات

پیمانے پر مشاہدے کی قیمت کتنی ہے؟

اوپن سورس اسٹیکس (پرومیتھیس، گرافانا، لوکی) کے لیے مشاہداتی لاگت فی میزبان $10-50 سے لے کر $30-100+ فی میزبان تجارتی حل (ڈیٹا ڈوگ، نیو ریلیک) کے لیے ہے۔ سب سے بڑی لاگت کا ڈرائیور لاگ والیوم ہے -- ڈیبگ لاگز کے نمونے لے کر، ذخیرہ شدہ لاگز کو کمپریس کر کے، اور مناسب برقرار رکھنے کے دورانیے کو ترتیب دے کر بہتر بنائیں۔ 50 سرورز کے تحت زیادہ تر کاروباروں کے لیے، لاگت $500-2,000 فی مہینہ ہے۔

کیا مجھے OpenTelemetry یا وینڈر کے لیے مخصوص ایجنٹ استعمال کرنا چاہیے؟

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

میں NestJS ایپلیکیشن کے لیے مانیٹرنگ کیسے ترتیب دوں؟

NestJS میں، درخواست کے وقت کے لیے انٹرسیپٹرز کا استعمال کریں، غلطی سے باخبر رہنے کے لیے استثنائی فلٹرز، اور ارتباطی ID کے پھیلاؤ کے لیے مڈل ویئر کا استعمال کریں۔ غلطی سے باخبر رہنے کے لیے سنٹری کو @sentry/nestjs کے ساتھ ضم کریں۔ prom-client لائبریری کے ساتھ Prometheus میٹرکس کو /metrics کے اختتامی نقطہ پر برآمد کریں۔ JSON آؤٹ پٹ کے لیے nestjs-pino یا winston کے ساتھ تشکیل شدہ لاگنگ کا استعمال کریں۔

نگرانی اور مشاہدے میں کیا فرق ہے؟

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

میں اپنی ٹیم کو مشاہدے میں سرمایہ کاری کے لیے کیسے قائل کروں؟

مشاہداتی بہتری سے پہلے اور بعد میں پیداواری واقعات کے لیے مین ٹائم ٹو ریزولوشن (MTTR) کو ٹریک کریں۔ اچھی مشاہدہ کرنے والی ٹیمیں عام طور پر MTTR کو 60-70% تک کم کرتی ہیں۔ ROI دکھانے کے لیے انجینئرنگ لاگت سے بچائے گئے وقت کو ضرب دیں۔ نیز صارف کی رپورٹس کے مقابلے میں نگرانی کے ذریعے پائے جانے والے واقعات کی تعداد کا پتہ لگائیں -- فعال پتہ لگانے سے صارفین کا اعتماد بڑھتا ہے۔

---

آگے کیا ہے۔

اگر آپ کے پاس کچھ نہیں ہے تو ایرر ٹریکنگ (سینٹری) کے ساتھ شروع کریں -- یہ پروڈکشن کی غلطیوں کو پکڑنے اور ان پر متنبہ کرکے سب سے فوری قیمت فراہم کرتا ہے۔ اگلا، ارتباطی IDs کے ساتھ سٹرکچرڈ لاگنگ شامل کریں۔ پھر Prometheus اور Grafana ڈیش بورڈز کے ساتھ میٹرکس کلیکشن کو لاگو کریں۔ آخر میں، جب آپ کے پاس متعدد خدمات ہوں تو تقسیم شدہ ٹریسنگ شامل کریں۔

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

ECOSIRE Odoo ERP اور حسب ضرورت تعمیرات پر چلنے والے کاروباری پلیٹ فارمز کے لیے مشاہداتی اسٹیک کو لاگو کرتا ہے۔ ہماری DevOps ٹیم سے رابطہ کریں نگرانی اور مشاہدے کے جائزے کے لیے۔

---

شائع کردہ بذریعہ ECOSIRE — کاروباروں کو Odoo ERP، Shopify eCommerce، اور OpenClaw AI میں AI سے چلنے والے حل کے ساتھ پیمانے میں مدد کرنا۔