Jinsi ya kusakinisha Uptime Kuma kwenye Docker

Unachojenga

Container moja ndogo inayofuatilia seva na tovuti zako nyingine kutoka nje na kukutaarifu mara moja pale moja inapokoma kujibu, kupitia barua pepe, Telegram, Discord au webhook. Uptime Kuma ni mchakato mmoja wa Node unaotumia faili la SQLite, hivyo huendeshwa vyema kwa 256-512 MB ya RAM, na hukupa dashibodi ya moja kwa moja, grafu za historia na ukurasa wa hadhara wa hali ya huduma. Usakinishaji ni faili la Compose la mistari kumi; sehemu ya msingi ni pale unapoiendesha na kama arifa zako zimewahi kufanya kazi kwenye jaribio, kwa sababu kifuatiliaji ambacho hujathibitisha kuwa kinaweza kukufikia ni kibaya zaidi kuliko kutokuwa na chochote: hukufanya ujihisi uko salama wakati hakuna unachokifuatilia.

Endesha kifuatiliaji mahali ambapo hitilafu haiwezi kukifikia

Uamuzi huu ndio unaoamua kufanikiwa au kufeli kwa mfumo mzima, kwa hivyo unakuja kwanza. Usiendeshe Uptime Kuma kwenye seva moja na vitu inavyofuatilia. Ikiwa kifuatiliaji kipo kwenye seva inayofuatiliwa, tukio unalolihofia, kama seva hiyo kufa au kuishiwa na kumbukumbu, litakiua kifuatiliaji pia na hutapata tahadhari yoyote: ukimya kutoka kwa kifuatiliaji kilichokufa unaonekana sawa na "kila kitu kiko sawa." Kuna mtego mwingine fiche hata wakati seva ikiwa hai: kifuatiliaji kilichoelekezwa kwenye localhost kinashiriki CPU na mzigo wa kazi, kwa hivyo ongezeko la ghafla la mzigo (load spike) linaweza kusababisha ukaguzi wake kuchelewa na kuonyesha lengo kama down, hali ambayo ni kengele ya uongo, wakati watumiaji halisi wanahudumiwa vizuri.

Kwa hivyo, endesha Uptime Kuma kwenye VPS tofauti na ile inayofuatiliwa, ikiwezekana kwa mtoa huduma mwingine au eneo lingine, ikifikia huduma zako kama watumiaji wako wanavyofanya: kupitia mtandao wa umma (public internet), kwa kutumia hostname. Instance ya bei nafuu inatosha, na VPS moja ndogo ya ufuatiliaji inaweza kufuatilia seva zako zote. Utengano huo ni muhimu zaidi kwa programu nzito unazohifadhi, kwa sababu kitu kama maktaba ya picha ya PhotoPrism au Immich kinaweza kutumia CPU kwa saa nyingi wakati kikifanya index ya import mpya, na kifuatiliaji kinachoshiriki maunzi hayo kitatoa taarifa ya uongo kuhusu huduma ambayo ina shughuli nyingi tu. Ili kugundua Uptime Kuma iliyokufa yenyewe, ongeza push heartbeat kutoka kwa cron iliyo mahali pengine.

Mahitaji ya awali na ukubwa wa seva

• VPS mpya ya Ubuntu 24.04 yenye Docker Engine na plugin ya Compose v2, iliyosakinishwa kutoka kwenye hazina (repository) ya apt ya Docker yenyewe, siyo kifurushi cha docker.io cha distro, ambacho huwa kinachelewa kusasishwa.
• 256 MB ya RAM inatosha kuendesha monitors chache; 512 MB hadi 1 GB inatosha kwa monitors nyingi pamoja na reverse proxy, na CPU haitumiki sana kati ya ukaguzi mmoja na mwingine.
• Domain na rekodi ya DNS A (kwa mfano status.example.com inayoelekeza kwenye VPS), ikiwa tu unataka TLS na ukurasa wa hadhara wa hali ya huduma (status page). Instance ya faragha inaweza kuruka hatua ya DNS na kutumia VPN au SSH tunnel.
• Mtandao wa kutoka (outbound) kuelekea mahali ambapo tahadhari (alerts) zitatumwa: SMTP kwa mtoa huduma wako wa barua pepe, au HTTPS kwa Telegram na Discord.

