লগিং ও মনিটরিং কী?
লগিং (Logging) হলো সিস্টেমের বিভিন্ন ইভেন্ট ও ডাটা জমা করে রাখার প্রক্রিয়া। আর মনিটরিং (Monitoring) হলো সেই লগ ও মেট্রিক বিশ্লেষণ করে সিস্টেমের স্বাস্থ্য বোঝার প্রক্রিয়া।
সহজ ভাষায়:
লগিং = ডায়েরি লেখা। মনিটরিং = ডায়েরি পড়ে বোঝা কখন কী হয়েছে, সিস্টেম ঠিক আছে কিনা।
[অ্যাপ্লিকেশন] → লগ তৈরি করে → স্টোরেজ → অ্যানালাইসিস → অ্যালার্ট → অ্যাকশন
↑ ↑
(লগিং) (মনিটরিং)
কেন লগিং ও মনিটরিং দরকার?
| কারণ |
ব্যাখ্যা |
| ডিবাগিং |
প্রোডাকশনে বাগ হলে লগ দেখে কারণ বের করা যায় |
| পারফরম্যান্স ট্র্যাকিং |
রেসপন্স টাইম, থ্রুপুট, এরর রেট দেখা |
| অ্যালার্টিং |
কিছু ভুল হলে সঙ্গে সঙ্গে নোটিফিকেশন পাওয়া |
| ক্যাপাসিটি প্ল্যানিং |
ট্রেন্ড দেখে বুঝা কবে রিসোর্স বাড়াতে হবে |
| সিকিউরিটি অডিট |
কে কখন কী করলো তার হিসাব রাখা |
| কমপ্লায়েন্স |
律法 অনুযায়ী লগ রাখা বাধ্যতামূলক (GDPR, HIPAA) |
পার্ট ১: লগিং (Logging)
লগের প্রকারভেদ
| লেভেল |
ব্যবহার |
উদাহরণ |
| DEBUG |
ডেভেলপমেন্টে ডিটেইল |
"ভেরিয়েবল x = 10, ফাংশনে ঢুকলাম" |
| INFO |
সাধারণ অপারেশন |
"User 123 লগইন করেছে" |
| WARN |
সমস্যা হতে পারে |
"ডাটাবেস কানেকশন ধীর (২ সেকেন্ড)" |
| ERROR |
এরর কিন্তু সিস্টেম চালু |
"পেমেন্ট ফেইলড, রি-ট্রাই করা হবে" |
| FATAL |
মারাত্মক এরর, অ্যাপ বন্ধ |
"ডাটাবেস কানেক্ট করতে পারিনি, বন্ধ করছি" |
স্ট্রাকচার্ড লগিং
লগ মেশিন-রিডেবল হওয়া উচিত (JSON ফরম্যাট)।
❌ খারাপ লগ (টেক্সট):
2024-01-15 10:30:45 User 123 login success from IP 192.168.1.1
✅ ভালো লগ (স্ট্রাকচার্ড JSON):
{
"timestamp": "2024-01-15T10:30:45Z",
"level": "INFO",
"service": "auth-service",
"user_id": 123,
"action": "login",
"ip": "192.168.1.1",
"duration_ms": 45,
"trace_id": "abc-123-def"
}
লগ ফরম্যাটে কী থাকা দরকার
| ফিল্ড |
প্রয়োজনীয়তা |
কেন |
| timestamp |
আবশ্যক |
কখন ঘটেছে তা জানতে |
| level |
আবশ্যক |
DEBUG/INFO/ERROR চিহ্নিত করতে |
| service |
আবশ্যক |
কোন সার্ভিস থেকে লগ এসেছে |
| message |
আবশ্যক |
মানুষের পড়ার জন্য |
| trace_id |
সুপারিশড |
একই রিকোয়েস্টের লগ গ্রুপ করতে |
| user_id |
প্রয়োজনমতো |
কোন ইউজার প্রভাবিত |
| duration_ms |
প্রয়োজনমতো |
পারফরম্যান্স ট্র্যাকিং |
লগিং বেস্ট প্র্যাকটিস
| টিপস |
বিস্তারিত |
| কনফিডেনশিয়াল ডাটা লগ করবেন না |
পাসওয়ার্ড, টোকেন, ক্রেডিট কার্ড নম্বর কখনো লগ করবেন না |
| লগ রোটেশন করুন |
logrotate বা elk stack দিয়ে পুরোনো লগ ডিলিট করুন |
| সেন্ট্রালাইজড লগিং |
সব সার্ভিসের লগ এক জায়গায় আনুন (ELK, Loki) |
| কনটেক্সট যোগ করুন |
শুধু "এরর" না লিখে বলুন কোন ফাংশন, কোন লাইন |
| স্যাম্পলিং |
খুব বেশি লগ হলে ১% স্যাম্পল করুন |
পার্ট ২: মনিটরিং (Monitoring)
মেট্রিকের প্রকারভেদ
| মেট্রিক টাইপ |
ব্যাখ্যা |
উদাহরণ |
| কাউন্টার (Counter) |
শুধু বাড়ে, কখনো কমে না |
রিকোয়েস্ট总数, এরর总数 |
| গেজ (Gauge) |
বাড়ে/কমে |
মেমোরি ইউসেজ, একটিভ কানেকশন |
| হিস্টোগ্রাম |
ডিস্ট্রিবিউশন মাপে |
রেসপন্স টাইম (p50, p95, p99) |
| মিটার (Meter) |
রেট মাপে |
রিকোয়েস্ট/সেকেন্ড |
গোল্ডেন সিগন্যাল (Google SRE)
চারটি মেট্রিক সব সিস্টেমে মনিটর করতে হবে:
১. লেটেন্সি → রিকোয়েস্ট কত সময় নিচ্ছে
২. ট্রাফিক → কত রিকোয়েস্ট আসছে (RPS)
৩. এরর → কত রিকোয়েস্ট ফেইল করছে (%)
৪. স্যাচুরেশন → সিস্টেম কতটুকু ব্যস্ত (CPU, মেমরি, ডিস্ক)
USE মেথড (ব্রেন্ডান গ্রেগ)
প্রতি রিসোর্সের জন্য তিনটি মেট্রিক:
U = Utilization (কতটা ব্যবহার হচ্ছে - %)
S = Saturation (কতটা লাইন বাকি আছে - queue length)
E = Errors (কত এরর হচ্ছে)
RED মেথড (মাইক্রোসার্ভিসের জন্য)
R = Rate (প্রতি সেকেন্ডে কত রিকোয়েস্ট)
E = Errors (কত শতাংশ রিকোয়েস্ট ফেইল করছে)
D = Duration (রিকোয়েস্ট কত সময় নিচ্ছে)
মেট্রিক সংগ্রহ আর্কিটেকচার
পুল মডেল (Prometheus)
[মেট্রিক সার্ভার] → প্রতি ১৫ সেকেন্ডে → [অ্যাপ ১] (HTTP /metrics)
→ প্রতি ১৫ সেকেন্ডে → [অ্যাপ ২]
→ প্রতি ১৫ সেকেন্ডে → [ডাটাবেস]
পুশ মডেল (Graphite, InfluxDB)
[অ্যাপ ১] → (কিয়ের মাধ্যমে) → [মেট্রিক সার্ভার]
[অ্যাপ ২] ↗
জনপ্রিয় টুল স্ট্যাক
| স্ট্যাক |
উপাদান |
কখন ব্যবহার |
| ELK |
Elasticsearch + Logstash + Kibana |
লগিং ফোকাস |
| Prometheus + Grafana |
Prometheus + Grafana |
মেট্রিক ফোকাস |
| Loki + Promtail + Grafana |
Loki |
কুবারনেটিস পরিবেশ |
| Datadog |
অল-ইন-ওয়ান (পেইড) |
এন্টারপ্রাইজ |
| New Relic |
APM ফোকাস |
অ্যাপ্লিকেশন পারফরম্যান্স |
| Sentry |
এরর ট্র্যাকিং ফোকাস |
এরর মনিটরিং জন্য |
অ্যালার্টিং (Alerting)
অ্যালার্টের প্রকারভেদ
| টাইপ |
ব্যাখ্যা |
উদাহরণ |
| শর্ট-টার্ম |
১-২ মিনিট পরে কিছু হয় |
৫০০ এরর বেড়ে গেলে |
| লং-টার্ম |
১০-১৫ মিনিট দেখে |
ডিস্ক ফুল হতে ৯০% পূর্ণ |
| প্রেডিকটিভ |
ভবিষ্যতে সমস্যা হবে |
রেট অনুযায়ী আর ২ দিনে ডিস্ক শেষ |
অ্যালার্ট রুল উদাহরণ (PromQL)
groups:
- name: example
rules:
# হাই এরর রেট
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
for: 2m
annotations:
summary: "High error rate: {{ $value }}"
# হাই লেটেন্সি
- alert: HighLatency
expr: histogram_quantile(0.95, http_request_duration_seconds) > 0.5
for: 5m
# ডিস্ক প্রায় ফুল
- alert: DiskAlmostFull
expr: (node_filesystem_free_bytes / node_filesystem_size_bytes) < 0.1
for: 5m
# সার্ভিস ডাউন
- alert: ServiceDown
expr: up{job="myapp"} == 0
for: 1m
অ্যালার্ট বেস্ট প্র্যাকটিস
| টিপস |
কেন গুরুত্বপূর্ণ |
| শুধু অ্যাকশনেবল অ্যালার্ট |
যে অ্যালার্টে কিছু করার নেই, সেটা বাদ দিন |
| ফলস পজিটিভ কমানো |
খুব স্পর্শকাতর অ্যালার্ট সতর্কতা কমায় |
| এস্কেলেশন পলিসি |
৫ মিনিটে কেউ রেসপন্ড না করলে অন্যের কাছে যান |
| সাইলেন্ট (শান্ত) সময় |
রক্ষণাবেক্ষণের সময় অ্যালার্ট বন্ধ রাখুন |
| অ্যালার্ট ডকুমেন্টেশন |
প্রতিটি অ্যালার্টের জন্য "কী করবেন" লিখে রাখুন |
ডিস্ট্রিবিউটেড ট্রেসিং
পুরো রিকোয়েস্টের গল্প বোঝার জন্য ট্রেসিং জরুরি।
[ফ্রন্টএন্ড] → [অর্ডার সার্ভিস] → [পেমেন্ট সার্ভিস] → [ডাটাবেস]
│ │ │ │
└─────────────────┴───────────────────┴────────────────┘
(ট্রেসের আইডি: abc123)
ওপেনটেলিমেট্রি (OpenTelemetry): স্ট্যান্ডার্ড ট্রেসিং ফরম্যাট (সব ক্লাউডে কাজ করে)
from opentelemetry import trace
tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span("process-order"):
# আপনার কোড
with tracer.start_as_current_span("check-inventory"):
check_inventory()
with tracer.start_as_current_span("charge-payment"):
charge_payment()
লগিং & মনিটরিং আর্কিটেকচার
প্রোডাকশন রেডি আর্কিটেকচার
[অ্যাপ ১] ─┐
[অ্যাপ ২] ─┼→ [লগ এজেন্ট] → [কাফকা] → [লগ প্রসেসর] → [Elasticsearch] → [কিবানা]
[অ্যাপ ৩] ─┘ (Fluentd) (Logstash) ↑
│
[মেট্রিক] ───→ [Prometheus] ──────────────────────────────────────┘
[Grafana]
↑
[অ্যালার্ট ম্যানেজার]
লগ ভলিউম ও খরচ
| সিস্টেম সাইজ |
ডেইলি লগ ভলিউম |
লগ রাখার সময় |
স্টোরেজ খরচ (প্রায়) |
| ছোট (১০ সার্ভিস) |
১০ GB |
৭ দিন |
৭০ GB |
| মাঝারি (৫০ সার্ভিস) |
৫০০ GB |
৩০ দিন |
১৫ TB |
| বড় (২০০+ সার্ভিস) |
২-৫ TB |
৩০-৯০ দিন |
১০০+ TB |
খরচ বাঁচানোর কৌশল:
- পুরোনো লগ কম্প্রেস করুন
- DEBUG লগ খুব কম রাখুন
- শুধু ERROR লগ অনেকদিন রাখুন
- স্যাম্পলিং (১০% রিকোয়েস্টের লগ রাখুন)
লগ ও মেট্রিক ভিজুয়ালাইজেশন
গুরুত্বপূর্ণ ড্যাশবোর্ড
| ড্যাশবোর্ড |
কী দেখায় |
| ওভারভিউ |
সব সার্ভিসের স্ট্যাটাস (সবুজ/লাল) |
| পারফরম্যান্স |
লেটেন্সি গ্রাফ, থ্রুপুট, এরর রেট |
| ইনফ্রাস্ট্রাকচার |
CPU, মেমরি, ডিস্ক, নেটওয়ার্ক |
| বিজনেস মেট্রিক |
কত অর্ডার হয়েছে, কত ইউজার লগইন করেছে |
| এরর অ্যানালাইসিস |
সবচেয়ে ঘন ঘন এরর কোনটা |
চিটশিট: কখন কী করবেন
| সমস্যা |
লগ দেখবেন? |
মেট্রিক দেখবেন? |
ট্রেস দেখবেন? |
| অ্যাপ্লিকেশন ক্র্যাশ |
✅ |
❌ |
❌ |
| রেসপন্স টাইম বেড়েছে |
❌ |
✅ |
✅ |
| ইউজার বলছে "কাজ করছে না" |
✅ |
✅ |
✅ |
| সার্ভারের CPU ১০০% |
❌ |
✅ |
❌ |
| ডাটাবেস কুয়েরি ধীর |
✅ |
✅ |
✅ |
| সিকিউরিটি ইনসিডেন্ট |
✅ |
❌ |
❌ |
সাধারণ ভুল ও সমাধান
| ভুল |
সমস্যা |
সমাধান |
| অতিরিক্ত অ্যালার্ট |
কেউ রেসপন্ড করে না |
গুরুত্ব অনুযায়ী প্রায়োরিটি দিন |
| কোনও স্ট্রাকচার ছাড়া লগ |
পার্স করা কঠিন |
JSON ফরম্যাটে লগ করুন |
| PII ডাটা লগ করা |
GDPR ভায়োলেশন |
লগিং করার আগে স্যানিটাইজ করুন |
| লগ রোটেশন নেই |
ডিস্ক ফুল হয়ে যায় |
logrotate সেট করুন |
| অ্যাকশনেবল অ্যালার্ট নেই |
অ্যালার্ট এলেও কী করবেন বুঝবেন না |
রানবুক লেখুন |
