ஆல் Matt Connor 2026-07-15 · புதுப்பிக்கப்பட்டது 2026-08-30

Uptime Kuma மூலம் இணையதளங்களை கண்காணிப்பது எப்படி?

Q: Telegram அல்லது email மூலம் alerts பெறுவது எப்படி?

Settings என்பதற்குச் சென்று Notifications-ல் புதிய channel-ஐச் சேர்க்கவும், பின் அதை ஒவ்வொரு monitor-உடனும் இணைக்கவும். Telegram-க்கு, @BotFather மூலம் ஒரு bot-ஐ உருவாக்கி, https://api.telegram.org/bot /getUpdates-லிருந்து chat.id-ஐப் பெறவும். Email-க்கு, உங்கள் provider two-factor authentication பயன்படுத்தினால், SSL-க்கு 465 அல்லது STARTTLS-க்கு 587-ஐப் பயன்படுத்தி, app password-ஐ உள்ளிடவும். Test பொத்தானை அழுத்தி, செய்தி வந்து சேருகிறதா என்பதை உறுதிப்படுத்திய பின் அதைப் பயன்படுத்தத் தொடங்கவும்.

Q: Uptime Kuma மூலம் cron job அல்லது backup script-ஐக் கண்காணிக்க முடியுமா?

ஆம், அதற்கு Push monitor-ஐப் பயன்படுத்தலாம்: Uptime Kuma உங்களுக்கு ஒரு URL-ஐ வழங்கும். அதை உங்கள் script-ன் இறுதியில் curl செய்யவும், அப்போதுதான் script வெற்றிகரமாக முடிந்தால் மட்டும் அது இயங்கும். ஒருவேளை job தோல்வியடைந்தாலோ அல்லது server செயலிழந்தாலோ, heartbeat வந்து சேராது; குறிப்பிட்ட கால இடைவெளிக்குப் பிறகு உங்களுக்கு alert வரும். ஒரு scheduled job உண்மையில் இயங்கியதா என்பதை அறிய இதுவே நம்பகமான வழி, ஏனெனில் வெளிப்புறக் கண்காணிப்பு கருவியால் script-க்குள் நடப்பதைப் பார்க்க முடியாது.

Docker வழியாக Uptime Kuma-வை நிறுவி உங்கள் இணையதளங்கள், DNS மற்றும் cron jobs ஆகியவற்றை கண்காணிக்கவும். மின்னஞ்சல் அல்லது Telegram மூலம் உடனடி எச்சரிக்கைகளைப் பெறவும்.

நீங்கள் உருவாக்குவது என்ன

உங்கள் பிற server-கள் மற்றும் இணையதளங்களை வெளியிலிருந்து கண்காணித்து, அவை பதிலளிக்கத் தவறும் தருணத்தில் மின்னஞ்சல், Telegram, Discord அல்லது webhook மூலம் உங்களுக்குத் தெரிவிக்கும் ஒரு சிறிய container-ஐ நீங்கள் உருவாக்குகிறீர்கள். Uptime Kuma என்பது SQLite கோப்பால் ஆதரிக்கப்படும் ஒரு Node process ஆகும். இது 256-512 MB RAM-ல் சிறப்பாக இயங்கும். இது உங்களுக்கு நேரடி dashboard, வரலாற்று வரைபடங்கள் மற்றும் பொதுவான status page ஆகியவற்றை வழங்குகிறது. இதன் நிறுவல் பத்து வரிகள் கொண்ட Compose கோப்பு மட்டுமே. இதில் முக்கியமான பகுதி, நீங்கள் அதை எங்கே இயக்குகிறீர்கள் என்பதும், உங்கள் எச்சரிக்கை அறிவிப்புகள் (alerts) சோதனையின் போது ஒருமுறையாவது செயல்பட்டதா என்பதும்தான். ஏனெனில், உங்களை வந்தடையும் என்று உறுதிப்படுத்தப்படாத கண்காணிப்பு கருவி, கண்காணிப்பு இல்லாததை விட மோசமானது: அது எதையும் கண்காணிக்காமல், நீங்கள் பாதுகாப்பாக இருப்பதாக ஒரு மாயையை உருவாக்குகிறது.

கண்காணிப்பு கருவியை பாதிப்பு ஏற்படாத இடத்தில் இயக்குதல்

