Uptime Kuma দিয়ে সার্ভার মনিটরিং করার নিয়ম

আপনি যা তৈরি করছেন

একটি ছোট কন্টেইনার যা বাইরে থেকে আপনার অন্যান্য সার্ভার এবং ওয়েবসাইটগুলোর ওপর নজর রাখবে। কোনো একটি সার্ভার সাড়া দেওয়া বন্ধ করলেই এটি আপনাকে ইমেইল, Telegram, Discord বা webhook-এর মাধ্যমে জানিয়ে দেবে। Uptime Kuma একটি Node প্রসেস যা SQLite ফাইল ব্যবহার করে, তাই এটি 256-512 MB RAM-এ অনায়াসেই চলে। এটি আপনাকে একটি লাইভ ড্যাশবোর্ড, হিস্ট্রি গ্রাফ এবং একটি পাবলিক স্ট্যাটাস পেজ প্রদান করে। এর ইনস্টলেশন প্রক্রিয়াটি মাত্র দশ লাইনের একটি Compose ফাইল; তবে আসল গুরুত্বপূর্ণ বিষয় হলো আপনি এটি কোথায় চালাচ্ছেন এবং আপনার অ্যালার্টগুলো কোনো টেস্টে কাজ করেছে কি না। কারণ যে মনিটরিং সিস্টেম আপনি পরীক্ষা করেননি, সেটি না থাকাই ভালো: কারণ এটি আপনাকে সুরক্ষিত থাকার মিথ্যা অনুভূতি দেয়, অথচ বাস্তবে কোনো কিছুর ওপর নজর রাখছে না।

মনিটরটিকে এমন জায়গায় চালান যেখানে বিভ্রাট পৌঁছাতে পারবে না

এই একটি সিদ্ধান্তই পুরো বিষয়টি সফল বা ব্যর্থ করে দেয়, তাই এটি সবার আগে আসা উচিত। Uptime Kuma-কে সেই বক্সে চালাবেন না যেটিকে এটি পর্যবেক্ষণ করছে। যদি মনিটরটি সেই সার্ভারেই থাকে যেটিকে সে পর্যবেক্ষণ করছে, তবে যে ঘটনার জন্য আপনি চিন্তিত—যেমন বক্সটি বন্ধ হয়ে যাওয়া বা মেমোরি শেষ হয়ে যাওয়া—তা মনিটরটিকেও অকেজো করে দেবে এবং আপনি কোনো সতর্কবার্তা পাবেন না: একটি মৃত মনিটরের নীরবতা আর "সবকিছু ঠিক আছে" এই বার্তার মধ্যে কোনো পার্থক্য থাকে না। বক্সটি চালু থাকা অবস্থায়ও একটি সূক্ষ্ম ফাঁদ রয়েছে: localhost-এর দিকে নির্দেশ করা একটি মনিটর তার ওয়ার্কলোডের সাথে CPU শেয়ার করে, তাই লোড বেড়ে গেলে মনিটরের নিজস্ব চেক টাইম-আউট হয়ে যায় এবং টার্গেটকে down হিসেবে দেখায়। এটি একটি ভুল অ্যালার্ম, অথচ প্রকৃত ব্যবহারকারীরা তখনো পরিষেবাটি ঠিকঠাক পাচ্ছেন।

তাই Uptime Kuma-কে এমন একটি ভিন্ন VPS-এ চালান যেটিকে সে পর্যবেক্ষণ করছে না। আদর্শগতভাবে এটি ভিন্ন কোনো প্রোভাইডার বা অঞ্চলের হওয়া উচিত, যা আপনার ব্যবহারকারীরা যেভাবে পরিষেবা ব্যবহার করে সেভাবেই অর্থাৎ পাবলিক ইন্টারনেটের মাধ্যমে হোস্টনাম ব্যবহার করে কানেক্ট করবে। একটি সস্তা ইনস্ট্যান্সই যথেষ্ট এবং একটি ছোট মনিটরিং VPS আপনার সমস্ত সার্ভার পর্যবেক্ষণ করতে পারে। ভারী অ্যাপগুলোর ক্ষেত্রে এই বিচ্ছিন্নতা সবচেয়ে বেশি গুরুত্বপূর্ণ, কারণ PhotoPrism বা Immich ফটো লাইব্রেরির মতো কোনো অ্যাপ নতুন ইমপোর্ট ইনডেক্স করার সময় ঘণ্টার পর ঘণ্টা CPU দখল করে রাখতে পারে। সেক্ষেত্রে একই হার্ডওয়্যার শেয়ার করা মনিটরটি এমন একটি পরিষেবাকে ডাউন হিসেবে দেখাবে যা আসলে কেবল ব্যস্ত। Kuma নিজেই ডাউন হয়েছে কি না তা নিশ্চিত করতে, অন্য কোথাও থেকে একটি cron-এর মাধ্যমে push heartbeat যোগ করুন।

