Metrics monitoring ও alerting সিস্টেম ডিজাইন

লক্ষ্য: হাজারো server ও অ্যাপ থেকে সংখ্যা (metrics) সংগ্রহ, সস্তায় সংরক্ষণ, dashboard-এ দেখানো এবং কিছু ভুল হলে মানুষকে alert দেওয়া।

Requirement

• প্রতি সেকেন্ডে লক্ষ লক্ষ data point গ্রহণ।
• সাম্প্রতিক data দ্রুত query; পুরোনো data সস্তায় রাখা।
• মাত্রা অনুযায়ী নমনীয় aggregation (গড়, percentile, rate)।
• কম ভুল সতর্কতাসহ নির্ভরযোগ্য alerting।
• Monitoring সিস্টেম নিজেই highly available হবে।

Data model

Metric হলো একটি time series: একটি নাম, label-এর সেট (key-value tag) এবং (timestamp, value) বিন্দুর ক্রম।

উদাহরণ: http_requests_total{service="api", status="500", region="dhaka"}।

সংগ্রহ: push বনাম pull

• Pull (Prometheus ধাঁচ): server নির্দিষ্ট সময় পরপর প্রতিটি target-এর /metrics endpoint scrape করে। কোন target বন্ধ তা সহজে বোঝা যায়; service discovery লাগে।
• Push (agent, StatsD): অ্যাপ বা agent collector-এ metric পাঠায়। স্বল্পস্থায়ী job ও firewall-ঘেরা host-এর জন্য ভালো।

প্রায়ই মিশ্রণ ব্যবহার হয়। Burst শোষণে গ্রহণের সামনে queue (Kafka) থাকতে পারে।

Storage: time-series database

Time-series data append-only লেখা হয় ও সময়ের পরিসরে পড়া হয়, তাই বিশেষ storage সবচেয়ে ভালো:

• বিন্দুগুলো series ও সময়ের block অনুযায়ী গুচ্ছ করুন এবং delta ও delta-of-delta compression ব্যবহার করুন (বিন্দুর মধ্যে timestamp ও মান সামান্যই বদলায়)। Compression অনুপাত খুব বেশি।
• সাম্প্রতিক data memory বা দ্রুত disk-এ রাখুন।
• পুরোনো data downsample করুন (১০ সেকেন্ডের বিন্দুর বদলে ৫ মিনিটের গড়) এবং সবচেয়ে পুরোনোগুলো মুছতে retention নিয়ম দিন।

Cardinality: ক্লাসিক ফাঁদ

প্রতিটি অনন্য label সংমিশ্রণ আলাদা series। user_id বা পূর্ণ URL-এর মতো সীমাহীন মানের label লক্ষ লক্ষ series বানিয়ে সিস্টেম ভেঙে দিতে পারে। Label কম-cardinality রাখুন, আর বেশি-cardinality data log বা trace-এ রাখুন।

Query ও dashboard

Query language series জুড়ে rate, যোগফল ও percentile হিসাব করে। Dashboard (যেমন Grafana) refresh বিরতিতে এই query চালায়, তাই সাধারণ query cache করুন এবং সময়ের পরিসর সীমিত করুন।

Alerting

1. নিয়ম ঠিক করুন: যেমন "৫ মিনিট ধরে error হার ৫%-এর ওপরে"।
2. একটি evaluator নিয়মিত নিয়ম যাচাই করে।
3. Fire হওয়া alert alert manager-এ যায়, যা group, deduplicate, silence ও route করে (chat, ইমেইল, ফোন)।

ভালো alert কাজে লাগার মতো এবং user-এর অনুভব করা লক্ষণের (error, latency) ওপর ভিত্তি করে, সাথে "for" সময় যাতে বারবার ওঠানামা না হয়। অতিরিক্ত গোলমেলে alert alert fatigue ঘটায়।

নির্ভরযোগ্যতা

Collector ও storage-এর replica চালান, monitor-কেও monitor করুন (আলাদা সহজ যাচাই), এবং যে সিস্টেম দেখছেন তার ওপর নির্ভর করবেন না।

Scaling

Series-এর hash দিয়ে storage node-এ shard করুন, target গুচ্ছ ভাগ করে একাধিক scraper চালান এবং query স্তর দিয়ে aggregate করুন।

মূল কথা: label-ভিত্তিক time-series মডেল, downsampling সহ দক্ষ সংকুচিত storage, cardinality-র কড়া নিয়ন্ত্রণ, এবং কাজে লাগার মতো, গুচ্ছ করা alerting।

---

System Design সিরিজ, পর্ব ৪ (infrastructure ডিজাইন): 4 নম্বর (মোট 4)। আগের লেখা: Distributed key-value store ডিজাইন (Dynamo-ধাঁচ).