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

Uptime Kuma Docker கண்காணிப்பு அமைப்பு

Q: Telegram அல்லது மின்னஞ்சல் மூலம் எப்படி எச்சரிக்கைகளைப் பெறுவது?

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

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

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

Uptime Kuma-வை Docker-இல் இயக்கி websites, ports, DNS, cron jobs ஆகியவற்றைக் கண்காணிக்கலாம். email, Telegram வழியாக எச்சரிக்கை பெற்று status page வெளியிட முழு வழிகாட்டி.

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

ஒரு சிறிய கொள்கலன். இது உங்கள் மற்ற சேவையகங்கள் மற்றும் இணையதளங்களை வெளியிலிருந்து கவனிக்கிறது. ஏதாவது ஒன்று பதிலளிக்க நிற்கும்போது உடனே உங்களுக்குத் தெரிவிக்கிறது. இந்தத் தகவல் email, Telegram, Discord அல்லது webhook வழியாக வரும். Uptime Kuma என்பது ஒரு Node செயல்முறை. இதற்குப் பின்னணியாக ஒரு SQLite கோப்பு உள்ளது. எனவே இது 256-512 MB RAM-இல் எளிதாக இயங்கும். இது ஒரு நேரடி டாஷ்போர்டு, வரலாற்று வரைபடங்கள் மற்றும் பொதுநிலை பக்கத்தைத் தருகிறது. நிறுவல் பத்து வரிகொண்ட Compose கோப்பு மட்டுமே. உண்மையில் முக்கியமானது இதை நீங்கள் எங்கு இயக்குகிறீர்கள் மற்றும் உங்கள் எச்சரிக்கைகள் சோதனையில் எப்போதாவது இயங்கியதா என்பதே. ஏனெனில் நீங்கள் சோதித்து உறுதி செய்யாத கண்காணிப்பு கண்காணிப்பே இல்லாததை விட மோசம். அது எதையும் கவனிக்காமல் உங்களுக்குப் பாதுகாப்பு இருப்பது போன்ற ஒரு பிரமையை உருவாக்கும்.

கண்காணிப்பை சேவை தடை அடையாத இடத்தில் இயக்கவும்

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

எனவே Uptime Kuma-வை அது கண்காணிக்கும் சேவையகத்திலிருந்து மாறுபட்ட ஒரு VPS-ல் இயக்கவும். வேறு வழங்குநர் அல்லது பகுதியில் இயக்குவது சிறந்தது. உங்கள் பயனர்கள் சேவையை அணுகும் வழியிலேயே கண்காணிப்பு கருவியும் அதை அணுகட்டும்: பொது இணையத்தின் வழியாக, hostname-ஐ அடிப்படையாகக் கொண்டு. ஒரு மலிவான instance போதுமானது. ஒரு சிறிய கண்காணிப்பு 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 உங்கள் ஃபயர்வாலைப் பொருட்படுத்தாமல் உங்கள் டாஷ்போர்டைப் பொது இணையத்தில் வைக்கிறது. loopback-க்குப் பிணைப்பது அதைத் தனிப்பட்டதாக வைத்திருக்கும்; வெளியே reverse proxy மட்டுமே தெரியும். ஒரு தனிப்பட்ட instance proxy-ஐத் தவிர்த்து சுயமாக ஹோஸ்ட் செய்யப்பட்ட WireGuard VPN வழியாக 3001-ஐ அடையலாம்.

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

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

ஒரு எச்சரிக்கை: /app/data POSIX கோப்புப் பூட்டுகளுடன் கூடிய கோப்பு முறைமையில் இருக்க வேண்டும். உள்ளூர் Docker volume போதுமானது; NFS-ல் SQLite டேட்டாபேஸ் சேதமடைந்து SQLITE_BUSY மற்றும் database disk image is malformed கிடைக்கும், எனவே ஒரு போதும் நெட்வொர்க் பகிர்வைப் பயன்படுத்த வேண்டாம்.

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

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

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

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

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

Email (SMTP). host, port, encryption, username, password, ஒரு 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 ஐ அனுப்பவும், 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 ஒருங்கிணைப்பு கையாளுகிறது.

கண்காணிப்புகளைச் சேர்க்கவும், ஒரு சமயத்தில் ஒரு வகை

Add New Monitor என்பதைச் சொடுக்கவும். ஒரு வகையைத் தேர்ந்தெடுக்கவும். Friendly Name, Check Interval (60 விநாடிகள் பொருத்தமானது), 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 கண்காணிப்பு "புரவலன் செயலிழந்தது" அல்லது "வழங்குநர் ping-ஐத் தடுக்கிறார்" என்பதைக் குறிக்கலாம்; ஒரு TCP கண்காணிப்பு மூலம் உறுதிப்படுத்தவும்.
DNS. நீங்கள் குறிப்பிடும் ஒரு resolver-க்கு எதிராக ஒரு பதிவை (A, AAAA, MX, TXT போன்றவற்றை) தீர்க்கிறது. விடையை உறுதிப்படுத்த முடியும்; இது registrar அல்லது DNS சேவை தடையை ஆரம்பத்திலேயே கண்டறியும்.
Push. தலைகீழான கண்காணிப்பு; அடுத்ததாக விளக்கப்படுகிறது.

ஒரு cron வேலையை push (heartbeat) மானிட்டர் மூலம் கண்காணித்தல்