Faili la Compose

Weka maudhui haya ndani ya /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:

Anzisha huduma na ufuatilie boot ya kwanza:

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

Kuanza kwa usahihi kutatoa logi ya Listening on 3001 na kisha huduma itatulia. Kuna mambo matatu ya makusudi katika faili hilo.

127.0.0.1:3001:3001, si 3001:3001. Docker huchapisha port kwa kutumia sheria za DNAT zinazotathminiwa kabla ufw kuona pakiti yoyote, kwa hivyo 3001:3001 ya kawaida huweka dashboard yako kwenye mtandao wa umma bila kujali firewall yako. Kufunga huduma kwenye loopback huifanya iwe ya faragha, huku reverse proxy pekee ikiwa wazi; instance ya faragha inaweza kuruka proxy na kufikia 3001 kupitia VPN ya WireGuard unayojiendeshea.

Named volume kwenye /app/data. Kila kitu ambacho Uptime Kuma hukumbuka, kama database ya SQLite, monitors zako, mipangilio ya notification na nembo za status-page, hukaa hapo. Ukipoteza faili hili utaanza na skrini tupu ya admin; hili ndilo kitu pekee unachopaswa kukihifadhi (backup).

Image imefungwa kwenye tag kuu, :2. Hiyo ndiyo toleo thabiti la sasa; angalia Docker Hub kwa toleo jipya zaidi kabla ya kulinakili, na usiwahi kufuatilia tag inayobadilika kama latest, ambayo mradi huu haupendekezi. Kuruka toleo kuu (major-version) kwenye image hii ni mchakato wa kubadilisha database (migration) ambao hauwezi kutenduliwa, hivyo unapaswa kuufanya kwa makusudi, si kwa bahati mbaya wakati wa routine pull.

Tahadhari moja: /app/data lazima ikae kwenye mfumo wa faili (filesystem) unaotumia POSIX file locks. Docker volume ya ndani inafaa; kwenye NFS, database ya SQLite huharibika na utasababisha SQLITE_BUSY na database disk image is malformed, kwa hivyo usiwahi kutumia network share.

Uendeshaji wa kwanza: tengeneza akaunti ya msimamizi

Vinjari hadi kwenye instance kupitia proxy yako katika https://status.example.com, au kupitia SSH tunnel: endesha ssh -L 3001:127.0.0.1:3001 user@your-vps na ufungue http://localhost:3001. Ukurasa wa kwanza ni fomu ya usanidi kwa ajili ya jina la mtumiaji na nenosiri la msimamizi; hakuna login chaguo-msingi. Chagua nenosiri imara: dashibodi hii huona anwani za ndani na token za kila kitu unachokifuatilia. Umelisahau baadaye? Liweke upya kutoka kwenye host, si kwenye kivinjari:

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

Ongeza njia zako za arifa kwanza, na uzijaribu

Sanidi arifa kabla ya kuongeza monitors, ili uweze kuambatisha njia ya mawasiliano unapounda kila monitor. Nenda kwenye Settings kisha Notifications kisha Setup Notification, na utumie kitufe cha Test cha kila njia ili kuthibitisha kuwa ujumbe unafika, kwa sababu arifa ambayo haijajaribiwa ndiyo sababu ya pili ya kawaida inayofanya usanidi kushindwa kimyakimya.

Email (SMTP). Jaza host, port, encryption, username, password, anwani ya From na To. Mchanganyiko mbili zinazofanya kazi ni 465 huku "Secure" ikiwa imewekwa TLS/SSL, au 587 ikiwa na STARTTLS. Kwa Gmail na watoa huduma wengi wanaotumia uthibitishaji wa hatua mbili (two-factor auth), lazima utengeneze app password; password ya kawaida ya akaunti itarejesha Error: Invalid login: 535-5.7.8 Username and Password not accepted.

Telegram. Mtumie ujumbe @BotFather, tuma /newbot, kisha nakili bot token. Kwa ajili ya chat ID yako, mtumie ujumbe bot mpya mara moja, fungua https://api.telegram.org/bot<token>/getUpdates, na usome chat.id kutoka kwenye JSON. Bot ambayo hujawahi kuitumia kutuma ujumbe kwanza itakuwa na getUpdates tupu na haina mahali pa kutuma ujumbe.

