Monitoring Alert: health check, owner ও runbook

এই পাঠে যা শিখবেন

• Actionable alert এবং dashboard signal আলাদা করা
• Health probe-এর উদ্দেশ্য ঠিক করা
• Noise কমিয়ে owner ও runbook যুক্ত করা

সমস্যা দিয়ে শুরু

রাতে CPU ৮০ শতাংশ হলেই page আসে, কিন্তু on-call কী করবেন জানেন না। অন্যদিকে checkout failure হচ্ছে, CPU কম বলে কোনো alert নেই। Alert-এর লক্ষ্য মানুষকে নির্দিষ্ট action করানো, dashboard-এর প্রতিটি line report করা নয়। User impact, urgency এবং response ownership একসঙ্গে সংজ্ঞায়িত না করলে alert fatigue গুরুত্বপূর্ণ incident-ও আড়াল করে দেয়।

সহজ করে বুঝি

Page urgent human action চায়; ticket কম জরুরি planned work; dashboard exploration-এর জন্য। Symptom-based alert user-visible error বা latency দেখে, cause signal diagnosis-এ সাহায্য করে। Readiness traffic নিতে পারে কি না, liveness process stuck কি না এবং synthetic check বাইরে থেকে user journey চলে কি না দেখে। একটি probe তিন উদ্দেশ্যই নির্ভুলভাবে পূরণ করবে ধরে নেবেন না।

পরিচিত একটি উপমা

Fire alarm ধোঁয়ার প্রতিটি কণা report করার যন্ত্র নয়। এমন সংকেত চাই যাতে মানুষ নির্দিষ্ট evacuation বা inspection action নেন। রান্নাঘরের harmless steam-এ বারবার alarm বাজলে সত্যিকারের আগুনেও মানুষ গুরুত্ব না দিতে পারেন।

নকশাটি দেখুন

flowchart LR
 U[User outcome metrics] --> R[Windowed alert rules]
 H[Health and synthetic checks] --> R
 R --> G[Group and deduplicate]
 G --> O[Responsible on call]
 O --> B[Runbook and mitigation]
 B --> V[Verify recovery]

Outcome metrics ও external checks rule-এ যায়। Short transient event filter করার window এবং sustained impact threshold থাকে। Related symptoms grouped হলে এক incident-এ বহু page কমে। On-call runbook থেকে safe action নেন, তারপর user-visible recovery verify করেন। Monitoring pipeline itself silent হলে আলাদা watchdog বা dead-man signal কাজে লাগতে পারে।

PHP ও Laravel-এ প্রয়োগ

routes/web.php-তে readiness-style database check fragment। Database critical dependency ধরে নেওয়া হয়েছে। Dedicated short database connection timeout config প্রয়োজন; catch block credentials প্রকাশ করে না। এ route লিভনেসে ব্যবহার করলে shared DB outage-এ সব Pod restart হতে পারে, তাই probe purpose আলাদা রাখুন।

use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Route;
Route::get('/health/ready', function () {
    try {
        DB::select('select 1');
        return response()->json(['ready' => true]);
    } catch (\Throwable) {
        return response()->json(['ready' => false], 503);
    }
});

সুবিধা, সীমাবদ্ধতা ও trade-off

Sensitive alert দ্রুত detection দেয়, কিন্তু false positive operator fatigue বাড়ায়। Long window noise কমায়, urgent failure ধরতে দেরি করতে পারে। Multi-window burn alert সেই trade-off সামলাতে পারে। Dependency outage-এ সব application page duplicate করলে coordination খারাপ হয়। Alert suppression এবং grouping এমনভাবে করুন যাতে independent second incident চুপসে না যায়।

সাধারণ ভুল

• Owner এবং action ছাড়া threshold page বানানো।
• DB unavailable দেখে সব web process restart করা।
• Missing monitoring data-কে healthy ধরে alert বন্ধ করা।

আরও একটু গভীরে

Runbook-এ dashboard, recent deployment, safe rollback এবং escalation contact রাখুন। Alert payload-এ service, impact, time window এবং relevant links দিন, sensitive query parameters নয়। Planned maintenance silence expiryসহ দিন। নিয়মিত alert review-এ false positives, missed incident ও response delay দেখুন। Test notification path যাতে rota বা contact ভুলে page হারিয়ে না যায়।

মনে রাখুন

ভালো alert নির্দিষ্ট user risk-এ দায়িত্বপ্রাপ্ত মানুষকে actionable context দেয়; probe ও page-এর উদ্দেশ্য আলাদা।

নিজে চেষ্টা করুন

Checkout error budget দ্রুত পোড়ার একটি page rule design করুন। Owner, threshold window, runbook এবং recovery signal লিখুন। CPU high কিন্তু user impact নেই—এটি page, ticket না dashboard হবে যুক্তি দিন।

নিজের বোঝা যাচাই করুন

1. CPU high মানেই page?

সবসময় নয়। Urgent action ও user risk আছে কি না দেখুন; saturation diagnosis-এর useful signal হতে পারে।

2. Readiness ও liveness এক?

না। Readiness traffic eligibility, liveness restart-worthy stuck state বোঝায়। Dependency outage-এ ভুল probe cascade ঘটাতে পারে।

3. Grouping কেন?

এক underlying incident-এর বহু symptom থেকে duplicate interruptions কমায়। Independent incident লুকাচ্ছে কি না দেখতে হবে।

4. Runbook কী রাখবে?

Impact বুঝতে links, safe mitigation, verification ও escalation। শুধু restart everything বলা যথেষ্ট নয়।

5. Alert নিজে test করব?

হ্যাঁ। Rule, notification routing, rota ও recovery message কাজ করছে কি না periodic drill দরকার।

আরও পড়ুন

• Prometheus alerting practices
• Kubernetes probes