Uptime Kuma సెల్ఫ్-హోస్టెడ్ మానిటరింగ్ సెటప్ గైడ్

మీరు ఏమి నిర్మిస్తున్నారు

ఇది ఒక చిన్న కంటైనర్. ఇది బయటి నుండి మీ ఇతర సర్వర్లను మరియు వెబ్‌సైట్‌లను పర్యవేక్షిస్తుంది. ఏదైనా సర్వర్ స్పందించడం ఆగిపోయిన వెంటనే, ఇది మీకు ఇమెయిల్, Telegram, Discord లేదా webhook ద్వారా తెలియజేస్తుంది. Uptime Kuma అనేది SQLite ఫైల్‌తో పనిచేసే ఒకే ఒక Node ప్రాసెస్. కాబట్టి ఇది 256-512 MB RAM తో సులభంగా నడుస్తుంది. ఇది మీకు లైవ్ డాష్‌బోర్డ్, హిస్టరీ గ్రాఫ్‌లు మరియు పబ్లిక్ స్టేటస్ పేజీని అందిస్తుంది. దీని ఇన్‌స్టాలేషన్ పది లైన్ల Compose ఫైల్‌తో పూర్తవుతుంది. ఇక్కడ ముఖ్యమైన విషయం ఏమిటంటే, మీరు దీన్ని ఎక్కడ రన్ చేస్తున్నారు మరియు మీ అలర్ట్‌లు టెస్ట్ చేసినప్పుడు ఎప్పుడైనా పనిచేశాయా అనేది. ఎందుకంటే, మీరు పరీక్షించని మానిటర్ ఏమీ లేకపోవడం కంటే ప్రమాదకరం: ఇది ఏమీ పర్యవేక్షించకుండానే, మీరు సురక్షితంగా ఉన్నామనే భ్రమను కలిగిస్తుంది.

మానిటర్‌ను అవుటేజ్ ప్రభావం పడని చోట రన్ చేయండి

ఈ ఒక్క నిర్ణయం మొత్తం వ్యవస్థ యొక్క పనితీరును నిర్ణయిస్తుంది, కాబట్టి దీనికి ప్రాధాన్యత ఇవ్వాలి. Uptime Kuma ను అది పర్యవేక్షించే సర్వర్‌లోనే రన్ చేయవద్దు. మానిటర్ పర్యవేక్షించే సర్వర్‌లోనే ఉంటే, ఆ సర్వర్ ఆగిపోవడం లేదా మెమరీ అయిపోవడం వంటి సమస్యలు తలెత్తినప్పుడు మానిటర్ కూడా ఆగిపోతుంది. దీనివల్ల మీకు ఎటువంటి హెచ్చరిక అందదు: మానిటర్ ఆగిపోవడం వల్ల వచ్చే నిశ్శబ్దం, అంతా బాగుందనే సంకేతంలా కనిపిస్తుంది. సర్వర్ పని చేస్తున్నప్పుడు కూడా ఒక చిన్న ఇబ్బంది ఉంటుంది: localhost ను పర్యవేక్షించే మానిటర్ అదే CPUని వాడుకుంటుంది. సర్వర్‌లో లోడ్ పెరిగినప్పుడు మానిటర్ చెక్ టైమ్ అవుట్ అయ్యి, సర్వర్ down అయినట్లు తప్పుడు హెచ్చరికను ఇస్తుంది, కానీ నిజానికి వినియోగదారులకు సేవలు అందుతూనే ఉంటాయి.