இந்த ஒரு முடிவுதான் ஒட்டுமொத்த அமைப்பின் வெற்றியையும் தோல்வியையும் தீர்மானிக்கிறது, எனவே இதுவே முதன்மையானது. Uptime Kuma-வை அது கண்காணிக்கும் அதே server-ல் இயக்க வேண்டாம். கண்காணிப்பு கருவி தான் கண்காணிக்கும் server-லேயே இருந்தால், அந்த server செயலிழப்பது அல்லது memory தீர்ந்து போவது போன்ற நீங்கள் கவலைப்படும் அதே நிகழ்வு, கண்காணிப்பு கருவியையும் செயலிழக்கச் செய்துவிடும். இதனால் உங்களுக்கு எந்த எச்சரிக்கையும் கிடைக்காது: கண்காணிப்பு கருவி செயலிழந்தால் வரும் அமைதி, "எல்லாம் சரியாக உள்ளது" என்ற செய்தியைப் போலவே தோன்றும். server இயங்கிக்கொண்டிருக்கும்போதே ஒரு நுணுக்கமான சிக்கலும் உள்ளது: localhost-ஐ கண்காணிக்கும் கருவி, அதே workload-உடன் CPU-வைப் பகிர்ந்து கொள்கிறது. இதனால் load அதிகரிக்கும்போது, கண்காணிப்பு கருவியின் check நேரம் முடிந்து (timeout), இலக்கை down என்று தவறாகக் காட்டும். ஆனால், உண்மையான பயனர்களுக்குச் சேவை தடையின்றி கிடைத்துக் கொண்டிருக்கும்.

எனவே, Uptime Kuma-வை அது கண்காணிக்கும் server-லிருந்து வேறுபட்ட VPS-ல் இயக்கவும். முடிந்தால், வெவ்வேறு provider அல்லது region-ல் உள்ள server-ஐத் தேர்ந்தெடுக்கவும். பயனர்கள் அணுகுவது போலவே, public internet வழியாக hostname மூலம் உங்கள் சேவைகளை அது அணுகட்டும். ஒரு மலிவான instance போதுமானது; ஒரு சிறிய monitoring VPS மூலம் உங்கள் அனைத்து server-களையும் கண்காணிக்க முடியும். நீங்கள் host செய்யும் கனமான application-களுக்கு இந்தத் தனிமைப்படுத்துதல் மிக முக்கியம். உதாரணமாக, PhotoPrism அல்லது Immich photo library போன்ற பயன்பாடுகள், புதிய கோப்புகளை index செய்யும்போது பல மணிநேரம் CPU-வை முழுமையாகப் பயன்படுத்தலாம். அதே hardware-ல் இயங்கும் கண்காணிப்பு கருவி, பிஸியாக இருக்கும் ஒரு சேவையை செயலிழந்துவிட்டதாகத் தவறாகக் காட்டும். Kuma-வே செயலிழந்துவிட்டதா என்பதைக் கண்டறிய, வேறொரு இடத்தில் உள்ள cron மூலம் push heartbeat-ஐச் சேர்க்கவும்.

முன்நிபந்தனைகள் மற்றும் அளவு நிர்ணயம்

புதிய Ubuntu 24.04 VPS, அதில் Docker Engine மற்றும் Compose v2 plugin நிறுவப்பட்டிருக்க வேண்டும். இவை Docker-ன் சொந்த apt repository-லிருந்து நிறுவப்பட வேண்டும்; docker.io distro package-ஐப் பயன்படுத்த வேண்டாம், ஏனெனில் அவை பழைய பதிப்புகளாக இருக்கும்.
256 MB RAM-ல் சில monitors-களை இயக்கலாம்; டஜன் கணக்கான monitors மற்றும் reverse proxy-க்கு 512 MB முதல் 1 GB RAM போதுமானது. சோதனைகளுக்கு இடைப்பட்ட நேரத்தில் CPU பயன்பாடு மிகக் குறைவாகவே இருக்கும்.
ஒரு domain மற்றும் DNS A record (உதாரணமாக, VPS-ஐக் குறிக்கும் status.example.com) தேவை. இது TLS மற்றும் பொதுவான status page தேவைப்பட்டால் மட்டுமே அவசியம். தனிப்பட்ட பயன்பாட்டிற்கு DNS தேவையில்லை, அதற்குப் பதிலாக VPN அல்லது SSH tunnel-ஐப் பயன்படுத்தலாம்.
எச்சரிக்கைகள் அனுப்பப்பட வேண்டிய இடத்திற்கு outbound network இணைப்பு இருக்க வேண்டும்: உங்கள் மின்னஞ்சல் சேவைக்கு 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 என்று பதிவாகி, பின் அமைதியாகும். அந்த கோப்பில் உள்ள மூன்று விஷயங்கள் திட்டமிட்டுச் சேர்க்கப்பட்டவை.

3001:3001 அல்ல, 127.0.0.1:3001:3001. Docker, DNAT விதிகளை ufw அந்த பாக்கெட்டைப் பார்ப்பதற்கு முன்பே மதிப்பீடு செய்கிறது. எனவே, வெறும் 3001:3001 என்று குறிப்பிடுவது உங்கள் firewall-ஐ மீறி, dashboard-ஐ பொது இணையத்தில் வெளிப்படுத்திவிடும். Loopback-ல் bind செய்வதன் மூலம் அதைத் தனிப்பட்டதாக வைத்திருக்கலாம்; reverse proxy மட்டுமே வெளிப்படையாக இருக்கும். ஒரு private instance, proxy-ஐத் தவிர்த்துவிட்டு self-hosted WireGuard VPN வழியாக 3001-ஐ அடைய முடியும்.