Discord. Kwenye channel, fungua Edit Channel kisha Integrations kisha Webhooks kisha New Webhook, nakili URL, na uibandike kama arifa ya Discord.

Generic webhook. Kwa kitu kingine chochote, kama Slack incoming webhook, endpoint maalum, au hook ya home-automation, aina ya Webhook hutuma JSON payload kwa kutumia POST kwenye URL unayotoa, na ushirikiano wa Apprise uliopo ndani yake unashughulikia huduma nyingine karibu tisini zilizopo kwenye orodha. Ikiwa ungependa kusiwe na mtu wa tatu kati ya hitilafu na simu yako, chagua aina ya ntfy iliyojengewa ndani na uielekeze kwenye seva ya ntfy unayojiendeshea mwenyewe, ambayo inasukuma ujumbe kwenye simu yako kupitia njia unayoimiliki kuanzia mwanzo hadi mwisho.

Ongeza monitors, aina moja kwa wakati mmoja

Bofya Add New Monitor, chagua aina, kisha weka Friendly Name, Check Interval (sekunde 60 ni muda mwafaka), Retries (idadi ya kufeli mfululizo kabla ya kuashiria "down"; 2 au 3 ili pakiti moja iliyopotea isisababishe tahadhari), na arifa za kutuma. Aina utakazotumia ni hizi:

• HTTP(s). URL kamili. Hali ya "up" inamaanisha kupokea status code inayokubalika (kwa kawaida 200-299; unaweza kuipanua chini ya Accepted Status Codes ikiwa 301 au 401 ni ya kawaida kwako). Hii ndiyo njia kuu ya kufuatilia tovuti na API.
• HTTP(s) - Keyword. Ombi lilelile, lakini ili hali iwe "up" inahitaji pia mfuatano wa maneno (string) uwepo, au kutokuwepo ikiwa Invert imechaguliwa, ndani ya mwili wa jibu (body). Hii inasaidia kugundua tovuti inayorejesha 200 OK wakati inaonyesha ujumbe wa "Error establishing a database connection", jambo ambalo check ya kawaida ya HTTP ingeliona kama huduma nzima. Pia ni check sahihi kwa front end ya kivinjari inayowasiliana na backend tofauti, kama skin ya Halcyon ya duka la video juu ya Jellyfin, ambapo ukurasa wake hurejesha 200 kwa furaha wakati seva ya media iliyo nyuma yake haipatikani.
• TCP Port. Muunganisho wa TCP pekee kwenda kwa host na port, kwa huduma ambazo si HTTP: SSH kwenye 22, Postgres kwenye 5432, seva ya SMTP kwenye 25, au seva ya michezo.
• Ping. ICMP echo: njia rahisi ya kupima upatikanaji na latency. Hata hivyo, mitandao mingi na firewall za wingu huzuia ICMP, kwa hivyo monitor ya ping inayowaka nyekundu inaweza kumaanisha "host imezimwa" au "mtoa huduma anazuia ping"; thibitisha kwa kutumia monitor ya TCP.
• DNS. Inatafuta rekodi (A, AAAA, MX, TXT, n.k.) kupitia resolver unayotaja, na inaweza kuhakiki jibu, jambo linalosaidia kugundua mapema matatizo ya msajili wa domain au kukatika kwa DNS.
• Push. Monitor ya aina ya "inside-out", tutaielezea hapa chini.

Kufuatilia cron job kwa kutumia push (heartbeat) monitor

Kila monitor iliyotajwa hapo juu hufikia huduma yako kutoka nje. Push monitor hufanya kazi kinyume: Uptime Kuma husubiri, na job yako huipigia simu ili kusema "Nimefanya kazi." Hii ndiyo njia pekee ya uhakika ya kufuatilia backup au cron: HTTP check inajua kama URL inajibu, lakini job yenyewe ndiyo inayojua kama imekamilika.

Tengeneza monitor ya aina ya Push. Uptime Kuma itatengeneza URL ya kipekee kama hii:

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

