کم سے کم کے ساتھ زیادہ کرنا؟ بہتر لاگ ان اور بہتر آلات کے بغیر نہیں

جب سے میں نے 1992 میں ٹیکنالوجی میں شروع کیا (تقریبا تین دہائیوں پہلے!), میں نے بہت سے اسکرینوں کا سامنا کیا ہے جہاں مجھے انتظار کیا گیا تھا کہ میں کم سے کم کے ساتھ زیادہ کروں.

ایک تجربہ میرے وقت میں ایک کلاؤڈ ماڈلنگ پروجیکٹ پر ایک بیکٹینڈ آرکیٹیکٹ کے طور پر نظر آتا ہے.minimize or eliminate service-level logging—لوگنگ کہ ہم ڈبگنگ اور واقعات کا تجزیہ کرنے کے لئے بڑے پیمانے پر پر بھروسہ کیا. اس فیصلے کو ہماری نگرانی کے پلیٹ فارم پر لاگ ان کی اعلی قیمت کی وجہ سے ڈرائیو کیا گیا تھا.

یہ کام کرتا تھا - جب تک یہ نہیں ہوا.

ہم واقعی ان گیمز کی ضرورت تھی!

غیر متوقع طور پر، ایک غیر متوقع مسئلہ پیدا ہوا، اور ہمیں ان ناکام لوگوں کی ضرورت تھی. وہ بنیادی وجہ کو تلاش کرنے کا واحد طریقہ بن گیا. ان کے بغیر، گھنٹوں کو حل کے بغیر چیک کیا گیا، غیر یقینی بڑھ گیا، اور اضطراب نے پوری ٹیم کو پیروی کی.

// Sample (but not the real) log line removed during our cost-cutting
{
  "timestamp": "2025-03-21T14:05:03Z",
  "service": "preference-engine",
  "level": "ERROR",
  "message": "Worker queue overflow: unable to dispatch to worker pool",
  "requestId": "abc123",
  "userId": "admin_42"
}

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

_sourceCategory=prod/preference-engine "Worker queue overflow"
| count by userId, requestId

ہمارے درختوں کو کم کرنے کے لئے کہا جاتا ہے کہ پوری منصوبہ بندی کو ایک حساس حالت میں ڈال دیا گیا ہے.

لیین کا مطلب یہ نہیں ہے کہ وسائل کے لئے بھوکا ہے

واضح کرنے کے لئے، "جیسے کم کے ساتھ زیادہ کریں" ذہنیت بنیادی طور پر برا نہیں ہے. بہت سے شروع کاروں کو اہم ترجیحات پر توجہ مرکوز کرتے ہوئے اور ہلکے، مؤثر سافٹ ویئر کا استعمال کرتے ہوئے ترقی.

لیکن یہ "ایک اچھا" نوعیت نہیں تھا. اور کلاؤڈ میں منتقل کرنے کے لئے ہماری مدت مقرر کی گئی تھی. ہم براؤزر کی کمائی کی تاریخ کے خلاف مقابلہ کر رہے تھے. اس کا مطلب یہ تھا کہ سروسز کو کلاؤڈ پر مبنی ڈیزائن میں دوبارہ لکھنا، کسٹمر ٹیموں کے ساتھ تعاون کرنا، اور دباؤ کے تحت فراہم کرنا. مکمل ٹیسٹ کی پوزیشن یا گہری نگرانی کے انضمام کے لئے وقت کے بغیر،we relied on logs to resolve our issuesاور غیر متوقع سکرین کے لئے بنیادی وجہ کا تعین کرنے میں مدد کریں. جو ابتدائی طور پر ٹھیک تھا، ہم نے صرف ہر طریقہ کار پر کام کرتے وقت ضروری لاگ ان کو شامل کیا.

لیکن جب لوڈنگ کاٹ دیا گیا تھا، ٹیم کو ظاہر کیا گیا تھا.

ریٹ کی وجہ نیٹ کے بغیر

Internal testing went well. As production approached, we felt confident in our new cloud-based architecture. We had resolved known issues in test and met our deadline.

لیکن ہم جلدی سمجھ گئے کہ ہماری اعتماد غلط جگہ پر تھی اور ہماری ٹیسٹ کی پوشیدہیت کی کمی تھی.

