পাঠ ৪১ · ৫৭-এর মধ্যে · মডিউল ১০
Home / Courses / Cloud Computing & DevOps / মনিটরিং ও মেট্রিক্স

মনিটরিং ও মেট্রিক্স বেসিকস

Monitoring & metrics basics
৮ মিনিট পড়া মধ্যবর্তী · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

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

  • মেট্রিক্স কী এবং কেন এগুলো টাইম-সিরিজ হিসেবে সংগ্রহ করা হয়
  • পুল-বেসড ও পুশ-বেসড মেট্রিক্স সংগ্রহের মধ্যে পার্থক্য এবং প্রতিটি কখন উপযুক্ত
  • চারটি "গোল্ডেন সিগন্যাল" — যেকোনো সার্ভিসের স্বাস্থ্য বোঝার সর্বজনীন কাঠামো
  • Python দিয়ে একটি পুল-বেসড স্ক্র্যাপ সিমুলেট করে গোল্ডেন-সিগন্যাল থ্রেশহোল্ডের ভিত্তিতে স্বাস্থ্য রিপোর্ট তৈরি করা

১ · মেট্রিক্স কী

মেট্রিক্সMetricsসময়ের সাথে সংগৃহীত সংখ্যাগত পরিমাপ (CPU ব্যবহার, রিকোয়েস্ট সংখ্যা, এরর রেট, লেটেন্সি) — টাইম-সিরিজ ডেটা হিসেবে সংরক্ষিত ও ড্যাশবোর্ডে ভিজুয়ালাইজড। হলো যেকোনো সিস্টেমের স্বাস্থ্য ও আচরণ বোঝার মৌলিক একক — CPU ব্যবহার, মেমরি ব্যবহার, প্রতি সেকেন্ডে রিকোয়েস্ট সংখ্যা, এরর রেট, রেসপন্স লেটেন্সি ইত্যাদি সংখ্যাগত মান নিয়মিত বিরতিতে সংগ্রহ করে টাইম-সিরিজ হিসেবে সংরক্ষণ করা হয় — এর ফলে সময়ের সাথে ট্রেন্ড দেখা যায় (যেমন "গত এক ঘণ্টায় লেটেন্সি ধীরে ধীরে বাড়ছে") এবং ড্যাশবোর্ডে গ্রাফ আকারে ভিজুয়ালাইজ করা যায়।

২ · পুল-বেসড বনাম পুশ-বেসড মেট্রিক্স সংগ্রহ

মেট্রিক্স সংগ্রহের দুটি প্রধান মডেল আছে —

  • পুল-বেসড (Prometheus-স্টাইল) — একটি কেন্দ্রীয় মনিটরিং সিস্টেম পর্যায়ক্রমে প্রতিটি সার্ভিসের একটি নির্দিষ্ট এন্ডপয়েন্ট থেকে বর্তমান মেট্রিক্স মান "স্ক্র্যাপ" (টেনে নেয়)। সুবিধা: একটি সার্ভিস থেকে কোনো রেসপন্স না এলে সহজেই বোঝা যায় সেটি ডাউন — স্বাস্থ্য-যাচাইয়ের যুক্তি সহজ।
  • পুশ-বেসড — প্রতিটি সার্ভিস নিজে থেকে সক্রিয়ভাবে তার মেট্রিক্স একটি কেন্দ্রীয় কালেক্টরে পাঠায়। সুবিধা: এমন সংক্ষিপ্ত-জীবনকালীন ওয়ার্কলোডের (যেমন কিছু সার্ভারলেস ফাংশন, ties to M11) জন্য ভালো কাজ করে যেগুলো স্ক্র্যাপ করার মতো যথেষ্ট সময় ধরে নাও চলতে পারে।
কোনটি কখন

পুল-বেসড পদ্ধতিতে কালেক্টরকে আগে থেকেই জানতে হয় ঠিক কোন কোন টার্গেট স্ক্র্যাপ করতে হবে — দীর্ঘস্থায়ী, সবসময়-চলমান সার্ভিসের (VM, কন্টেইনার, Kubernetes পড) জন্য এটি স্বাভাবিক ফিট। পুশ-বেসড পদ্ধতিতে সার্ভিসকেই সক্রিয়ভাবে রিপোর্ট করতে হয়, তাই স্বল্পস্থায়ী বা অনিয়মিতভাবে চালু হওয়া ওয়ার্কলোডের জন্য এটি বেশি উপযুক্ত।

৩ · চারটি গোল্ডেন সিগন্যাল

যেকোনো সার্ভিসের জন্য সবচেয়ে গুরুত্বপূর্ণ চারটি মেট্রিক্স, সাধারণভাবে "গোল্ডেন সিগন্যাল" নামে পরিচিত —

