Monitoring-এর গোড়া: metrics, Prometheus, Grafana ও alert

Monitoring মানে সময়ের সাথে আপনার সিস্টেম সম্পর্কে সংখ্যা জমানো, dashboard-এ দেখানো এবং কিছু ভুল হলে জানানো। এটি না থাকলে বিভ্রাটের কথা আপনি জানেন ব্যবহারকারীর কাছ থেকে।

কী মাপবেন

শুরুর কাজের সেট হলো Google-এর SRE বইয়ের চার golden signal:

• Latency: request নিতে কত সময় লাগে (শুধু গড় নয়, p95 ও p99-এর মতো ধীর শতকরা দেখুন)।
• Traffic: প্রতি সেকেন্ডে কত request।
• Error: ব্যর্থ request-এর হার।
• Saturation: resource কতটা ভরা (CPU, memory, disk, connection)।

Server-এ আরও দেখুন disk space, memory, load, এবং মূল service ও certificate চালু আছে কি না ও মেয়াদ শেষের কাছাকাছি কি না।

Metrics, log ও trace

• Metrics: সময়ের সাথে সংখ্যা। সস্তা, প্রবণতা ও alert-এর জন্য ভালো।
• Log: বিস্তারিত event। কেন হলো খুঁজতে ভালো।
• Trace: একাধিক service জুড়ে একটি request-এর পথ।

Metrics দিয়ে শুরু করুন, দরকার হলে বাকিগুলো যোগ করুন।

Prometheus ও Grafana কীভাবে মেলে

• Prometheus একটি time-series database যা নিয়মিত বিরতিতে HTTP endpoint (সাধারণত /metrics) থেকে metrics টেনে আনে (scrape)। এটি সংরক্ষণ করে ও alert rule যাচাই করে।
• Exporter যারা নিজে metrics দেয় না তাদের জন্য তা প্রকাশ করে। node_exporter Linux মেশিনের metrics দেয়।
• Grafana Prometheus থেকে পড়ে dashboard আঁকে।
• Alertmanager Prometheus-এর alert নিয়ে দল করে email, Slack বা অন্য চ্যানেলে পাঠায়।

ছোট Prometheus config

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ["localhost:9100"]
  - job_name: myapp
    static_configs:
      - targets: ["localhost:3000"]

Port 9100-এ node_exporter চালান, Prometheus-কে তার দিকে নির্দেশ করুন, Grafana-য় Prometheus data source যোগ করুন এবং তৈরি node dashboard import করুন।

অ্যাপ থেকে metrics প্রকাশ

বেশিরভাগ ভাষায় Prometheus client library আছে। /metrics-এ counter (request, error) ও histogram (request-এর সময়) প্রকাশ করুন।

এই endpoint ব্যক্তিগত রাখুন: localhost বা অভ্যন্তরীণ network-এ bind করুন বা সুরক্ষিত করুন, কারণ এটি ভেতরের তথ্য ফাঁস করতে পারে।

কাজের alert

কোনো target ২ মিনিট বন্ধ থাকলে জ্বলে ওঠা rule-এর উদাহরণ:

groups:
  - name: basics
    rules:
      - alert: InstanceDown
        expr: up == 0
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "{{ $labels.job }} is down"

প্রথমে ভালো alert: service বন্ধ, disk প্রায় ভরা, বেশি error হার, certificate শিগগির শেষ, এবং চলেনি এমন backup।

Alert-এর ক্লান্তি এড়ান

• প্রতিটি ছোট কারণে নয়, ব্যবহারকারী যা অনুভব করে (error, ধীরতা) তাতে alert দিন।
• ছোট spike যাতে না জাগায় সেজন্য for: ব্যবহার করুন।
• প্রতিটি alert করণীয় হতে হবে। কারও কিছু করার না থাকলে সেটি dashboard panel বানান।
• জরুরি page আর কম অগ্রাধিকারের ticket আলাদা করুন।
• বিরক্তিকর alert নিয়মিত পর্যালোচনা করে মুছুন।

ভুলবেন না

• বাইরে থেকেও monitor করুন (uptime check), কারণ মৃত server নিজের খবর দিতে পারে না।
• Grafana ও Prometheus login ও HTTPS দিয়ে সুরক্ষিত করুন, ইন্টারনেটে খোলা রাখবেন না।
• Retention ঠিক করুন যাতে metrics disk ভরে না ফেলে।
• প্রতিটি alert-এর জন্য ছোট runbook রাখুন: এর মানে কী ও প্রথমে কী করবেন।

মূল কথা: latency, traffic, error ও saturation মাপুন, Prometheus scrape করুক ও Grafana দেখাক, শুধু যেখানে মানুষকে কাজ করতে হবে সেখানে alert দিন, এবং বাইরে থেকেও সাইট যাচাই করুন।

---

Linux ও DevOps সিরিজ, পর্ব ২ (delivery ও পরিচালনা): 3 নম্বর (মোট 5)। আগের লেখা: GitHub Actions দিয়ে CI/CD: নিরাপদে test, build ও deploy.