Weka Heartbeat Interval kulingana na muda ambao job hiyo huendeshwa, ukiongeza muda kidogo wa ziada. Kisha ongeza mstari mmoja mwishoni mwa script yako, ili itume ishara pale tu inapofanikiwa:

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

Kama job itafeli, set -e itasitisha kabla ya kufika kwenye curl; kama seva imezimika, haitaendeshwa kabisa. Kwa vyovyote vile, heartbeat itasimama, na muda wa interval-pamoja-na-retries ukipita, Uptime Kuma itabadilisha hali ya monitor kuwa down na kukutumia tahadhari. Ichukulie token hiyo ya push kama siri: mtu yeyote aliye nayo anaweza kughushi ishara ya mafanikio.

Jenga ukurasa wa hali ya huduma kwa umma

Ukurasa wa hali ya huduma (status page) ni sehemu inayotazamwa na wateja: inaonyesha huduma zipi ziko hewani na historia yake ya hivi karibuni, bila kufichua dashibodi yako. Nenda kwenye Status Pages kisha New Status Page, ipe jina na slug (njia ya umma, kama vile /status/main), buruta monitor unazotaka kwenye vikundi kama "Websites" na "APIs", ongeza nembo na maelezo mafupi, kisha Save. Unaweza pia kuunganisha ukurasa huo na domain yake ili status.example.com iuhudumie moja kwa moja.

Tahadhari mbili: ongeza tu monitor ambazo uko tayari kuzifanya kuwa za umma, kwa sababu ukurasa wa hali ya huduma hufichua kuwa huduma ipo na kama iko hewani; na dashibodi hubaki nyuma ya login yako wakati ukurasa wa hali ya huduma kwa makusudi ni wa umma na hauhitaji uthibitisho (auth).

Iweke nyuma ya reverse proxy yenye TLS, na uzingatie websockets

Kwa instance ya umma, weka reverse proxy mbele ya container inayofanya kazi kwenye loopback kwa ajili ya TLS na hostname. Jambo dogo ambalo huwasumbua watu wengi: UI ya Uptime Kuma ni programu ya Socket.IO inayofanya kazi moja kwa moja, kwa hivyo proxy lazima iboreshe (upgrade) muunganisho wa WebSocket. Ukikosa hili, ukurasa utapakia lakini hautaunganishwa kamwe; dashibodi itabaki kwenye "Connecting...", heartbeats hazitasasishwa, na console ya kivinjari itaonyesha WebSocket connection to 'wss://.../socket.io/...' failed.

Sakinisha nginx na certbot, kisha andika vhost inayoelekeza kwenye port ya loopback. Iweke kwenye port 80 kwa sasa na uruhusu certbot iongeze TLS baadaye; changamoto, kipima muda cha renewal na njia zake za kufeli zimefafanuliwa katika kutoa vyeti vya Let's Encrypt kwa kutumia certbot na nginx.

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

Hifadhi hii kama /etc/nginx/sites-available/status.example.com; mistari miwili ya WebSocket ndiyo muhimu:

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

Washa tovuti, jaribu usanidi, kisha uruhusu certbot iandike upya block hiyo ili isikilize kwenye 443, iweke cheti na iongeze 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

Jozi ya Upgrade na Connection "upgrade" ndiyo kila kitu, na proxy_read_timeout 3600s inazuia nginx kukata socket inayodumu kwa muda mrefu; certbot hunakili zote mbili kwenye block ya 443 inayotengeneza. Ikiwa tayari unaendesha containers kadhaa nyuma ya proxy moja, kuzielekeza kupitia Traefik na TLS ya kiotomatiki hufanya vivyo hivyo kwa kutumia container labels na kusambaza WebSocket upgrades kwa chaguo-msingi.

Usiweke basic-auth kwenye vhost nzima, kwa sababu hiyo pia itafunga ukurasa wa hali ya umma (public status page) na endpoint ya /api/push. Tumia mfumo wa kuingia (login) wa ndani wa Uptime Kuma, ongeza fail2ban kufuatilia majaribio ya kuingia yaliyofeli mara kwa mara ikiwa inapatikana kwenye Internet, na ikiwa dashibodi haihitaji kuwa ya umma, acha kutumia proxy na uifikie kupitia VPN.

