AI نے سافٹ ویئر بنانے کے ہمارے طریقے کو بدل دیا ہے، لیکن اس نے مشینوں کے بارے میں ایک بنیادی حقیقت کو نہیں بدلا۔ وہ بھی ہماری طرح شور (noise) میں ڈوب جاتے ہیں۔ جب انجینئرز پہلی بار AI کی مدد سے ڈیبگنگ (debugging) کا تجربہ کرتے ہیں، تو ان کی جبلت سادہ ہوتی ہے: ماڈل کو سب کچھ فراہم کر دیں۔ تمام خام لاگز (raw logs)، ٹریسز (traces) اور میٹرکس (metrics) کو کانٹیکسٹ ونڈو (context window) میں ڈال دیا جاتا ہے۔ اس کا نتیجہ بصیرت نہیں بلکہ ناکامی ہوتا ہے۔ حجم بہت زیادہ ہوتا ہے۔ سگنل (signal) ختم ہو جاتا ہے۔ میٹرکس ایک ٹول میں ہوتے ہیں، ٹریسز دوسرے میں، اور ماڈل انہیں ایک مربوط کہانی میں نہیں جوڑ سکتا۔ اس سے پہلے کہ AI آپ کے سسٹمز کی نگرانی (observe) کرنے میں آپ کی مدد کر سکے، آپ کو خود ان کی نگرانی کرنی ہوگی۔ آپ کو پہلے ڈیٹا کو ترتیب دینا (shape) ہوگا۔

خام لاگز (Raw Logs) کیوں AI پائپ لائنز کو خراب کرتے ہیں

جدید سسٹمز ایسی رفتار سے ٹیلی میٹری (telemetry) پیدا کرتے ہیں جسے کوئی انسان نہیں پڑھ سکتا۔ یہ چیز انہیں مصنوعی ذہانت (AI) کے لیے بہترین بنانی چاہیے، لیکن ایسا نہیں ہے۔ ایک لارج لینگویج ماڈل (LLM) کی کانٹیکسٹ ونڈو، اگرچہ بڑھ رہی ہے، لیکن پھر بھی ایک محدود پائپ کی طرح ہے۔ اسے غیر فلٹر شدہ پروڈکشن لاگز سے بھر دیں تو آپ اصل خرابی (outage) کو چھپا دیتے ہیں اور کرون جاب (cron job) کے ہارٹ بیٹس اور ہیلتھ چیک کے شور پر ٹوکنز ضائع کرتے ہیں۔ اس سے بھی بدتر یہ کہ خام لاگز میں تعلقات (relationships) کی کمی ہوتی ہے۔ دوپہر 2:00 بجے لیٹنسی (latency) میں اضافہ اور اسی وقت کے لاگ میں ڈیٹا بیس کنکشن کی غلطی واضح طور پر ایک دوسرے سے متعلق ہیں، لیکن جب تک کوئی پہلے سے اس تعلق کو ترتیب نہ دے، AI کو اندازہ لگانا پڑتا ہے۔ اندازہ لگانا مہنگا، سست اور اکثر غلط ہوتا ہے۔

اس کا حل آرکیٹیکچرل (architectural) ہے، الگورتھمک (algorithmic) نہیں۔ کسی ماڈل کو پرامپٹ (prompt) دینے سے پہلے آپ کو یہ فیصلہ کرنا ہوگا کہ کیا جمع کیا جائے گا، اسے کیسے ترتیب دیا جائے گا، اور کون سا بیک اینڈ کس سوال کا جواب دے گا۔

مانیٹرنگ کے چار محور (Axes)

airCloset میں، انجینئرنگ ٹیم نے observability کو ایک واحد فائر ہوز (firehose) کے طور پر دیکھنا بند کر دیا۔ انہوں نے مانیٹرنگ کو چار الگ محوروں میں تقسیم کیا۔ ہر محور کا ایک مخصوص ڈھانچہ ہے اور وہ ایک مخصوص سوال کا جواب دیتا ہے۔

  • Application: لاگز اور ٹریسز جواب دیتے ہیں "ابھی کیا ہو رہا ہے؟"
  • Infrastructure: میٹرکس جواب دیتے ہیں "کیا ہمارے پاس کافی وسائل ہیں؟"
  • CI: لاگز اور الرٹس جواب دیتے ہیں "کیا ٹوٹا اور کب؟"
  • LLM: میٹرکس اور منظم ریکارڈز جواب دیتے ہیں "ہم کتنا خرچ کر رہے ہیں؟"

یہ علیحدگی اس لیے اہم ہے کیونکہ ریئل ٹائم لیٹنسی گراف کے لیے صحیح ڈھانچہ بعد میں کیے جانے والے لاگت کے تجزیہ (post-hoc cost analysis) کے لیے بیکار ہے۔ چاروں ڈومینز پر ایک ہی اسکیما (schema) نافذ کرنے سے بالکل وہی شور پیدا ہوتا ہے جو AI کی مدد کو بے کار بنا دیتا ہے۔

CI Observability: کھینچیں (Pull)، دھکیلیں (Push) نہیں

کنٹینیو اس انٹیگریشن (CI) وہ جگہ ہے جہاں کوڈ حقیقت سے ملتا ہے۔ جب کوئی بلڈ (build) فیل ہوتا ہے، تو ڈویلپرز کو تیزی سے صورتحال معلوم کرنے کی ضرورت ہوتی ہے۔ سادہ طریقہ یہ ہے کہ CI رنر (runner) چلتے وقت لاگز کو براہ راست آپ کے observability بیک اینڈ پر پش (push) کر دے۔ یہ کارآمد لگتا ہے، لیکن حقیقت میں خطرناک ہے۔

airCloset میں، انہوں نے اس ماڈل کو الٹ دیا۔ CI رنر observability اسٹیک کو نہیں چھیڑتا۔ GitHub Actions ورک فلو ختم ہونے کے بعد، وہ GitHub API سے لاگز کھینچتے (pull) ہیں اور انہیں Loki میں شامل (ingest) کر دیتے ہیں۔

یہ پل (pull) آرکیٹیکچر تین ٹھوس فوائد فراہم کرتا ہے۔

Decoupling (علیحدگی)۔ اگر انجیشن پائپ لائن (ingestion pipeline) میں کوئی مسئلہ آئے یا Grafana تک رسائی نہ ہو، تو ٹیسٹ رن خود متاثر نہیں ہوتا۔ بلڈ اپنی خوبیوں پر پاس یا فیل ہوتا ہے۔ observability کی ناکامی کی وجہ سے کبھی بھی ڈیپلائمنٹ (deployment) کو نہیں روکنا چاہیے۔

Security (سیکیورٹی)۔ CI ورک فلو کو کبھی بھی Grafana API کی (key) کی ضرورت نہیں ہوتی۔ ٹیسٹ کوڈ ان خفیہ معلومات (secrets) تک پہنچنے کے لیے بدنام ہے جن تک اسے نہیں پہنچنا چاہیے، اور اس خطرے کو ختم کرنے سے اگر کوئی ڈیپینڈینسی (dependency) متاثر ہو جائے تو اس کے اثرات کا دائرہ محدود ہو جاتا ہے۔

Cross-querying (کراس کوئرینگ)۔ ایک بار جب CI