மேலே உள்ள ஒவ்வொரு மானிட்டரும் வெளியிலிருந்து உங்கள் சேவைக்குள் அணுகுகிறது. ஒரு 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 நின்றுவிடுகிறது, மேலும் இடைவெளி மற்றும் மறுமுயற்சி சாளரம் கடந்ததும், Uptime Kuma மானிட்டரை down நிலைக்கு மாற்றி உங்களுக்கு எச்சரிக்கை அனுப்புகிறது. அந்த push token-ஐ ஒரு ரகசியமாகக் கருதவும்: அதை வைத்திருப்பவர் எவரும் ஒரு ஆரோக்கியமான heartbeat-ஐ போலி அமைக்க முடியும்.

பொது நிலைப் பக்கத்தை உருவாக்கவும்

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

இரண்டு எச்சரிக்கைகள்: நீங்கள் பொதுவாகக் காட்டத் தயாராக இருக்கும் monitors-ஐ மட்டுமே சேர்க்கவும். ஏனெனில் ஒரு நிலைப் பக்கம் ஒரு சேவை இருப்பதையும் அது இயங்குகிறதா இல்லையா என்பதையும் வெளிப்படுத்தும். டாஷ்போர்டு உங்கள் login-க்குப் பின்னால் பாதுகாக்கப்பட்டிருக்கும். ஆனால் நிலைப் பக்கம் வெளிப்படையாகப் பொதுவானது. அதற்கு 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-இலிருந்து 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 ப்ளாக்கில் இரண்டையும் நகலெடுக்கிறது. நீங்கள் ஏற்கனவே ஒரு ப்ராக்ஸிக்குப் பின் பல கன்டெய்னர்களை இயக்கினால், தானியங்கி TLS உடன் அவற்றை Traefik வழியாக ரூட் செய்தல் அதே செயலை கன்டெய்னர் லேபிள்களுடன் செய்கிறது மற்றும் இயல்பாகவே WebSocket அப்கிரேடுகளை ஃபார்வர்டு செய்கிறது.

முழு vhost க்கும் basic-auth பயன்படுத்த வேண்டாம், ஏனெனில் அது பொது நிலை பக்கம் மற்றும் /api/push எண்ட்பாயிண்ட் ஆகியவற்றையும் பூட்டிவிடும். Uptime Kuma-வின் உள்ளமைக்கப்பட்ட லாகினை வைத்திருக்கவும், இது இணையத்துடன் இணைக்கப்பட்டிருந்தால் தொடர்ச்சியான தோல்வியடைந்த லாகின்களுக்காக fail2ban கவனித்தல் சேர்க்கவும், மேலும் டாஷ்போர்டு பொதுவாக தேவையில்லை என்றால், ப்ராக்ஸியை நீக்கி ஒரு 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 கோப்பு ஒருங்கிணைந்த நிலையில் இருக்கும்:

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 முதல் தொடக்கத்தில் ஏதேனும் database migration-ஐ இயக்கும்; docker compose logs -f-ஐக் கவனிக்கவும். pull செய்வதற்கு முன்பு மேலே உள்ள backup-ஐ எடுக்கவும், மேலும் ஒரு major tag-க்குள் இருக்கவும்: :1-இலிருந்து :2-க்கு மாறுவது ஒரு வழி migration ஆகும், எனவே முதலில் backup எடுத்துக்கொண்டு release notes-ஐச் சரிபார்க்கவும்.

பிழை நிலைகள், நீங்கள் காணும் சரங்களுடன்

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

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

மின்னஞ்சல் சோதனையில் Invalid login: 535-5.7.8 Username and Password not accepted. SMTP சான்றளவு தகவல்கள் தவறாக உள்ளன. அல்லது provider-க்கு app-சார்ந்த கடவுச்சொல் தேவை. நீங்கள் கணக்கின் கடவுச்சொல்லை கொடுத்துள்ளீர்கள். app கடவுச்சொல்லை உருவாக்கி அதை ஒட்டவும்.

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

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

டாஷ்போர்டு "Connecting..." என்ற நிலையில் சிக்கிக்கொண்டது. console-ல் WebSocket connection ... failed காட்டப்படுகிறது. reverse proxy WebSocket-ஐ upgrade செய்யவில்லை. nginx-ல் Upgrade மற்றும் Connection "upgrade" headers-ஐ சேர்க்கவும். அல்லது அவற்றை இயல்பாக அனுப்பும் proxy-ஐ பயன்படுத்தவும். உதாரணம்: Traefik அல்லது Caddy. HTML ஏற்றப்படுகிறது. ஏனெனில் அது சாதாரண HTTP GET. live socket மட்டுமே upgrade தேவை.

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

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

FAQ

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

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

Telegram அல்லது மின்னஞ்சல் மூலம் எப்படி எச்சரிக்கைகளைப் பெறுவது?

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

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

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

Uptime Kuma அல்லது Zabbix — எதை இயக்க வேண்டும்?

Uptime Kuma பத்து நிமிடங்களில், கிட்டத்தட்ட எந்த வளமும் இல்லாமல், "அது வெளிப்புறமாக இயங்குகிறதா, எனக்கு எச்சரிக்கை வந்ததா" என்பதற்கு விடையளிக்கிறது. மேலும் ஒரு status page-ஐயும் தருகிறது. இது CPU, நினைவகம் மற்றும் வட்டின் போக்குகள் அல்லது fleet-அளவிலான வரம்புகள் போன்ற ஆழமான அளவீடுகளைச் சேகரிக்காது. அதற்காக, முழுமையான ஒரு Zabbix கண்காணிப்பு server என்பது அதிக எடையுள்ள, agent-அடிப்படையிலான கருவி. பலர் இரண்டையும் இயக்குகிறார்கள். இன்னும் எதை இயக்க வேண்டும் என்று முடிவு செய்யவில்லையா? 2026-ல் தாங்களே host செய்ய வேண்டியவை குறித்த நமது தொகுப்பு கண்காணிப்பைச் சரியான சூழலில் வைக்கிறது.

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