కాబట్టి Uptime Kuma ను అది పర్యవేక్షించే సర్వర్ కంటే వేరొక VPSలో రన్ చేయండి. వీలైతే వేరే ప్రొవైడర్ లేదా వేరే రీజియన్‌లో ఉంచడం మంచిది. మీ వినియోగదారులు ఎలాగైతే పబ్లిక్ ఇంటర్నెట్ ద్వారా, హోస్ట్‌నేమ్ ఉపయోగించి సేవలను పొందుతారో, మానిటర్ కూడా అలాగే యాక్సెస్ చేయాలి. దీని కోసం తక్కువ ధరలో లభించే ఒక చిన్న VPS సరిపోతుంది, ఒకే మానిటరింగ్ VPS మీ అన్ని సర్వర్లను పర్యవేక్షించగలదు. మీరు హోస్ట్ చేసే భారీ అప్లికేషన్ల విషయంలో ఈ విభజన చాలా ముఖ్యం. ఉదాహరణకు, PhotoPrism లేదా Immich ఫోటో లైబ్రరీ వంటివి కొత్త డేటాను ఇండెక్స్ చేస్తున్నప్పుడు గంటల తరబడి CPUని పూర్తిగా వాడుకుంటాయి. అదే హార్డ్‌వేర్‌పై మానిటర్ ఉంటే, సర్వర్ బిజీగా ఉన్నప్పుడు కూడా అది సేవలు ఆగిపోయాయని తప్పుడు అలారాలు ఇస్తుంది. Kuma స్వయంగా ఆగిపోతే గుర్తించడానికి, వేరే చోట ఉన్న cron ద్వారా push heartbeat ను సెటప్ చేయండి.

ముందస్తు అవసరాలు మరియు పరిమాణం (Sizing)

• 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 IPని సూచించాలి). ఇది మీకు 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 అని లాగ్ చేస్తుంది మరియు నిశ్శబ్దంగా మారుతుంది. ఆ ఫైల్‌లో మూడు విషయాలు ఉద్దేశపూర్వకంగా ఉంచబడ్డాయి.

127.0.0.1:3001:3001, 3001:3001 కాదు. Docker పోర్ట్‌లను DNAT రూల్స్‌తో పబ్లిష్ చేస్తుంది, ఇవి ufw ప్యాకెట్‌ను చూడకముందే అమలు చేయబడతాయి. కాబట్టి, కేవలం 3001:3001 అని ఉంచితే, మీ ఫైర్‌వాల్‌తో సంబంధం లేకుండా మీ డాష్‌బోర్డ్ పబ్లిక్ ఇంటర్నెట్‌లోకి వస్తుంది. లూప్‌బ్యాక్ (loopback) కు బైండ్ చేయడం ద్వారా దానిని ప్రైవేట్‌గా ఉంచవచ్చు, కేవలం రివర్స్ ప్రాక్సీ మాత్రమే బయటకు కనిపిస్తుంది; ప్రైవేట్ ఇన్‌స్టాన్స్ ప్రాక్సీని దాటవేసి self-hosted WireGuard VPN ద్వారా 3001 ని చేరుకోగలదు.

/app/data వద్ద ఒక named volume. Uptime Kuma గుర్తుంచుకునే ప్రతిదీ, అంటే SQLite డేటాబేస్, మీ మానిటర్లు, నోటిఫికేషన్ సెట్టింగ్‌లు మరియు స్టేటస్-పేజీ లోగోలు, అక్కడే ఉంటాయి. అది పోతే మీరు ఖాళీ అడ్మిన్ స్క్రీన్‌తో ప్రారంభించాల్సి వస్తుంది; మీరు బ్యాకప్ తీసుకోవలసిన ఏకైక విషయం ఇదే.

ఇమేజ్ ఒక మేజర్ ట్యాగ్, :2 కి పిన్ చేయబడింది. ఇది ప్రస్తుత స్టేబుల్ లైన్; దీనిని కాపీ చేసే ముందు సరికొత్త మేజర్ వెర్షన్ కోసం Docker Hub ని తనిఖీ చేయండి. latest వంటి మారుతున్న ట్యాగ్‌లను ఎప్పుడూ ట్రాక్ చేయవద్దు, ఎందుకంటే ప్రాజెక్ట్ దీనిని నిరుత్సాహపరుస్తుంది. ఈ ఇమేజ్‌పై మేజర్-వెర్షన్ జంప్ అనేది ఒక వన్-వే డేటాబేస్ మైగ్రేషన్, దీనిని మీరు ఉద్దేశపూర్వకంగానే చేయాలి, రొటీన్ పుల్ (pull) సమయంలో పొరపాటున జరగకూడదు.

ఒక హెచ్చరిక: /app/data తప్పనిసరిగా POSIX ఫైల్ లాక్‌లు ఉన్న ఫైల్‌సిస్టమ్‌పై ఉండాలి. లోకల్ Docker వాల్యూమ్ అయితే పర్వాలేదు; NFS పై అయితే SQLite డేటాబేస్ కరప్ట్ అవుతుంది మరియు మీకు SQLITE_BUSY మరియు database disk image is malformed వస్తాయి, కాబట్టి నెట్‌వర్క్ షేర్‌ను ఎప్పుడూ ఉపయోగించవద్దు.

