Uptime Kuma Docker Kurulumu ve İzleme Rehberi
Uptime Kuma ile web sitelerinizi ve portlarınızı Docker uzerinde izleyin. Sunucu kesintilerini e-posta veya Telegram ile bildiren bu aracın kurulumunu ve yapılandırmasını ogrenin.
İnşa edilen yapı
Diğer sunucularınızı ve web sitelerinizi dışarıdan izleyen, bunlardan biri yanıt vermeyi bıraktığı anda e-posta, Telegram, Discord veya webhook üzerinden bildirim gönderen tek ve küçük bir container oluşturulacaktır. Uptime Kuma, bu kurulumda bir SQLite dosyası tarafından desteklenen tek bir Node sürecidir. v2 sürümü, gömülü veya harici MariaDB ile de çalışabilir. Bu nedenle 256-512 MB RAM ile rahatça çalışır ve canlı bir dashboard, geçmiş grafiklerini ve herkese açık bir durum sayfasını kullanıma sunar. Kurulum için on satırlık bir Compose dosyası yeterlidir. Asıl önemli olan, bunun nerede çalıştırıldığı ve uyarıların daha önce bir test sırasında gerçekten gönderilip gönderilmediğidir. Size ulaşabildiği kanıtlanmamış bir monitör, hiç monitör olmamasından daha kötüdür. Çünkü koruma sağladığı izlenimi verirken hiçbir şeyi izlemiyor olabilir.
İzleme aracını kesintinin ulaşamayacağı bir yerde çalıştırın
Bu karar tüm sistemin başarısını belirlediği için ilk sırada yer alır. Uptime Kuma'yı izlediği servislerle aynı sunucuda çalıştırmayın. İzleme aracı, izlediği sunucuda barındırılıyorsa, ilgilendiğiniz olay (sunucunun çökmesi veya belleğin tükenmesi) izleme aracını da devre dışı bırakır ve hiçbir uyarı alamazsınız: ölü bir izleme aracından gelen sessizlik, "her şey yolunda" mesajıyla aynı şekilde algılanır. Sunucu ayaktayken bile daha sinsi bir tuzak mevcuttur: localhost adresine yönlendirilmiş bir izleme aracı, CPU'yu iş yüküyle paylaşır; bu nedenle bir yük artışı, kendi kontrolünün zaman aşımına uğramasına ve hedefin down (kapalı) durumuna geçmesine neden olur. Bu, gerçek kullanıcılar hizmet alabiliyorken oluşan hatalı bir alarmdır.
Bu yüzden Uptime Kuma'yı izlediği sunucudan farklı bir VPS üzerinde, ideal olarak farklı bir sağlayıcı veya bölgede çalıştırın ve servislerinize kullanıcılarınızın yaptığı gibi, yani genel internet üzerinden ve ana bilgisayar adı (hostname) ile ulaşın. Ucuz bir örnek (instance) yeterlidir ve küçük bir izleme VPS'i tüm sunucularınızı izleyebilir. Bu ayrım, barındırdığınız ağır uygulamalar için en kritik noktadır; çünkü PhotoPrism veya Immich fotoğraf kütüphanesi gibi bir uygulama, yeni bir içe aktarma işlemini dizinlerken CPU'yu saatlerce meşgul edebilir. Aynı donanımı paylaşan bir izleme aracı, sadece meşgul olan bir servis için "kapalı" uyarısı verecektir. Kuma'nın kendisinin çökme ihtimaline karşı, başka bir yerden cron ile bir push heartbeat ekleyin.
Ön gereksinimler ve boyutlandırma
- Docker Engine ve Compose v2 eklentisi kurulu, güncel bir Ubuntu 24.04 VPS. Kurulum, geride kalan
docker.iodağıtım paketleri yerine doğrudan Docker'ın kendi apt deposundan yapılmalıdır. - 256 MB RAM birkaç izleme servisi için yeterlidir; 512 MB ile 1 GB arası bellek, onlarca servis ve reverse proxy için rahat bir çalışma ortamı sağlar. İşlemci kullanımı kontroller arasında neredeyse boştadır.
- TLS ve herkese açık bir durum sayfası isteniyorsa, bir alan adı ve DNS
Akaydı (örneğin VPS'i işaret edenstatus.example.com) gereklidir. Özel bir kurulumda DNS atlanabilir; VPN veya SSH tüneli kullanılabilir. - Uyarıların gönderileceği yerlere yönelik giden ağ trafiği: E-posta sağlayıcınız için SMTP veya Telegram ve Discord için HTTPS erişimi.
Compose dosyası
Bunu /srv/uptime-kuma/compose.yaml içine yerleştirin.
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:Container'ı başlatın ve ilk açılışı izleyin:
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-kumaDoğru bir başlangıçta Listening on 3001 günlüğe yazılır ve ardından çıktı kesilir. Bu dosyada üç tercih bilinçli olarak yapılmıştır.
127.0.0.1:3001:3001, 3001:3001 değil. Docker, portları ufw paketi görmeden önce değerlendirilen DNAT kurallarıyla yayınlar. Bu nedenle yalın bir 3001:3001, ufw kurallarınızdan bağımsız olarak dashboard'u genel internete açar; yalnızca Docker'ın kendi DOCKER-USER zincirine eklediğiniz kurallar bu trafiği filtreleyebilir. Loopback'e bağlamak servisi özel tutar ve yalnızca reverse proxy dışarıya açılır. Bunun anlamı, 3001 adresine yalnızca ana makinenin erişebileceğidir: reverse proxy kullanılmayan özel bir instance için aşağıda gösterilen SSH tüneli kullanılmalıdır. self-hosted WireGuard VPN üzerinden erişmek için portun 127.0.0.1 yerine sunucunun WireGuard adresinde, örneğin 10.8.0.1:3001:3001 üzerinde yayınlanması gerekir.
/app/data konumunda adlandırılmış bir volume. Uptime Kuma'nın hatırladığı her şey burada tutulur: SQLite veritabanı, monitor'ler, bildirim ayarları ve durum sayfası logoları. Bu volume kaybedilirse boş bir admin ekranıyla başlanır. Yedeklemeniz gereken tek öğe budur.
Image, :2 major tag'ine sabitlenmiştir. Bu, güncel kararlı sürüm serisidir. Dosyayı kopyalamadan önce en yeni major sürüm için Docker Hub'ı kontrol edin. Projenin kullanımdan kaldırdığı latest gibi hareketli bir tag'i hiçbir zaman takip etmeyin. Bu image üzerinde major sürüm yükseltmesi veritabanı migration işlemi çalıştırır. Bu işlemi rutin bir pull sırasında tesadüfen değil, elinizde güncel bir yedek varken bilinçli olarak başlatmanız gerekir.
Bir uyarı: /app/data, POSIX dosya kilitlerini destekleyen bir dosya sisteminde bulunmalıdır. Yerel bir Docker volume'ü uygundur. NFS üzerinde SQLite veritabanı bozulur ve SQLITE_BUSY ile database disk image is malformed hatalarını alırsınız. Bu nedenle bir ağ paylaşımı kullanmayın.
İlk çalıştırma: yönetici hesabını oluşturma
Proxy üzerinden https://status.example.com adresini açarak veya SSH tüneli kullanarak instance'a erişin: ssh -L 3001:127.0.0.1:3001 user@your-vps komutunu çalıştırın ve http://localhost:3001 adresini açın. Yeni bir v2 kurulumunda ilk ekran, kullanılacak veritabanını sorar; SQLite seçilmelidir. SQLite, tüm verileri /app/data volume'unda tutar. Aşağıdaki yedekleme ve sorun giderme adımları bu yapılandırmayı temel alır. Ardından yönetici kullanıcı adı ve parolası için bir kurulum formu görüntülenir; varsayılan oturum açma bilgisi yoktur. Gerçek ve güçlü bir parola belirleyin. Bu dashboard, izlediğiniz tüm bileşenlerin dahili adreslerini ve token'larını görür. Parolayı daha sonra unutursanız tarayıcıdan değil, host üzerinden sıfırlayın:
sudo docker compose exec uptime-kuma npm run reset-passwordBildirim kanallarını önce ekleyin ve test edin
İzleyicileri eklemeden önce uyarıları yapılandırın. Böylece her izleyiciyi oluştururken bir kanal ekleyebilirsiniz. Settings then Notifications then Setup Notification yolunu izleyin. Mesajın ulaştığını doğrulamak için her kanalın Test düğmesini kullanın. Test edilmemiş bir bildirim, kurulumun sessizce başarısız olmasının en yaygın ikinci nedenidir.
Email (SMTP). Host, port, encryption, username, password, From ve To alanlarını doldurun. Yaygın yapılandırmalar, "Secure" seçeneği TLS/SSL olarak ayarlanmış şekilde 465 veya STARTTLS ile 587 kullanır. Bazı sunucular STARTTLS için 25 portunu da sunar. Bu nedenle sağlayıcınızın belgelediği portu ve modu kullanın. Gmail ve iki faktörlü kimlik doğrulama kullanan çoğu sağlayıcı için bir app password oluşturmanız gerekir. Normal hesap parolası Error: Invalid login: 535-5.7.8 Username and Password not accepted hatasına neden olur.
Telegram. @BotFather mesajını gönderin ve /newbot komutunu çalıştırıp bot token'ını kopyalayın. Chat ID değerini almak için yeni bota bir kez mesaj gönderin, https://api.telegram.org/bot<token>/getUpdates adresini açın ve JSON içindeki chat.id değerini okuyun. Önce mesaj göndermediğiniz bir botun getUpdates değeri boştur ve mesaj gönderebileceği bir hedef yoktur.
Discord. Kanalda Edit Channel then Integrations then Webhooks then New Webhook yolunu açın. URL'yi kopyalayın ve bunu Discord bildirimi olarak yapıştırın.
Generic webhook. Diğer seçenekler için, örneğin Slack incoming webhook, özel bir endpoint veya ev otomasyonu hook'u kullanmak istediğinizde, Webhook türü sağladığınız URL'ye JSON payload'ı POST yöntemiyle gönderir. Birlikte sunulan Apprise entegrasyonu, listedeki yaklaşık doksan diğer servisin çoğunu destekler. Bir kesinti ile telefonunuzun arasında üçüncü taraf bulunmasını istemiyorsanız yerleşik ntfy türünü seçin ve bunu kendi çalıştırdığınız bir ntfy sunucusuna yönlendirin. Bu sunucu, uçtan uca kontrol ettiğiniz bir kanal üzerinden mobil cihazınıza bildirim gönderir.
İzleyicileri tek seferde bir tür olacak şekilde ekleyin
Add New Monitor düğmesine tıklayın, bir tür seçin ve Friendly Name (Dost İsim), Check Interval (Kontrol Aralığı; 60 saniye makul bir süredir), Retries (Yeniden Deneme; "down" durumuna geçmeden önceki ardışık başarısızlık sayısı; tek bir paket kaybının uyarı tetiklememesi için 2 veya 3) ve tetiklenecek bildirimleri ayarlayın. Kullanacağınız türler şunlardır:
- HTTP(s). Tam bir URL. "Up" durumu, kabul edilen bir durum kodunu ifade eder (varsayılan olarak 200-299;
301veya401sizin için normal bir durumsa Accepted Status Codes kısmından bu aralığı genişletin). Web siteleri ve API'ler için temel aracınızdır. - HTTP(s) - Keyword. Aynı istek türüdür ancak "up" durumu için yanıt gövdesinde belirli bir dizenin bulunması (veya Invert seçeneği işaretliyse bulunmaması) gerekir. Bu, sitenin "Error establishing a database connection" (Veritabanı bağlantısı kurulamadı) hatası verirken
200 OKdöndürmesi gibi durumları yakalar; düz bir HTTP kontrolü bunu sağlıklı olarak algılayabilir. Ayrıca, ayrı bir arka uçla konuşan tarayıcı ön yüzleri için de doğru kontrol yöntemidir; örneğin Jellyfin üzerinde çalışan bir Halcyon video-store arayüzü, arka plandaki medya sunucusuna ulaşılamadığı halde sayfa iskeletini200koduyla başarıyla döndürebilir. - TCP Port. HTTP olmayan servisler için bir ana bilgisayar ve porta yapılan yalın TCP bağlantısıdır: 22 numaralı portta SSH, 5432 numaralı portta Postgres, 25 numaralı portta bir SMTP sunucusu veya bir oyun sunucusu gibi.
- Ping. ICMP echo: düşük maliyetli erişilebilirlik ve gecikme ölçümü. Ancak birçok ağ ve bulut güvenlik duvarı ICMP trafiğini engeller; bu nedenle kırmızı bir ping izleyicisi "sunucu kapalı" anlamına gelebileceği gibi "sağlayıcı ping'i engelliyor" anlamına da gelebilir; durumu bir TCP izleyicisi ile doğrulayın.
- DNS. Belirlediğiniz bir çözümleyici üzerinden bir kaydı (A, AAAA, MX, TXT vb.) sorgular ve yanıtı doğrulayabilir; böylece kayıt kuruluşu veya DNS kesintilerini erkenden tespit edebilirsiniz.
- Push. Bir sonraki bölümde ele alınacak olan, içeriden dışarıya doğru çalışan izleyici türüdür.
Bir cron işini push (heartbeat) monitörü ile izleme
Yukarıdaki tüm monitörler, hizmetinize dışarıdan erişir. Bir push monitörü ise tam tersi şekilde çalışır: Uptime Kuma bekler ve sizin işiniz ona "çalıştım" bilgisini gönderir. Bir yedekleme veya cron işini izlemenin tek güvenilir yolu budur: bir HTTP denetimi URL'nin yanıt verdiğini bilir, ancak işin başarıyla tamamlandığını yalnızca işin kendisi bilir.
Push türünde bir monitör oluşturun. Uptime Kuma, aşağıdakine benzer benzersiz bir URL oluşturur:
https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=Heartbeat Interval (Sinyal Aralığı) değerini, işin çalışma sıklığına biraz pay ekleyerek ayarlayın. Ardından, yalnızca başarı durumunda tetiklenmesi için betiğin sonuna şu satırı ekleyin:
#!/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="İş başarısız olursa, set -e curl komutundan önce durur; sunucu kapalıysa betik zaten hiç çalışmaz. Her iki durumda da sinyal durur ve interval-plus-retries (aralık artı yeniden deneme) süresi dolduğunda, Uptime Kuma monitörü down (kapalı) durumuna getirir ve sizi uyarır. Bu push token değerini bir sır olarak saklayın: ona sahip olan herkes sahte bir "sağlıklı" sinyali gönderebilir.
Halka açık bir durum sayfası oluşturma
Durum sayfası, müşterilerin gördüğü arayüzdür; panelinizi ifşa etmeden hangi servislerin çalıştığını ve geçmiş durumlarını gösterir. Status Pages menüsünden New Status Page seçeneğine gidin, bir isim ve slug (örneğin /status/main gibi halka açık yol) belirleyin, izlemek istediğiniz monitörleri "Websites" ve "APIs" gibi gruplara sürükleyin, bir logo ve kısa açıklama ekleyip kaydedin. Sayfayı kendi alan adınıza bağlayarak status.example.com üzerinden doğrudan yayınlanmasını da sağlayabilirsiniz.
İki hususa dikkat edilmelidir: Yalnızca halka açık olmasında sakınca görmediğiniz monitörleri ekleyin, çünkü durum sayfası bir servisin varlığını ve çalışıp çalışmadığını ifşa eder. Yönetim paneli giriş bilgilerinizle korunmaya devam ederken, durum sayfası kasıtlı olarak herkese açıktır ve kimlik doğrulama gerektirmez.
TLS ile reverse proxy arkasına alın ve WebSocket bağlantılarını unutmayın
Herkese açık bir instance için loopback adresine bağlı container'ın önüne TLS ve hostname desteği sağlayan bir reverse proxy yerleştirin. Herkesin gözden kaçırdığı ayrıntı şudur: Uptime Kuma'nın arayüzü canlı bir Socket.IO uygulamasıdır; bu nedenle proxy, WebSocket bağlantısını yükseltmelidir. Bu adım atlanırsa sayfa yüklenir ancak bağlantı kurulmaz; dashboard "Connecting..." durumunda kalır, canlı heartbeat değerleri güncellenmez ve tarayıcı konsolunda WebSocket connection to 'wss://.../socket.io/...' failed görüntülenir.
nginx ve certbot'u kurun. Ardından loopback portuna proxy yapan vhost'u yazın. Şimdilik port 80 üzerinde çalıştırın ve TLS ekleme işlemini certbot'a bırakın. Challenge, yenileme zamanlayıcısı ve hata durumları certbot ve nginx ile Let's Encrypt sertifikaları verme bölümünde açıklanmıştır.
sudo apt install -y nginx certbot python3-certbot-nginxBu içeriği /etc/nginx/sites-available/status.example.com olarak kaydedin. Önemli olan iki WebSocket satırıdır:
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;
}
}Siteyi etkinleştirin ve yapılandırmayı test edin. Ardından certbot'un bloğu 443 portunu dinleyecek şekilde yeniden yazmasını, sertifikayı eklemesini ve HTTP'den HTTPS'ye yönlendirme oluşturmasını sağlayın:
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.comUpgrade ve Connection "upgrade" birlikte tüm işi yapar. proxy_read_timeout 3600s ise nginx'in uzun süre açık kalan socket bağlantısını sonlandırmasını engeller. certbot, oluşturduğu 443 bloğuna bu iki ayarı da kopyalar. Aynı proxy arkasında birden fazla container çalıştırıyorsanız otomatik TLS ile Traefik üzerinden yönlendirme aynı işlemi container label'larıyla yapar ve WebSocket yükseltmelerini varsayılan olarak iletir.
Tüm vhost'a basic auth uygulamayın. Bu, herkese açık durum sayfasına ve /api/push endpoint'ine erişimi de engeller. Uptime Kuma'nın yerleşik giriş mekanizmasını kullanın. İnternete açıksa tekrarlanan başarısız girişleri fail2ban ile izleme yöntemini ekleyin. Dashboard'un herkese açık olması gerekmiyorsa proxy'yi kaldırın ve SSH tunnel üzerinden erişin. Alternatif olarak VPN kullanın ve portu loopback yerine VPN adresinde yayınlayın.
Sertifika süresi takibi, doğru yöntemle
Bir HTTP(s) monitörü, TLS sertifikası süresi dolmadan önce sizi uyarabilir: Certificate Expiry Notification seçeneğini işaretlediğinizde, Uptime Kuma belirlenen gün sayısından önce bildirim gönderir. İki hata, yanlış okumaya neden olur. İzleme işlemini IP adresi ile değil, hostname ile yapın; aksi takdirde SNI içermeyen bir istek sunucunun varsayılan sertifikasını döndürür ve Hostname/IP does not match certificate's altnames hatası alırsınız. Ayrıca, süresi dolan sertifikalar için uyarı almak istediğiniz bir monitörde Ignore TLS/SSL Error seçeneğini işaretlemeyin: bu ayar, kendinden imzalı (self-signed) dahili sunucular içindir (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT); ancak bu seçenek, Uptime Kuma'nın sertifikayı denetlemesini tamamen durdurur ve süre takibi de devre dışı kalır.
Yedekleme: tek bir dizin
Her şey /app/data içinde barındığından, yedekleme işlemi container durdurulmuşken alınan bir volume kopyasıdır; bu sayede SQLite dosyası tutarlı kalır:
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 startCompose, proje dizinini önek olarak eklediği için önce docker volume ls | grep kuma ile volume'un gerçek adını doğrulayın. Ardından tarball dosyasını sunucudan dışarı kopyalayın; aynı VPS üzerindeki bir yedek, yedek değil sadece bir kopyadır. Geri yükleme işlemi bunun tersidir: stack'i durdurun, içeriği boş bir /app/data volume'una çıkartın ve başlatın.
Yükseltmeler
Yükseltme işlemi bir image çekme işlemidir:
cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -dYeni container, ilk başlatmada gerekli veritabanı migrasyonunu çalıştırır; docker compose logs -f kaydını izleyin. Image çekme işleminden önce yukarıda belirtilen yedeği alın ve aynı major tag içinde kalın: :1 sürümünden :2 sürümüne geçiş veritabanını migrate eder. Projenin migrasyon kılavuzuna göre yarıda kesilen bir migrasyon, yedeğin geri yüklenmesini ve işlemin yeniden denenmesini gerektirir. Bu nedenle önce yedek alın; ardından ilgili kılavuzu ve release notes belgelerini okuyun.
Hata modları ve karşılaşacağınız dizeler
localhost adresine yönlendirilen monitörde hatalı "kapalı" durumu. Monitör timeout of 48000ms exceeded veya connect ETIMEDOUT hatasıyla kırmızıya döner, ancak servis dizüstü bilgisayarınızdan yanıt veriyordur. Eğer monitör, Uptime Kuma'nın çalıştığı aynı ana makineyi hedefliyorsa, bir CPU veya bellek artışı hedefi değil, kontrol işlemini kısıtlamıştır. Monitörü ayrı bir VPS'e taşıyın ve genel ana makine adını (public hostname) hedefleyin.
connect ECONNREFUSED 127.0.0.1:443 (veya herhangi bir port). O portta dinleme yapan bir servis yoktur: servis kapalı olabilir veya localhost adresini, sunucunuz değil container olan 127.0.0.1 içinden izliyor olabilirsiniz. Loopback yerine genel ana makine adını izleyin.
E-posta testinde Invalid login: 535-5.7.8 Username and Password not accepted. SMTP kimlik bilgileri yanlıştır veya sağlayıcı hesap parolanız yerine uygulamaya özel bir parola bekliyordur. Uygulamaya özel bir parola oluşturun ve bunu yapıştırın.
E-posta testinde connect ETIMEDOUT veya queryA ETIMEDOUT <host>. Yanlış port kullanılmıştır veya sağlayıcı giden SMTP trafiğini engelliyordur. 465 veya 587 değerlerinin Secure/STARTTLS ayarıyla eşleştiğini doğrulayın ve ana makine üzerinden nc -vz smtp.example.com 587 ile test edin. Birçok sağlayıcı giden 25 trafiğini engeller; bazıları ise siz talep edene kadar gönderim portlarını kapalı tutar.
E-posta testinde self signed certificate veya unable to verify the first certificate. SMTP sunucunuz, Node tarafından güvenilmeyen bir sertifika sunuyordur; sorunu geçici çözümlerle örtmek yerine posta sunucusunun sertifikasını düzeltin.
Dashboard "Connecting..." durumunda takılı kalıyor, konsol WebSocket connection ... failed hatası gösteriyor. Reverse proxy, WebSocket bağlantısını yükseltmiyordur (upgrade). Nginx üzerinde Upgrade ve Connection "upgrade" başlıklarını ekleyin veya Traefik ya da Caddy gibi bu başlıkları varsayılan olarak ileten bir proxy kullanın. HTML yüklenir çünkü bu normal bir HTTP GET isteğidir; yalnızca canlı soket bağlantısı yükseltme gerektirir.
Sertifika süresi monitörü uyarı vermiyor veya hatalı uyarı veriyor. Ya sertifika kontrolünü devre dışı bırakan Ignore TLS/SSL Error seçeneği işaretlidir ya da monitör bir IP adresini hedefliyordur ve SNI eksikliği nedeniyle Hostname/IP does not match certificate's altnames hatasıyla yanlış sertifikayı okuyordur. "Ignore" seçeneğinin işaretini kaldırın ve ana makine adı üzerinden izleme yapın.
Loglarda SQLITE_BUSY veya database disk image is malformed. /app/data birimi, düzgün dosya kilitleme desteği olmayan bir dosya sisteminde (genellikle NFS) bulunuyordur; birimi yerel bir Docker birimine taşıyın ve yedekten geri yükleyin.
FAQ
Uptime monitorumu nerede çalıştırmalıyım?
İzlediği sunuculardan farklı bir sunucuda, ideal olarak başka bir sağlayıcıda veya bölgede, kullanıcılarınızın yaptığı gibi genel internet üzerinden ana bilgisayar adı (hostname) ile erişerek çalıştırılmalıdır. Eğer monitör, hedefleriyle aynı sunucuyu paylaşıyorsa, sunucuyu devre dışı bırakan bir kesinti monitörü de devre dışı bırakır; ayrıca aşırı yüklenmiş bir ana bilgisayar, aslında düzgün çalışan servisler için "kapalı" uyarısı verebilir. Küçük, ayrı bir VPS her iki sorunu da önler.
Telegram veya e-posta üzerinden nasıl uyarı alabilirim?
Ayarlar (Settings) ardından Bildirimler (Notifications) kısmından kanalı ekleyin ve ardından her monitöre atayın. Telegram için @BotFather ile bir bot oluşturun ve https://api.telegram.org/bot<token>/getUpdates üzerinden chat.id değerini okuyun; e-posta için, sağlayıcınız iki faktörlü kimlik doğrulama kullanıyorsa SSL için 465 veya STARTTLS için 587 ayarlarını bir uygulama şifresiyle birlikte kullanın. Test düğmesine basın ve güvenilirliğinden emin olmadan önce mesajın ulaştığını doğrulayın.
Uptime Kuma bir cron job veya yedekleme betiğini izleyebilir mi?
Evet, bu Push monitörü ile mümkündür: Uptime Kuma size bir URL verir ve siz de bunu betiğin sonuna curl komutuyla eklersiniz; böylece sadece başarı durumunda tetiklenir. Eğer iş başarısız olursa veya sunucu kapalıysa sinyal (heartbeat) asla ulaşmaz ve süre dolduğunda uyarılırsınız. Harici bir kontrol betiğin içini göremeyeceği için, zamanlanmış bir işin gerçekten çalıştığını bilmenin tek güvenilir yolu budur.
Uptime Kuma mı yoksa Zabbix mi, hangisini çalıştırmalıyım?
Uptime Kuma, "dışarıdan bakıldığında çalışıyor mu ve beni uyardı mı" sorusuna, neredeyse hiç kaynak tüketmeden ve bir durum sayfası (status page) sunarak on dakika içinde yanıt verir. CPU, bellek ve disk eğilimleri veya filo genelindeki eşik değerleri gibi derin metrikleri toplamaz; bunun için tam teşekküllü bir Zabbix izleme sunucusu daha ağır, aracı tabanlı (agent-based) bir araçtır ve birçok kişi her ikisini de çalıştırır. Hâlâ ne çalıştıracağınıza karar veremediyseniz, 2026 yılında self-host edilecekler listemiz izleme araçlarını bağlamına oturtmaktadır.