পূর্বশর্ত এবং সাইজিং

• একটি নতুন Ubuntu 24.04 VPS যেখানে Docker Engine এবং Compose v2 plugin ইনস্টল করা থাকতে হবে। এটি অবশ্যই Docker-এর নিজস্ব apt repository থেকে ইনস্টল করবেন, docker.io ডিস্ট্রো প্যাকেজ থেকে নয়, কারণ সেটির ভার্সন পুরনো হয়।
• 256 MB RAM-এ অল্প কিছু মনিটর চালানো সম্ভব; তবে ডজনখানেক মনিটর এবং reverse proxy-র জন্য 512 MB থেকে 1 GB RAM রাখা সুবিধাজনক। চেক করার মধ্যবর্তী সময়ে CPU প্রায় অলস অবস্থায় থাকে।
• একটি ডোমেইন এবং একটি DNS A রেকর্ড (যেমন status.example.com যা VPS-কে নির্দেশ করে), এটি শুধুমাত্র তখনই প্রয়োজন যদি আপনি TLS এবং পাবলিক স্ট্যাটাস পেজ ব্যবহার করতে চান। ব্যক্তিগত ব্যবহারের ক্ষেত্রে DNS এড়িয়ে VPN বা SSH tunnel ব্যবহার করা যেতে পারে।
• অ্যালার্ট পাঠানোর জন্য আউটবাউন্ড নেটওয়ার্ক সংযোগ: আপনার মেইল প্রোভাইডারের জন্য SMTP, অথবা Telegram এবং Discord-এর জন্য HTTPS সংযোগ।

Compose ফাইল

এটি /srv/uptime-kuma/compose.yaml-এ রাখুন।

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

এটি চালু করুন এবং প্রথম বুট পর্যবেক্ষণ করুন:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

সঠিকভাবে শুরু হলে এটি Listening on 3001 লগ করবে এবং শান্ত হয়ে যাবে। এই ফাইলে তিনটি বিষয় ইচ্ছাকৃতভাবে রাখা হয়েছে।

127.0.0.1:3001:3001, 3001:3001 নয়। Docker পোর্টগুলোকে DNAT রুল দিয়ে পাবলিশ করে যা ufw প্যাকেট দেখার আগেই কার্যকর হয়, তাই সরাসরি 3001:3001 ব্যবহার করলে আপনার ফায়ারওয়াল থাকা সত্ত্বেও ড্যাশবোর্ডটি পাবলিক ইন্টারনেটে উন্মুক্ত হয়ে যাবে। লুপব্যাকে বাইন্ড করলে এটি ব্যক্তিগত থাকে এবং শুধুমাত্র রিভার্স প্রক্সি উন্মুক্ত থাকে; একটি প্রাইভেট ইনস্ট্যান্স প্রক্সি এড়িয়ে একটি self-hosted WireGuard VPN-এর মাধ্যমে 3001-এ পৌঁছাতে পারে।

/app/data-এ একটি named volume। Uptime Kuma যা কিছু মনে রাখে, যেমন SQLite ডাটাবেস, আপনার মনিটর, নোটিফিকেশন সেটিংস এবং স্ট্যাটাস-পেজের লোগো, সবকিছু এখানেই থাকে। এটি হারিয়ে ফেললে আপনি একটি খালি অ্যাডমিন স্ক্রিন পাবেন; এটিই একমাত্র জিনিস যা আপনার ব্যাকআপ রাখা উচিত।

ইমেজটি একটি মেজর ট্যাগের সাথে পিন করা, :2। এটি বর্তমান স্টেবল লাইন; কপি করার আগে Docker Hub-এ নতুন মেজর ভার্সন চেক করুন এবং কখনোই latest-এর মতো পরিবর্তনশীল ট্যাগ ট্র্যাক করবেন না, যা প্রজেক্টটি নিরুৎসাহিত করে। এই ইমেজে মেজর-ভার্সন জাম্প একটি ওয়ান-ওয়ে ডাটাবেস মাইগ্রেশন, যা আপনি ইচ্ছাকৃতভাবে করতে চাইবেন, রুটিন পুলের সময় হঠাৎ করে নয়।

একটি সতর্কতা: /app/data অবশ্যই POSIX ফাইল লক সমর্থন করে এমন ফাইলসিস্টেমে থাকতে হবে। লোকাল Docker ভলিউম ঠিক আছে; NFS-এ SQLite ডাটাবেস করাপ্ট হয়ে যায় এবং আপনি SQLITE_BUSY ও database disk image is malformed এর মতো ত্রুটি পাবেন, তাই কখনোই নেটওয়ার্ক শেয়ার ব্যবহার করবেন না।