Ufuatiliaji wa muda wa kuisha kwa cheti, kwa usahihi

Kifuatiliaji cha HTTP(s) kinaweza pia kukuonya kabla ya cheti cha TLS kuisha muda wake: weka alama kwenye Certificate Expiry Notification na Uptime Kuma itatuma tahadhari siku kadhaa kabla. Makosa mawili husababisha usomaji usio sahihi. Fuatilia kwa kutumia hostname, siyo IP, kwa sababu ombi lisilo na SNI hupokea cheti chaguo-msingi cha seva na utaona Hostname/IP does not match certificate's altnames. Na usitie alama kwenye Ignore TLS/SSL Error kwenye kifuatiliaji unachotaka kikutumie maonyo ya kuisha kwa cheti: kitufe hicho ni kwa ajili ya seva za ndani zenye vyeti vya kujisaini (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT), lakini kinazuia Uptime Kuma kukagua cheti kabisa, ikiwemo muda wa kuisha.

Hifadhi nakala: ni saraka moja

Kwa sababu kila kitu kipo ndani ya /app/data, hifadhi nakala ni nakala ya volume hiyo inayochukuliwa wakati container imesimamishwa, ili faili la SQLite liwe thabiti:

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

Thibitisha jina halisi la volume kwa kutumia docker volume ls | grep kuma kwanza, kwa sababu Compose huongeza kiambishi awali cha saraka ya mradi. Kisha nakili faili la tarball nje ya seva hiyo, kwa sababu hifadhi nakala iliyo kwenye VPS hiyo hiyo ni nakala tu, si hifadhi nakala. Urejeshaji ni kinyume chake: simamisha stack, toa faili kwenye volume tupu ya /app/data, kisha uianzishe.

Uboreshaji

Uboreshaji ni kitendo cha kuvuta (pull) image mpya:

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

Container mpya huendesha migration yoyote ya database wakati wa kuanza kwa mara ya kwanza; fuatilia docker compose logs -f. Chukua backup iliyotajwa hapo juu kabla ya kuvuta image, na ubaki ndani ya tag kuu: kuhama kutoka :1 kwenda :2 ni migration ya njia moja, kwa hivyo hifadhi nakala kwanza na usome maelezo ya toleo (release notes).

Njia za kufeli, pamoja na ujumbe utakaouona

"Down" ya uongo kwenye monitor inayolenga localhost. Monitor inabadilika kuwa nyekundu na kuonyesha timeout of 48000ms exceeded au connect ETIMEDOUT, ingawa huduma inajibu vizuri kutoka kwenye laptop yako. Ikiwa inalenga seva ileile ambayo Uptime Kuma inaendeshwa, basi ongezeko la CPU au kumbukumbu limesababisha check kufeli, si huduma yenyewe. Hamisha monitor hiyo kwenye VPS nyingine na uilenge kwenye hostname ya umma.

connect ECONNREFUSED 127.0.0.1:443 (au port yoyote). Hakuna huduma inayosikiliza kwenye port hiyo: aidha huduma imefeli, au umemonitor localhost ukiwa ndani ya container, ambapo 127.0.0.1 ni container yenyewe, si seva yako. Monitor hostname ya umma, usitumie loopback.

Invalid login: 535-5.7.8 Username and Password not accepted kwenye jaribio la barua pepe. Credentials za SMTP si sahihi, au mtoa huduma anahitaji app-specific password na wewe umetumia password ya akaunti yako. Tengeneza app password na uweke hiyo.

connect ETIMEDOUT au queryA ETIMEDOUT <host> kwenye jaribio la barua pepe. Port si sahihi, au mtoa huduma anazuia mawasiliano ya SMTP ya kutoka nje. Hakikisha 465 au 587 inalingana na mpangilio wa Secure/STARTTLS, na jaribu kutoka kwenye host kwa kutumia nc -vz smtp.example.com 587. Watoa huduma wengi huzuia traffic ya kutoka nje kwenye 25 na wengine huzuia submission ports hadi uwaombe ruhusa.

