התקנת Uptime Kuma ב-Docker לניטור שרתים ואתרים

מה אתם בונים

מכולה (container) אחת קטנה שעוקבת אחר השרתים ואתרי האינטרנט שלכם מבחוץ, ומתריעה ברגע שאחד מהם מפסיק להגיב – באמצעות דוא"ל, Telegram, Discord או webhook. Uptime Kuma הוא תהליך Node יחיד המגובה בקובץ SQLite, לכן הוא רץ בנוחות ב־256-512 MB של RAM, ומספק לכם לוח בקרה חי, גרפי היסטוריה ודף סטטוס ציבורי. ההתקנה מבוססת על קובץ Compose בן עשר שורות; החלק שבאמת חשוב הוא היכן אתם מריצים אותו והאם ההתראות שלכם הופעלו אי פעם בבדיקה, כיוון שמערכת ניטור שלא הוכחתם שהיא מסוגלת להגיע אליכם גרועה יותר מאי-קיום מערכת כלל: היא גורמת לכם להרגיש מוגנים בזמן שהיא לא מנטרת דבר.

הריצו את הניטור במקום שבו התקלה לא יכולה להגיע אליו

החלטה זו היא הקריטית ביותר, ולכן היא מופיעה ראשונה. אל תריצו את Uptime Kuma על אותו שרת שבו נמצאים השירותים שאתם מנטרים. אם כלי הניטור נמצא על השרת שהוא מנטר, האירוע שחשוב לכם לזהות – קריסת השרת או מחסור בזיכרון – יגרום גם לקריסת כלי הניטור, ולא תקבלו שום התראה. שתיקה של כלי ניטור מושבת נראית בדיוק כמו "הכול תקין". קיימת מלכודת עדינה יותר גם כשהשרת פעיל: כלי ניטור שמכוון ל-localhost חולק את ה-CPU עם עומס העבודה, כך שקפיצה בעומס עלולה לגרום לבדיקה שלו לחרוג מזמן ההמתנה (timeout) ולסמן את היעד כ-down. זוהי התראת שווא, בעוד המשתמשים האמיתיים מקבלים שירות כסדרו.

לכן, הריצו את Uptime Kuma על שרת VPS שונה מזה שהוא מנטר, רצוי אצל ספק אחר או באזור גיאוגרפי אחר. עליו לגשת לשירותים שלכם כפי שהמשתמשים שלכם ניגשים אליהם: דרך האינטרנט הציבורי, באמצעות שם המתחם. מופע (instance) זול מספיק למטרה זו, ושרת ניטור קטן אחד יכול לעקוב אחר כל השרתים שלכם. הפרדה זו חשובה במיוחד עבור יישומים כבדים שאתם מארחים, שכן תוכנות כמו ספריית תמונות מסוג PhotoPrism או Immich יכולות להעסיק את ה-CPU במשך שעות בזמן אינדוקס של ייבוא חדש. כלי ניטור שחולק את אותו חומרה ידווח על שירות שרק נמצא בעומס כעל שירות מושבת. כדי לזהות קריסה של Uptime Kuma עצמו, הוסיפו push heartbeat מתוך cron בשרת אחר.

דרישות קדם וגודל שרת

• שרת VPS חדש עם Ubuntu 24.04, הכולל את Docker Engine ותוסף Compose v2, מותקנים ממאגר ה-apt הרשמי של Docker ולא מחבילת ה-docker.io של ההפצה, שנוטה להתיישן.
• זיכרון RAM בנפח 256 MB מספיק להרצת מספר מצומצם של ניטורים; נפח של 512 MB עד 1 GB מספק עבודה נוחה לעשרות ניטורים בתוספת ה-reverse proxy, כאשר צריכת ה-CPU נותרת קרובה לאפס בין בדיקה לבדיקה.
• שם מתחם (domain) ורשומת DNS מסוג A (למשל status.example.com המצביעה על ה-VPS), נדרשים רק אם ברצונכם להשתמש ב-TLS ובדף סטטוס ציבורי. מופע פרטי יכול לוותר על DNS ולהשתמש ב-VPN או ב-SSH tunnel.
• גישה לרשת חיצונית עבור שליחת התראות: SMTP לספק הדואר שלכם, או HTTPS עבור Telegram ו-Discord.