লেটেন্সি (Latency)
একটি রিকোয়েস্ট প্রসেস করতে কত সময় লাগছে।
ট্রাফিক (Traffic)
প্রতি সেকেন্ডে কতগুলো রিকোয়েস্ট আসছে (রিকোয়েস্ট রেট)।
এরর (Errors)
কত শতাংশ রিকোয়েস্ট ব্যর্থ হচ্ছে (৫xx রেসপন্স ইত্যাদি)।
স্যাচুরেশন (Saturation)
একটি রিসোর্স (CPU, মেমরি) কতটা "পূর্ণ" — সীমার কতটা কাছাকাছি।
Python
# পুল-বেসড মেট্রিক্স স্ক্র্যাপ ও গোল্ডেন-সিগন্যাল স্বাস্থ্য-চেক সিমুলেশন
# (fake in-memory সার্ভিস মেট্রিক্স — real Prometheus/এন্ডপয়েন্ট কল নয়)

services = {
    "order-service": {"latency_ms": 120, "error_rate_pct": 0.8, "cpu_saturation_pct": 55},
    "payment-service": {"latency_ms": 640, "error_rate_pct": 1.2, "cpu_saturation_pct": 70},
    "inventory-service": {"latency_ms": 90, "error_rate_pct": 7.5, "cpu_saturation_pct": 40},
    "notification-service": {"latency_ms": 310, "error_rate_pct": 0.3, "cpu_saturation_pct": 92},
}

def scrape_all(services_registry):
    # প্রতিটি সার্ভিসের বর্তমান মেট্রিক্স স্ন্যাপশট সংগ্রহ করা (পুল-বেসড স্ক্র্যাপ সিমুলেশন)
    return {name: dict(metrics) for name, metrics in services_registry.items()}

def evaluate_health(metrics, latency_threshold_ms=500, error_threshold_pct=5, saturation_threshold_pct=85):
    problems = []
    if metrics["latency_ms"] > latency_threshold_ms:
        problems.append(f"উচ্চ লেটেন্সি ({metrics['latency_ms']}ms > {latency_threshold_ms}ms)")
    if metrics["error_rate_pct"] > error_threshold_pct:
        problems.append(f"উচ্চ এরর রেট ({metrics['error_rate_pct']}% > {error_threshold_pct}%)")
    if metrics["cpu_saturation_pct"] > saturation_threshold_pct:
        problems.append(f"উচ্চ CPU স্যাচুরেশন ({metrics['cpu_saturation_pct']}% > {saturation_threshold_pct}%)")
    return problems

snapshot = scrape_all(services)

print("স্বাস্থ্য রিপোর্ট —")
for service_name, metrics in snapshot.items():
    problems = evaluate_health(metrics)
    status = "UNHEALTHY" if problems else "HEALTHY"
    print(f"\n{service_name}: {status}")
    print(f"  মেট্রিক্স: {metrics}")
    if problems:
        for p in problems:
            print(f"  - {p}")

    
লক্ষ্য করুন payment-service-এর লেটেন্সি (৬৪০ms) থ্রেশহোল্ড (৫০০ms) পার করে যাওয়ায় সেটি UNHEALTHY হিসেবে চিহ্নিত হয়, inventory-service-এর এরর রেট (৭.৫%) থ্রেশহোল্ড (৫%) পার করায় সেটিও UNHEALTHY, এবং notification-service-এর CPU স্যাচুরেশন (৯২%) থ্রেশহোল্ড (৮৫%) পার করায় সেটিও UNHEALTHY — অথচ order-service সব থ্রেশহোল্ডের মধ্যে থাকায় HEALTHY। এই চারটি সিগন্যাল একসাথে দেখলে একটি সার্ভিসের সমস্যার ধরন (ধীর? ব্যর্থ? রিসোর্স-সীমাবদ্ধ?) দ্রুত বোঝা যায়।
মূল কথা · Key takeaway

মেট্রিক্স হলো "সিস্টেম কেমন করছে" তার সংখ্যাগত প্রমাণ — গোল্ডেন সিগন্যালের মতো একটি সাধারণ কাঠামো যেকোনো নতুন সার্ভিসের জন্যও দ্রুত একটি অর্থপূর্ণ স্বাস্থ্য-চেক তৈরি করতে সাহায্য করে। কিন্তু মেট্রিক্স একাই সম্পূর্ণ ছবি দেয় না — L42-এ আমরা দেখব লগ কীভাবে একক ইভেন্টের বিস্তারিত প্রসঙ্গ যোগ করে, এবং L43-এ ট্রেসিং কীভাবে একটি নির্দিষ্ট রিকোয়েস্টের সম্পূর্ণ যাত্রা দেখায়।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ পুল-বেসড মনিটরিং-এ "একটি সার্ভিস থেকে কোনো রেসপন্স না আসা মানেই সেটি ডাউন" — এই ধারণাটি একটি সার্ভারলেস ফাংশনের ক্ষেত্রে (M11) কেন সমস্যাজনক হতে পারে?

