যে সিস্টেমকে আপনি দেখতে পান না, সেটাকে আপনি চালাতেও পারেন না। Monitoring হলো চলমান সিস্টেম থেকে সংকেত সংগ্রহ, সংরক্ষণ ও বিশ্লেষণ করার ব্যবস্থা — যাতে সমস্যা user-এর আগে আপনি জানতে পারেন, এবং সমস্যা হলে কারণটা দ্রুত খুঁজে পান।
Monitoring-এর তিনটা স্তম্ভ (three pillars of observability):
- Metrics — সংখ্যায় প্রকাশিত সময়ভিত্তিক ডেটা (request rate, error rate, latency, CPU)। সস্তা, দীর্ঘদিন রাখা যায়, alert-এর জন্য আদর্শ। বলে "কিছু একটা ভুল"।
- Logs — নির্দিষ্ট ঘটনার বিস্তারিত রেকর্ড। ব্যয়বহুল কিন্তু সমৃদ্ধ। বলে "ঠিক কী ঘটেছিল"।
- Traces — একটা request-এর পুরো যাত্রাপথ, প্রতিটা service-এ কত সময় লেগেছে তার হিসাবসহ। Microservice-এ অপরিহার্য। বলে "কোথায় সময়টা গেল"।
একটা কার্যকর কাঠামো হলো Four Golden Signals: Latency, Traffic, Errors, Saturation. প্রতিটা service-এর জন্য এই চারটা থাকলে বেশিরভাগ সমস্যা ধরা পড়ে।
Health Monitoring
সিস্টেমের প্রতিটা component চালু ও কার্যক্ষম আছে কি না — সবচেয়ে মৌলিক স্তর। বাস্তবায়ন হয় health endpoint দিয়ে (/health), যা load balancer ও orchestrator নিয়মিত ডাকে।
আগে বলা পার্থক্যটা এখানেও কেন্দ্রীয় — liveness (process বেঁচে আছে? না থাকলে restart) বনাম readiness (এখন ট্রাফিক নিতে পারবে? না পারলে শুধু ট্রাফিক সরাও)।
একটা ভালো health check শুধু 200 OK ফেরত দেয় না, বরং গুরুত্বপূর্ণ নির্ভরতাগুলোও পরখ করে (database সংযোগ, cache, জরুরি downstream)। তবে সাবধান — health check-এ সব নির্ভরতা যাচাই করলে একটা তুচ্ছ downstream ব্যর্থতা আপনার পুরো fleet-কে "অসুস্থ" ঘোষণা করে সিস্টেম বন্ধ করে দিতে পারে। তাই জরুরি ও ঐচ্ছিক নির্ভরতা আলাদা করুন।
Availability Monitoring
সেবাটা প্রকৃতপক্ষে কতটা সময় ব্যবহারযোগ্য ছিল — অর্থাৎ uptime। এখানে দুটো দৃষ্টিকোণ থাকা দরকার:
- Synthetic monitoring (black-box) — বাইরে থেকে বিভিন্ন অঞ্চল থেকে নিয়মিত কৃত্রিম request পাঠিয়ে দেখা সেবাটা সাড়া দিচ্ছে কি না। এটা user-এর অভিজ্ঞতার সবচেয়ে কাছাকাছি, এবং ট্রাফিক কম থাকলেও কাজ করে।
- Real User Monitoring (RUM) — প্রকৃত user-দের browser/app থেকে ডেটা সংগ্রহ। প্রকৃত অভিজ্ঞতা দেখায়, কিন্তু user না থাকলে ডেটাও নেই।
এখানেই SLI / SLO / SLA ধারণাগুলো আসে: SLI হলো আপনি যা মাপছেন (সফল request-এর শতাংশ), SLO হলো আপনার অভ্যন্তরীণ লক্ষ্য (৯৯.৯%), আর SLA হলো গ্রাহকের সাথে চুক্তিবদ্ধ প্রতিশ্রুতি (সাধারণত SLO-র চেয়ে শিথিল)। SLO থেকে পাওয়া error budget একটা শক্তিশালী ধারণা — ৯৯.৯% লক্ষ্য মানে মাসে ৪৩ মিনিট ব্যর্থতার অনুমতি আছে; সেই বাজেট থাকলে দ্রুত release করুন, ফুরিয়ে গেলে স্থিতিশীলতায় মন দিন।
Performance Monitoring
সিস্টেম কত দ্রুত কাজ করছে এবং প্রবণতা কোন দিকে যাচ্ছে। মূল metric গুলো — request latency (p50/p95/p99), throughput, database query time, cache hit rate, queue depth ও queue-তে অপেক্ষার সময়, এবং resource ব্যবহার (CPU, memory, disk I/O, network)।
দুটো নীতি মনে রাখুন। প্রথমত, গড় নয়, percentile দেখুন (Latency vs Throughput)। দ্বিতীয়ত, প্রবণতা ঘটনার চেয়ে গুরুত্বপূর্ণ — আজ p99 ৩০০ms হওয়াটা তত জরুরি নয়, যতটা জরুরি হলো গত সপ্তাহে সেটা ১০০ms ছিল। এই ধীর অবনতিই আগাম সতর্কতা দেয়, এবং capacity planning-এর ভিত্তি তৈরি করে।
Distributed tracing এখানে অপরিহার্য — একটা ধীর request-এর trace দেখলে সাথে সাথে বোঝা যায় সময়টা কোন service বা কোন query-তে গেছে।
Security Monitoring
নিরাপত্তা-সংক্রান্ত ঘটনা শনাক্ত ও নথিভুক্ত করা: ব্যর্থ login-এর অস্বাভাবিক হার (brute force), অস্বাভাবিক ভৌগোলিক অবস্থান থেকে প্রবেশ, অনুমতিহীন resource-এ প্রবেশের চেষ্টা, privilege বৃদ্ধি, ডেটা রপ্তানির অস্বাভাবিক পরিমাণ, ও ট্রাফিকের হঠাৎ অস্বাভাবিক ধরন।
এর কেন্দ্রে থাকে audit log — কে, কখন, কী করল, কোথা থেকে। এটা শুধু নিরাপত্তা নয়, compliance-এর (GDPR, PCI-DSS, SOC 2) জন্যও বাধ্যতামূলক। Audit log অপরিবর্তনীয় (immutable) ও আলাদা জায়গায় রাখা উচিত, যাতে সিস্টেমে প্রবেশ করা আক্রমণকারী নিজের চিহ্ন মুছতে না পারে।
গুরুত্বপূর্ণ সতর্কতা: log-এ কখনো password, token, API key, পূর্ণ card নম্বর বা ব্যক্তিগত সংবেদনশীল ডেটা লিখবেন না। Log সংগ্রহের পথেই এগুলো ছেঁকে ফেলার ব্যবস্থা রাখুন।
Usage Monitoring
কে সিস্টেম ব্যবহার করছে, কীভাবে, এবং কতটা — এটা প্রযুক্তিগত ও ব্যবসায়িক দুই দিকেই কাজে লাগে। কোন feature আসলে ব্যবহৃত হচ্ছে, কোন API endpoint কতটা ডাকা হচ্ছে, কোন গ্রাহক কতটা resource খাচ্ছে, user কোথায় ঝরে পড়ছে।
ব্যবহারিক প্রয়োগ: বিলিং ও metering, capacity planning, rate limit নির্ধারণ, ও পণ্যের সিদ্ধান্ত (কোনো feature কেউ ব্যবহার না করলে সেটা রক্ষণাবেক্ষণ করার মানে নেই)। প্রতি-গ্রাহক ব্যবহারের হিসাব Noisy Neighbor সমস্যা শনাক্তেও সাহায্য করে।
Instrumentation
উপরের সব কিছুর ভিত্তি — application-এর ভেতর থেকে ডেটা নির্গত করার প্রকৃত কাজটা। কোডে metric counter, timer, structured log ও trace span যোগ করা।
কিছু ব্যবহারিক নির্দেশনা:
- Structured logging ব্যবহার করুন (JSON), প্লেইন টেক্সট নয় — তাহলেই খোঁজা ও বিশ্লেষণ সম্ভব।
- Correlation ID / trace ID প্রতিটা request-এর সাথে সব service ও সব log line-এ বয়ে নিয়ে যান। এটা ছাড়া distributed debugging প্রায় অসম্ভব।
- Cardinality-র প্রতি সতর্ক থাকুন — metric-এর label-এ user ID বা request ID দিলে metric store বিস্ফোরিত হবে। উচ্চ-cardinality ডেটা log ও trace-এ যাবে, metric-এ নয়।
- Sampling ব্যবহার করুন — বড় স্কেলে ১০০% trace সংরক্ষণ অসম্ভব ব্যয়বহুল; তবে error ও ধীর request গুলো সবসময় রাখুন।
- OpenTelemetry-র মতো মান ব্যবহার করুন, যাতে vendor বদলানো সহজ থাকে।
Visualization & Alerts
সংগৃহীত ডেটা কাজে লাগে তখনই যখন তা মানুষের কাছে সঠিক সময়ে পৌঁছায়।
Dashboard তিন স্তরে সাজান: একটা উঁচু-স্তরের ব্যবসায়িক দৃশ্য (order rate, revenue), একটা service-স্তরের golden signals দৃশ্য, এবং প্রয়োজনে গভীরে যাওয়ার বিস্তারিত দৃশ্য। প্রতিটা dashboard-এর একটা নির্দিষ্ট প্রশ্নের উত্তর দেওয়ার কথা — ৫০টা graph-এর একটা দেয়াল কোনো প্রশ্নেরই উত্তর দেয় না।
Alert-এর ক্ষেত্রে একটাই সোনালি নিয়ম: মানুষকে জাগানোর মতো alert কেবল সেটাই হওয়া উচিত, যেটার জন্য মানুষের তাৎক্ষণিক পদক্ষেপ দরকার। তাই —
- উপসর্গে alert করুন, কারণে নয় — "user-রা checkout করতে পারছে না" (ভালো) বনাম "CPU ৮০%" (খারাপ, কারণ CPU বেশি হলেও user ঠিক থাকতে পারে)।
- Alert fatigue-ই সবচেয়ে বড় শত্রু — অতিরিক্ত ও অকেজো alert মানুষকে সব alert উপেক্ষা করতে শেখায়, ফলে আসল সমস্যাটাও মিস হয়।
- প্রতিটা alert-এর সাথে একটা runbook থাকুক — কী হয়েছে, কী দেখতে হবে, কী করতে হবে।
- জরুরি নয় এমন সংকেতকে page না করে ticket বা dashboard-এ পাঠান।
পূর্ববর্তী: Performance Antipatterns · পরবর্তী: Cloud Design Patterns — Design & Implementation