প্রথমবার চালানো: অ্যাডমিন অ্যাকাউন্ট তৈরি করুন

আপনার প্রক্সির মাধ্যমে https://status.example.com ঠিকানায় অথবা SSH টানেলের মাধ্যমে ইনস্ট্যান্সটি ব্রাউজ করুন: ssh -L 3001:127.0.0.1:3001 user@your-vps কমান্ডটি চালান এবং http://localhost:3001 খুলুন। প্রথম পৃষ্ঠায় অ্যাডমিনিস্ট্রেটর ইউজারনেম এবং পাসওয়ার্ড সেটআপ করার একটি ফর্ম থাকবে; এখানে কোনো ডিফল্ট লগইন নেই। একটি শক্তিশালী পাসওয়ার্ড নির্বাচন করুন: এই ড্যাশবোর্ডটি আপনার মনিটর করা সমস্ত কিছুর অভ্যন্তরীণ ঠিকানা এবং টোকেন দেখতে পায়। পরবর্তীতে পাসওয়ার্ড ভুলে গেলে ব্রাউজার থেকে নয়, বরং হোস্ট থেকে রিসেট করুন:

sudo docker compose exec uptime-kuma npm run reset-password

প্রথমে আপনার নোটিফিকেশন চ্যানেলগুলো যোগ করুন এবং সেগুলো পরীক্ষা করুন

মনিটর যোগ করার আগেই অ্যালার্ট সেটআপ করুন, যাতে প্রতিটি মনিটর তৈরির সময় আপনি একটি চ্যানেল যুক্ত করতে পারেন। Settings থেকে Notifications এবং তারপর Setup Notification-এ যান। প্রতিটি চ্যানেলের Test বাটন ব্যবহার করে নিশ্চিত করুন যে বার্তাটি সঠিকভাবে পৌঁছাচ্ছে, কারণ পরীক্ষা না করা নোটিফিকেশন সেটআপ ব্যর্থ হওয়ার দ্বিতীয় প্রধান কারণ।

Email (SMTP)। host, port, encryption, username, password, একটি From এবং একটি To ঠিকানা পূরণ করুন। দুটি কার্যকর কম্বিনেশন হলো TLS/SSL-এ "Secure" সেট করা 465 অথবা STARTTLS সহ 587। Gmail এবং টু-ফ্যাক্টর অথেন্টিকেশন থাকা অধিকাংশ প্রোভাইডারের ক্ষেত্রে আপনাকে একটি app password তৈরি করতে হবে; সাধারণ অ্যাকাউন্টের পাসওয়ার্ড ব্যবহার করলে Error: Invalid login: 535-5.7.8 Username and Password not accepted ত্রুটি দেখাবে।

Telegram। @BotFather-কে মেসেজ দিন, /newbot পাঠান এবং বট টোকেনটি কপি করুন। আপনার chat ID-এর জন্য, নতুন বটটিকে একবার মেসেজ দিন, https://api.telegram.org/bot<token>/getUpdates খুলুন এবং JSON থেকে chat.id পড়ুন। যে বটকে আপনি আগে মেসেজ দেননি, তার getUpdates খালি থাকে এবং সেখানে কোনো বার্তা পাঠানো সম্ভব নয়।

Discord। চ্যানেলে গিয়ে Edit Channel থেকে Integrations, তারপর Webhooks এবং New Webhook খুলুন। URL-টি কপি করুন এবং Discord নোটিফিকেশন হিসেবে পেস্ট করুন।

Generic webhook। অন্য যেকোনো কিছুর জন্য, যেমন Slack incoming webhook, কাস্টম এন্ডপয়েন্ট বা হোম-অটোমেশন হুক, Webhook টাইপটি আপনার দেওয়া URL-এ একটি JSON পেলোড POST করে। এছাড়া, অন্তর্ভুক্ত Apprise ইন্টিগ্রেশন তালিকার অন্যান্য নব্বইটিরও বেশি সার্ভিস সমর্থন করে। যদি আপনি চান যে কোনো তৃতীয় পক্ষ আপনার আউটেজ এবং ফোনের মাঝে না থাকুক, তবে বিল্ট-ইন ntfy টাইপটি বেছে নিন এবং সেটিকে আপনার নিজের চালানো একটি ntfy সার্ভার-এর দিকে নির্দেশ করুন। এটি আপনার নিয়ন্ত্রণাধীন একটি চ্যানেলের মাধ্যমে সরাসরি আপনার হ্যান্ডসেটে পুশ নোটিফিকেশন পাঠাবে।

