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

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

একটি ছোট container, যা বাইরে থেকে আপনার অন্যান্য server এবং website পর্যবেক্ষণ করে। কোনোটি উত্তর দেওয়া বন্ধ করলেই এটি email, Telegram, Discord অথবা webhook-এর মাধ্যমে আপনাকে জানায়। Uptime Kuma একটি Node process। এই সেটআপে এটি একটি SQLite file ব্যবহার করে। v2 embedded অথবা external MariaDB দিয়েও চালানো যায়। তাই 256-512 MB RAM-এ এটি স্বাচ্ছন্দ্যে চলে। এতে live dashboard, history graph এবং public status page থাকে।

Installation-এর জন্য দশ লাইনের Compose file যথেষ্ট। আসল বিষয় হলো আপনি এটি কোথায় চালাচ্ছেন এবং পরীক্ষায় আপনার alert কখনও কাজ করেছে কি না। কারণ কোনো monitor যে আপনার কাছে পৌঁছাতে পারে, তা কখনও যাচাই না করলে সেটি একেবারেই monitor না থাকার চেয়েও খারাপ। এটি আপনাকে নিরাপদ থাকার অনুভূতি দেয়, কিন্তু কিছুই পর্যবেক্ষণ করে না।

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

এই একটি সিদ্ধান্তই পুরো বিষয়টি সফল বা ব্যর্থ করে দেয়, তাই এটি সবার আগে আসা উচিত। 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:

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

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 দেখা যাবে, এরপর আর নতুন লগ থাকবে না। ওই ফাইলের 3টি বিষয় ইচ্ছাকৃত।

127.0.0.1:3001:3001, 3001:3001 নয়। Docker DNAT rule ব্যবহার করে port publish করে। এই rule-গুলো ufw প্যাকেট দেখার আগেই প্রয়োগ করে। তাই খালি 3001:3001 ব্যবহার করলে আপনার dashboard public Internet-এ উন্মুক্ত হয়ে যায়, ufw rule যা-ই থাকুক না কেন। শুধু Docker-এর নিজস্ব DOCKER-USER chain-এ যোগ করা rule এটি filter করতে পারে। loopback-এ bind করলে এটি private থাকে এবং শুধু reverse proxy উন্মুক্ত থাকে। এর অর্থ, কেবল host নিজেই 3001-এ পৌঁছাতে পারে। proxy ছাড়া private instance-এ নিচে দেখানো SSH tunnel ব্যবহার করুন। নিজে পরিচালিত WireGuard VPN-এর মাধ্যমে এটিতে পৌঁছাতে হলে server-এর WireGuard address-এ port publish করতে হবে, যেমন 10.8.0.1:3001:3001, 127.0.0.1-এর পরিবর্তে।

/app/data-এ একটি named volume। Uptime Kuma যে সব তথ্য মনে রাখে, যেমন SQLite database, আপনার monitor, notification setting এবং status-page logo, সেগুলো এখানে থাকে। এটি হারালে আপনি খালি admin screen দিয়ে শুরু করবেন। Backup নেওয়ার জন্য এটিই একমাত্র আবশ্যক জিনিস।

Image-টি একটি major tag, :2-এ pinned। এটিই বর্তমান stable line। ফাইলটি কপি করার আগে Docker Hub-এ সর্বশেষ major version পরীক্ষা করুন। latest-এর মতো পরিবর্তনশীল tag কখনো track করবেন না; project এটি deprecated করেছে। এই image-এ major-version jump হলে database migration চলে। তাই এটি routine pull-এর সময় অনিচ্ছাকৃতভাবে না চালিয়ে fresh backup হাতে রেখে ইচ্ছাকৃতভাবে চালানো উচিত।

একটি সতর্কতা: /app/data অবশ্যই POSIX file lock সমর্থন করে এমন filesystem-এ থাকতে হবে। Local Docker volume ঠিক আছে। কিন্তু NFS-এ SQLite database corrupt হয় এবং SQLITE_BUSY ও database disk image is malformed দেখা যায়। তাই network share কখনো ব্যবহার করবেন না।

প্রথমবার চালু করা: admin account তৈরি

আপনার proxy-এর মাধ্যমে https://status.example.com-এ instance-এ যান, অথবা একটি SSH tunnel ব্যবহার করুন: ssh -L 3001:127.0.0.1:3001 user@your-vps চালান এবং http://localhost:3001 খুলুন। নতুন v2 install-এ প্রথম screen-এ কোন database ব্যবহার করবেন তা জানতে চাওয়া হয়; SQLite বেছে নিন। এতে সবকিছু /app/data volume-এ সংরক্ষিত থাকে এবং নিচের backup ও troubleshooting ধাপগুলোও এটিই ধরে নেয়। এরপর administrator username ও password সেট করার একটি form আসে; কোনো default login নেই। বাস্তবসম্মত একটি password বেছে নিন। এই dashboard-এ আপনি যেসব service monitor করেন, সেগুলোর internal address ও token দেখা যায়। পরে password ভুলে গেলে browser থেকে নয়, host থেকে reset করুন:

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

প্রথমে আপনার notification channel যোগ করুন এবং পরীক্ষা করুন

monitor যোগ করার আগে alert সেট up করুন, যাতে প্রতিটি monitor তৈরির সময় একটি channel সংযুক্ত করতে পারেন। Settings then Notifications then Setup Notification-এ যান এবং প্রতিটি channel-এর Test button ব্যবহার করে নিশ্চিত করুন যে message পৌঁছেছে। কারণ পরীক্ষা না করা notification কোনো setup নীরবে ব্যর্থ হওয়ার দ্বিতীয় সর্বাধিক সাধারণ কারণ।