/app/data-ல் ஒரு named volume. Uptime Kuma நினைவில் கொள்ளும் அனைத்தும், அதாவது SQLite database, உங்கள் monitors, notification அமைப்புகள் மற்றும் status-page லோகோக்கள் அனைத்தும் அங்கேயே இருக்கும். இதை இழந்தால், நீங்கள் காலியான admin திரையிலிருந்துதான் தொடங்க வேண்டும்; இதை மட்டுமே நீங்கள் backup எடுக்க வேண்டும்.

Image ஒரு major tag-ல், அதாவது :2-ல் நிலைநிறுத்தப்பட்டுள்ளது. இதுவே தற்போதைய stable வரிசை. நகலெடுப்பதற்கு முன் Docker Hub-ல் புதிய major பதிப்பைச் சரிபார்க்கவும். latest போன்ற மாறும் tag-களை ஒருபோதும் பயன்படுத்த வேண்டாம், ஏனெனில் அந்த project அதைத் தவிர்க்க அறிவுறுத்துகிறது. இந்த image-ல் ஒரு major-version மாற்றம் என்பது ஒருமுறை மட்டுமே செய்யக்கூடிய database migration ஆகும்; இதை நீங்கள் திட்டமிட்டுச் செய்ய வேண்டுமே தவிர, வழக்கமான pull-ன் போது தற்செயலாக நடக்க விடக்கூடாது.

ஒரு எச்சரிக்கை: /app/data, POSIX file locks வசதி கொண்ட filesystem-ல் இருக்க வேண்டும். ஒரு local Docker volume இதற்குச் சரியானது; NFS-ல் SQLite database சிதைந்து, SQLITE_BUSY மற்றும் database disk image is malformed பிழைகள் ஏற்படும். எனவே, network share-ஐ ஒருபோதும் பயன்படுத்த வேண்டாம்.

முதல் முறை இயக்கம்: நிர்வாகி கணக்கை உருவாக்குதல்

உங்கள் proxy வழியாக https://status.example.com முகவரியில் உள்ள instance-ஐ அணுகவும், அல்லது SSH tunnel பயன்படுத்தவும்: ssh -L 3001:127.0.0.1:3001 user@your-vps கட்டளையை இயக்கி http://localhost:3001 முகவரியைத் திறக்கவும். முதல் பக்கத்தில் நிர்வாகி பயனர் பெயர் மற்றும் கடவுச்சொல்லை அமைப்பதற்கான படிவம் இருக்கும்; இயல்பான login விவரங்கள் எதுவும் கிடையாது. வலுவான கடவுச்சொல்லைத் தேர்ந்தெடுக்கவும்: நீங்கள் கண்காணிக்கும் அனைத்து internal முகவரிகளையும் tokens-களையும் இந்த dashboard அணுகும். கடவுச்சொல்லை மறந்துவிட்டால், browser வழியாக அல்லாமல் host-லிருந்து அதை reset செய்யவும்:

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

முதலில் உங்கள் அறிவிப்பு சேனல்களைச் சேர்த்து, அவற்றைச் சோதிக்கவும்

மானிட்டர்களைச் சேர்ப்பதற்கு முன்பே எச்சரிக்கை அமைப்புகளை (alerts) தயார் செய்யவும், அப்போதுதான் ஒவ்வொரு மானிட்டரை உருவாக்கும்போதும் ஒரு சேனலை அதனுடன் இணைக்க முடியும். Settings என்பதற்குச் சென்று, பின் Notifications மற்றும் Setup Notification என்பதைத் தேர்ந்தெடுக்கவும். ஒவ்வொரு சேனலிலும் உள்ள Test பொத்தானைப் பயன்படுத்தி செய்தி சரியாகச் சென்றடைகிறதா என்பதை உறுதிப்படுத்தவும்; ஏனெனில், சோதிக்கப்படாத அறிவிப்பு அமைப்பு, அமைவு (setup) அமைதியாகத் தோல்வியடைவதற்கு இரண்டாவது பொதுவான காரணமாகும்.

Email (SMTP). host, port, encryption, username, password, From மற்றும் To ஆகிய விவரங்களை நிரப்பவும். வேலை செய்யும் இரண்டு சேர்க்கைகள் இவை: 465 உடன் "Secure" என்பதை TLS/SSL என அமைப்பது, அல்லது 587 உடன் STARTTLS-ஐப் பயன்படுத்துவது. Gmail மற்றும் இரு-காரணி அங்கீகாரம் (two-factor auth) கொண்ட பெரும்பாலான சேவை வழங்குநர்களுக்கு நீங்கள் app password-ஐ உருவாக்க வேண்டும்; சாதாரண கணக்கு கடவுச்சொல்லைப் பயன்படுத்தினால் Error: Invalid login: 535-5.7.8 Username and Password not accepted பிழை ஏற்படும்.

