AI সফটওয়্যার তৈরির পদ্ধতি বদলে দিয়েছে, কিন্তু এটি মেশিন সম্পর্কে একটি মৌলিক সত্য পরিবর্তন করতে পারেনি। মানুষের মতো তারাও নয়েজ বা অপ্রাসঙ্গিক তথ্যের ভিড়ে হারিয়ে যায়। যখন ইঞ্জিনিয়াররা প্রথমবার AI-assisted debugging নিয়ে পরীক্ষা-নিরীক্ষা করেন, তখন তাদের সহজাত প্রবৃত্তি হয়: মডেলটিকে সবকিছু দিয়ে দিন। Raw logs, traces এবং metrics—সবকিছুই context window-তে ঢেলে দেওয়া হয়। এর ফলাফল কোনো অন্তর্দৃষ্টি (insight) নয়, বরং ব্যর্থতা। তথ্যের পরিমাণ অনেক বেশি হয়ে যায়। সিগন্যাল হারিয়ে যায়। Metrics থাকে এক টুলে, traces থাকে অন্য টুলে, আর মডেলটি সেগুলোকে একটি সুসংগত গল্পের মতো সাজাতে পারে না। AI আপনার সিস্টেম পর্যবেক্ষণ করতে সাহায্য করার আগে, আপনাকে নিজে সেগুলো পর্যবেক্ষণ করতে হবে। আপনাকে প্রথমে ডেটাকে একটি নির্দিষ্ট কাঠামো দিতে হবে।

কেন Raw Logs AI পাইপলাইনকে অকেজো করে দেয়

আধুনিক সিস্টেমগুলো এমন গতিতে telemetry তৈরি করে যা কোনো মানুষের পক্ষে পড়া সম্ভব নয়। এটি তাদের কৃত্রিম বুদ্ধিমত্তার জন্য উপযুক্ত করে তোলার কথা ছিল। কিন্তু বাস্তবে তা হয় না। একটি Large Language Model-এর context window বড় হলেও তা একটি সীমিত পাইপের মতো। এতে যদি ফিল্টার না করা production logs ঢেলে দেওয়া হয়, তবে আপনি আসল আউটটেজ (outage) বা সিস্টেম বিভ্রাটের তথ্য চাপা দিয়ে cron job heartbeat এবং health-check-এর নয়েজের পেছনে টোকেন নষ্ট করবেন। আরও খারাপ বিষয় হলো, raw logs-এ কোনো পারস্পরিক সম্পর্ক থাকে না। দুপুর ২টায় ল্যাটেন্সির (latency) একটি স্পাইক এবং একই সময়ে একটি লগে ডাটাবেস কানেকশন এরর—এগুলো স্পষ্টতই সম্পর্কিত, কিন্তু কেউ যদি আগে থেকে সেই সম্পর্কটি কাঠামোবদ্ধ (structured) না করে দেয়, তবে AI-কে অনুমান করতে হয়। অনুমান করা ব্যয়বহুল, ধীরগতির এবং প্রায়শই ভুল হয়।

এর সমাধান অ্যালগরিদমিক নয়, বরং আর্কিটেকচারাল। কোনো মডেলকে প্রম্পট করার আগেই আপনাকে সিদ্ধান্ত নিতে হবে কী সংগ্রহ করা হবে, কীভাবে তা সাজানো হবে এবং কোন ব্যাকএন্ড কোন প্রশ্নের উত্তর দেবে।

মনিটরিংয়ের চারটি অক্ষ (Axes)

airCloset-এ ইঞ্জিনিয়ারিং টিম observability-কে একটি একক 'firehose' হিসেবে দেখা বন্ধ করেছে। তারা মনিটরিংকে চারটি আলাদা অক্ষে বিভক্ত করেছে। প্রতিটি অক্ষের একটি নির্দিষ্ট কাঠামো রয়েছে এবং প্রতিটি নির্দিষ্ট প্রশ্নের উত্তর দেয়।

  • Application: Logs এবং traces উত্তর দেয় "এখন ঠিক কী ঘটছে?"
  • Infrastructure: Metrics উত্তর দেয় "আমাদের কি পর্যাপ্ত রিসোর্স আছে?"
  • CI: Logs এবং alerts উত্তর দেয় "কী ভেঙেছে এবং কখন?"
  • LLM: Metrics এবং structured records উত্তর দেয় "আমরা কত খরচ করছি?"

এই বিভাজনটি গুরুত্বপূর্ণ কারণ রিয়েল-টাইম ল্যাটেন্সি গ্রাফের জন্য সঠিক কাঠামোটি post-hoc কস্ট অ্যানালাইসিসের জন্য অকেজো। চারটি ডোমেইনের ওপর একটিমাত্র স্কিমা (schema) চাপিয়ে দিলে ঠিক সেই ধরনের নয়েজ তৈরি হয় যা AI-এর সহায়তাকে অকেজো করে তোলে।

CI Observability: পুশ (Push) নয়, পুল (Pull) করুন

Continuous integration হলো সেই জায়গা যেখানে কোড বাস্তবের মুখোমুখি হয়। যখন একটি বিল্ড ফেইল করে, ডেভেলপারদের দ্রুত সেই ঘটনার কারণ জানা প্রয়োজন। একটি সাধারণ বা আনাড়ি পদ্ধতি হলো CI runner চলাকালীন সরাসরি আপনার observability backend-এ লগ পুশ করা। এটি কার্যকর মনে হলেও আসলে এটি বিপজ্জনক।

airCloset-এ তারা এই মডেলটি উল্টে দিয়েছে। CI runner observability stack-এ কোনো স্পর্শ করে না। GitHub Actions workflow শেষ হওয়ার পর, তারা GitHub API থেকে লগ পুল করে এবং সেগুলো Loki-তে ইনজেস্ট (ingest) করে।

এই পুল আর্কিটেকচার তিনটি সুনির্দিষ্ট সুবিধা প্রদান করে।

Decoupling. যদি ইনজেশন পাইপলাইনে কোনো সমস্যা হয় বা Grafana-তে পৌঁছানো না যায়, তবে টেস্ট রান নিজে unaffected বা অপরিবর্তিত থাকে। বিল্ড তার নিজস্ব যোগ্যতায় পাস বা ফেইল হয়। একটি observability ব্যর্থতার কারণে কখনোই ডেপ্লয়মেন্ট বন্ধ হওয়া উচিত নয়।

Security. CI workflow-এর কখনোই Grafana API key-এর প্রয়োজন হয় না। টেস্ট কোড প্রায়শই এমন সব সিক্রেট (secrets) স্পর্শ করার জন্য পরিচিত যা তার করা উচিত নয়; এই এক্সপোজার কমিয়ে দিলে কোনো ডিপেন্ডেন্সি কম্প্রোমাইজ হলেও ক্ষতির পরিধি (blast radius) কমে যায়।

Cross-querying. একবার CI