একটি মাল্টি-রিজিয়ন হেলথ-চেক অ্যাগ্রিগেটর তৈরি করা
সাও পাওলোর (São Paulo) একজন ব্যবহারকারী একটি অচল এজ নোডের (edge node) সম্মুখীন হলেন। তিনি কোনো বাগ রিপোর্ট (bug report) করলেন না। তিনি ট্যাবটি বন্ধ করে দিলেন এবং অন্য কিছু দেখতে থাকলেন।
একটি সাধারণ আপটাইম মনিটর (uptime monitor) এটি ধরতে পারে না। বেশিরভাগ মনিটর একটি মাত্র স্থান থেকে প্রোব (probe) করে। সেই একটি জায়গা থেকে সবকিছুই ঠিকঠাক (green) দেখায়।
আমাদের স্ট্যাটাস পেজে ১০০% আপটাইম দেখাচ্ছিল, অথচ প্রকৃত ব্যবহারকারীরা টাইমআউট (timeout) পাচ্ছিলেন। একটি গ্লোবাল হেলথ চেক আমাদের ভুল তথ্য দিচ্ছিল।
কীভাবে আমরা এমন একটি সিস্টেম তৈরি করেছি যা সঠিক তথ্য দেয়, তা নিচে দেওয়া হলো।
সমস্যা: স্যাম্পলিং বায়াস (Sampling Bias) আপনার মনিটর যদি একটি মাত্র ডেটা সেন্টারে থাকে, তবে এটি কেবল একটি বাস্তবতাই দেখতে পায়। সিঙ্গাপুর এবং সাও পাওলোর এজগুলো সংযোগ বিচ্ছিন্ন করলেও আপনার মনিটর হয়তো সবকিছু ঠিকঠাক (green) রিপোর্ট করতে পারে।
ভিডিও ট্রাফিক এই সমস্যাটিকে আরও বাড়িয়ে তোলে। সাধারণ আঞ্চলিক ত্রুটিগুলোর মধ্যে রয়েছে:
- একটি মহাদেশকে প্রভাবিত করে এমন ত্রুটিপূর্ণ BGP রুট।
- ক্যাশ ইভিকশন (Cache evictions) যা স্লো অরিজিন ফলব্যাক (slow origin fallback) করতে বাধ্য করে।
- ডিস্ক ত্রুটি যা TLS হ্যান্ডশেক টাইমআউট ঘটায়।
- নির্দিষ্ট লোকাল রিজলভারের (local resolvers) ক্ষেত্রে DNS সমস্যা।
একটি মাত্র "200 OK" রেসপন্স আপনাকে প্রায় কিছুই জানাতে পারে না।
হেলথ বা স্বাস্থ্যের জন্য আমাদের তিনটি নিয়ম: আমরা শুধু স্ট্যাটাস কোডের ওপর নির্ভর করা ছেড়ে দিয়েছি। আমরা তিনটি মেট্রিক ব্যবহার করে হেলথ বা স্বাস্থ্য নির্ধারণ করি:
- রিচেবিলিটি (Reachability): TCP এবং TLS হ্যান্ডশেক অবশ্যই ৮০০ মিলি-সেকেন্ডের (800ms) মধ্যে শেষ হতে হবে।
- ল্যাটেন্সি (Latency): আমরা p95 Time-to-First-Byte (TTFB) ট্র্যাক করি। গড় (average) মান সেই স্লো টেইল (slow tail) লুকিয়ে ফেলে যা ব্যবহারকারীদের বিরক্ত করে।
- কারেক্টনেস (Correctness): রেসপন্স বডিতে অবশ্যই একটি প্রত্যাশিত মার্কার থাকতে হবে। একটি 200 OK রেসপন্স যদি এরর পেজ (error page) রিটার্ন করে, তবে সেটি একটি ব্যর্থতা।
সমাধান: মাল্টি-রিজিয়ন প্রোবিং (Multi-Region Probing) আমরা একটি বড় মনিটর ব্যবহার করা বন্ধ করে দিয়েছি। পরিবর্তে, আমরা সস্তা আঞ্চলিক VPS ইনস্ট্যান্সগুলোতে ছোট ছোট Go বাইনারি (Go binaries) ডেপ্লয় করি।
প্রতিটি প্রোবার (prober):
- স্থানীয় ভ্যান্টেজ পয়েন্ট (local vantage point) থেকে এজগুলো পরীক্ষা করে।
- প্রকৃত TTFB ডেটা পেতে
httptraceব্যবহার করে। - ফলাফলগুলো একটি সেন্ট্রাল অ্যাগ্রিগেটর (central aggregator)-এ পোস্ট করে।
আমরা স্টোরেজের জন্য SQLite ব্যবহার করি। এটি সহজ এবং কোনো অতিরিক্ত ওভারহেড ছাড়াই আমাদের কাজের চাপ সামলাতে পারে। আমরা প্রি-অ্যাগ্রিগেটেড ডেটার পরিবর্তে র (raw) স্যাম্পল সংরক্ষণ করি। এটি আমাদের পরবর্তীতে হিস্ট্রি পুনরায় স্কোর করতে বা নির্দিষ্ট ত্রুটি ডিবাগ করতে সাহায্য করে।
গোপন রহস্য: কোরাম (Quorum) নেটওয়ার্ক সবসময়ই নয়েজি (noisy) হয়। একটি প্যাকেট ড্রপ হওয়া মানেই আউটটেজ (outage) নয়।
আমরা ফলস অ্যালার্ম (false alarms) রোধ করতে একটি কোরাম সিস্টেম ব্যবহার করি। যখন একাধিক অঞ্চল একমত হয়, কেবল তখনই আমরা একটি এজকে "ডাউন" (down) হিসেবে ঘোষণা করি। যদি একটি অঞ্চল ত্রুটি দেখে কিন্তু অন্যগুলো না দেখে, তবে আমরা টিমকে পেজ (page) করি না। এই ডিজাইনের কারণে আমাদের ৯% ফলস অ্যালার্ট কমে গেছে।
মূল শিক্ষা:
- ব্যবহারকারীরা যা ব্যবহার করেন তা প্রোব করুন, কোনো সিন্থেটিক পাথ (synthetic path) নয়।
- গড় নয়, বরং টেইল ল্যাটেন্সি (tail latency - p95) ট্র্যাক করুন।
- অনেক অঞ্চলে ডিসপোজেবল (disposable) এবং সস্তা প্রোবার ব্যবহার করুন।
- পেজার ফ্যাটিগ (pager fatigue) এড়াতে কোরাম ব্যবহার করুন।
- আপনার স্টোরেজ স্ট্যাক সহজ রাখুন।
আপনার কোনো ভারী অবজারভেবিলিটি প্ল্যাটফর্মের প্রয়োজন নেই। আপনার প্রয়োজন লোকাল প্রোবস, র ডেটা এবং এমন একটি নিয়ম যা নয়েজ দেখে আতঙ্কিত হয় না।