শেখো / অবজার্ভেবিলিটি ও SRE

Logging, Metrics, Tracing

9 মিনিট Module 8 · Observability & SRE

এক নজরে

●Observability-র তিন স্তম্ভ হলো Logs, Metrics আর Traces — একসাথে এরা সিস্টেমের ভিতরে কী ঘটছে তা বুঝতে সাহায্য করে।
●Logs বলে কী ঘটেছে, Metrics বলে কতটা/কেমন চলছে, আর Traces বলে একটা request কোন পথে গেল।
●ELK দিয়ে log, Prometheus দিয়ে metric, আর Jaeger দিয়ে distributed tracing করা হয়।

সমস্যাটা কী?

ধরো তোমার e-commerce সাইট হঠাৎ ধীর হয়ে গেল। গ্রাহকরা অভিযোগ করছেন "checkout করতে ৩০ সেকেন্ড লাগছে"। তুমি server-এ login করে দেখলে CPU ঠিক আছে, কিন্তু সমস্যা কোথায় তা ধরতে পারছ না। Payment service? Database? নাকি কোনো external API?

আধুনিক সিস্টেমে একটা request ১০-১৫টা service-এর ভিতর দিয়ে যায়। ভিতরে কী ঘটছে তা বাইরে থেকে দেখা যায় না — এটাকে বলে black box সমস্যা। এই অন্ধকার দূর করার নামই Observability। আর এর ভিত্তি হলো তিনটি স্তম্ভ: Logs, Metrics, Traces।

মূল ধারণা

Observability হলো একটা সিস্টেমের external output (log, metric, trace) দেখে তার internal state বোঝার ক্ষমতা — কোনো নতুন code না লিখেই যেকোনো প্রশ্নের উত্তর পাওয়া।

Monitoring আর Observability এক জিনিস নয়। Monitoring তোমাকে আগে থেকে ঠিক করা প্রশ্নের উত্তর দেয় ("CPU কি ৮০%-এর বেশি?")। Observability তোমাকে এমন প্রশ্নেরও উত্তর দিতে দেয় যা তুমি আগে ভাবোইনি ("কেন শুধু চট্টগ্রামের Android user-দের checkout fail হচ্ছে?")।

তিন স্তম্ভ আলাদা প্রশ্নের উত্তর দেয়:

Logs — কী ঘটেছে (what happened)
Metrics — কতটা, কেমন চলছে (how much / how healthy)
Traces — কোথায়, কোন পথে (where in the flow)

কীভাবে কাজ করে

Logs — ঘটনার বিবরণ

Log হলো নির্দিষ্ট সময়ের ঘটনার text record। পুরোনো দিনে আমরা লিখতাম print("user logged in") — এটা unstructured log, পড়া যায় কিন্তু মেশিনে query করা কঠিন।

আধুনিক উপায় হলো Structured Logging — JSON আকারে key-value:

{
  "timestamp": "2026-06-21T10:30:00Z",
  "level": "ERROR",
  "service": "payment",
  "user_id": "u_8821",
  "trace_id": "abc123",
  "message": "payment gateway timeout",
  "duration_ms": 5021
}

এখন তুমি query করতে পারো: "গত ১ ঘণ্টায় payment service-এ যত ERROR এসেছে, সব দেখাও"। ELK stack (Elasticsearch + Logstash + Kibana) বা Loki এই কাজে জনপ্রিয়।

Metrics — সংখ্যায় স্বাস্থ্য

Metric হলো সময়ের সাথে পরিবর্তিত সংখ্যা (time-series)। তিন ধরনের metric সবচেয়ে গুরুত্বপূর্ণ:

Metric Type	অর্থ	উদাহরণ
Counter	শুধু বাড়ে, কখনো কমে না	মোট request সংখ্যা, মোট error
Gauge	উঠানামা করে	বর্তমান memory usage, active connection
Histogram	value-গুলোকে bucket-এ ভাগ করে	request latency-র p50/p95/p99 distribution

Prometheus metric সংগ্রহ করে (pull model), আর Grafana দিয়ে সুন্দর dashboard বানানো হয়। Metric সস্তা ও hালকা — তাই সারাক্ষণ ধরে রাখা যায়।

Traces — request-এর যাত্রাপথ

Distributed Tracing-এ একটা request যখন service-গুলোর ভিতর দিয়ে যায়, তখন প্রতিটা ধাপ record হয়। পুরো যাত্রাটা হলো trace, আর প্রতিটা ছোট ধাপ (এক service-এর কাজ) হলো Span।

প্রতিটা request-এ একটা unique trace_id যুক্ত হয় যা সব service-এ পাস হয়। ফলে তুমি দেখতে পারো:

Trace abc123 (মোট 5021ms)
├─ api-gateway          12ms
├─ auth-service         8ms
├─ cart-service         45ms
└─ payment-service      4956ms  ← এখানেই দেরি!
   └─ external-gateway  4900ms  ← আসল দোষী