Telegram. @BotFather-க்கு செய்தி அனுப்பி, /newbot கட்டளையை வழங்கவும், பின் bot token-ஐ நகலெடுக்கவும். உங்கள் chat ID-க்கு, புதிய bot-க்கு ஒருமுறை செய்தி அனுப்பி, https://api.telegram.org/bot<token>/getUpdates-ஐத் திறந்து, JSON-லிருந்து chat.id-ஐப் படிக்கவும். நீங்கள் முதலில் செய்தி அனுப்பாத bot-க்கு getUpdates காலியாக இருக்கும், மேலும் அதற்குச் செய்தி அனுப்ப இடமும் இருக்காது.

Discord. அந்த சேனலில், Edit Channel என்பதற்குச் சென்று, பின் Integrations, Webhooks, New Webhook என்பதைத் திறந்து, URL-ஐ நகலெடுத்து, அதை Discord அறிவிப்பு வகையாக ஒட்டவும்.

Generic webhook. பிற சேவைகளுக்கு, அதாவது Slack incoming webhook, custom endpoint, அல்லது home-automation hook போன்றவற்றுக்கு, Webhook வகை நீங்கள் வழங்கும் URL-க்கு JSON payload-ஐ POST செய்யும். மேலும், இதனுடன் இணைக்கப்பட்டுள்ள Apprise integration பட்டியலில் உள்ள மற்ற தொண்ணூறுக்கும் மேற்பட்ட சேவைகளை ஆதரிக்கிறது. ஒரு செயலிழப்புக்கும் உங்கள் தொலைபேசிக்கும் இடையில் எந்த மூன்றாம் தரப்பினரும் இருக்கக்கூடாது என்று நீங்கள் விரும்பினால், உள்ளமைக்கப்பட்ட ntfy வகையைத் தேர்ந்தெடுத்து, அதை நீங்கள் சொந்தமாக இயக்கும் ntfy server-க்குச் சுட்டிக்காட்டவும். இது நீங்கள் முழுமையாகக் கட்டுப்படுத்தும் சேனல் வழியாக உங்கள் கைபேசிக்கு அறிவிப்புகளை அனுப்பும்.

ஒவ்வொரு வகையாக monitors-ஐச் சேர்க்கவும்

Add New Monitor என்பதைக் கிளிக் செய்து, ஒரு வகையைத் தேர்வு செய்யவும். பின் Friendly Name, Check Interval (60 seconds என்பது பொருத்தமானது), Retries ("down" நிலைக்குச் செல்வதற்கு முன் ஏற்படும் தொடர்ச்சியான தோல்விகள்; ஒன்று அல்லது இரண்டு packet-கள் தொலைந்தால் உடனே எச்சரிக்கை வராமல் இருக்க 2 அல்லது 3 என அமைக்கவும்), மற்றும் அனுப்ப வேண்டிய notifications ஆகியவற்றை அமைக்கவும். நீங்கள் பயன்படுத்த வேண்டிய வகைகள்:

HTTP(s). ஒரு முழுமையான URL. ஒரு status code ஏற்றுக்கொள்ளப்பட்டால் அது "up" எனக் கருதப்படும் (இயல்பாக 200-299; உங்களுக்கு 301 அல்லது 401 சாதாரணமாக இருந்தால் Accepted Status Codes என்பதில் அதைச் சேர்க்கவும்). இது இணையதளங்கள் மற்றும் API-களுக்கான முதன்மையான சோதனையாகும்.
HTTP(s) - Keyword. இதுவும் அதே கோரிக்கையைத்தான் செய்யும், ஆனால் "up" எனக் கருதப்பட, குறிப்பிட்ட string அந்தப் பக்கத்தில் இருக்க வேண்டும். Invert தேர்வு செய்யப்படவில்லை எனில், அந்த string இருந்தால் மட்டுமே அது இயங்குவதாகக் கருதப்படும். இது, "Error establishing a database connection" என்ற செய்தியைத் திரையில் காட்டும்போதும், சாதாரண HTTP சோதனையில் 200 OK எனத் தவறாகக் காட்டும் நிலையைத் தவிர்க்க உதவும். தனித்தனி backend-உடன் இணைக்கப்பட்ட browser front-end-களுக்கும் இதுவே சரியான சோதனை. உதாரணமாக, Jellyfin-க்கு மேலாக இயங்கும் Halcyon video-store skin, அதன் media server அணுக முடியாத நிலையிலும் 200 எனச் சரியாகக் காட்டும், ஆனால் இந்தச் சோதனை அதைச் சரியாகக் கண்டறியும்.
TCP Port. HTTP அல்லாத சேவைகளுக்கான நேரடி TCP இணைப்பு: SSH-க்கு 22, Postgres-க்கு 5432, SMTP server-க்கு 25, அல்லது game server-கள்.
Ping. ICMP echo: இது எளிமையான இணைப்பு மற்றும் latency-ஐச் சோதிக்க உதவும். ஆனால் பல நெட்வொர்க்குகள் மற்றும் cloud firewalls ICMP-ஐத் தடுக்கும் என்பதால், ping தோல்வியடைந்தால் அது "host down" என்று அர்த்தமல்ல, "provider ping-ஐத் தடுக்கிறது" என்றும் இருக்கலாம்; இதை உறுதிப்படுத்த TCP monitor-ஐப் பயன்படுத்தவும்.
DNS. நீங்கள் குறிப்பிடும் resolver-ஐப் பயன்படுத்தி ஒரு record-ஐ (A, AAAA, MX, TXT போன்றவை) resolve செய்யும். இது DNS செயலிழப்பு அல்லது registrar சிக்கல்களை முன்கூட்டியே கண்டறிய உதவும்.
Push. இது உள்ளிருந்து வெளியே செயல்படும் monitor, இதைப் பற்றி அடுத்து பார்ப்போம்.

