جب سے میں نے 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 زیادہ سے زیادہ عام طور پر ایک علامتی ہے، نہیں ایک root وجہ. MTTR کے صنعت بینکنگ عام طور پر ایٹمی ٹیموں کو ایک گھنٹہ کے اندر اندر MTTR حاصل کرتے ہیں. لیکن ہم سمجھتے تھے کہ رفتار صرف خود کار طریقے سے نہیں ہے - یہ ہے کم وفاداری سگنل، جیسے عام 500 غلطیوں یا مجموعی میٹرک سے تاخیر سے خبردار، واقعی میں مدد نہیں کرتے. high-fidelity signals بدقسمتی سے، تفصیلی، کنٹیکٹو سیگنالز - جیسے userId، requestId، اور ایک سروس ٹریک کے ساتھ ساختہ لاگ ان - براہ راست root cause کے لئے کاٹ سکتے ہیں.Observability پلیٹ فارمز MTTR کو کم کرسکتے ہیں، لیکن صرف اگر آپ کو انسٹال کردہ ڈیٹا کام کر سکتے ہیں. اگر آپ کے لاگ ان ان سوالات کا جواب نہیں دیتے ہیں تو، آپ کا MTTR ٹیم کی رفتار کے بارے میں نہیں ہے - یہ سگنل کی واضحات کے بارے میں ہے. کس طرح Sumo Logic کے ماڈل نے دن کو بچایا ہو سکتا ہے لہذا میرے کلاؤڈ ماڈلنگ پروجیکٹ کے دوران کیا مختلف ہو سکتا تھا - اور بہتر؟ سب سے پہلے، میں واقعی چاہتا ہوں کہ ہم نے بہتر لاگ ان تجزیہ اور ایپلی کیشن کی کارکردگی کی نگرانی (APM) کی تھی. اور اس کے ساتھ ساتھ APM، لاگ ان کے انتظام، سروس کی نگرانی، خبروں، اور مقرر کردہ میٹرک کو عملی کامیابی یا ناکامی کے ساتھ قریبی طور پر مطابقت رکھتا تھا. اور میں اپنے لوحوں کو واپس کرنا چاہتا ہوں! میں نے تحقیق کی کہ کس طرح  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. DevSecOps: یہ آپ کی درخواست کے لئے ادائیگی کرنے کا وقت ہے، نہیں کھانے، سب سے زیادہ منطق کیا آپ ایک ٹیم ہیں جس میں مکمل یونٹ ٹیسٹ کی پوزیشن نہیں ہے؟ حقیقی وقت کی نشاندہیوں یا چمکدار میٹرک کی کمی سے متاثر ہیں؟ ایک سخت بجٹ پر؟ لاگ ان کی کمی کی وجہ سے ناکام؟ 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 جب آپ کو لامحدود جذب ہے تو، آپ کو ایک ٹن ڈیٹا ہے. اور جب آپ معلومات کی تلاش شروع کرتے ہیں تو، آپ کو شروع کرنے کے لئے ایک جگہ کی ضرورت ہے. یہ خود کار طریقے سے غیر معمولی رویے کو گروپ، outliers کو پتہ چلتا ہے، اور آپ کو صرف ایک سوال لکھنے سے پہلے سروسز کے درمیان منسلک سیگنالوں کی سطح. machine-assisted triage tools اس واقعے کے پیچھے، 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 اس مضمون میں، ہم دیکھتے ہیں کہ کس طرح ایک سٹور کاسٹ انجیکشن ماڈل اس مشن کے ساتھ مطابقت رکھتا ہے. یہ ٹیموں کو تیزی سے بنیادی وجوہات کی شناخت کرنے میں مدد ملتی ہے، غیر فعال وقت کو کم کریں، اور اس کے مقابلے میں پریشر کی سطح کو کم کرنے میں مدد ملتی ہے. ایک بہت اچھا دن ہے!

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

یہ آڈیو کہانی کی اصل زبان میں تیار کی گئی ہے!

بہت لمبا؛ پڑھنے کے لئے

Make resilience your competitive advantage

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

About Author

تبصرے

ہینگ ٹیگز

یہ مضمون اس میں پیش کیا گیا تھا۔

Related Stories

AI Search Traffic Marketshare for Calling HackerNoon Blogs: 52% OpenAI, 30% Amazon & 18% Perplexity

On Sunday, the 26th of November, 1631

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Urbain Grandier by Alexandre Dumas - Table of Links

AI Search Traffic Marketshare for Calling HackerNoon Blogs: 52% OpenAI, 30% Amazon & 18% Perplexity

On Sunday, the 26th of November, 1631

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Urbain Grandier by Alexandre Dumas - Table of Links

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps