Observability — log, metric, trace, SLI-SLO আর error budget

১ · Monitoring বনাম observability — জানা প্রশ্ন আর অজানা প্রশ্ন

ঈদের আগের রাত। একটি কাল্পনিক mobile banking সেবায় অভিযোগ — “টাকা পাঠাতে অনেক সময় লাগছে।” Dashboard-এ সব সবুজ: CPU ৪০%, error rate স্বাভাবিক, health check ঠিক। তবু কিছু মানুষ কষ্ট পাচ্ছেন। কোথায়?

Monitoring হলো আগে থেকে ঠিক করা কিছু সংখ্যার ওপর নজর রাখা আর সীমা পেরোলে সতর্ক করা — “জানা অজানা” (known unknowns): আমরা জানি কী জিজ্ঞেস করতে হবে, শুধু এই মুহূর্তের উত্তরটি জানি না। Observability হলো বাইরের সংকেত দেখে ভেতরের অবস্থা বোঝার ক্ষমতা, এমন প্রশ্নেও যা আগে কেউ ভাবেনি — “অজানা অজানা” (unknown unknowns): হয়তো সমস্যা শুধু app-এর নতুন সংস্করণে, শুধু একটি অংশীদার ব্যাংকে, যা মোট গড়ে ডুবে যায়।

শব্দটি এসেছে control theory থেকে — ১৯৬০ সালের দিকে Rudolf Kálmán একটি ব্যবস্থাকে “observable” বলেন, যদি output দেখে ভেতরের অবস্থা পুরো বের করা যায়। দুটি প্রতিযোগী নয়: observability-র তথ্যের ওপরেই monitoring আর alert দাঁড়ায়।

পাঁচ রকম সংকেত

এই সংকেতগুলো কীভাবে সার্ভিস থেকে বেরিয়ে মানুষের চোখ পর্যন্ত পৌঁছায়, নিচের ছবিতে দেখুন। প্রতিটি সেবার ভেতরে একটি instrumentation লাইব্রেরি সংকেত তৈরি করে; একটি collector সেগুলো জমা করে, ছাঁকে, ভাগ করে আলাদা storage-এ পাঠায়; সেখান থেকে dashboard আর alert.

শুরুর রাতের সমস্যাটি gray failure-এর পরিচিত রূপ: health check-এর চোখে সুস্থ, ব্যবহারকারীর চোখে অসুস্থ (পর্ব ৪৪)। প্রতিকার হলো আসল অনুরোধের error আর latency মাপা, আর version, region, অংশীদারের মতো মাত্রা ধরে ভাগ করে দেখতে পারা।

২ · Log — কাঠামোবদ্ধ বিবরণ, level, sampling, খরচ আর গোপনীয়তা

মুদি দোকানের খাতার কথা ভাবুন। একজন দোকানি লেখেন “রহিম ভাই চাল নিলেন, পরে দেবেন।” আরেকজন কলাম টেনে লেখেন: তারিখ │ নাম │ জিনিস │ পরিমাণ │ দাম │ বাকি. মাস শেষে “কার কাছে কত বাকি” বের করতে প্রথম খাতায় পুরো রাত লাগে, দ্বিতীয়টিতে কয়েক মিনিট। Log-এও তাই। মুক্ত বাক্যের log মানুষ পড়তে পারে, কিন্তু যন্ত্র খুঁজতে পারে না; structured log-এ প্রতিটি ঘটনা নির্দিষ্ট নামের ঘরসহ একটি record, সাধারণত JSON.

2026-10-28 21:14:03 ERROR Payment failed for user 01712345678 after 3 retries, bank timeout

{
  "ts": "2026-10-28T15:14:03.481Z",
  "level": "ERROR",
  "service": "payment",
  "version": "2.14.1",
  "region": "dc-a",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "event": "bank_call_failed",
  "partner": "bank-07",
  "attempt": 3,
  "duration_ms": 2004,
  "error": "upstream_timeout",
  "user_ref": "u_8f3a91",
  "msisdn_masked": "017******78"
}

দ্বিতীয় রূপে “গত ১৫ মিনিটে partner = bank-07 আর error = upstream_timeout কতবার, কোন version-এ” — এক লাইনের query. খেয়াল করুন: সময় UTC-তে (পর্ব ৩৯), ঘটনার একটি স্থির নাম (event), সংখ্যা সংখ্যা হিসেবে, আর ফোন নম্বর ঢাকা। সবচেয়ে জরুরি ঘর trace_id: এ দিয়েই এই লাইনটি trace আর অন্য সেবার log-এর সাথে জোড়া যায়। আগের পর্বগুলোর request id (পর্ব ১১) আর correlation id (পর্ব ৩২) একই কাজ করে; আধুনিক ব্যবস্থায় সাধারণত trace id-ই সেই ভূমিকা নেয়।

Level — কোন ঘটনা কতটা জরুরি

Level পাঁচটি প্রচলিত: DEBUG (উন্নয়নের খুঁটিনাটি, production-এ সাধারণত বন্ধ), INFO (স্বাভাবিক অর্থবহ ঘটনা), WARN (অস্বাভাবিক কিন্তু সামলানো গেছে, যেমন retry-তে সফল), ERROR (কাজটি ব্যর্থ) আর FATAL (প্রক্রিয়া আর চলতে পারছে না)। সাধারণ ভুল দুটি: সব কিছু ERROR-এ লেখা, আর ব্যবহারকারীর ভুল ইনপুটকে (যেমন ভুল PIN) ERROR বলা।

খরচ — log সবচেয়ে বেশি টাকা খায়

একটি হিসাব করি। ধরা যাক একটি সেবা ১,০০০ req/s পায়, প্রতিটি অনুরোধে গড়ে ৫টি log লাইন, প্রতিটি ৫০০ byte. তাহলে প্রতি সেকেন্ডে ১,০০০ × ৫ × ৫০০ = ২৫ লাখ byte = ২.৫ MB; দিনে ২.৫ × ৮৬,৪০০ = ২,১৬,০০০ MB, অর্থাৎ প্রায় ২১৬ GB; ৩০ দিন রাখলে প্রায় ৬.৪৮ TB — এক সেবার জন্য, compression ছাড়া, আর search-এর index (পর্ব ২৭) ধরলে আরও বেশি।

খরচ কমানোর উপায়গুলো:

• Sampling: সব ERROR আর WARN রাখুন, সফল অনুরোধের INFO-র মাত্র ১০%. ধরা যাক লাইনের ২% ERROR/WARN: তখন প্রতি সেকেন্ডে ৫,০০০ লাইনের মধ্যে থাকে ১০০ + ৪,৯০০ × ০.১ = ৫৯০টি, অর্থাৎ দিনে প্রায় ২৫.৫ GB — আগের প্রায় আট ভাগের এক ভাগ। Trace-এর sampling সিদ্ধান্তের সাথে মিলিয়ে নিলে (অংশ ৫) একটি নমুনা অনুরোধের সব লাইন একসাথে থাকে।
• প্রতি অনুরোধে একটি সমৃদ্ধ লাইন: পাঁচটি টুকরো লাইনের বদলে অনুরোধ শেষে সব গুরুত্বপূর্ণ ঘরসহ একটি “wide event”.
• স্তরভিত্তিক retention: শেষ ৭ দিন দ্রুত খোঁজার storage-এ, তারপর সস্তা object storage-এ, তারপর মুছে ফেলা; সময়সীমা ঠিক করে আইন আর ব্যবসার প্রয়োজন।
• Log-এর হার সীমা: বাগের লুপে লাখো ERROR যেন pipeline না ডোবায়, তাই সেবার ভেতরে log-এর rate limit রাখুন (পর্ব ৪৯)।

Log সাধারণত সরাসরি index-এ যায় না: agent লাইনগুলো batch করে একটি টেকসই log-এ (Kafka-ধরনের, পর্ব ৩৩) পাঠায়, সেখান থেকে indexer পড়ে — হঠাৎ ভিড়েও লাইন হারায় না।

৩ · Metric — counter, gauge, histogram আর label-এর বিস্ফোরণ

Log প্রতিটি ঘটনা আলাদা রাখে; metric ঘটনাগুলোকে গুনে বা মেপে একটি সংখ্যায় আনে, আর কিছুক্ষণ পরপর সেই সংখ্যাটি সময়ের সাথে লেখে। ১০ req/s হোক বা ১০ লাখ req/s, একটি counter-এর খরচ প্রায় একই — এজন্যই metric সস্তা, দ্রুত, আর alert-এর মূল ভিত্তি। মৌলিক ধরন তিনটি:

প্রতিটি metric-এর সাথে থাকে কিছু label — key-value মাত্রা, যেমন route, status, pod. প্রতিটি আলাদা label-সমন্বয় একটি আলাদা time series. Prometheus-ধরনের ব্যবস্থায় সেবা একটি text পাতায় metric দেখায়, এমন:

# TYPE http_requests_total counter
http_requests_total{route="/transfer",method="POST",status="200"} 1849302
http_requests_total{route="/transfer",method="POST",status="503"} 2114
# TYPE queue_depth gauge
queue_depth{queue="sms"} 37
# TYPE request_duration_seconds histogram
request_duration_seconds_bucket{route="/transfer",le="0.1"} 1702111
request_duration_seconds_bucket{route="/transfer",le="0.3"} 1838950
request_duration_seconds_bucket{route="/transfer",le="1"} 1850604
request_duration_seconds_bucket{route="/transfer",le="+Inf"} 1851416
request_duration_seconds_sum{route="/transfer"} 98213.7
request_duration_seconds_count{route="/transfer"} 1851416

Histogram-এর bucket-গুলো ক্রমযোজিত (cumulative): le="0.3" মানে ০.৩ সেকেন্ড বা তার কম সময়ে শেষ হওয়া সব অনুরোধ, ০.১-এর নিচেরগুলোসহ। _sum ÷ _count দেয় গড়, এখানে প্রায় ৫৩ ms. লক্ষ করুন, ১৮,৩৮,৯৫০ ÷ ১৮,৫১,৪১৬ ≈ ৯৯.৩৩% অনুরোধ ৩০০ ms-এর মধ্যে — এটি অংশ ৭-এর latency SLI, কোনো percentile আন্দাজ ছাড়াই, সরাসরি।

Cardinality-র বিস্ফোরণ

Time series-এর সংখ্যা হলো সব label-এর মানের সংখ্যার গুণফল। ধরা যাক ২০টি route, ৫টি status, ৩টি method, ৫০টি pod: ২০ × ৫ × ৩ × ৫০ = ১৫,০০০টি series. Histogram-এ ১০টি bucket আর _sum, _count মিলিয়ে প্রতিটির ১২টি — মোট ১,৮০,০০০. এখনো সামলানো যায়। এবার কেউ সরল মনে user_id label জুড়লেন, ১০ লাখ ব্যবহারকারী: সবচেয়ে খারাপ ক্ষেত্রে ১৫,০০০ × ১০,০০,০০০ = ১,৫০০ কোটি series. বাস্তবে সব সমন্বয় ঘটে না, তবু metric database-এর memory ফুরিয়ে যেতে পারে। একে বলে cardinality explosion (cardinality মানে ভিন্ন মানের সংখ্যা)।

নিয়ম: label-এর মান হবে সীমিত আর আগে থেকে জানা। user_id, request_id, email, ID-সহ পূর্ণ URL (/users/8812/orders-এর বদলে route-এর ছাঁচ /users/:id/orders) কখনো label নয় — ওগুলো log বা trace-এর জায়গা। “কতজন আলাদা ব্যবহারকারী” জানতে চাইলে প্রতিটি user-এর series নয়, একটি HyperLogLog (পর্ব ৪৫)।

Pull বনাম push — metric কে কার কাছে নিয়ে যায়

Prometheus-ধরনের ব্যবস্থা pull করে: metric server নিজে প্রতি কয়েক সেকেন্ডে (সাধারণত ১৫–৬০ s, config-নির্ভর) প্রতিটি সেবার /metrics পাতা পড়ে আনে — একে বলে scrape; কোন সেবা কোথায় আছে তা জানে service discovery থেকে। StatsD বা OpenTelemetry-র OTLP-ধরনের ব্যবস্থায় সেবা নিজে push করে পাঠায়।

বাস্তবে দুটি মেশে: স্বল্পায়ু job-এর জন্য Prometheus-এর জগতে একটি “pushgateway” আছে, আর অনেক collector দুই ধরনই নেয়। Metric জমা হয় একটি time-series database-এ, যা পাশাপাশি সময়ের মান খুব ভালো compress করে; পুরোনো ডেটা কম ঘন করে রাখা হয় (downsampling), যেমন ১৫ দিন পর ৫ মিনিটের মান।

৪ · Percentile-এর গড় হয় না — histogram-এর bucket থেকে p99

পর্ব ৪-এ দেখেছেন, গড় latency ঠকায়, তাই মাপা হয় percentile (p99), আর কয়েকটি সার্ভারের p99-এর গড় নেওয়া যায় না। Dashboard-এ “গড়” একটি বোতাম চাপলেই আসে বলে এই ভুলটি observability-তে সবচেয়ে বেশি হয়।

কারণটি গাণিতিক। Percentile একটি ক্রমের মান — সব মাপ সাজালে নির্দিষ্ট স্থানে যেটি পড়ে। গড়ের মতো এটি রৈখিক (linear) নয়: দুটি দলের p99 জানলেও মিলিত দলের ক্রমে কোন মান কোথায় পড়বে, তা বলা যায় না, কারণ কোন দলের ধীর অনুরোধ কতগুলো আর কত বড়, সেই তথ্য p99-এর একটি সংখ্যায় হারিয়ে গেছে। মিলিত p99 সবসময় দুই দলের p99-এর মাঝে (ছোটটি থেকে বড়টির মধ্যে) কোথাও থাকে, কিন্তু ঠিক কোথায় — তা বলতে লাগে পুরো বণ্টন, অথবা অন্তত তার একটি মেলানো যায় এমন সারাংশ। Histogram ঠিক সেই সারাংশ: প্রতিটি সার্ভারের একই bucket-এর গণনা যোগ করলেই মিলিত histogram.

নিচের simulator তিনটি সার্ভার বানায়: A বেশিরভাগ অনুরোধ সামলায় আর দ্রুত; C অল্প অনুরোধ পায়, কিন্তু তার ৮% আটকে যায় প্রায় ১.৫ সেকেন্ডে। তারপর ধরে নেয় সার্ভারগুলো শুধু bucket-গণনা পাঠায়, আর Prometheus-এর histogram_quantile-এর মতো bucket-এর ভেতরে সরলরেখায় p99 আন্দাজ করে।