మొదటి రన్: అడ్మిన్ ఖాతాను సృష్టించడం

మీ proxy ద్వారా https://status.example.com వద్ద ఉన్న instance ను బ్రౌజ్ చేయండి, లేదా SSH tunnel ద్వారా వెళ్ళండి: 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). హోస్ట్, పోర్ట్, ఎన్‌క్రిప్షన్, యూజర్‌నేమ్, పాస్‌వర్డ్, ఒక 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 అని టైప్ చేసి, బాట్ టోకెన్‌ను కాపీ చేయండి. మీ చాట్ ఐడి కోసం, కొత్త బాట్‌కు ఒకసారి సందేశం పంపి, https://api.telegram.org/bot<token>/getUpdates ను ఓపెన్ చేసి, JSON నుండి chat.id ను చదవండి. మీరు మొదట సందేశం పంపని బాట్ యొక్క getUpdates ఖాళీగా ఉంటుంది మరియు సందేశం పంపడానికి ఎక్కడా అవకాశం ఉండదు.

Discord. ఛానెల్‌లో, Edit Channel ఆపై Integrations ఆపై Webhooks ఆపై New Webhook ఓపెన్ చేయండి, URL ను కాపీ చేసి, దానిని Discord నోటిఫికేషన్‌గా పేస్ట్ చేయండి.

Generic webhook. మరేదైనా సేవ కోసం, అంటే Slack ఇన్‌కమింగ్ వెబ్‌హుక్, కస్టమ్ ఎండ్‌పాయింట్, హోమ్-ఆటోమేషన్ హుక్ వంటి వాటి కోసం, Webhook రకం మీరు అందించిన URL కు JSON పేలోడ్‌ను POST చేస్తుంది. అలాగే, బండిల్ చేయబడిన Apprise ఇంటిగ్రేషన్ జాబితాలోని తొంభైకి పైగా ఇతర సేవలను కవర్ చేస్తుంది. ఒకవేళ సర్వర్ డౌన్ అయినప్పుడు మరియు మీ ఫోన్‌కు మధ్య మూడవ పక్షం (third party) ఉండకూడదని మీరు భావిస్తే, అంతర్నిర్మిత ntfy రకాన్ని ఎంచుకుని, దానిని మీరు స్వయంగా నడుపుతున్న ntfy సర్వర్ వైపు మళ్లించండి. ఇది మీరు ఎండ్-టు-ఎండ్ నియంత్రించే ఛానెల్ ద్వారా మీ హ్యాండ్‌సెట్‌కు పుష్ నోటిఫికేషన్‌లను పంపుతుంది.

ఒక్కో రకమైన మానిటర్‌ను జోడించండి

Add New Monitor పై క్లిక్ చేసి, ఒక రకాన్ని ఎంచుకోండి. Friendly Name, Check Interval (60 సెకన్లు సరైనది), Retries ("down" అని చూపడానికి ముందు వరుసగా ఎన్నిసార్లు విఫలం కావాలో నిర్ణయించేవి; 2 లేదా 3 ఉంచితే ఒక ప్యాకెట్ డ్రాప్ అయినంత మాత్రాన అలర్ట్ రాదు), మరియు పంపాల్సిన నోటిఫికేషన్లను సెట్ చేయండి. మీరు ఉపయోగించే రకాలు ఇవే:

• HTTP(s). పూర్తి URL. సర్వర్ నుండి ఆమోదయోగ్యమైన status code వస్తే అది "up" అని అర్థం (డిఫాల్ట్‌గా 200-299; మీకు 301 లేదా 401 సాధారణం అయితే Accepted Status Codes లో వాటిని జోడించండి). వెబ్‌సైట్లు మరియు APIల కోసం ఇది ప్రధానమైనది.
• HTTP(s) - Keyword. ఇది కూడా HTTP(s) లాంటిదే, కానీ "up" అని చూపడానికి పేజీ బాడీలో ఒక నిర్దిష్ట string ఉండాలి (లేదా Invert ఆప్షన్ వాడితే ఆ string ఉండకూడదు). సాధారణ HTTP చెక్ "Error establishing a database connection" అని ఉన్నా కూడా పేజీని healthy అని చూపిస్తుంది, కానీ ఈ పద్ధతి ద్వారా అటువంటి 200 OK ఎర్రర్లను పట్టుకోవచ్చు. బ్రౌజర్ ఫ్రంట్ ఎండ్ వేరే బ్యాకెండ్‌తో మాట్లాడేటప్పుడు ఇది చాలా ఉపయోగకరం. ఉదాహరణకు, Jellyfin పైన నడిచే Halcyon video-store skin, దీని పేజీ షెల్ 200 అని చూపిస్తుంది, కానీ వెనుక ఉన్న మీడియా సర్వర్ అందుబాటులో లేకపోవచ్చు.
• TCP Port. HTTP కాని సేవల కోసం హోస్ట్ మరియు పోర్ట్‌కు నేరుగా TCP కనెక్షన్ చేయడం: SSH కోసం 22, Postgres కోసం 5432, SMTP సర్వర్ కోసం 25, లేదా గేమ్ సర్వర్లు.
• Ping. ICMP echo: ఇది తక్కువ ఖర్చుతో కూడిన రీచబిలిటీ మరియు లేటెన్సీ చెక్. అయితే, చాలా నెట్‌వర్క్‌లు మరియు క్లౌడ్ ఫైర్‌వాల్‌లు ICMPని బ్లాక్ చేస్తాయి. కాబట్టి, పింగ్ మానిటర్ ఎరుపు రంగులో ఉంటే అది "హోస్ట్ డౌన్" అని కావచ్చు లేదా "ప్రొవైడర్ పింగ్‌ను బ్లాక్ చేస్తున్నారు" అని కావచ్చు; దీన్ని నిర్ధారించుకోవడానికి TCP మానిటర్‌ను వాడండి.
• DNS. మీరు పేర్కొన్న రిజాల్వర్‌ను ఉపయోగించి ఒక రికార్డును (A, AAAA, MX, TXT మొదలైనవి) రిజాల్వ్ చేస్తుంది. సమాధానాన్ని సరిచూసుకోవడం ద్వారా రిజిస్ట్రార్ లేదా DNS సమస్యలను ముందుగానే గుర్తించవచ్చు.
• Push. ఇది ఇన్సైడ్-అవుట్ మానిటర్, దీని గురించి తర్వాత చర్చిస్తాము.

Push (heartbeat) మానిటర్ ఉపయోగించి cron job ను పర్యవేక్షించడం

పైన పేర్కొన్న మానిటర్లన్నీ మీ సర్వీసును బయటి నుంచి చేరుకుంటాయి. Push మానిటర్ దీనికి భిన్నంగా పనిచేస్తుంది: Uptime Kuma వేచి ఉంటుంది, మరియు మీ job "నేను పూర్తయ్యాను" అని దానికి సమాచారం పంపుతుంది. బ్యాకప్ లేదా cron job ను పర్యవేక్షించడానికి ఇది అత్యంత ఖచ్చితమైన మార్గం: 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-plus-retries సమయం ముగిసిన తర్వాత, Uptime Kuma ఆ మానిటర్‌ను down స్థితికి మారుస్తుంది మరియు మీకు అలర్ట్ పంపుతుంది. ఆ push token ను రహస్యంగా ఉంచండి: అది తెలిసిన ఎవరైనా తప్పుడు heartbeat ను పంపగలరు.

పబ్లిక్ స్టేటస్ పేజీని నిర్మించడం

స్టేటస్ పేజీ అనేది వినియోగదారులకు కనిపించే వీక్షణ: ఇది మీ డాష్‌బోర్డ్‌ను బయటపెట్టకుండా, ఏ సేవలు అందుబాటులో ఉన్నాయి మరియు వాటి ఇటీవలి చరిత్రను చూపుతుంది. Status Pages then New Status Page కు వెళ్ళండి, దానికి ఒక పేరు మరియు స్లగ్‌ను (/status/main వంటి పబ్లిక్ పాత్) ఇవ్వండి, మీకు కావలసిన మానిటర్లను "Websites" మరియు "APIs" వంటి గ్రూపుల్లోకి డ్రాగ్ చేయండి, ఒక లోగో మరియు చిన్న వివరణను జోడించి, Save చేయండి. మీరు ఈ పేజీని సొంత డొమైన్‌కు బైండ్ చేయవచ్చు, తద్వారా status.example.com ద్వారా అది నేరుగా అందుబాటులోకి వస్తుంది.

రెండు జాగ్రత్తలు: మీరు పబ్లిక్ చేయడానికి సిద్ధంగా ఉన్న మానిటర్లను మాత్రమే జోడించండి, ఎందుకంటే ఒక సేవ ఉనికిలో ఉందని మరియు అది పని చేస్తుందో లేదో స్టేటస్ పేజీ వెల్లడిస్తుంది; డాష్‌బోర్డ్ మీ లాగిన్ వెనుక సురక్షితంగా ఉంటుంది, కానీ స్టేటస్ పేజీ ఉద్దేశపూర్వకంగానే పబ్లిక్‌గా ఉంటుంది మరియు దానికి ఎటువంటి ఆథెంటికేషన్ అవసరం లేదు.

దీనిని TLS కలిగిన reverse proxy వెనుక ఉంచండి మరియు websockets ను గమనించండి

పబ్లిక్ ఇన్‌స్టాన్స్ కోసం, TLS మరియు hostname కోసం loopback-bound కంటైనర్ ముందు ఒక reverse proxyని ఉంచండి. అందరూ పొరబడే ముఖ్యమైన విషయం: Uptime Kuma యొక్క UI ఒక live Socket.IO అప్లికేషన్, కాబట్టి proxy తప్పనిసరిగా WebSocket కనెక్షన్‌ను upgrade చేయాలి. ఇది మిస్ అయితే పేజీ లోడ్ అవుతుంది కానీ కనెక్ట్ అవ్వదు; డాష్‌బోర్డ్ "Connecting..." అని చూపిస్తూనే ఉంటుంది, live heartbeats అప్‌డేట్ అవ్వవు మరియు బ్రౌజర్ కన్సోల్ WebSocket connection to 'wss://.../socket.io/...' failedని చూపిస్తుంది.

nginx మరియు certbotలను ఇన్‌స్టాల్ చేయండి, ఆపై loopback పోర్ట్‌కు proxy చేసే vhostను రాయండి. ప్రస్తుతానికి దీనిని పోర్ట్ 80పై ఉంచండి మరియు ఆ తర్వాత certbot ద్వారా TLSను జోడించండి; challenge, renewal timer మరియు వాటి failure modes గురించి 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 చేయండి, కాన్ఫిగరేషన్‌ను పరీక్షించండి, ఆపై certbot ద్వారా ఆ బ్లాక్‌ను 443 పోర్ట్ కోసం 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 కట్ చేయకుండా ఆపుతుంది; certbot ఈ రెండింటినీ అది సృష్టించే 443 బ్లాక్‌లోకి కాపీ చేస్తుంది. మీరు ఇప్పటికే ఒకే proxy వెనుక అనేక కంటైనర్లను నడుపుతుంటే, container labels ద్వారా Traefik తో routing మరియు automatic TLS కూడా అదే పనిని చేస్తుంది మరియు డిఫాల్ట్‌గా WebSocket upgradesను forward చేస్తుంది.

మొత్తం vhostకు basic-auth పెట్టకండి, ఎందుకంటే అది పబ్లిక్ స్టేటస్ పేజీని మరియు /api/push ఎండ్‌పాయింట్‌ను కూడా లాక్ చేస్తుంది. Uptime Kuma యొక్క అంతర్నిర్మిత లాగిన్‌ను అలాగే ఉంచండి, ఇది ఇంటర్నెట్‌కు అందుబాటులో ఉంటే repeated failed logins కోసం fail2ban పర్యవేక్షణను జోడించండి, మరియు డాష్‌బోర్డ్ పబ్లిక్‌గా ఉండాల్సిన అవసరం లేకపోతే, proxyని తీసివేసి VPN ద్వారా దానిని యాక్సెస్ చేయండి.

TLS సర్టిఫికేట్ గడువు ముగింపును పర్యవేక్షించడం