Push (heartbeat) monitor மூலம் cron job-ஐ கண்காணித்தல்

மேலே உள்ள அனைத்து monitor-களும் உங்கள் service-ஐ வெளியிலிருந்து அணுகுகின்றன. Push monitor இதற்கு நேர்மாறாகச் செயல்படுகிறது: Uptime Kuma காத்திருக்கும், உங்கள் job தான் "நான் இயங்கிவிட்டேன்" என்று அதற்குத் தெரிவிக்கும். Backup அல்லது cron-ஐக் கண்காணிக்க இதுவே சரியான வழி: HTTP check மூலம் ஒரு URL பதிலளிக்கிறதா என்று மட்டுமே அறிய முடியும், ஆனால் job முழுமையாக முடிவடைந்ததா என்பதை அந்த job-ஆல் மட்டுமே உறுதிப்படுத்த முடியும்.

Push வகை monitor ஒன்றை உருவாக்கவும். Uptime Kuma பின்வருவது போன்ற ஒரு தனித்துவமான URL-ஐ உருவாக்கும்:

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

Heartbeat Interval-ஐ உங்கள் job இயங்கும் கால இடைவெளிக்கு ஏற்ப, சிறிது கூடுதல் நேரத்துடன் அமைக்கவும். பின், உங்கள் script-ன் இறுதியில் ஒரு வரியைச் சேர்க்கவும். இது 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 தோல்வியடைந்தால், curl கட்டளைக்கு முன்பே set -e நின்றுவிடும்; server செயலிழந்திருந்தால், script இயங்காது. எப்படியாயினும் heartbeat நின்றுவிடும். குறிப்பிட்ட கால இடைவெளி மற்றும் retry வரம்பைத் தாண்டியதும், Uptime Kuma அந்த monitor-ஐ down நிலைக்கு மாற்றி உங்களுக்கு எச்சரிக்கை அனுப்பும். அந்த push token-ஐ ரகசியமாக வைத்திருக்கவும்: அது தெரிந்த எவரும் போலி heartbeat-ஐ அனுப்ப முடியும்.

பொதுவான status page-ஐ உருவாக்குதல்

Status page என்பது வாடிக்கையாளர்கள் பார்க்கும் ஒரு தளமாகும்: இது உங்கள் dashboard-ஐ வெளிப்படுத்தாமல், எந்தெந்த சேவைகள் இயங்குகின்றன மற்றும் அவற்றின் சமீபத்திய வரலாறு ஆகியவற்றை மட்டும் காட்டும். Status Pages பகுதிக்குச் சென்று New Status Page என்பதைத் தேர்ந்தெடுக்கவும். அதற்கு ஒரு பெயரையும், slug-ஐயும் (பொதுவான path, உதாரணமாக /status/main) வழங்கவும். நீங்கள் கண்காணிக்க விரும்பும் monitors-ஐ "Websites" மற்றும் "APIs" போன்ற குழுக்களாக இழுத்துச் சேர்க்கவும். ஒரு லோகோ மற்றும் சிறிய விளக்கத்தைச் சேர்த்து, Save செய்யவும். இந்த பக்கத்தை அதன் சொந்த domain-உடன் இணைக்க முடியும், இதன் மூலம் status.example.com நேரடியாக அந்தப் பக்கத்தைக் காட்டும்.

இரண்டு எச்சரிக்கைகள்: நீங்கள் பொதுவெளியில் காட்ட விரும்பும் monitors-ஐ மட்டுமே சேர்க்கவும், ஏனெனில் ஒரு status page ஒரு சேவை இருப்பதை மற்றும் அது இயங்குகிறதா என்பதை வெளிப்படுத்தும். உங்கள் dashboard உங்கள் login-க்கு பின் பாதுகாப்பாக இருக்கும், அதே சமயம் status page வேண்டுமென்றே பொதுவானதாக வைக்கப்பட்டுள்ளது, அதற்கு எந்தவிதமான அங்கீகாரமும் (auth) தேவையில்லை.

TLS-உடன் கூடிய reverse proxy-க்கு பின்னால் நிறுவுதல் மற்றும் WebSocket-களை கவனித்தல்