ایک بار جب ہم پیداوار میں تھے اور حقیقی گاہکوں نے پلیٹ فارم کا استعمال کیا تھا تو، ان پریشان غیر متوقع کنارے کیسوں کو ظاہر کیا گیا تھا. اور یقینی طور پر، تفصیلی لاگ ان یا کافی نگرانی کے بغیر، ہم اس مسئلہ کی تحقیقات کرنے کا کوئی طریقہ نہیں تھا.

اگر ہم دونوں backend ٹیسٹ اور frontend پر پیداوار گاہکوں کے لئے لاگ ان تھے تو، ہم جان سکتے تھے کہ کیا ہوتا ہے اور ٹیم (اور صارف) کو خبردار کیا.

_sourceCategory=prod/preference-engine OR prod/frontend error
| join ( _sourceCategory=prod/tester-feedback “queue error” )
  on requestId
| fields requestId, _sourceCategory, message

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

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

MTTR کے مقابلے میں سیگنال کے معیار

ایک اور مسئلہ یہ تھا کہ ہمارے واقعات کی ریٹروپرائز میں، واپسی کے لئے وقت کا مطلب ہے (MTTR کےلیکن ہم نے پایا کہ MTTR زیادہ سے زیادہ عام طور پر ایک علامتی ہے، نہیں ایک root وجہ.

صنعت بینکنگ عام طور پر ایٹمی ٹیموں کو ایک گھنٹہ کے اندر اندر MTTR حاصل کرتے ہیں. لیکن ہم سمجھتے تھے کہ رفتار صرف خود کار طریقے سے نہیں ہے - یہ ہےhigh-fidelity signalsکم وفاداری سگنل، جیسے عام 500 غلطیوں یا مجموعی میٹرک سے تاخیر سے خبردار، واقعی میں مدد نہیں کرتے.

بدقسمتی سے، تفصیلی، کنٹیکٹو سیگنالز - جیسے userId، requestId، اور ایک سروس ٹریک کے ساتھ ساختہ لاگ ان - براہ راست root cause کے لئے کاٹ سکتے ہیں.Observability پلیٹ فارمز MTTR کو کم کرسکتے ہیں، لیکن صرف اگر آپ کو انسٹال کردہ ڈیٹا کام کر سکتے ہیں.

اگر آپ کے لاگ ان ان سوالات کا جواب نہیں دیتے ہیں تو، آپ کا MTTR ٹیم کی رفتار کے بارے میں نہیں ہے - یہ سگنل کی واضحات کے بارے میں ہے.

کس طرح Sumo Logic کے ماڈل نے دن کو بچایا ہو سکتا ہے

لہذا میرے کلاؤڈ ماڈلنگ پروجیکٹ کے دوران کیا مختلف ہو سکتا تھا - اور بہتر؟

سب سے پہلے، میں واقعی چاہتا ہوں کہ ہم نے بہتر لاگ ان تجزیہ اور ایپلی کیشن کی کارکردگی کی نگرانی (APM) کی تھی. اور اس کے ساتھ ساتھ APM، لاگ ان کے انتظام، سروس کی نگرانی، خبروں، اور مقرر کردہ میٹرک کو عملی کامیابی یا ناکامی کے ساتھ قریبی طور پر مطابقت رکھتا تھا.

اور میں اپنے لوحوں کو واپس کرنا چاہتا ہوں!DevSecOps: یہ آپ کی درخواست کے لئے ادائیگی کرنے کا وقت ہے، نہیں کھانے،میں نے تحقیق کی کہ کس طرحسب سے زیادہ منطق disrupted the observability space by offering a pay-per-analysis model. Logs can be ingested continuously, but you only pay when you need to query or analyze them.

کیا آپ ایک ٹیم ہیں جس میں مکمل یونٹ ٹیسٹ کی پوزیشن نہیں ہے؟ حقیقی وقت کی نشاندہیوں یا چمکدار میٹرک کی کمی سے متاثر ہیں؟ ایک سخت بجٹ پر؟ لاگ ان کی کمی کی وجہ سے ناکام؟

Zero-Cost مکمل کھپت کے ساتھ، ٹیموں کو فکر کے بغیر ان کی ضرورت کے طور پر لاگ ان کرسکتے ہیں. اور جب آخر میں یہ واقعہ ہوتا ہے (اور یہ ہو جائے گا)، تجزیہ کی درخواست پر، براہ راست گاہکوں کے اثرات یا کاروباری مسلسلیت سے منسلک ایک مناسب قیمت پر شروع کیا جا سکتا ہے.

یہ نقطہ نظر کنٹرول کو واپس کرتا ہے اور اضطراب کو کم کرتا ہے کیونکہ ٹیموں کو سب سے زیادہ اہم وقت پر مکمل طور پر تحقیقات کرنے کی صلاحیت ہے.

لیکن انتظار کریں: آپ کو بھی آپ کے سوالات کو صاف کرنے کے لئے مشین کی مدد سے ٹریڈنگ کی ضرورت ہے

Modern observability is not just about having all that beautiful log data—it is also about knowing where to look in that data.high-fidelity signals.

جب آپ کو لامحدود جذب ہے تو، آپ کو ایک ٹن ڈیٹا ہے. اور جب آپ معلومات کی تلاش شروع کرتے ہیں تو، آپ کو شروع کرنے کے لئے ایک جگہ کی ضرورت ہے.machine-assisted triage toolsیہ خود کار طریقے سے غیر معمولی رویے کو گروپ، outliers کو پتہ چلتا ہے، اور آپ کو صرف ایک سوال لکھنے سے پہلے سروسز کے درمیان منسلک سیگنالوں کی سطح.

اس واقعے کے پیچھے، Sumo Logic اسٹیٹیٹک الگورتھمز اور مشین سیکھنے کا استعمال کرتے ہوئے:

• مجموعی طور پر، مجموعی طور پر، مجموعی طور پر، مجموعی طور پر، مجموعی طور پر، مجموعی طور پر، مجموعی طور پر، مجموعی طور پر.
• میٹرک اور لوگوں میں outliers کا پتہ لیں (مثال کے طور پر، سروس، علاقے، یا صارف کی مجموعہ کے مطابق غلطی پیکس).
• میٹا ڈیٹا (مثال کے طور پر، AWS ٹیگ، Kubernetes pod info، تنصیب مارکرز).
• قدرتی زبان کی پروسیسنگ کسٹمرز semantic similarity کی طرف سے لاگ ان کرتے ہیں، نہ صرف string matching.

یہ خاص طور پر لامحدود ذائقہ کے اعلی حجم کے ماحول میں مفید ہے. ہزاروں لوگ لائنوں کے ذریعے سوئچ کرنے کے بجائے، آپ کو "لوگ دستخط" حاصل کرتے ہیں-مجسم نمونے جو متعلقہ واقعات کے گروپوں کی نمائندگی کرتے ہیں.

Workflow کے مثالیں

_sourceCategory=prod/* error
| logreduce

یہ ایک ہی کمانڈ آہستہ آہستہ لاگ ان کے اعداد و شمار کو اس طرح کے طور پر کام کرنے کے قابل بیکٹس میں جمع کرتا ہے:

Error: Worker queue overflow
Error: Auth token expired for user *
Error: Timeout in service *

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

| where message matches "Auth token expired*"
| count by userId, region

اس کا نتیجہ؟ کم آنکھوں کی تلاش، تیزی سے فیصلہ کرنے کے راستے، حادثے کے دوران کم اضطراب.

نتیجہ

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

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

"آپ کے وقت کو خصوصیات / کارکردگی فراہم کرنے پر توجہ مرکوز کریں جو آپ کی ذاتی ملکیت کا قدر بڑھاتا ہے. ہر چیز کے لئے فریم ورکز، مصنوعات اور خدمات کا استعمال کریں." — J. Vester

"آپ کے وقت کو خصوصیات / کارکردگی فراہم کرنے پر توجہ مرکوز کریں جو آپ کی ذاتی ملکیت کا قدر بڑھاتا ہے. ہر چیز کے لئے فریم ورکز، مصنوعات اور خدمات کا استعمال کریں." — J. Vester

اس مضمون میں، ہم دیکھتے ہیں کہ کس طرح ایک سٹور کاسٹ انجیکشن ماڈل اس مشن کے ساتھ مطابقت رکھتا ہے. یہ ٹیموں کو تیزی سے بنیادی وجوہات کی شناخت کرنے میں مدد ملتی ہے، غیر فعال وقت کو کم کریں، اور اس کے مقابلے میں پریشر کی سطح کو کم کرنے میں مدد ملتی ہے.

ایک بہت اچھا دن ہے!