TLS సర్టిఫికేట్ గడువు ముగిసేలోపే HTTP(s) మానిటర్ మిమ్మల్ని హెచ్చరించగలదు: Certificate Expiry Notification ఆప్షన్‌ను ఎంచుకుంటే, నిర్ణీత రోజుల ముందుగానే Uptime Kuma మీకు అలర్ట్ పంపుతుంది. అయితే, రెండు పొరపాట్ల వల్ల ఇది తప్పుడు సమాచారాన్ని ఇవ్వవచ్చు. మానిటరింగ్‌ను IP ద్వారా కాకుండా hostname ద్వారా చేయండి, లేదంటే SNI లేని అభ్యర్థన సర్వర్ యొక్క default సర్టిఫికేట్‌ను మాత్రమే చూస్తుంది, దీనివల్ల 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 మొదటిసారి ప్రారంభమైనప్పుడు ఏదైనా 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 ఏ హోస్ట్‌పై నడుస్తుందో అదే హోస్ట్‌ను అది లక్ష్యంగా చేసుకుంటే, CPU లేదా మెమరీ పెరగడం వల్ల చెక్ విఫలమై ఉండవచ్చు, సేవ విఫలం కాలేదు. మానిటర్‌ను వేరొక VPSకి మార్చి, పబ్లిక్ హోస్ట్‌నేమ్‌ను లక్ష్యంగా చేసుకోండి.

connect ECONNREFUSED 127.0.0.1:443 (లేదా ఏదైనా పోర్ట్). ఆ పోర్ట్‌లో ఏదీ వినడం లేదు (listening): సేవ ఆగిపోయి ఉండవచ్చు, లేదా మీరు కంటైనర్ లోపల నుండి localhost ను పర్యవేక్షిస్తున్నారు, అక్కడ 127.0.0.1 అంటే మీ సర్వర్ కాదు, కంటైనర్ మాత్రమే. లూప్‌బ్యాక్ (loopback) కాకుండా పబ్లిక్ హోస్ట్‌నేమ్‌ను పర్యవేక్షించండి.