একবারে একটি করে মনিটর যোগ করুন

Add New Monitor-এ ক্লিক করুন, একটি ধরন নির্বাচন করুন এবং Friendly Name, Check Interval (60 সেকেন্ড একটি যুক্তিসঙ্গত সময়), Retries ("down" হিসেবে গণ্য করার আগে পরপর ব্যর্থতার সংখ্যা; 2 বা 3 সেট করুন যাতে একটি প্যাকেট ড্রপ হলেই অ্যালার্ট না আসে), এবং কোন নোটিফিকেশনগুলো পাঠানো হবে তা নির্ধারণ করুন। যে ধরনগুলো আপনি ব্যবহার করবেন:

• HTTP(s). একটি পূর্ণাঙ্গ URL। সার্ভার থেকে গ্রহণযোগ্য স্ট্যাটাস কোড (ডিফল্টভাবে 200-299) আসলে এটি "up" হিসেবে গণ্য হয়; যদি আপনার ক্ষেত্রে 301 বা 401 স্বাভাবিক হয়, তবে Accepted Status Codes-এর অধীনে তা বাড়িয়ে নিন। ওয়েবসাইট এবং API-এর জন্য এটিই আপনার প্রধান হাতিয়ার।
• HTTP(s) - Keyword. একই অনুরোধ, তবে "up" হওয়ার জন্য রেসপন্স বডিতে নির্দিষ্ট কোনো স্ট্রিং থাকা আবশ্যক (অথবা Invert অপশন ব্যবহার করলে অনুপস্থিত থাকা আবশ্যক)। এটি সেই পরিস্থিতি শনাক্ত করে যখন সাইট 200 OK স্ট্যাটাস কোড দেয় কিন্তু বডিতে "Error establishing a database connection" লেখা থাকে, যা সাধারণ HTTP চেক স্বাস্থ্যকর হিসেবে গণ্য করে। ব্রাউজার ফ্রন্ট-এন্ডের সাথে আলাদা ব্যাক-এন্ড যুক্ত থাকলে এটি সঠিক চেক; যেমন Jellyfin-এর ওপর Halcyon ভিডিও-স্টোর স্কিন, যার পেজ শেল সফলভাবে 200 রেসপন্স দিলেও পেছনের মিডিয়া সার্ভারটি নাগালের বাইরে থাকতে পারে।
• TCP Port. HTTP নয় এমন সার্ভিসের জন্য কোনো হোস্ট ও পোর্টে সরাসরি TCP কানেকশন; যেমন 22 পোর্টে SSH, 5432 পোর্টে Postgres, 25 পোর্টে SMTP সার্ভার বা কোনো গেম সার্ভার।
• Ping. ICMP ইকো: এটি রিচেবিলিটি এবং ল্যাটেন্সি পরীক্ষার একটি সাশ্রয়ী উপায়। তবে অনেক নেটওয়ার্ক এবং ক্লাউড ফায়ারওয়াল ICMP ড্রপ করে, তাই একটি রেড পিং মনিটরের অর্থ "হোস্ট ডাউন" অথবা "প্রোভাইডার পিং ব্লক করেছে" হতে পারে; সেক্ষেত্রে TCP মনিটর দিয়ে নিশ্চিত হয়ে নিন।
• DNS. আপনার নির্দিষ্ট করা রেজলভারের বিপরীতে একটি রেকর্ড (A, AAAA, MX, TXT ইত্যাদি) রেজলভ করে এবং উত্তরের সত্যতা যাচাই করে, যা রেজিস্ট্রার বা DNS বিভ্রাট দ্রুত শনাক্ত করতে সাহায্য করে।
• Push. ইনসাইড-আউট মনিটর, যা পরবর্তী অংশে আলোচনা করা হয়েছে।

একটি push (heartbeat) মনিটরের মাধ্যমে cron job মনিটর করা

উপরের প্রতিটি মনিটর বাইরে থেকে আপনার সার্ভিসের ভেতরে প্রবেশ করে। একটি push মনিটর উল্টোভাবে কাজ করে: Uptime Kuma অপেক্ষা করে এবং আপনার জব নিজেই সেটিকে জানায় যে "আমি সফলভাবে সম্পন্ন হয়েছি।" ব্যাকআপ বা cron মনিটর করার এটিই একমাত্র নির্ভরযোগ্য উপায়: একটি HTTP চেক কেবল জানতে পারে যে URL-টি সাড়া দিচ্ছে কি না, কিন্তু শুধুমাত্র জবটিই জানে যে এটি সফলভাবে শেষ হয়েছে কি না।

Push টাইপের একটি মনিটর তৈরি করুন। Uptime Kuma একটি ইউনিক URL তৈরি করবে যা দেখতে অনেকটা এরকম:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