קובץ ה-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 חשוף חושף את לוח הבקרה שלכם לאינטרנט הציבורי ללא קשר ל-firewall. קישור ל-loopback שומר על פרטיות, כאשר רק ה-reverse proxy חשוף; מופע פרטי יכול לדלג על ה-proxy ולהגיע ל-3001 דרך חיבור WireGuard VPN מאוחסן עצמית.

נפח (volume) בעל שם ב-/app/data. כל מה ש-Uptime Kuma זוכר – מסד הנתונים SQLite, הניטורים, הגדרות ההתראות והלוגואים של דפי הסטטוס – נשמר שם. אובדן הנפח יחזיר אתכם למסך ניהול ריק; זהו הפריט היחיד שחובה לגבות.

ה-image מקובע לתג גרסה ראשית, :2. זהו קו היציבות הנוכחי; בדקו ב-Docker Hub מהי הגרסה הראשית החדשה ביותר לפני העתקתה, ולעולם אל תעקבו אחר תג משתנה כמו latest, שהפרויקט אינו ממליץ עליו. קפיצת גרסה ראשית ב-image זה היא תהליך העברת מסד נתונים חד-כיווני שתרצו להפעיל באופן יזום, ולא להיתקל בו במהלך עדכון שגרתי.

סייג אחד: /app/data חייב לשבת על מערכת קבצים עם נעילות קבצים מסוג POSIX. נפח Docker מקומי הוא תקין; ב-NFS מסד הנתונים SQLite עלול להיפגם ותקבלו את SQLITE_BUSY ו-database disk image is malformed, לכן לעולם אל תשתמשו בשיתוף רשת.

הרצה ראשונה: יצירת חשבון מנהל

גשו למופע דרך ה-proxy שלכם בכתובת 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 של כל ערוץ כדי לוודא שההודעה מגיעה ליעדה. התראה שלא נבדקה היא הגורם השני בשכיחותו לכך שהגדרה נכשלת בשקט.

Email (SMTP). מלאו את ה-host, ה-port, שיטת ההצפנה, שם המשתמש, הסיסמה, וכתובות ה-From וה-To. שתי הקומבינציות התקינות הן 465 עם הגדרת "Secure" על TLS/SSL, או 587 עם STARTTLS. עבור Gmail ורוב הספקים הדורשים אימות דו-שלבי, עליכם להנפיק app password; סיסמת חשבון רגילה תחזיר שגיאת Error: Invalid login: 535-5.7.8 Username and Password not accepted.

Telegram. שלחו הודעה ל-@BotFather, שלחו את הפקודה /newbot, והעתיקו את ה-bot token. עבור ה-chat ID שלכם, שלחו הודעה אחת לבוט החדש, פתחו את https://api.telegram.org/bot<token>/getUpdates, וקראו את ה-chat.id מתוך ה-JSON. בוט שלא שלחתם לו הודעה תחילה יציג getUpdates ריק ולא יהיה לו לאן לשלוח הודעות.

Discord. בתוך הערוץ, פתחו את Edit Channel ולאחר מכן Integrations ואז Webhooks ואז New Webhook, העתיקו את ה-URL, והדביקו אותו כהתראת Discord.

Generic webhook. לכל צורך אחר, כגון Slack incoming webhook, נקודת קצה מותאמת אישית, או hook לאוטומציה ביתית, סוג ה-Webhook מבצע POST של JSON payload ל-URL שתספקו. אינטגרציית Apprise המצורפת מכסה את רוב תשעים ומשהו השירותים האחרים ברשימה. אם אתם מעדיפים ששום צד שלישי לא יתווך בין תקלה לבין הטלפון שלכם, בחרו בסוג ה-ntfy המובנה והפנו אותו אל שרת ntfy שאתם מריצים בעצמכם, אשר דוחף התראות למכשיר שלכם דרך ערוץ שנמצא בשליטתכם המלאה מקצה לקצה.

הוספת ניטורים, סוג אחד בכל פעם