Jaeger বা Zipkin এই কাজ করে। OpenTelemetry এখন standard হয়ে উঠেছে — এটা দিয়ে তিন ধরনের data-ই সংগ্রহ করা যায়।

সহজ উদাহরণ

ভাবো তুমি একটা কুরিয়ার কোম্পানির মালিক। Log হলো প্রতিটা parcel-এর scan history ("ঢাকা hub-এ পৌঁছেছে, ৩টায়")। Metric হলো daily dashboard ("আজ ৫০০ parcel, গড় delivery ২ দিন")। Trace হলো একটা নির্দিষ্ট parcel-এর পুরো journey দেখা — কোন hub-এ আটকে ছিল তা ধরা। একটা parcel দেরিতে গেলে log দিয়ে শুরু করবে, metric দিয়ে বুঝবে এটা একটা না সব parcel-এর সমস্যা, আর trace দিয়ে ঠিক কোন hub দায়ী তা বের করবে।

প্রকারভেদ — কখন কোনটা

তিন স্তম্ভ প্রতিযোগী নয়, পরিপূরক। সাধারণ workflow:

Metric দিয়ে শুরু — alert এলো "p99 latency ২ সেকেন্ড ছাড়িয়েছে"। এটা তোমাকে জানায় সমস্যা আছে।
Trace দিয়ে খোঁজো — কোন service ধীর? এটা জানায় কোথায় সমস্যা।
Log দিয়ে গভীরে যাও — ঐ service-এর log পড়ে দেখো ঠিক কী ভুল হয়েছে (যেমন: "DB connection pool exhausted")।

প্রশ্ন	কোন স্তম্ভ
সিস্টেম কি সুস্থ?	Metrics
কোন service ধীর?	Traces
ঠিক কী error হলো?	Logs
গত মাসের তুলনায় traffic কেমন?	Metrics
user u_8821-এর সাথে কী ঘটেছিল?	Logs + Traces

কখন ব্যবহার করবে / করবে না

ছোট, single-service app-এ শুধু ভালো log-ই অনেকটা যথেষ্ট। tracing বসানোর জটিলতা তখন বাড়তি বোঝা।
microservice architecture (৩+ service) হলে tracing প্রায় বাধ্যতামূলক — নইলে সমস্যা খুঁজতে দিন কেটে যাবে।
সব জায়গায় metric রাখো — এটা সবচেয়ে সস্তা ও ২৪/৭ চালু রাখা যায়।

সাবধান

সব log DEBUG level-এ রেখে দিলে storage খরচ আকাশছোঁয়া হবে এবং আসল ERROR খড়ের গাদায় সুঁই হয়ে যাবে। Production-এ সাধারণত INFO/WARN/ERROR রাখো, আর tracing-এ sampling করো (যেমন ১০% request) যাতে খরচ ও volume নিয়ন্ত্রণে থাকে। মনে রেখো — log-এ কখনো password, card number বা PII লিখো না।

বাস্তব উদাহরণ

একটা bKash-সদৃশ payment platform চিন্তা করো। একদিন support team জানালো কিছু user "টাকা কাটল কিন্তু balance update হলো না" অভিযোগ করছে।

Metric dashboard-এ দেখা গেল payment_success_rate ৯৯.৯% থেকে ৯৭%-এ নেমেছে — সমস্যা confirm।
Trace খুঁজে দেখা গেল fail হওয়া request-গুলোর span-এ ledger-service timeout করছে।
ঐ service-এর Log-এ পাওয়া গেল database deadlock detected — root cause।

তিন স্তম্ভ মিলিয়ে ১৫ মিনিটে সমস্যা ধরা পড়ল, যা শুধু log দিয়ে খুঁজলে ঘণ্টার পর ঘণ্টা লাগত।

টিপস

Interview-এ যদি জিজ্ঞেস করে "তিন স্তম্ভ আলাদা কেন?", এক লাইনে বলো — Logs = discrete events (what), Metrics = aggregated numbers over time (how much), Traces = request flow across services (where)। তারপর যোগ করো যে এরা পরিপূরক: metric দিয়ে detect, trace দিয়ে localize, log দিয়ে diagnose। trace_id দিয়ে তিন data যুক্ত (correlate) করার কথা বললে interviewer বুঝবে তুমি practical।

মূল শব্দ (Key Terms)

Structured Logging Histogram Distributed Tracing Span

মিনি কুইজ

1. একটা request আপনার ১০টা microservice-এর মধ্যে কোন পথে গেল আর কোথায় ধীর হলো — এটা বুঝতে কোনটা সবচেয়ে কাজের?

2. Prometheus-এ request latency-র distribution (p50, p95, p99) মাপতে কোন metric type সবচেয়ে উপযুক্ত?

3. Structured logging-এর মূল সুবিধা কী?

পরের পাঠSLI, SLO, SLA ও Error Budget