Heartbeat Interval-কে জবের চলার সময়ের সাথে সামান্য বাড়তি সময় যোগ করে সেট করুন। এরপর স্ক্রিপ্টের একদম শেষে একটি লাইন যোগ করুন, যাতে এটি শুধুমাত্র সফল হওয়ার পরেই কার্যকর হয়:

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

যদি জবটি ব্যর্থ হয়, তবে set -e কমান্ডটি curl-এর আগেই বন্ধ হয়ে যাবে; আর যদি সার্ভারটি ডাউন থাকে, তবে এটি কখনোই চলবে না। উভয় ক্ষেত্রেই heartbeat বন্ধ হয়ে যাবে এবং interval-এর সাথে অতিরিক্ত retry-এর সময় পার হওয়ার পর, Uptime Kuma মনিটরটিকে down হিসেবে চিহ্নিত করবে এবং আপনাকে সতর্ক করবে। এই push token-টিকে গোপন রাখুন: যার কাছে এটি থাকবে, সে চাইলে মিথ্যা heartbeat পাঠিয়ে সিস্টেমকে সচল দেখাতে পারবে।

একটি পাবলিক স্ট্যাটাস পেজ তৈরি করুন

স্ট্যাটাস পেজ হলো গ্রাহকদের জন্য দৃশ্যমান একটি ইন্টারফেস: এটি আপনার ড্যাশবোর্ড প্রকাশ না করেই কোন কোন সার্ভিস সচল আছে এবং তাদের সাম্প্রতিক ইতিহাস প্রদর্শন করে। Status Pages থেকে New Status Page-এ যান, একটি নাম এবং একটি স্লাগ (পাবলিক পাথ, যেমন /status/main) দিন, আপনার কাঙ্ক্ষিত মনিটরগুলোকে "Websites" বা "APIs"-এর মতো গ্রুপে ড্র্যাগ করুন, একটি লোগো ও সংক্ষিপ্ত বিবরণ যোগ করুন এবং Save করুন। আপনি চাইলে এই পেজটিকে নিজস্ব ডোমেইনের সাথে বাইন্ড করতে পারেন, যাতে status.example.com সরাসরি এটি পরিবেশন করে।

দুটি সতর্কতা: শুধুমাত্র সেই মনিটরগুলোই যোগ করুন যা আপনি প্রকাশ্যে দেখাতে ইচ্ছুক, কারণ একটি স্ট্যাটাস পেজ প্রকাশ করে যে একটি সার্ভিস বিদ্যমান আছে এবং সেটি সচল কি না; এছাড়া ড্যাশবোর্ড আপনার লগইন-এর আড়ালে সুরক্ষিত থাকে, কিন্তু স্ট্যাটাস পেজটি ইচ্ছাকৃতভাবেই পাবলিক এবং এতে কোনো অথেন্টিকেশনের প্রয়োজন হয় না।

একটি রিভার্স প্রক্সির পেছনে TLS সহ স্থাপন করুন এবং WebSocket-এর দিকে খেয়াল রাখুন

পাবলিক ইনস্ট্যান্সের জন্য, TLS এবং হোস্টনামের সুবিধার্থে লুপব্যাক-বাউন্ড কন্টেইনারের সামনে একটি রিভার্স প্রক্সি বসান। যে বিষয়টি সাধারণত সবার ভুল হয়: Uptime Kuma-এর UI একটি লাইভ Socket.IO অ্যাপ, তাই প্রক্সিকে অবশ্যই WebSocket কানেকশন আপগ্রেড করতে হবে। এটি না করলে পেজ লোড হবে কিন্তু কানেক্ট হবে না; ড্যাশবোর্ড "Connecting..." অবস্থায় আটকে থাকবে, লাইভ হার্টবিট আপডেট হবে না এবং ব্রাউজার কনসোলে WebSocket connection to 'wss://.../socket.io/...' failed দেখা যাবে।

nginx এবং certbot ইনস্টল করুন, তারপর লুপব্যাক পোর্টে প্রক্সি করার জন্য vhost লিখুন। আপাতত এটিকে পোর্ট 80-এ রাখুন এবং পরবর্তীতে certbot দিয়ে TLS যোগ করুন; চ্যালেঞ্জ, রিনিউয়াল টাইমার এবং এর ফেইলিয়র মোডগুলো issuing Let's Encrypt certificates with certbot and nginx-এ আলোচনা করা হয়েছে।

sudo apt install -y nginx certbot python3-certbot-nginx

এটিকে /etc/nginx/sites-available/status.example.com হিসেবে সেভ করুন; এখানে WebSocket-এর দুটি লাইনই সবচেয়ে গুরুত্বপূর্ণ:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