// Three servers behind one service. Is the average of their p99s the service p99?
let seed = 50; function rand() {     // mulberry32: seeded PRNG
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const lat = (base, slowP, slowMs) =>  // ms: normal body, plus a rare slow tail
  rand() < slowP ? slowMs * (0.5 + rand()) : base * (0.5 + 2 * rand() * rand());
const servers = [["A", 7000, 20, 0.002, 400], ["B", 2500, 35, 0.005, 600], ["C", 500, 60, 0.08, 1500]];
const pct = (xs, q) => [...xs].sort((a, b) => a - b)[Math.ceil(q * xs.length) - 1];  // nearest rank
const le = [5, 10, 25, 50, 100, 250, 500, 1000, 2500, Infinity];   // bucket upper bounds, ms
const all = [], p99s = [], merged = le.map(() => 0);
console.log("server  requests  p50 ms  p99 ms");
for (const [name, n, base, slowP, slowMs] of servers) {
  const xs = Array.from({ length: n }, () => lat(base, slowP, slowMs));
  all.push(...xs); p99s.push(pct(xs, 0.99));
  le.forEach((b, k) => merged[k] += xs.filter(x => x <= b).length);  // each server exports counts only
  console.log(name.padEnd(8) + String(n).padStart(8) + pct(xs, 0.5).toFixed(1).padStart(8) + pct(xs, 0.99).toFixed(1).padStart(8));
}
const avg = p99s.reduce((a, b) => a + b) / p99s.length;
const wavg = servers.reduce((s, sv, i) => s + sv[1] * p99s[i], 0) / all.length;
console.log("average of the three p99s   " + avg.toFixed(1) + " ms");
console.log("request-weighted average    " + wavg.toFixed(1) + " ms");
console.log("TRUE p99 of all 10000       " + pct(all, 0.99).toFixed(1) + " ms");
console.log("merged buckets (le:count) " + le.map((b, k) => b + ":" + merged[k]).join(" "));
const rank = 0.99 * all.length, i = merged.findIndex(c => c >= rank);
const lo = i ? le[i - 1] : 0, below = i ? merged[i - 1] : 0;   // linear inside the bucket
const est = lo + (le[i] - lo) * (rank - below) / (merged[i] - below);
console.log("p99 from merged histogram   " + est.toFixed(1) + " ms (inside bucket " + lo + "-" + le[i] + ")");

server  requests  p50 ms  p99 ms
A           7000    17.7    45.3
B           2500    31.0    80.1
C            500    52.8  2081.1
average of the three p99s   735.5 ms
request-weighted average    155.8 ms
TRUE p99 of all 10000       106.1 ms
merged buckets (le:count) 5:0 10:0 25:6015 50:9270 100:9893 250:9938 500:9951 1000:9962 2500:10000 Infinity:10000
p99 from merged histogram   123.3 ms (inside bucket 100-250)

এ থেকে তিনটি ব্যবহারিক নিয়ম:

• সার্ভার থেকে percentile নয়, bucket পাঠান। আগেই হিসাব করা quantile (“summary”) মেলানো যায় না; bucket যোগ করা যায়।
• SLO-র সীমায় একটি bucket রাখুন। SLO যদি “৩০০ ms-এর মধ্যে”, তাহলে le="0.3" bucket থাকলে ভালো অনুরোধের অনুপাত সরাসরি গোনা যায়, কোনো interpolation ছাড়াই — যেমন অংশ ৩-এর ৯৯.৩৩%.
• সূক্ষ্মতা দরকার হলে sketch. t-digest-এর মতো quantile sketch (পর্ব ৪৫) বা নতুন ব্যবস্থার exponential histogram কম জায়গায় মেলানো যায় এমন, আর প্রান্তে বেশি নির্ভুল সারাংশ রাখে। কোন ব্যবস্থায় কোনটি আছে, তা সংস্করণভেদে আলাদা।

৫ · Trace — span, parent-child, traceparent আর sampling

একটি “টাকা পাঠান” অনুরোধ হয়তো পাঁচটি সেবা পেরোয় (পর্ব ৪৭), শেষে latency ২ সেকেন্ড। কোন সেবা দোষী? প্রতিটির metric বলছে “আমার গড় ঠিক আছে”। উত্তর দেয় distributed tracing.

একটি trace হলো একটি অনুরোধের সব কাজের গাছ। গাছের প্রতিটি নোড একটি span: একটি নির্দিষ্ট কাজ (একটি HTTP call, একটি database query), যার আছে trace id (পুরো অনুরোধের এক), নিজের span id, parent span id (কে তাকে ডেকেছে), নাম, শুরুর সময়, স্থায়িত্ব, status, আর কিছু attribute (route, ব্যাংক-অংশীদার, version). যে span-এর parent নেই, সে root span. এক সেবা থেকে আরেক সেবায় trace id আর নিজের span id পৌঁছে দেওয়ার কাজটির নাম context propagation, আর HTTP-তে এর মানক header হলো W3C Trace Context-এর traceparent.

GET /v1/accounts/balance HTTP/1.1
Host: payment.internal
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
tracestate: vendorx=t61rcWkgMzE

চারটি অংশ, ড্যাশ দিয়ে আলাদা: 00 version; ৩২ hex অক্ষরের (১৬ byte) trace id; ১৬ hex অক্ষরের (৮ byte) parent id — যে span এই অনুরোধ পাঠাল; আর trace flags, যার শেষ bit 1 মানে trace-টি নমুনায় রাখা হচ্ছে। tracestate ঐচ্ছিক, বিভিন্ন বিক্রেতার নিজস্ব তথ্যের জন্য। W3C এটিকে মানদণ্ড (Recommendation) হিসেবে প্রকাশ করে ২০২০ সালে।

OpenTelemetry এই কাজের বিক্রেতা-নিরপেক্ষ মানদণ্ড: log, metric আর trace-এর API ও SDK, স্বয়ংক্রিয় instrumentation, পাঠানোর protocol OTLP, আর একটি collector. ২০১৯ সালে OpenTracing আর OpenCensus মিলে তৈরি, এখন CNCF-এর অধীনে। কোড একবার instrument করে backend বদলানো যায় শুধু collector-এর config বদলে; তবে ভাষাভেদে SDK-র পরিপক্বতা লেখার সময়ে আলাদা।

Critical path — কোন অংশ দ্রুত করলে লাভ

Trace-এ সব ধীর span সমান দোষী নয়। Order যদি inventory আর payment-কে একসাথে (parallel) ডাকে, দুটির যেটি পরে শেষ হয় শুধু সেটিই মোট সময় ঠিক করে। যে span-শিকল মোট সময় ঠিক করে, তা critical path. নিচের simulator এলোমেলো ক্রমে আসা span-গুলো parent id ধরে গাছে জোড়ে, তারপর শেষ থেকে পেছনে হেঁটে critical path বের করে: প্রতিটি span-এ সবার শেষে শেষ হওয়া সন্তানে ঢোকে, তারপর তার শুরুর আগের অংশে একই কাজ।

// Spans reach the collector out of order. Rebuild the trace tree, then find the critical path.
let seed = 4; function rand() {      // mulberry32: seeded PRNG
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const hex = n => Array.from({ length: n }, () => (rand() * 16 | 0).toString(16)).join("");
const traceId = hex(32);                 // one id for the whole request
const ms = (lo, hi) => Math.round(lo + (hi - lo) * rand());
const S = {}; const span = (name, parent, start, dur) =>
  (S[name] = { id: hex(16), name, parent: parent && S[parent].id, start, end: start + dur });
span("gateway", null, 0, 0); span("order", "gateway", 1, 0);
span("auth", "order", 2, ms(5, 12));
const t0 = S.auth.end + 1;                              // after auth: two calls in parallel
span("inventory", "order", t0, ms(15, 30)); span("inv.db", "inventory", t0 + 2, S.inventory.end - t0 - 4);
span("payment", "order", t0, ms(40, 80)); span("bank", "payment", t0 + 3, S.payment.end - t0 - 6);
S.order.end = Math.max(S.inventory.end, S.payment.end) + 2; S.gateway.end = S.order.end + 1;
const arrived = Object.values(S);         // Fisher-Yates shuffle: collector order is random
for (let i = arrived.length - 1; i > 0; i--) { const j = rand() * (i + 1) | 0; [arrived[i], arrived[j]] = [arrived[j], arrived[i]]; }
console.log("arrival order: " + arrived.map(s => s.name).join(", "));
const byId = {}, kids = {}; let root;
for (const s of arrived) { byId[s.id] = s; kids[s.id] = []; }
for (const s of arrived) s.parent ? kids[s.parent].push(s) : (root = s);
(function show(s, depth) {
  console.log("  ".repeat(depth) + s.name.padEnd(14 - 2 * depth) + String(s.start).padStart(4) +
    " ms +" + String(s.end - s.start).padStart(3) + " ms  span " + s.id.slice(0, 8));
  kids[s.id].sort((a, b) => a.start - b.start).forEach(c => show(c, depth + 1));
})(root, 0);
function crit(s, until) {                     // walk backwards from the end of s
  const path = [s]; let t = Math.min(s.end, until);
  for (const c of [...kids[s.id]].sort((a, b) => b.end - a.end))
    if (c.end <= t) { path.push(...crit(c, t)); t = c.start; }
  return path;
}
console.log("critical path: " + crit(root, Infinity).sort((a, b) => a.start - b.start).map(s => s.name).join(" > "));
console.log("payment -> bank header  traceparent: 00-" + traceId + "-" + S.payment.id + "-01");

arrival order: inventory, gateway, order, inv.db, payment, bank, auth
gateway          0 ms + 88 ms  span c1c65809
  order          1 ms + 86 ms  span a71cf07e
    auth         2 ms +  5 ms  span 38cd17af
    inventory    8 ms + 30 ms  span 6fe71101
      inv.db    10 ms + 26 ms  span e3ab9deb
    payment      8 ms + 77 ms  span 0c6e80b0
      bank      11 ms + 71 ms  span f51c1d57
critical path: gateway > order > auth > payment > bank
payment -> bank header  traceparent: 00-e531381f9bc5be8b67bef75c4c857078-0c6e80b0e997c64f-01

Head বনাম tail sampling

প্রতিটি অনুরোধের পুরো trace রাখা ব্যয়বহুল: ২,০০০ req/s, প্রতিটিতে ৩০টি span, প্রতিটি ৫০০ byte হলে প্রতি সেকেন্ডে ৩০ MB, দিনে প্রায় ২.৬ TB. তাই নমুনা রাখা হয়।

অনেক দল দুটি মেশায়: head sampling-এ বেশিরভাগ বাদ, কিন্তু error হলে span-কে “অবশ্যই রাখা হোক” চিহ্ন; সাথে collector-এ tail নিয়ম। আর exemplar histogram-এর bucket-এর পাশে একটি নমুনা trace id রাখে, যাতে dashboard-এর লাফ থেকে এক ক্লিকে সেই রকম একটি ধীর trace খোলা যায় (সমর্থন সংস্করণভেদে আলাদা)।

৬ · কী মাপবেন — RED, USE আর চারটি golden signal

কোন সংখ্যা সবার আগে দেখবেন? তিনটি পরিচিত, পরস্পরের পরিপূরক কাঠামো:

বাস্তবে নিয়মটি দাঁড়ায়: সেবার জন্য RED, তার নিচের সম্পদের জন্য USE. RED বলে ব্যবহারকারী কষ্ট পাচ্ছেন কি না (লক্ষণ); USE বলে কেন (কারণ)। নিচের টেবিলে কয়েকটি অংশের জন্য উদাহরণ:

তিনটি সূক্ষ্ম ফাঁদ:

• দ্রুত ব্যর্থতা latency-কে “ভালো” দেখায়। একটি সেবা ২ ms-এ 503 ফেরালে গড় latency কমে যায়। সফল আর ব্যর্থ অনুরোধের latency আলাদা মাপুন।
• সব error HTTP status-এ নেই। 200 OK কিন্তু ভুল ব্যালান্স — ধরতে লাগে ব্যবসায়িক metric বা বাইরে থেকে কৃত্রিম অনুরোধ পাঠানো synthetic monitoring.
• Saturation আগে আসে, ব্যর্থতা পরে। Utilisation ৮০% থেকে ৯৫%-এ গেলে queue-তে অপেক্ষা বহুগুণ বাড়ে (পর্ব ৪-এর M/M/1); queue-র দৈর্ঘ্য বা অপেক্ষার সময় তাই সবচেয়ে আগাম সতর্কতা (পর্ব ১৮)।

৭ · SLI থেকে SLO, তারপর error budget আর তার নীতি

পর্ব ৫-এ তিনটি শব্দ আর nines-এর টেবিল দেখেছেন: SLI মাপা সংখ্যা, SLO দলের লক্ষ্য, SLA গ্রাহকের সাথে চুক্তি; আর error budget = ১০০% − SLO. এখানে প্রশ্ন হলো সেগুলো যন্ত্রে বসানো যায় কীভাবে।

একটি ভালো SLI-এর নির্দিষ্ট রূপ

প্রতিটি শব্দ লিখে ঠিক করতে হয়। বৈধ কোনগুলো — ভুল PIN-এর 4xx সাধারণত গোনা হয় না, তবে হঠাৎ 4xx-এর ঢল আলাদা করে দেখা দরকার। কোথায় মাপবেন — load balancer-এ মাপলে যে সার্ভার উত্তরই দেয়নি সেটিও ধরা পড়ে। জানালা — সাধারণত চলমান ৩০ দিন, যাতে মাসের প্রথম দিনে বাজেট হঠাৎ “ভরে” না যায়।

অনুরোধ-ভিত্তিক SLO-তে বাজেট আসলে ব্যর্থ অনুরোধের সংখ্যা; পর্ব ৫-এর মিনিটগুলো পূর্ণ বিভ্রাটের সমতুল্য। নিচের ক্যালকুলেটর দুটিই দেখায়, আর সাথে burn rate: পর্যবেক্ষিত ব্যর্থতার অনুপাত ÷ অনুমোদিত অনুপাত। Burn rate ১ মানে ঠিক ৩০ দিনে বাজেট শেষ।

// Error budget over a 30-day rolling window, steady 1,000 requests per second.
const days = 30, minutes = days * 24 * 60, rps = 1000;
const requests = rps * 86400 * days;
const f = (x, d = 0) => x.toLocaleString("en-US", { minimumFractionDigits: d, maximumFractionDigits: d });
console.log("window: " + days + " days = " + f(minutes) + " min, " + f(requests) + " requests");
console.log("SLO      budget  full-outage minutes  failed requests allowed  per day");
for (const slo of [99, 99.9, 99.95, 99.99]) {
  const b = (100 - slo) / 100;                 // allowed bad fraction
  console.log((slo + "%").padEnd(8) + ((100 - slo).toFixed(2) + "%").padStart(7) +
    f(b * minutes, 2).padStart(21) + f(Math.round(b * requests)).padStart(25) +
    f(Math.round(b * requests / days)).padStart(9));
}
// Burn rate = (observed bad fraction) / (allowed bad fraction). 1.0 = exactly on budget.
const slo = 99.9, b = (100 - slo) / 100;
console.log("\nSLO " + slo + "%: burn  error ratio  budget empty after  budget used in 1 h");
for (const burn of [1, 2, 6, 14.4, 36, 1000]) {
  const hoursToEmpty = days * 24 / burn;
  const empty = hoursToEmpty >= 72 ? f(hoursToEmpty / 24, 1) + " days"
    : hoursToEmpty >= 1 ? f(hoursToEmpty, 1) + " h" : f(hoursToEmpty * 60, 1) + " min";
  const used = Math.min(100, burn / (days * 24) * 100);   // a budget cannot go below empty
  console.log(String(burn).padStart(13) + ((burn * b * 100).toFixed(2) + "%").padStart(13) +
    empty.padStart(20) + (used.toFixed(2) + "%").padStart(20));
}

window: 30 days = 43,200 min, 2,592,000,000 requests
SLO      budget  full-outage minutes  failed requests allowed  per day
99%       1.00%               432.00               25,920,000  864,000
99.9%     0.10%                43.20                2,592,000   86,400
99.95%    0.05%                21.60                1,296,000   43,200
99.99%    0.01%                 4.32                  259,200    8,640

SLO 99.9%: burn  error ratio  budget empty after  budget used in 1 h
            1        0.10%           30.0 days               0.14%
            2        0.20%           15.0 days               0.28%
            6        0.60%            5.0 days               0.83%
         14.4        1.44%              50.0 h               2.00%
           36        3.60%              20.0 h               5.00%
         1000      100.00%            43.2 min             100.00%

Error-budget policy — আগে থেকে লেখা চুক্তি

বাজেট শুধু একটি সংখ্যা হলে কাজে আসে না; দরকার একটি error-budget policy — product, development আর operations দল আগে থেকেই একমত হয়ে লেখেন, বাজেট কমলে কী হবে। SRE workbook-এর উদাহরণ নীতির আদলে একটি কাল্পনিক নীতি:

• ৫০%-এর বেশি বাকি: স্বাভাবিক — নতুন feature, পরীক্ষা, সাহসী release.
• ২৫–৫০% বাকি: সতর্ক — প্রতিটি release ধীরে, canary দিয়ে (পর্ব ৫৩), বড় বিভ্রাটের postmortem বাধ্যতামূলক।
• ২৫%-এর কম: feature freeze — শুধু নির্ভরযোগ্যতা আর নিরাপত্তার কাজ; postmortem-এর action item সবার আগে।
• শেষ: সব ঝুঁকিপূর্ণ বদল বন্ধ।

৮ · Alert — burn rate, দুই জানালা, লক্ষণ আর alert fatigue

সবচেয়ে সরল alert: “গত ৫ মিনিটে error ratio ১%-এর বেশি হলে page.” সমস্যা দুই দিকে। এক মিনিটের ঝাঁকুনিতে এটি রাত ৩টায় মানুষকে জাগায়, অথচ বাজেট প্রায় খরচই হয়নি; আবার ০.৩%-এর ধীর ফুটো সীমা ছোঁয় না, অথচ দিনে বাজেটের ১০% খায়। প্রশ্নটা “error কত?” নয়, প্রশ্ন হলো “এই গতিতে বাজেট কত দ্রুত ফুরোচ্ছে?”

Burn rate থেকে alert-এর সীমা — হিসাবটি

SLO-র জানালা T (৩০ দিন = ৭২০ ঘণ্টা), burn rate b, আর w সময় ধরে চললে বাজেটের যে অংশ খরচ হয়:

একইভাবে “৬ ঘণ্টায় ৫%” → b = ০.০৫ × ৭২০ ÷ ৬ = ৬, আর “৩ দিনে ১০%” → b = ০.১০ × ৩০ ÷ ৩ = ১. Google-এর SRE workbook (২০১৮)-এর “Alerting on SLOs” অধ্যায় এই তিনটিকে সূচনা-বিন্দু হিসেবে সুপারিশ করে: প্রথম দুটিতে page (এখনই মানুষ দরকার), তৃতীয়টিতে ticket (কর্মদিবসে দেখলেই চলে)। সংখ্যাগুলো সূচনা-বিন্দু, আইন নয়।

কেন দুটি জানালা? শুধু ১ ঘণ্টার জানালা হলে বিভ্রাট থামার পরও প্রায় এক ঘণ্টা alert বন্ধ হয় না। তাই একটি ছোট জানালাও লাগে — সাধারণত লম্বাটির ১/১২, যেমন ৫ মিনিট — আর দুটিতেই সীমা পেরোলে তবেই page: লম্বা জানালা বলে “ক্ষতিটা অর্থবহ”, ছোটটি বলে “এখনো চলছে”। একে বলে multi-window, multi-burn-rate alert. ধরার সময়ও হিসাব করা যায়: error ratio e হলে ১ ঘণ্টার জানালা ১৪.৪-এ পৌঁছায় প্রায় ১৪.৪ × ০.০০১ × ৬০ ÷ e মিনিটে — পূর্ণ বিভ্রাটে (e = ১) প্রায় ০.৮৬ মিনিট, ৮% error-এ প্রায় ১০.৮ মিনিট।

নিচের simulator ৩০ দিনের প্রতি মিনিটের গণনা বানায় (১,০০০ req/s): স্বাভাবিক ০.০২% error, এলোমেলো কিছু এক মিনিটের ঝাঁকুনি (৮%), দিন ৯-এর ১৪:০০-তে ২০ মিনিটের একটি আসল বিভ্রাট (৮%), আর দিন ২২ থেকে ০.৩%-এর ধীর ফুটো। তারপর তিনটি নিয়ম পরীক্ষা করে: সরল সীমা, দুই জানালার page, আর ৩ দিনের ticket.

// 30 days of per-minute error counts, SLO 99.9% (allowed bad ratio 0.001). Who pages, and when?
let seed = 9; function rand() {      // mulberry32: seeded PRNG
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const D = 1440, M = 30 * D, REQ = 60000, B = 0.001;   // 1,000 req/s = 60,000 per minute
const inc0 = 9 * D + 14 * 60, leak0 = 22 * D;          // incident day 9 14:00 (20 min), leak from day 22
const bad = [], kind = [];
for (let m = 0; m < M; m++) {
  let r = 0.0002, k = "ok";                           // healthy: 0.02% errors
  if (rand() < 0.0007) { r = 0.08; k = "blip"; }      // 1-minute blip (pod restart), harmless
  if (m >= leak0) { r = Math.max(r, 0.003); k = k === "blip" ? k : "leak"; }   // slow leak: 0.3%
  if (m >= inc0 && m < inc0 + 20) { r = 0.08; k = "incident"; }               // real outage: 8%
  bad.push(REQ * r * (0.5 + rand())); kind.push(k);
}
const pre = [0]; bad.forEach((x, m) => pre.push(pre[m] + x));
const burn = (m, w) => (pre[m + 1] - pre[Math.max(0, m + 1 - w)]) / (Math.min(w, m + 1) * REQ * B);
const rules = [["threshold: 5m error ratio > 1%", m => burn(m, 5) * B > 0.01],
  ["page: (1h & 5m > 14.4) or (6h & 30m > 6)", m => (burn(m, 60) > 14.4 && burn(m, 5) > 14.4) ||
                                               (burn(m, 360) > 6 && burn(m, 30) > 6)],
  ["ticket: 3d & 6h burn > 1", m => burn(m, 3 * D) > 1 && burn(m, 360) > 1]];
const when = m => "day " + Math.floor(m / D) + " " + String(Math.floor(m % D / 60)).padStart(2, "0") +
  ":" + String(m % 60).padStart(2, "0");
const real = (m, ticket) => (m >= inc0 && m < inc0 + 80) || (ticket && m >= leak0);
for (const [name, rule] of rules) {
  let on = false; const fires = [];
  for (let m = 0; m < M; m++) { const x = rule(m); if (x && !on) fires.push(m); on = x; }
  const good = fires.filter(m => real(m, name.startsWith("ticket")));
  console.log(name + "\n  fired " + fires.length + "x, false alarms " + (fires.length - good.length) +
    ", real: " + (good.map(when).join(", ") || "none"));
}
let m = 0; while (m < M && pre[m + 1] < B * REQ * M) m++;
console.log("blips: " + kind.filter(k => k === "blip").length + ", 30-day budget used: " +
  (pre[M] / (B * REQ * M) * 100).toFixed(1) + "%, budget empty at " + (m < M ? when(m) : "never"));

threshold: 5m error ratio > 1%
  fired 24x, false alarms 23, real: day 9 14:00
page: (1h & 5m > 14.4) or (6h & 30m > 6)
  fired 1x, false alarms 0, real: day 9 14:12
ticket: 3d & 6h burn > 1
  fired 1x, false alarms 0, real: day 22 18:23
blips: 24, 30-day budget used: 102.4%, budget empty at day 29 18:25

লক্ষণে alert, কারণে নয়

“CPU ৯০%”, “pod restart”, “disk ৮০%” — এগুলো কারণ। CPU ৯০%-এও ব্যবহারকারী হয়তো কিছু টের পান না; আবার CPU ৩০%-এ থেকেও একটি deadlock সব অনুরোধ আটকে দিতে পারে। লক্ষণভিত্তিক alert page দেয় শুধু যখন ব্যবহারকারী কষ্ট পাচ্ছেন বা শিগগির পাবেন — SLO-র burn rate তার পরিষ্কার রূপ; কারণের সংকেত থাকে dashboard-এ। ব্যতিক্রম: “এই হারে disk ৪ ঘণ্টায় ভরবে” — ভবিষ্যৎ লক্ষণের নির্ভরযোগ্য পূর্বাভাস।

Alert fatigue বাস্তব বিপদ: যে page প্রায়ই মিথ্যা, মানুষ তা উপেক্ষা করতে শেখেন — আসল দিনেও। প্রতিটি page হবে জরুরি, পদক্ষেপযোগ্য, আর মানুষের বুদ্ধি দরকার এমন; প্রতিবার একই যান্ত্রিক কাজ লাগলে সেটি স্বয়ংক্রিয় করুন।

On-call, runbook আর dashboard

On-call মানে পালা করে একজন নির্দিষ্ট সময়ে page-এর দায়িত্বে থাকেন; টেকসই রাখতে পালায় যথেষ্ট মানুষ আর page সীমিত রাখতে হয় — SRE বই একটি ১২ ঘণ্টার পালায় দুটির বেশি ঘটনা না রাখার মতো লক্ষ্যের কথা বলে। প্রতিটি alert-এর সাথে একটি runbook: অর্থ, প্রভাব, কোন dashboard দেখবেন, সাধারণ কারণ, নিরাপদ প্রতিকার (rollback, traffic সরানো, feature flag বন্ধ), আর কাকে ডাকবেন।

Dashboard-এর ভালো ছাঁচ ওপর থেকে নিচে: SLO আর বাকি বাজেট; প্রতিটি সেবার RED; নির্ভরতা আর সম্পদের USE; আর সব গ্রাফে deploy ও config বদলের চিহ্ন, কারণ অনেক বিভ্রাট শুরু হয় একটি বদলের ঠিক পরে।

৯ · Incident response, postmortem আর observability-র খরচ

Alert বেজেছে। বড় বিভ্রাটে ভূমিকা আলাদা করা হয়: incident commander সমন্বয় আর সিদ্ধান্ত নেন (নিজে কোড ঠিক করেন না), একজন আসল পরিবর্তন করেন, আরেকজন গ্রাহক ও অন্য দলকে খবর দেন। মূলমন্ত্র: আগে প্রশমন (mitigation), পরে মূল কারণ।

Blameless postmortem-এর যুক্তি সরল: মানুষকে শাস্তি দিলে পরের বার তাঁরা ঘটনা লুকান, আর প্রতিষ্ঠান শেখে না। বিমান চলাচলের নিরাপত্তা-সংস্কৃতির এই চিন্তা সফটওয়্যারে জনপ্রিয় হয় John Allspaw-এর ২০১২ সালের একটি লেখার মতো আলোচনায়। Postmortem, failover-এর অনুশীলন আর দুর্যোগ থেকে ফেরা — পর্ব ৫১; এই metric দিয়েই canary analysis নতুন সংস্করণকে পুরোনোটির পাশে তুলনা করে — পর্ব ৫৩।

Observability-র খরচ — নকশার অংশ

Observability বিনামূল্যে নয়: storage, network, index আর instrumentation-এর CPU — বড় প্রতিষ্ঠানে এর বিল অবকাঠামোর উল্লেখযোগ্য অংশ হতে পারে।

ছয় মাসে কেউ না খোলা dashboard আর কোনো প্রশ্নে না লাগা metric বাদ দিন।

১০ · AI-এর যুগে — observability-র নকশা যাচাই

Monitoring-এর নকশা চাইলে AI প্রায়ই একটি তালিকা দেয়: “Prometheus, Grafana, ELK, Jaeger বসান; CPU ৮০%-এ alert; সব log রাখুন।” SLO নেই, কে কখন জাগবেন বলা নেই, খরচের হিসাব নেই, আর CPU-র alert লক্ষণ নয়। খসড়া AI দিতে পারে; কোনটি মাপবেন আর কেন — সেই বিচার আপনার।

AI-এর observability নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Error budget মিনিটে আর অনুরোধে নিজে হিসাব করেছি; burn rate-এর প্রতিটি সংখ্যা b × w ÷ T দিয়ে মিলিয়েছি
• প্রতিটি page লক্ষণভিত্তিক, পদক্ষেপযোগ্য, আর তার সাথে runbook আছে
• Percentile কোথাও গড় করা হয়নি; latency histogram-এ, SLO-র সীমায় একটি bucket আছে
• Metric-এর series-এর সংখ্যা label-এর গুণফল দিয়ে হিসাব করেছি; কোনো অসীম-মানের label নেই
• Log-এ কোনো পাসওয়ার্ড, OTP, token বা খোলা PII নেই; trace id সব log-এ আছে
• সংকেতের দৈনিক আকার আর মাসিক খরচের একটি হিসাব আছে, আর একটি সিমুলেটেড ঘটনা চালিয়ে alert-গুলো পরীক্ষা করেছি