SSD Nodes Learn
নির্দেশিকা Matt Connorদ্বারা Matt Connor · আপডেট করা হয়েছে 2026-07-25

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

Uptime Kuma একটি Docker কন্টেইনারে চালান। ওয়েবসাইট, port, DNS ও cron job পর্যবেক্ষণ করুন। ইমেল বা Telegram-এ অ্যালার্ট পান। আলাদা VPS থেকে পাবলিক স্ট্যাটাস পেজ প্রকাশ করুন।

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

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

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

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

তাই Uptime Kuma চালান একটি ভিন্ন VPS-এ, যে সার্ভারের কাজ নজরদারি করবে তার বাইরে। আদর্শভাবে একটি ভিন্ন প্রোভাইডার বা অঞ্চল ব্যবহার করুন। আপনার ব্যবহারকারীরা যেভাবে সেবা পান, সেভাবেই নজরদারিও যাবে: পাবলিক ইন্টারনেটের মাধ্যমে, hostname ধরে। একটি সস্তা ইনস্ট্যান্স যথেষ্ট। একটি ছোট নজরদারি VPS আপনার সব সার্ভার নজরদারি করতে পারে। Kuma নিজেই বন্ধ হয়ে গেছে কিনা তা ধরতে, অন্যত্র একটি cron থেকে push heartbeat যোগ করুন।

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

  • একটি নতুন Ubuntu 24.04 VPS, যাতে Docker Engine এবং Compose v2 প্লাগইন ইনস্টল করা আছে। এগুলি Docker-এর নিজস্ব apt রিপোজিটরি থেকে ইনস্টল করতে হবে, docker.io ডিস্ট্রো প্যাকেজ থেকে নয়, কারণ সেটি পুরোনো।
  • 256 MB RAM কয়েকটি মনিটর চালাতে পারে; 512 MB থেকে 1 GB ডজনখানেক মনিটর এবং রিভার্স প্রক্সির জন্য যথেষ্ট। চেকগুলির মধ্যবর্তী সময়ে CPU প্রায় আইডল থাকে।
  • একটি ডোমেইন এবং একটি DNS A রেকর্ড (যেমন status.example.com যা VPS-এ নির্দেশ করছে), শুধুমাত্র যদি আপনি TLS এবং একটি পাবলিক স্ট্যাটাস পেজ চান। একটি প্রাইভেট ইনস্ট্যান্স DNS ছাড়াই চলতে পারে এবং VPN বা SSH টানেল ব্যবহার করতে পারে।
  • অ্যালার্ট যেখানে যাবে সেখানে আউটবাউন্ড নেটওয়ার্ক সংযোগ: আপনার মেইল প্রোভাইডারের কাছে 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 আপনার ফায়ারওয়াল নির্বিশেষে আপনার ড্যাশবোর্ডকে পাবলিক ইন্টারনেটে প্রকাশ করে দেয়। লুপব্যাকে বাইন্ড করলে এটি প্রাইভেট থাকে, শুধু রিভার্স প্রক্সি প্রকাশিত থাকে; একটি প্রাইভেট ইনস্ট্যান্স প্রক্সি এড়িয়ে একটি সেলফ-হোস্টেড WireGuard VPN-এর মাধ্যমে 3001-এ পৌঁছাতে পারে।

/app/data-এ একটি নামকৃত ভলিউম। 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 বোতাম ব্যবহার করে নিশ্চিত করুন যে বার্তাটি পৌঁছায়, কারণ একটি অপরীক্ষিত নোটিফিকেশন হলো দ্বিতীয় সবচেয়ে সাধারণ কারণ যার জন্য একটি সেটআপ নীরবে ব্যর্থ হয়।

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

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

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

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

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

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

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

একটি push (heartbeat) মনিটর দিয়ে cron job পর্যবেক্ষণ

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

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

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

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

#!/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="

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

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

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

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

এটি একটি TLS সহ রিভার্স প্রক্সির পেছনে রাখুন এবং ওয়েবসকেটের প্রতি খেয়াল রাখুন

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

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

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-to-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 ব্লকে কপি করে। আপনি যদি একটি প্রক্সির পেছনে ইতিমধ্যে একাধিক কন্টেইনার চালান, তবে Traefik-এর মাধ্যমে স্বয়ংক্রিয় TLS সহ রাউটিং কন্টেইনার লেবেল দিয়ে একই কাজ করে এবং ডিফল্টভাবে WebSocket আপগ্রেড ফরওয়ার্ড করে।

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

সার্টিফিকেট মেয়াদ শেষ হওয়ার পর্যবেক্ষণ, সঠিকভাবে

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

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

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

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 ভলিউমে এক্সট্র্যাক্ট করুন, তারপর চালু করুন।

আপগ্রেড

আপগ্রেড হলো একটি ইমেজ পুল:

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

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

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

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

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

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

একটি ইমেইল পরীক্ষায় 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 মনিটর কোথায় চালানো উচিত?

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

আমি Telegram বা ইমেলে সতর্কতা কীভাবে পাব?

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

Uptime Kuma কি কোনো cron job বা ব্যাকআপ স্ক্রিপ্ট মনিটর করতে পারে?

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

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

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

#uptime-kuma#monitoring#docker#self-hosting#status-page