সাইটটি এনাবল করুন, কনফিগারেশন টেস্ট করুন, তারপর certbot-কে ব্লকটি রিরাইট করতে দিন যাতে এটি 443 পোর্টে লিসেন করে, সার্টিফিকেট যুক্ত করে এবং HTTP-থেকে-HTTPS রিডাইরেক্ট যোগ করে:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

Upgrade এবং Connection "upgrade" জোড়াটিই মূল বিষয়, এবং proxy_read_timeout 3600s নিশ্চিত করে যে nginx যেন দীর্ঘস্থায়ী সকেট কানেকশন বিচ্ছিন্ন না করে; certbot এই দুটি লাইনই তার তৈরি করা 443 ব্লকে কপি করে নেয়। আপনি যদি ইতিমধ্যে একটি প্রক্সির পেছনে একাধিক কন্টেইনার চালান, তবে routing them through Traefik with automatic TLS ব্যবহার করে কন্টেইনার লেবেলের মাধ্যমেই একই কাজ করা যায় এবং এটি ডিফল্টভাবেই WebSocket আপগ্রেড ফরওয়ার্ড করে।

পুরো vhost-এ basic-auth দেবেন না, কারণ এটি পাবলিক স্ট্যাটাস পেজ এবং /api/push এন্ডপয়েন্টকেও লক করে দেবে। Uptime Kuma-এর নিজস্ব লগইন সিস্টেম ব্যবহার করুন, যদি এটি ইন্টারনেটে উন্মুক্ত থাকে তবে fail2ban watching for repeated failed logins যোগ করুন, আর যদি ড্যাশবোর্ড পাবলিক করার প্রয়োজন না হয়, তবে প্রক্সি বাদ দিয়ে VPN-এর মাধ্যমে এটি অ্যাক্সেস করুন।

সার্টিফিকেটের মেয়াদ শেষ হওয়ার মনিটরিং, সঠিক পদ্ধতি

একটি HTTP(s) মনিটর TLS সার্টিফিকেটের মেয়াদ শেষ হওয়ার আগেই আপনাকে সতর্ক করতে পারে: Certificate Expiry Notification অপশনটি টিক দিন এবং Uptime Kuma নির্দিষ্ট সংখ্যক দিন আগে আপনাকে অ্যালার্ট পাঠাবে। দুটি ভুলের কারণে এটি ভুল তথ্য দেখাতে পারে। মনিটরিংয়ের জন্য IP নয়, hostname ব্যবহার করুন, কারণ SNI ছাড়া অনুরোধ পাঠালে সার্ভার তার ডিফল্ট সার্টিফিকেট প্রদান করে এবং আপনি Hostname/IP does not match certificate's altnames দেখতে পাবেন। এছাড়া, যে মনিটরের মাধ্যমে মেয়াদের সতর্কতা পেতে চান সেখানে Ignore TLS/SSL Error অপশনে টিক দেবেন না: এই টগলটি মূলত self-signed ইন্টারনাল হোস্টের জন্য (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT), কিন্তু এটি চালু থাকলে Uptime Kuma সার্টিফিকেটের মেয়াদসহ কোনো কিছুই যাচাই করে না।

ব্যাকআপ: এটি একটি ডিরেক্টরি

যেহেতু সবকিছু /app/data-এর মধ্যে থাকে, তাই কন্টেইনার বন্ধ থাকা অবস্থায় সেই ভলিউমের একটি কপি নেওয়াই হলো ব্যাকআপ। এতে SQLite ফাইলটি সামঞ্জস্যপূর্ণ (consistent) থাকে:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

প্রথমে docker volume ls | grep kuma ব্যবহার করে ভলিউমের আসল নাম নিশ্চিত করুন, কারণ Compose প্রজেক্ট ডিরেক্টরির নাম দিয়ে সেটির প্রিফিক্স তৈরি করে। এরপর tarball-টি সার্ভারের বাইরে কপি করুন, কারণ একই VPS-এ রাখা ফাইল ব্যাকআপ নয়, বরং একটি সাধারণ কপি মাত্র। রিস্টোর করার প্রক্রিয়াটি উল্টো: স্ট্যাকটি বন্ধ করুন, একটি খালি /app/data ভলিউমে ফাইলগুলো এক্সট্র্যাক্ট করুন এবং পুনরায় স্টার্ট করুন।

আপগ্রেড

আপগ্রেড করার অর্থ হলো নতুন ইমেজ পুল (pull) করা:

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