பொதுப் பயன்பாட்டிற்கான instance-க்கு, TLS மற்றும் hostname-க்காக loopback-bound container-க்கு முன்னால் ஒரு reverse proxy-ஐ அமைக்கவும். அனைவரையும் தடுமாறச் செய்யும் முக்கியமான விவரம் இதுதான்: Uptime Kuma-வின் UI ஒரு நேரடி Socket.IO செயலி, எனவே proxy ஆனது WebSocket இணைப்பை upgrade செய்ய வேண்டும். இதைத் தவறவிட்டால், பக்கம் ஏற்றப்படும் ஆனால் இணையாது; dashboard "Connecting..." நிலையிலேயே இருக்கும், நேரடி heartbeats புதுப்பிக்கப்படாது, மேலும் browser console-ல் WebSocket connection to 'wss://.../socket.io/...' failed பிழை தோன்றும்.

nginx மற்றும் certbot-ஐ நிறுவி, loopback port-க்கு proxy செய்யும் vhost-ஐ எழுதவும். இப்போதைக்கு அதை port 80-ல் வைக்கவும், பின்னர் certbot மூலம் TLS-ஐச் சேர்க்கலாம்; challenge, renewal timer மற்றும் அதன் தோல்வி முறைகள் certbot மற்றும் nginx மூலம் Let's Encrypt certificates வழங்குதல் பகுதியில் விளக்கப்பட்டுள்ளன.

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

தளத்தை enable செய்து, config-ஐச் சோதிக்கவும், பின்னர் certbot-ஐப் பயன்படுத்தி அந்த block-ஐ 443-ல் கேட்குமாறு மாற்றி, 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 நீண்ட காலம் நீடிக்கும் socket-ஐ nginx துண்டிப்பதைத் தடுக்கிறது; certbot இவை இரண்டையும் அது உருவாக்கும் 443 block-ல் நகலெடுக்கும். நீங்கள் ஏற்கனவே பல container-களை ஒரே proxy-க்கு பின்னால் இயக்குகிறீர்கள் என்றால், Traefik மூலம் தானியங்கி TLS-உடன் routing செய்தல் முறை container labels-ஐப் பயன்படுத்தி இதையே செய்யும் மற்றும் WebSocket upgrade-களை இயல்பாகவே forward செய்யும்.

முழு vhost-க்கும் basic-auth வைக்க வேண்டாம், ஏனெனில் அது பொது status பக்கம் மற்றும் /api/push endpoint-ஐயும் முடக்கிவிடும். Uptime Kuma-வின் உள்ளமைக்கப்பட்ட login-ஐப் பயன்படுத்தவும், அது இணையத்தில் இருந்தால் தொடர்ச்சியான login தோல்விகளைக் கண்காணிக்க fail2ban-ஐச் சேர்க்கவும். dashboard பொதுப்படையாக இருக்க வேண்டிய அவசியமில்லை என்றால், proxy-ஐத் தவிர்த்துவிட்டு VPN மூலம் அதை அணுகவும்.

Certificate-expiry கண்காணிப்பு, சரியான முறையில்

ஒரு HTTP(s) monitor, TLS certificate காலாவதியாவதற்கு முன்பே உங்களை எச்சரிக்க முடியும்: Certificate Expiry Notification-ஐத் தேர்வு செய்யவும், குறிப்பிட்ட நாட்களுக்கு முன்பே Uptime Kuma உங்களுக்கு எச்சரிக்கை அனுப்பும். இரண்டு தவறுகள் இதைத் தவறாகப் புரிந்துகொள்ளச் செய்கின்றன. IP-ஐக் கொண்டு அல்ல, hostname-ஐக் கொண்டு monitor செய்யவும், இல்லையெனில் SNI இல்லாத கோரிக்கை server-ன் default certificate-ஐப் பெறும், அப்போது உங்களுக்கு Hostname/IP does not match certificate's altnames பிழை தெரியும். மேலும், காலாவதி எச்சரிக்கைகள் தேவைப்படும் monitor-ல் Ignore TLS/SSL Error என்பதைத் தேர்வு செய்ய வேண்டாம்: அந்தத் தேர்வு self-signed internal hosts-க்காக (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT) உருவாக்கப்பட்டது, ஆனால் அது Uptime Kuma certificate-ஐச் சரிபார்ப்பதை முழுமையாகத் தடுத்துவிடும், காலாவதி தேதியையும் சேர்த்து அது சரிபார்க்காது.

Backups: இது ஒரு directory மட்டுமே