self signed certificate au unable to verify the first certificate kwenye jaribio la barua pepe. Seva yako ya SMTP inatoa cheti ambacho Node haikiamini; rekebisha cheti cha seva ya barua badala ya kupuuza tatizo hilo.

Dashboard imekwama kwenye "Connecting...", console inaonyesha WebSocket connection ... failed. Reverse proxy haifanyi upgrade ya WebSocket. Ongeza headers za Upgrade na Connection "upgrade" kwenye nginx, au tumia proxy inayopitisha headers hizo kwa default kama Traefik au Caddy. HTML inapakia kwa sababu ni HTTP GET ya kawaida; ni socket ya moja kwa moja pekee inayohitaji upgrade.

Monitor ya muda wa kuisha kwa cheti (Cert-expiry) haitoi onyo, au inatoa onyo lisilo sahihi. Aidha Ignore TLS/SSL Error imechaguliwa, jambo linalozima ukaguzi wa cheti, au monitor inalenga IP na kusoma cheti kisicho sahihi kwa sababu ya kukosekana kwa SNI, ikionyesha Hostname/IP does not match certificate's altnames. Ondoa uteuzi wa ignore, na umonitor kwa kutumia hostname.

SQLITE_BUSY au database disk image is malformed kwenye logs. Volume ya /app/data iko kwenye filesystem isiyounga mkono file locking ipasavyo, kwa kawaida NFS; ihamishe kwenye local Docker volume na urejeshe data kutoka kwenye backup.

FAQ

Je, ni wapi ninapaswa kuendesha monitor yangu ya uptime?

Kwenye seva tofauti na zile inazozifuatilia, ikiwezekana kwa mtoa huduma mwingine au katika eneo lingine, ikifikia seva hizo kupitia hostname kwenye mtandao wa umma kama wanavyofanya watumiaji wako. Ikiwa monitor inashiriki seva moja na huduma inazozifuatilia, hitilafu inayozima seva hiyo itazima pia monitor, na seva iliyozidiwa mzigo itatoa taarifa za uongo kuwa huduma "zimezimika" wakati ziko sawa. VPS ndogo tofauti huondoa matatizo yote mawili.

Ninawezaje kupata tahadhari kupitia Telegram au barua pepe?

Ongeza chaneli hiyo chini ya Settings kisha Notifications, kisha iunganishe na kila monitor. Kwa Telegram, tengeneza bot ukitumia @BotFather na usome chat.id kutoka https://api.telegram.org/bot<token>/getUpdates; kwa barua pepe, tumia 465 kwa SSL au 587 kwa STARTTLS pamoja na app password ikiwa mtoa huduma wako anatumia uthibitishaji wa hatua mbili (two-factor auth). Bonyeza Test na uhakikishe ujumbe umefika kabla ya kuitegemea.

Je, Uptime Kuma inaweza kufuatilia cron job au script ya backup?

Ndiyo, hiyo ni monitor ya aina ya Push: Uptime Kuma inakupa URL na wewe unaifanyia curl mwishoni mwa script ili ifanye kazi pale tu script inapofanikiwa. Ikiwa kazi itafeli au seva itazimika, heartbeat haitafika, na utapata tahadhari baada ya muda uliowekwa kupita. Hiyo ndiyo njia pekee ya kuaminika ya kujua kama kazi iliyopangwa imetekelezwa kikamilifu, kwa sababu ukaguzi wa nje hauwezi kuona kinachoendelea ndani ya script.

Uptime Kuma dhidi ya Zabbix, ni ipi ninapaswa kuendesha?

Uptime Kuma inajibu swali la "je, huduma iko hewani, kwa mtazamo wa nje, na je, imenitahadharisha" ndani ya dakika kumi kwa kutumia rasilimali chache sana, pamoja na kutoa ukurasa wa hali (status page). Haikusanyi takwimu za kina kama mwenendo wa CPU, kumbukumbu (memory), diski au vizingiti vya mfumo mzima; kwa ajili hiyo, seva kamili ya ufuatiliaji ya Zabbix ni zana nzito inayotegemea mawakala (agents), na watu wengi huendesha zote mbili. Bado unaamua nini cha kuendesha? Muhtasari wetu wa nini cha kujihostia mwaka 2026 unaweka ufuatiliaji katika muktadha wake.