নতুন কন্টেইনারটি প্রথমবার চালু হওয়ার সময় যেকোনো ডাটাবেস মাইগ্রেশন সম্পন্ন করে; তাই docker compose logs -f মনিটর করুন। নতুন ইমেজ পুল করার আগে উপরের নির্দেশ অনুযায়ী ব্যাকআপ নিন এবং একই মেজর ট্যাগের (major tag) মধ্যে থাকুন: :1 থেকে :2-এ যাওয়া একটি ওয়ান-ওয়ে (one-way) মাইগ্রেশন, তাই আগে ব্যাকআপ নিন এবং রিলিজ নোটগুলো যাচাই করুন।

ব্যর্থতার ধরন এবং যে বার্তাগুলো আপনি দেখতে পাবেন

localhost-এ নির্দেশিত মনিটরে ভুল "down" বার্তা। মনিটরটি timeout of 48000ms exceeded বা connect ETIMEDOUT দেখিয়ে লাল হয়ে যায়, অথচ আপনার ল্যাপটপ থেকে সার্ভিসটি ঠিকঠাক সাড়া দিচ্ছে। যদি এটি সেই একই হোস্টকে লক্ষ্য করে যেখানে Uptime Kuma চলছে, তবে CPU বা মেমোরির অতিরিক্ত চাপের কারণে চেকটি সম্পন্ন হতে পারেনি, লক্ষ্যবস্তু সার্ভারের সমস্যা নয়। মনিটরটিকে একটি আলাদা VPS-এ সরিয়ে নিন এবং পাবলিক হোস্টনাম ব্যবহার করে চেক করুন।

connect ECONNREFUSED 127.0.0.1:443 (অথবা অন্য যেকোনো পোর্ট)। ওই পোর্টে কোনো সার্ভিস লিসেন করছে না: হয় সার্ভিসটি বন্ধ আছে, অথবা আপনি কন্টেইনারের ভেতর থেকে localhost মনিটর করছেন, যেখানে 127.0.0.1 মানে হলো কন্টেইনারটি নিজে, আপনার সার্ভার নয়। লুপব্যাক নয়, বরং পাবলিক হোস্টনাম মনিটর করুন।

ইমেইল টেস্টে Invalid login: 535-5.7.8 Username and Password not accepted। SMTP ক্রেডেনশিয়াল ভুল আছে, অথবা প্রোভাইডার আপনার অ্যাকাউন্টের পাসওয়ার্ডের পরিবর্তে একটি অ্যাপ-নির্দিষ্ট পাসওয়ার্ড (app-specific password) চাইছে। একটি অ্যাপ পাসওয়ার্ড তৈরি করে সেটি ব্যবহার করুন।

ইমেইল টেস্টে connect ETIMEDOUT বা queryA ETIMEDOUT <host>। ভুল পোর্ট ব্যবহার করা হয়েছে, অথবা প্রোভাইডার আউটবাউন্ড SMTP ব্লক করে রেখেছে। নিশ্চিত করুন যে 465 বা 587 সেটিংসটি Secure/STARTTLS-এর সাথে সামঞ্জস্যপূর্ণ এবং হোস্ট থেকে nc -vz smtp.example.com 587 ব্যবহার করে পরীক্ষা করুন। অনেক প্রোভাইডার আউটবাউন্ড 25 ব্লক করে রাখে এবং কিছু প্রোভাইডার অনুরোধ না করা পর্যন্ত সাবমিশন পোর্টগুলো বন্ধ রাখে।

ইমেইল টেস্টে self signed certificate বা unable to verify the first certificate। আপনার SMTP সার্ভার এমন একটি সার্টিফিকেট প্রদান করছে যা Node বিশ্বাস করছে না; এটি এড়িয়ে না গিয়ে মেইল সার্ভারের সার্টিফিকেট ঠিক করুন।

ড্যাশবোর্ড "Connecting..." অবস্থায় আটকে আছে, কনসোলে WebSocket connection ... failed দেখাচ্ছে। রিভার্স প্রক্সি WebSocket আপগ্রেড করছে না। Nginx-এ Upgrade এবং Connection "upgrade" হেডারগুলো যোগ করুন, অথবা এমন একটি প্রক্সি ব্যবহার করুন যা ডিফল্টভাবে এগুলো ফরওয়ার্ড করে, যেমন Traefik বা Caddy। HTML লোড হয় কারণ এটি একটি সাধারণ HTTP GET অনুরোধ; শুধুমাত্র লাইভ সকেটের জন্য আপগ্রেড প্রয়োজন।