একটি সার্ভারলেস ফাংশন সাধারণত শুধু কোনো ইভেন্টে সাড়া দেওয়ার সময়ই চলে, তারপর সম্পূর্ণভাবে বন্ধ হয়ে যায় (কোনো "সবসময় চলমান" এন্ডপয়েন্ট থাকে না যা স্ক্র্যাপ করা যায়) — তাই স্ক্র্যাপ করার চেষ্টা করলে "রেসপন্স নেই" পাওয়া যাবে, যদিও ফাংশনটি সম্পূর্ণ স্বাভাবিকভাবেই কাজ করছে (শুধু এখন idle)। এই কারণেই এই ধরনের স্বল্পস্থায়ী ওয়ার্কলোডের জন্য পুশ-বেসড মডেল (ফাংশন নিজেই তার ইনভোকেশনের সময় মেট্রিক্স পাঠিয়ে দেয়) বেশি অর্থপূর্ণ।

প্র ০২ শুধু গড় (average) লেটেন্সি মনিটর করা কেন প্রায়ই বিভ্রান্তিকর, এবং পার্সেন্টাইল (যেমন p95, p99) কেন বেশি ব্যবহৃত হয়?

গড় লেটেন্সি একটি ছোট সংখ্যক অত্যন্ত ধীর রিকোয়েস্ট দ্বারা "গড়ে মিলিয়ে" লুকিয়ে যেতে পারে — যেমন ৯৯টি রিকোয়েস্ট ৫০ms-এ শেষ হলেও যদি ১টি রিকোয়েস্ট ৫০০০ms নেয়, তাহলে গড় তুলনামূলক কম দেখাবে, অথচ বাস্তবে কিছু ইউজার ভয়াবহ ধীর অভিজ্ঞতা পাচ্ছে। p95/p99 (৯৫% বা ৯৯% রিকোয়েস্ট এই সময়ের মধ্যে বা তার কম সময়ে শেষ হয়) সেই "সবচেয়ে খারাপ অভিজ্ঞতা পাওয়া" ইউজারদের সংখ্যা সরাসরি দেখায়, যা ব্যবহারিক অভিজ্ঞতার আরও সত্যি প্রতিফলন দেয়।

প্র ০৩ উপরের কোডে যদি evaluate_health ফাংশনে error_threshold_pct-এর মান 5-এর বদলে 10 করা হয়, তাহলে inventory-service-এর স্ট্যাটাস কী হবে?

inventory-service-এর error_rate_pct হলো ৭.৫%, যা নতুন থ্রেশহোল্ড ১০%-এর কম — তাই সেই নির্দিষ্ট চেকটি আর সমস্যা হিসেবে ধরা পড়বে না, এবং যেহেতু তার লেটেন্সি ও CPU স্যাচুরেশনও তাদের নিজ নিজ থ্রেশহোল্ডের মধ্যে আছে, সেই সার্ভিসটি এখন HEALTHY হিসেবে রিপোর্ট হবে — এটি দেখায় থ্রেশহোল্ড বেছে নেওয়া কতটা গুরুত্বপূর্ণ, কারণ খুব ঢিলা থ্রেশহোল্ড প্রকৃত সমস্যা মিস করতে পারে।

অনুশীলন

  1. পরীক্ষা করুন: উপরের কোড সেলে services dict-এ একটি নতুন সার্ভিস "auth-service" যোগ করুন যার মেট্রিক্স সব থ্রেশহোল্ডের ঠিক নিচে (যেমন latency_ms=200, error_rate_pct=1.0, cpu_saturation_pct=60), তারপর সম্পূর্ণ স্বাস্থ্য রিপোর্ট আবার চালান।

    নতুন সার্ভিসটি প্রিন্ট আউটে যুক্ত হবে এবং যেহেতু এর সব মেট্রিক্স নির্ধারিত থ্রেশহোল্ডের নিচে (৫০০ms, ৫%, ৮৫%), evaluate_health ফাংশন কোনো problems খুঁজে পাবে না, তাই এটি HEALTHY হিসেবে রিপোর্ট হবে — নিশ্চিত করে ফাংশনটি যেকোনো নতুন সার্ভিসের জন্যও সঠিকভাবে সাধারণীকরণ (generalize) করে।

  2. চিন্তা করুন: আপনার ব্যবহৃত কোনো অ্যাপ্লিকেশন (ওয়েবসাইট, মোবাইল অ্যাপ) কল্পনা করুন — এর জন্য চারটি গোল্ডেন সিগন্যাল বাস্তবে কী কী নির্দিষ্ট মেট্রিক্স দিয়ে পরিমাপ করা যেতে পারে?

    উদাহরণ: একটি ই-কমার্স ওয়েবসাইটের জন্য — লেটেন্সি: পেজ লোড টাইম বা চেকআউট API রেসপন্স টাইম; ট্রাফিক: প্রতি মিনিটে পেজ ভিউ বা অর্ডার সংখ্যা; এরর: ব্যর্থ চেকআউট বা পেমেন্ট ব্যর্থতার শতাংশ; স্যাচুরেশন: ডেটাবেস কানেকশন পুলের ব্যবহার শতাংশ বা সার্ভার CPU/মেমরি ব্যবহার — এই সুনির্দিষ্ট ম্যাপিং দেখায় কীভাবে সাধারণ কাঠামো যেকোনো নির্দিষ্ট সিস্টেমে প্রয়োগ করা যায়।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

পূর্ববর্তী পাঠ
L40 · সিক্রেট ম্যানেজমেন্ট ইন DevOps