Invalid login: 535-5.7.8 Username and Password not accepted ఈమెయిల్ టెస్ట్‌లో వస్తే. SMTP ఆధారాలు (credentials) తప్పుగా ఉన్నాయి, లేదా ప్రొవైడర్ మీ ఖాతా పాస్‌వర్డ్‌కు బదులుగా యాప్-నిర్దిష్ట పాస్‌వర్డ్ (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 నమ్మని సర్టిఫికేట్‌ను అందిస్తోంది; సమస్యను దాటవేయడానికి బదులుగా మెయిల్ సర్వర్ సర్టిఫికేట్‌ను సరిచేయండి.

Dashboard "Connecting..." వద్ద ఆగిపోవడం, కన్సోల్‌లో WebSocket connection ... failed కనిపించడం. రివర్స్ ప్రాక్సీ WebSocket ను అప్‌గ్రేడ్ చేయడం లేదు. nginxలో Upgrade మరియు Connection "upgrade" హెడర్‌లను జోడించండి, లేదా Traefik లేదా Caddy వంటి డిఫాల్ట్‌గా వాటిని ఫార్వర్డ్ చేసే ప్రాక్సీని ఉపయోగించండి. HTML లోడ్ అవుతుంది ఎందుకంటే అది సాధారణ HTTP GET; లైవ్ సాకెట్‌కు మాత్రమే అప్‌గ్రేడ్ అవసరం.

Cert-expiry మానిటర్ హెచ్చరించకపోవడం లేదా తప్పుగా హెచ్చరించడం. Ignore TLS/SSL Error ఎంపిక చేయబడి ఉండవచ్చు, ఇది సర్టిఫికేట్ తనిఖీని నిలిపివేస్తుంది, లేదా మానిటర్ IPని లక్ష్యంగా చేసుకుని SNI లేకపోవడం వల్ల తప్పు సర్టిఫికేట్‌ను చదువుతోంది, దీనివల్ల Hostname/IP does not match certificate's altnames కనిపిస్తుంది. Ignore ఎంపికను తీసివేసి, హోస్ట్‌నేమ్ ద్వారా పర్యవేక్షించండి.

SQLITE_BUSY లేదా database disk image is malformed లాగ్స్‌లో కనిపిస్తే. /app/data వాల్యూమ్ సరైన ఫైల్ లాకింగ్ లేని ఫైల్‌సిస్టమ్‌పై ఉంది, సాధారణంగా ఇది NFS; దానిని లోకల్ Docker వాల్యూమ్‌కు తరలించి, బ్యాకప్ నుండి పునరుద్ధరించండి.

FAQ

నా uptime monitor ను ఎక్కడ రన్ చేయాలి?

అది పర్యవేక్షించే సర్వర్లకు భిన్నమైన సర్వర్‌పై, వీలైతే వేరే ప్రొవైడర్ లేదా రీజియన్‌లో రన్ చేయాలి. మీ వినియోగదారులు ఎలాగైతే పబ్లిక్ ఇంటర్నెట్ ద్వారా hostname తో కనెక్ట్ అవుతారో, మీరు కూడా అలాగే పర్యవేక్షించాలి. ఒకవేళ monitor మరియు అది పర్యవేక్షించే సేవలు ఒకే సర్వర్‌లో ఉంటే, సర్వర్ డౌన్ అయినప్పుడు monitor కూడా ఆగిపోతుంది. అలాగే, సర్వర్ ఓవర్‌లోడ్ అయినప్పుడు సేవలు బాగున్నా కూడా monitor "down" అని చూపిస్తుంది. ఒక చిన్న VPS ను విడిగా వాడటం వల్ల ఈ సమస్యలు ఉండవు.

Telegram లేదా email ద్వారా alerts ఎలా పొందాలి?

Settings లోని Notifications విభాగానికి వెళ్లి channel ను జోడించండి, ఆపై దానిని ప్రతి monitor కు అనుసంధానించండి. Telegram కోసం, @BotFather ద్వారా ఒక bot ను సృష్టించి, https://api.telegram.org/bot<token>/getUpdates నుండి chat.id ను పొందండి. Email కోసం, SSL వాడితే 465 ను లేదా STARTTLS వాడితే 587 ను ఉపయోగించండి. మీ ప్రొవైడర్ two-factor authentication ఉపయోగిస్తుంటే, app password ను వాడండి. Alert సెట్టింగ్స్ మీద నమ్మకం ఉంచే ముందు, Test బటన్ నొక్కి సందేశం అందుతుందో లేదో నిర్ధారించుకోండి.

Uptime Kuma తో cron job లేదా backup script ను పర్యవేక్షించవచ్చా?

అవును, దీని కోసం Push monitor ను వాడాలి: Uptime Kuma మీకు ఒక URL ఇస్తుంది. ఆ script విజయవంతంగా పూర్తయినప్పుడు మాత్రమే అది కాల్ అయ్యేలా, script చివరలో ఆ URL ను curl చేయండి. ఒకవేళ job విఫలమైనా లేదా సర్వర్ డౌన్ అయినా, heartbeat అందదు కాబట్టి నిర్ణీత సమయం తర్వాత మీకు alert వస్తుంది. షెడ్యూల్ చేసిన job నిజంగా రన్ అయిందో లేదో తెలుసుకోవడానికి ఇదే నమ్మదగిన మార్గం, ఎందుకంటే బయటి నుండి చేసే check ద్వారా లోపల ఏం జరుగుతుందో తెలియదు.

Uptime Kuma మరియు Zabbix లలో దేనిని ఎంచుకోవాలి?

Uptime Kuma అనేది "సర్వర్ అందుబాటులో ఉందా, బయటి నుండి ఎలా కనిపిస్తోంది, alert వచ్చిందా" అనే ప్రశ్నలకు పది నిమిషాల్లో సమాధానం ఇస్తుంది. దీనికి చాలా తక్కువ వనరులు సరిపోతాయి మరియు status page కూడా ఉంటుంది. ఇది CPU, memory, disk వంటి లోతైన metrics ను లేదా పెద్ద నెట్‌వర్క్ పరికరాల గణాంకాలను సేకరించదు. అటువంటి పనుల కోసం పూర్తి స్థాయి Zabbix monitoring server వంటి agent-based సాధనాలు అవసరం. చాలామంది వీటిని రెండింటినీ కలిపి వాడుతుంటారు. అసలు దేనిని self-host చేయాలో ఇంకా నిర్ణయించుకోలేదా? 2026లో self-host చేయాల్సిన సేవల జాబితా మీకు సహాయపడుతుంది.