সার্টিফিকেট মেয়াদের মনিটর সতর্কবার্তা দিচ্ছে না, অথবা ভুল সতর্কবার্তা দিচ্ছে। হয় Ignore TLS/SSL Error অপশনটি টিক দেওয়া আছে, যা সার্টিফিকেট চেকিং বন্ধ করে দেয়, অথবা মনিটরটি একটি IP-কে লক্ষ্য করছে এবং SNI না থাকায় ভুল সার্টিফিকেট পড়ছে, যা Hostname/IP does not match certificate's altnames দেখাচ্ছে। ইগনোর অপশনটি আনটিক করুন এবং হোস্টনাম ব্যবহার করে মনিটর করুন।

লগে SQLITE_BUSY বা database disk image is malformed। /app/data ভলিউমটি এমন একটি ফাইলসিস্টেমে আছে যেখানে সঠিক ফাইল লকিং নেই, সাধারণত এটি NFS-এর ক্ষেত্রে ঘটে; এটিকে লোকাল Docker ভলিউমে সরিয়ে নিন এবং ব্যাকআপ থেকে রিস্টোর করুন।

FAQ

আমার uptime monitor কোথায় চালানো উচিত?

আদর্শগতভাবে, যে সার্ভারগুলোকে এটি পর্যবেক্ষণ করবে, সেগুলোর থেকে আলাদা কোনো সার্ভারে বা অন্য কোনো অঞ্চলে এটি চালান। আপনার ব্যবহারকারীরা যেভাবে public internet-এর মাধ্যমে hostname ব্যবহার করে সার্ভারে পৌঁছায়, মনিটরকেও সেভাবেই পৌঁছাতে দিন। মনিটর যদি তার লক্ষ্যবস্তু সার্ভারের সাথেই থাকে, তবে সার্ভার ডাউন হলে মনিটরও অকেজো হয়ে যাবে। এছাড়া, হোস্ট সার্ভারে অতিরিক্ত চাপ থাকলে সেটি সুস্থ সার্ভিসগুলোকেও "down" হিসেবে দেখাতে পারে। একটি ছোট আলাদা VPS এই উভয় সমস্যাই সমাধান করে।

আমি কীভাবে Telegram বা email-এ alert পাব?

Settings থেকে Notifications-এ গিয়ে চ্যানেলটি যোগ করুন এবং প্রতিটি মনিটরের সাথে তা যুক্ত করুন। Telegram-এর জন্য @BotFather ব্যবহার করে একটি bot তৈরি করুন এবং https://api.telegram.org/bot<token>/getUpdates থেকে chat.id সংগ্রহ করুন। email-এর ক্ষেত্রে, আপনার প্রোভাইডার two-factor authentication ব্যবহার করলে SSL-এর জন্য 465 অথবা STARTTLS-এর জন্য 587 ব্যবহার করুন এবং একটি app password দিন। Test বাটনে চাপ দিন এবং নিশ্চিত করুন যে বার্তাটি পৌঁছেছে, এরপরই এর ওপর নির্ভর করুন।

Uptime Kuma কি cron job বা backup script পর্যবেক্ষণ করতে পারে?

হ্যাঁ, এটি Push মনিটরের মাধ্যমে সম্ভব: Uptime Kuma আপনাকে একটি URL দেবে, যা আপনি স্ক্রিপ্টের শেষে curl করবেন, যাতে এটি কেবল সফলভাবে সম্পন্ন হলেই কাজ করে। যদি job ব্যর্থ হয় বা সার্ভার ডাউন থাকে, তবে heartbeat পৌঁছাবে না এবং নির্দিষ্ট সময় পার হওয়ার পর আপনাকে alert দেওয়া হবে। একটি scheduled job আসলে চলেছে কি না তা জানার এটিই একমাত্র নির্ভরযোগ্য উপায়, কারণ বাইরের কোনো চেক স্ক্রিপ্টের ভেতরের অবস্থা দেখতে পায় না।

Uptime Kuma বনাম Zabbix, কোনটি আমার চালানো উচিত?

Uptime Kuma দশ মিনিটের মধ্যে এবং খুব সামান্য রিসোর্স ব্যবহার করে উত্তর দেয় যে "এটি কি বাইরে থেকে সচল আছে এবং আমাকে কি alert দেওয়া হয়েছে", সাথে একটি status page-ও থাকে। এটি CPU, memory, disk trend বা পুরো নেটওয়ার্কের থ্রেশহোল্ডের মতো গভীর মেট্রিক্স সংগ্রহ করে না। সেই কাজের জন্য একটি পূর্ণাঙ্গ Zabbix monitoring server হলো ভারী এবং agent-ভিত্তিক টুল, এবং অনেকেই উভয়ই ব্যবহার করেন। এখনো সিদ্ধান্ত নিতে পারছেন না কী চালাবেন? 2026 সালে কী কী self-host করবেন তার আমাদের তালিকাটি মনিটরিংয়ের বিষয়টি আরও পরিষ্কার করবে।