அனைத்து தரவுகளும் /app/data-ல் இருப்பதால், container-ஐ நிறுத்திய பிறகு அந்த volume-ஐ நகலெடுப்பதே backup ஆகும். இவ்வாறு செய்யும்போது SQLite file சீரான நிலையில் (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

Compose, project directory-ஐ முன்னொட்டாக (prefix) சேர்ப்பதால், docker volume ls | grep kuma மூலம் அந்த volume-ன் உண்மையான பெயரை முதலில் உறுதிப்படுத்தவும். பின்னர், அந்த tarball-ஐ server-லிருந்து வெளியே நகர்த்தவும். ஒரே VPS-ல் சேமிக்கப்படும் backup, ஒரு நகல் மட்டுமே; அது உண்மையான backup ஆகாது. Restore செய்வதற்கு, stack-ஐ நிறுத்திவிட்டு, காலியாக உள்ள /app/data volume-ல் கோப்புகளைப் பிரித்தெடுத்து (extract), மீண்டும் தொடங்கவும்.

மேம்படுத்தல்கள் (Upgrades)

மேம்படுத்தல்கள் என்பது ஒரு image pull செயல்முறையாகும்:

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

புதிய container தொடங்கும்போது, முதல் முயற்சியிலேயே ஏதேனும் database migration இருந்தால் அதைச் செயல்படுத்தும்; docker compose logs -f-ஐக் கவனிக்கவும். Pull செய்வதற்கு முன்னால் மேலே குறிப்பிட்டுள்ளபடி backup எடுக்கவும், மேலும் ஒரே major tag-க்குள் இருக்கவும்: :1-லிருந்து :2-க்கு மாறுவது ஒரு வழிப்பாதை (one-way) migration ஆகும், எனவே முதலில் backup எடுத்துவிட்டு release notes-ஐச் சரிபார்க்கவும்.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் பிழைச் செய்திகள்

localhost-ஐக் கண்காணிக்கும்போது தவறான "down" நிலை. கண்காணிப்பு கருவி timeout of 48000ms exceeded அல்லது connect ETIMEDOUT பிழையைக் காட்டி சிவப்பு நிறத்திற்கு மாறுகிறது, ஆனால் உங்கள் மடிக்கணினியிலிருந்து அந்தச் சேவை சரியாக இயங்குகிறது. Uptime Kuma இயங்கும் அதே host-ஐ அது குறிவைத்தால், CPU அல்லது memory பயன்பாடு அதிகரித்ததால் அந்தச் சோதனை தோல்வியடைந்திருக்கலாம், இலக்குச் சேவை அல்ல. கண்காணிப்பு கருவியை வேறொரு VPS-க்கு மாற்றி, பொதுவான hostname-ஐக் குறிவைக்கவும்.

connect ECONNREFUSED 127.0.0.1:443 (அல்லது ஏதேனும் port). அந்த port-ல் எந்தச் சேவையும் இயங்கவில்லை: ஒன்று சேவை முடங்கியிருக்கலாம், அல்லது நீங்கள் container-க்குள் இருந்து localhost-ஐக் கண்காணித்திருக்கலாம். அங்கு 127.0.0.1 என்பது உங்கள் server அல்ல, அது container ஆகும். loopback-ஐக் கண்காணிக்காமல், பொதுவான hostname-ஐக் கண்காணிக்கவும்.

மின்னஞ்சல் சோதனையில் Invalid login: 535-5.7.8 Username and Password not accepted. SMTP நற்சான்றிதழ்கள் (credentials) தவறானவை, அல்லது உங்கள் கணக்கின் கடவுச்சொல்லுக்குப் பதிலாக அந்தச் சேவைக்குரிய பிரத்யேக கடவுச்சொல்லை (app-specific password) வழங்குமாறு மின்னஞ்சல் சேவை நிறுவனம் கோருகிறது. ஒரு app password-ஐ உருவாக்கி அதை உள்ளிடவும்.

மின்னஞ்சல் சோதனையில் connect ETIMEDOUT அல்லது queryA ETIMEDOUT <host>. தவறான port, அல்லது மின்னஞ்சல் சேவை நிறுவனம் வெளிச்செல்லும் (outbound) SMTP-ஐத் தடுக்கிறது. 465 அல்லது 587 ஆகியவை Secure/STARTTLS அமைப்புகளுடன் பொருந்துகிறதா என்பதை உறுதிப்படுத்தவும், மேலும் host-லிருந்து nc -vz smtp.example.com 587 மூலம் சோதிக்கவும். பல நிறுவனங்கள் வெளிச்செல்லும் 25-ஐத் தடுக்கின்றன, சில நிறுவனங்கள் நீங்கள் கோரும் வரை submission port-களைத் தடுக்கின்றன.

மின்னஞ்சல் சோதனையில் self signed certificate அல்லது unable to verify the first certificate. உங்கள் SMTP server வழங்கும் certificate-ஐ Node நம்பவில்லை; தற்காலிகத் தீர்வுகளைத் தேடாமல், மின்னஞ்சல் server-ன் certificate-ஐச் சரிசெய்யவும்.

Dashboard "Connecting..." நிலையிலேயே நிற்கிறது, console-ல் WebSocket connection ... failed பிழை காட்டுகிறது. Reverse proxy, WebSocket-ஐ upgrade செய்யவில்லை. Nginx-ல் Upgrade மற்றும் Connection "upgrade" headers-ஐச் சேர்க்கவும், அல்லது Traefik அல்லது Caddy போன்ற இயல்பாகவே அவற்றை forward செய்யும் proxy-ஐப் பயன்படுத்தவும். HTML கோப்புகள் சாதாரண HTTP GET மூலம் பதிவிறக்கம் செய்யப்படுவதால் அவை இயங்கும்; live socket-க்கு மட்டுமே இந்த upgrade தேவை.

Cert-expiry கண்காணிப்பு கருவி எச்சரிக்கை செய்யவில்லை அல்லது தவறாக எச்சரிக்கிறது. Ignore TLS/SSL Error தேர்வு செய்யப்பட்டிருக்கலாம், இது certificate சோதனையை முடக்கும்; அல்லது கண்காணிப்பு கருவி IP-ஐக் குறிவைப்பதால் SNI இல்லாமல் தவறான certificate-ஐப் படித்து Hostname/IP does not match certificate's altnames பிழையைக் காட்டலாம். Ignore தேர்வை நீக்கிவிட்டு, hostname மூலம் கண்காணிக்கவும்.

Logs-ல் SQLITE_BUSY அல்லது database disk image is malformed. /app/data volume, முறையான file locking வசதி இல்லாத filesystem-ல் (பொதுவாக NFS) உள்ளது; அதை local Docker volume-க்கு மாற்றி, backup-லிருந்து தரவை மீட்டெடுக்கவும்.

FAQ

எனது uptime monitor-ஐ நான் எங்கே இயக்க வேண்டும்?

அது கண்காணிக்கும் server-களிலிருந்து வேறொரு server-ல், முடிந்தால் வேறொரு provider அல்லது region-ல் இயக்குவது சிறந்தது. பயனர்களைப் போலவே, பொது இணையம் வழியாக hostname மூலம் அது server-களை அணுக வேண்டும். கண்காணிக்கும் கருவியும், அது கண்காணிக்கும் சேவைகளும் ஒரே server-ல் இருந்தால், அந்த server செயலிழக்கும்போது கண்காணிக்கும் கருவியும் செயலிழந்துவிடும். மேலும், server-ன் சுமை அதிகமாக இருக்கும்போது, சரியாக இயங்கும் சேவைகளைக் கூட அது "down" என்று தவறாகக் காட்டும். ஒரு சிறிய தனி VPS-ஐப் பயன்படுத்துவது இந்த இரண்டு சிக்கல்களையும் தவிர்க்கும்.

Telegram அல்லது email மூலம் alerts பெறுவது எப்படி?

Settings என்பதற்குச் சென்று Notifications-ல் புதிய channel-ஐச் சேர்க்கவும், பின் அதை ஒவ்வொரு monitor-உடனும் இணைக்கவும். Telegram-க்கு, @BotFather மூலம் ஒரு bot-ஐ உருவாக்கி, https://api.telegram.org/bot<token>/getUpdates-லிருந்து chat.id-ஐப் பெறவும். Email-க்கு, உங்கள் provider two-factor authentication பயன்படுத்தினால், SSL-க்கு 465 அல்லது STARTTLS-க்கு 587-ஐப் பயன்படுத்தி, app password-ஐ உள்ளிடவும். Test பொத்தானை அழுத்தி, செய்தி வந்து சேருகிறதா என்பதை உறுதிப்படுத்திய பின் அதைப் பயன்படுத்தத் தொடங்கவும்.

Uptime Kuma மூலம் cron job அல்லது backup script-ஐக் கண்காணிக்க முடியுமா?

ஆம், அதற்கு Push monitor-ஐப் பயன்படுத்தலாம்: Uptime Kuma உங்களுக்கு ஒரு URL-ஐ வழங்கும். அதை உங்கள் script-ன் இறுதியில் curl செய்யவும், அப்போதுதான் script வெற்றிகரமாக முடிந்தால் மட்டும் அது இயங்கும். ஒருவேளை job தோல்வியடைந்தாலோ அல்லது server செயலிழந்தாலோ, heartbeat வந்து சேராது; குறிப்பிட்ட கால இடைவெளிக்குப் பிறகு உங்களுக்கு alert வரும். ஒரு scheduled job உண்மையில் இயங்கியதா என்பதை அறிய இதுவே நம்பகமான வழி, ஏனெனில் வெளிப்புறக் கண்காணிப்பு கருவியால் script-க்குள் நடப்பதைப் பார்க்க முடியாது.

Uptime Kuma vs Zabbix, எதை நான் பயன்படுத்த வேண்டும்?

"சேவை இயங்குகிறதா, வெளிப்புறத்திலிருந்து அணுக முடிகிறதா, எனக்கு alert வந்ததா" என்ற கேள்விகளுக்கு Uptime Kuma பத்து நிமிடங்களில் பதில் அளிக்கும், இதற்கு மிகக் குறைந்த வளங்களே (resources) போதும்; மேலும் இதில் status page வசதியும் உள்ளது. CPU, memory, disk பயன்பாடு போன்ற விரிவான தரவுகளை இது சேகரிக்காது. அத்தகைய தரவுகளுக்கு, முழுமையான Zabbix monitoring server போன்ற agent-அடிப்படையிலான, சற்று கூடுதல் திறன் கொண்ட கருவி தேவைப்படும். பல பயனர்கள் இரண்டையுமே பயன்படுத்துகிறார்கள். எதை நிறுவுவது என்பதில் இன்னும் குழப்பமா? 2026-ல் எவற்றை self-host செய்யலாம் என்ற எங்களது தொகுப்பு கண்காணிப்புத் தேவைகளைத் தெளிவாக விளக்கும்.

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