Email (SMTP)। host, port, encryption, username, password, একটি From এবং একটি To পূরণ করুন। প্রচলিত সমন্বয় হলো 465, যেখানে "Secure" হিসেবে TLS/SSL সেট করা থাকে, অথবা 587, যেখানে STARTTLS ব্যবহৃত হয়। কিছু server 25-এও STARTTLS দেয়। তাই আপনার provider-এর documentation-এ দেওয়া port ও mode ব্যবহার করুন। Gmail এবং two-factor auth ব্যবহারকারী অধিকাংশ provider-এর ক্ষেত্রে আপনাকে একটি app password তৈরি করতে হবে। সাধারণ account password দিলে Error: Invalid login: 535-5.7.8 Username and Password not accepted ফেরত আসে।

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

Discord। channel-এ Edit Channel then Integrations then Webhooks then New Webhook খুলুন, URL কপি করুন এবং সেটি Discord notification হিসেবে paste করুন।

Generic webhook। অন্য যেকোনো কিছুর জন্য, যেমন Slack incoming webhook, custom endpoint বা home-automation hook, Webhook type আপনার সরবরাহ করা URL-এ একটি JSON payload POST করে। তালিকায় থাকা প্রায় নব্বইটিরও বেশি অন্য service-এর অধিকাংশই bundled Apprise integration-এর আওতায় পড়ে। কোনো outage এবং আপনার phone-এর মধ্যে তৃতীয় পক্ষ না থাকুক চাইলে built-in ntfy type বেছে নিন এবং সেটিকে আপনার নিজস্বভাবে চালানো একটি ntfy server-এর দিকে নির্দেশ করুন। এটি আপনার end-to-end নিয়ন্ত্রণাধীন একটি channel-এর মাধ্যমে আপনার handset-এ push করে।

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

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-সহ reverse proxy-এর পেছনে রাখুন এবং WebSocket-এর বিষয়টি খেয়াল রাখুন

Public instance-এর জন্য loopback-bound container-এর সামনে TLS এবং hostname ব্যবহারের জন্য একটি reverse proxy রাখুন। যে বিষয়টি প্রায়ই সমস্যার কারণ হয়: Uptime Kuma-এর UI একটি live Socket.IO app, তাই proxy-কে WebSocket connection upgrade করতে হবে। এটি বাদ পড়লে page load হয়, কিন্তু কখনো connect করে না; dashboard-এ "Connecting..." দেখাতে থাকে, live heartbeat update হয় না, এবং browser console-এ WebSocket connection to 'wss://.../socket.io/...' failed দেখা যায়।

nginx এবং certbot install করুন। এরপর loopback port-এ proxy করার জন্য vhost লিখুন। আপাতত এটিকে port 80-এ রাখুন এবং পরে certbot-কে TLS যোগ করতে দিন; challenge, renewal timer এবং এর failure mode certbot এবং nginx দিয়ে Let's Encrypt certificate জারি করা-এ ব্যাখ্যা করা হয়েছে।

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

এটি /etc/nginx/sites-available/status.example.com হিসেবে save করুন; WebSocket-এর দুটি line-ই গুরুত্বপূর্ণ:

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;
    }
}

site enable করুন, configuration test করুন, তারপর certbot-কে block-টি 443-এ listen করার জন্য rewrite করতে, certificate বসাতে এবং HTTP-to-HTTPS redirect যোগ করতে দিন:

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-কে দীর্ঘস্থায়ী socket বন্ধ করে দেওয়া থেকে বিরত রাখে; certbot তৈরি করা 443 block-এ দুটিই copy করে। একই proxy-এর পেছনে যদি আগে থেকেই একাধিক container চালান, automatic TLS সহ Traefik-এর মাধ্যমে সেগুলো route করা একই কাজ container label ব্যবহার করে করে এবং defaultভাবেই WebSocket upgrade forward করে।

পুরো vhost-এ basic auth ব্যবহার করবেন না। এতে public status page এবং /api/push endpoint-ও inaccessible হয়ে যাবে। Uptime Kuma-এর built-in login চালু রাখুন। এটি Internet-facing হলে বারবার ব্যর্থ login-এর জন্য fail2ban দিয়ে নজরদারি করা যোগ করুন। Dashboard public করার প্রয়োজন না থাকলে proxy বাদ দিয়ে SSH tunnel-এর মাধ্যমে, অথবা VPN-এর মাধ্যমে এতে প্রবেশ করুন। এ ক্ষেত্রে port-টি loopback-এর পরিবর্তে VPN address-এ publish করুন।

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

একটি 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 ভলিউমে ফাইলগুলো এক্সট্র্যাক্ট করুন এবং পুনরায় স্টার্ট করুন।

আপগ্রেড

আপগ্রেডের জন্য image pull করতে হয়:

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

নতুন container প্রথমবার start হলে প্রয়োজনীয় database migration চালায়; docker compose logs -f মনিটর করুন। pull করার আগে উপরের backup নিন এবং একই major tag-এর মধ্যে থাকুন: :1 থেকে :2-এ গেলে database migrate হয়। প্রকল্পের migration guide অনুযায়ী migration মাঝপথে বাধাগ্রস্ত হলে backup restore করে আবার চেষ্টা করতে হয়। তাই আগে backup নিন এবং সেই guide ও release notes পড়ুন।

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

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 করবেন তার আমাদের তালিকাটি মনিটরিংয়ের বিষয়টি আরও পরিষ্কার করবে।