לחצו על Add New Monitor, בחרו סוג, והגדירו את ה-Friendly Name, את ה-Check Interval (ערך של 60 שניות הוא סביר), את ה-Retries (מספר כשלים רצופים לפני הגדרה כ-"down"; ערך של 2 או 3 מונע התרעה על אובדן חבילה בודד), ואת ההתראות להפעלה. הסוגים בהם תשתמשו:

• HTTP(s). כתובת URL מלאה. מצב "up" משמעו קבלת קוד סטטוס תקין (כברירת מחדל 200-299; ניתן להרחיב זאת תחת Accepted Status Codes אם 301 או 401 הם תקינים עבורכם). זהו כלי העבודה העיקרי עבור אתרים ו־APIs.
• HTTP(s) - Keyword. אותה בקשה, אך מצב "up" דורש גם נוכחות של מחרוזת מסוימת בגוף התגובה, או היעדרותה אם הוגדר Invert. בדיקה זו מזהה מצב שבו האתר מחזיר 200 OK בזמן שהוא מציג "Error establishing a database connection", שגיאה שמוניטור HTTP רגיל יחשיב כפעולה תקינה. זוהי גם הבדיקה הנכונה עבור ממשק דפדפן שמתקשר עם backend נפרד, כמו למשל ממשק וידאו Halcyon מעל Jellyfin, שבו מעטפת הדף מחזירה 200 בהצלחה בעוד ששרת המדיה שמאחוריו אינו זמין.
• TCP Port. חיבור TCP גולמי למארח ולפורט, עבור שירותים שאינם HTTP: SSH בפורט 22, Postgres בפורט 5432, שרת SMTP בפורט 25, או שרת משחק.
• Ping. שליחת ICMP echo: דרך זולה לבדיקת זמינות והשהיה (latency). עם זאת, רשתות רבות ו־firewalls בענן חוסמים ICMP, לכן מוניטור Ping אדום יכול להעיד על "מארח למטה" או על "ספק שחוסם Ping"; יש לאמת זאת באמצעות מוניטור TCP.
• DNS. מבצע שאילתה לרשומה (A, AAAA, MX, TXT וכו') מול שרת DNS שתגדירו, ויכול לוודא את התשובה, מה שמאפשר לזהות מוקדם תקלות אצל רשם הדומיינים או בשרתי ה-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 כאל סוד: כל מי שמחזיק בו יכול לזייף דיווח על פעילות תקינה.

בניית דף סטטוס ציבורי

דף סטטוס הוא התצוגה המיועדת למשתמשים: הוא מציג אילו שירותים פעילים ואת ההיסטוריה האחרונה שלהם, מבלי לחשוף את לוח הבקרה שלכם. עברו אל Status Pages ואז New Status Page, תנו לו שם ו-slug (הנתיב הציבורי, כגון /status/main), גררו את הניטורים שברצונכם להציג לקבוצות כמו "Websites" ו-"APIs", הוסיפו לוגו ותיאור קצר, ושמרו. ניתן גם לקשור את הדף לדומיין משלו כך ש-status.example.com יציג אותו ישירות.

שתי אזהרות: הוסיפו רק ניטורים שאתם מוכנים לחשוף לציבור, שכן דף סטטוס חושף את קיומו של שירות ואת מצב הזמינות שלו; לוח הבקרה נשאר מאחורי פרטי ההתחברות שלכם, בעוד שדף הסטטוס הוא ציבורי במכוון ואינו דורש אימות.

הצבת השירות מאחורי reverse proxy עם TLS, ותשומת לב ל-WebSockets

עבור מופע ציבורי, הציבו reverse proxy לפני המכולה המאזינה ל-loopback לצורך TLS ושימוש בשם מתחם. הפרט שגורם לרוב המשתמשים להיתקל בקשיים: ממשק המשתמש של Uptime Kuma הוא אפליקציית Socket.IO פעילה, לכן ה-proxy חייב לבצע שדרוג (upgrade) לחיבור ה-WebSocket. אם תפספסו זאת, הדף ייטען אך לא יתחבר; לוח הבקרה יישאר במצב "Connecting...", פעימות הלב (heartbeats) לא יתעדכנו, ומסוף הדפדפן יציג WebSocket connection to 'wss://.../socket.io/...' failed.

התקינו את nginx ואת certbot, ולאחר מכן כתבו את ה-vhost שמבצע proxy לפורט ה-loopback. הגדירו אותו כרגע על פורט 80 ואפשרו ל-certbot להוסיף TLS לאחר מכן; האתגר, טיימר החידוש ומצבי הכשל שלו מכוסים ב-הנפקת תעודות Let's Encrypt באמצעות certbot ו-nginx.

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 לנתק את ה-socket בעל אורך החיים הארוך; certbot מעתיק את שניהם לתוך בלוק ה-443 שהוא מייצר. אם אתם כבר מריצים כמה מכולות מאחורי proxy אחד, ניתוב שלהן דרך Traefik עם TLS אוטומטי מבצע את אותה פעולה באמצעות תוויות מכולה ומעביר שדרוגי WebSocket כברירת מחדל.

אל תגדירו basic-auth על כל ה-vhost, כיוון שזה יחסום גם את דף הסטטוס הציבורי ואת ה-endpoint של /api/push. השאירו את מנגנון ההתחברות המובנה של Uptime Kuma, הוסיפו ניטור של fail2ban לניסיונות התחברות כושלים חוזרים אם השירות חשוף לאינטרנט, ואם אין צורך שלוח הבקרה יהיה ציבורי, וותרו על ה-proxy וגשו אליו דרך VPN.

ניטור תוקף תעודות, בדרך הנכונה

ניטור HTTP(s) יכול להתריע בפניכם לפני שתוקף תעודת ה-TLS יפוג: סמנו את 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, גיבוי הוא העתק של ה-volume הזה שמתבצע בזמן שהמכולה עצורה, כדי להבטיח שקובץ ה-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

תחילה יש לוודא את השם האמיתי של ה-volume באמצעות docker volume ls | grep kuma, כיוון ש-Compose מוסיף לו תחילית של ספריית הפרויקט. לאחר מכן, יש להעתיק את ה-tarball אל מחוץ לשרת, שכן גיבוי שנשמר על אותו ה-VPS הוא רק העתק, ולא גיבוי אמיתי. שחזור מתבצע בתהליך הפוך: עצירת ה-stack, חילוץ הקבצים לתוך volume ריק מסוג /app/data, והפעלתו מחדש.

שדרוגים

שדרוגים מתבצעים באמצעות משיכת image חדש:

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

הקונטיינר החדש מריץ כל migration של מסד הנתונים בעלייה הראשונה; יש לנטר את docker compose logs -f. בצעו את הגיבוי שצוין לעיל לפני המשיכה, והישארו בתוך אותו major tag: מעבר מ-:1 ל-:2 הוא תהליך migration חד-כיווני, לכן יש לגבות תחילה ולעיין בהערות השחרור (release notes).

מצבי כשל והודעות שגיאה נפוצות

חיווי "למטה" (down) שגוי במוניטור המופנה ל-localhost. המוניטור הופך לאדום עם timeout of 48000ms exceeded או connect ETIMEDOUT, למרות שהשירות מגיב כראוי מהמחשב האישי שלכם. אם המוניטור מכוון לאותו מארח שבו רץ Uptime Kuma, ייתכן שקפיצה ב-CPU או בזיכרון מנעה את ביצוע הבדיקה, ולא שהשירות עצמו נפל. העבירו את המוניטור ל-VPS נפרד וכוונו אותו לשם המתחם הציבורי.

connect ECONNREFUSED 127.0.0.1:443 (או כל פורט אחר). שום דבר לא האזין בפורט הזה: או שהשירות למטה, או שביצעתם ניטור ל-localhost מתוך המכולה, שם 127.0.0.1 הוא ה-container עצמו ולא השרת שלכם. בצעו ניטור לשם המתחם הציבורי, לא ל-loopback.

Invalid login: 535-5.7.8 Username and Password not accepted בבדיקת דואר אלקטרוני. פרטי הגישה ל-SMTP שגויים, או שהספק דורש סיסמה ספציפית ליישום (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 לא סומך עליה; תקנו את התעודה בשרת הדואר במקום לעקוף את הבדיקה.

לוח הבקרה תקוע על "Connecting...", הקונסולה מציגה WebSocket connection ... failed. ה-reverse proxy לא מבצע שדרוג (upgrade) ל-WebSocket. הוסיפו את ה-headers‏ Upgrade ו-Connection "upgrade" ב-nginx, או השתמשו ב-proxy שמעביר אותם כברירת מחדל, כמו Traefik או Caddy. דף ה-HTML נטען כי מדובר בבקשת HTTP GET רגילה; רק ה-socket החי דורש שדרוג.

מוניטור תוקף תעודה לא מתריע, או מתריע באופן שגוי. או שהאפשרות Ignore TLS/SSL Error מסומנת, מה שמנטרל את בדיקת התעודה, או שהמוניטור מכוון ל-IP וקורא את התעודה הלא נכונה בגלל חוסר ב-SNI, מה שגורם ל-Hostname/IP does not match certificate's altnames. בטלו את הסימון של ignore ובצעו ניטור לפי שם מתחם.

SQLITE_BUSY או database disk image is malformed בלוגים. ה-volume של /app/data נמצא על מערכת קבצים ללא תמיכה תקינה בנעילת קבצים (file locking), בדרך כלל NFS; העבירו אותו ל-Docker volume מקומי ושחזרו מגיבוי.

FAQ

היכן כדאי להריץ את ניטור הזמינות (uptime monitor)?

על שרת נפרד מזה שאתם מנטרים, רצוי אצל ספק אחר או באזור גיאוגרפי שונה, תוך גישה אליו באמצעות שם המתחם דרך האינטרנט הציבורי, בדיוק כפי שעושים המשתמשים שלכם. אם כלי הניטור חולק שרת עם היעדים שלו, התקלה שתפיל את השרת תפיל גם את הניטור, ועומס על המארח יגרום לו לדווח על שירותים כ"מושבתים" בעודם תקינים. VPS קטן ונפרד מונע את שתי הבעיות הללו.

כיצד מקבלים התראות ב-Telegram או בדוא"ל?

הוסיפו את הערוץ תחת Settings ולאחר מכן Notifications, ואז שייכו אותו לכל מוניטור. עבור Telegram, צרו בוט באמצעות @BotFather וקראו את chat.id מתוך https://api.telegram.org/bot<token>/getUpdates; עבור דוא"ל, השתמשו ב-465 עבור SSL או ב-587 עבור STARTTLS עם סיסמת אפליקציה אם הספק שלכם דורש אימות דו-שלבי. לחצו על Test וודאו שההודעה התקבלה לפני שתסתמכו על המערכת.

האם Uptime Kuma יכול לנטר משימת cron או סקריפט גיבוי?

כן, באמצעות מוניטור מסוג Push:‏ Uptime Kuma מספק לכם URL, ואתם מבצעים לו curl בסוף הסקריפט כך שהוא יופעל רק במקרה של הצלחה. אם המשימה נכשלת או שהשרת מושבת, ה-heartbeat לעולם לא יגיע, ואתם תקבלו התראה לאחר שיחלוף פרק הזמן שהוגדר. זו הדרך האמינה היחידה לדעת שמשימה מתוזמנת אכן רצה, שכן בדיקה חיצונית לא יכולה לראות מה קורה בתוך המערכת.

Uptime Kuma מול Zabbix, מה כדאי להריץ?

Uptime Kuma עונה על השאלה "האם השירות זמין, מבחוץ, והאם קיבלתי התראה" תוך עשר דקות ובצריכת משאבים אפסית, בתוספת דף סטטוס. הוא לא אוסף מדדים מעמיקים כמו מגמות CPU, זיכרון ודיסק או ספי התראה לכל הצי; עבור אלו, שרת ניטור מלא מסוג Zabbix הוא הכלי הכבד והמבוסס-סוכנים המתאים, ורבים מריצים את שניהם. עדיין מתלבטים מה להריץ? סקירת השירותים לאירוח עצמי לשנת 2026 שלנו מציבה את הניטור בהקשר הרחב.