Uptime Kuma’da Çoklu Kullanıcı ve Grup Yönetimi

Yazar:komut.io ekibi Uptime Kuma ile Servis ve Web Sitesi İzleme
0 Yorum

Uptime Kuma’yı tek başına kullananlar için hayat nispeten basit: bir kullanıcı, tüm monitörler, tek bir dashboard. Ama ekip büyüdükçe, farklı müşteriler veya projeler için izleme kurulumları çoğaldıkça, bu sadelik bir kısıtlamaya dönüşmeye başlıyor. Kimler hangi monitörleri görebilmeli? Geliştiriciler production veritabanı monitörünü silememeli. Müşteri A kendi servislerini görürken müşteri B’nin datalarına erişemememeli. İşte tam burada Uptime Kuma’nın çoklu kullanıcı yönetimi devreye giriyor ve bu konuda belgelerin oldukça eksik kaldığını söylemem gerekiyor.

Uptime Kuma’nın Kullanıcı Modeli: Gerçekçi Beklentiler

Önce net olalım: Uptime Kuma, kurumsal bir RBAC (Role-Based Access Control) sistemi değil. Eğer Grafana veya Zabbix düzeyinde granüler izin yönetimi bekliyorsanız, şu an için hayal kırıklığı yaşayabilirsiniz. Ancak v1.23 sonrasında gelen özellikler ve Status Page’in akıllıca kullanımıyla oldukça işlevsel bir çok kullanıcılı ortam kurabilirsiniz.

Mevcut kullanıcı modeli şu şekilde çalışıyor:

  • Admin kullanıcısı: Tam yetkiye sahip, tüm monitörleri ve ayarları yönetebilir
  • Read-only kullanıcılar: Sadece izleme yapabilen, değişiklik yapamayan kullanıcılar (API token aracılığıyla)
  • Status Pages: Halka açık veya parola korumalı, belirli monitörleri gösteren özel sayfalar

Bu yapıyı doğru anlayıp üzerine inşa etmek, sistemi kullanışlı kılmanın anahtarı.

Docker ile Çoklu Instance Yaklaşımı

Büyük ekiplerde veya farklı müşteri gruplarının tamamen izole edilmesi gerektiğinde, en temiz çözüm birden fazla Uptime Kuma instance’ı çalıştırmak. Evet, biraz kaynak israfı gibi görünüyor ama operasyonel netlik sağlıyor.

Bir docker-compose.yml ile birden fazla instance nasıl ayağa kaldırılır:

version: '3.8'

services:
  uptime-kuma-prod:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma-prod
    volumes:
      - ./data/prod:/app/data
    ports:
      - "3001:3001"
    restart: unless-stopped
    environment:
      - UPTIME_KUMA_PORT=3001

  uptime-kuma-staging:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma-staging
    volumes:
      - ./data/staging:/app/data
    ports:
      - "3002:3001"
    restart: unless-stopped

  uptime-kuma-client-a:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma-client-a
    volumes:
      - ./data/client-a:/app/data
    ports:
      - "3003:3001"
    restart: unless-stopped

Bu yaklaşımla her instance tamamen bağımsız bir veritabanına (SQLite) sahip oluyor. Nginx ile bu instance’ları farklı subdomain’lere yönlendiriyorsunuz:

# /etc/nginx/sites-available/uptime-prod
server {
    listen 80;
    server_name uptime-prod.sirketiniz.com;

    location / {
        proxy_pass http://localhost: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_cache_bypass $http_upgrade;
    }
}

Her subdomain için ayrı Let’s Encrypt sertifikası alıp bu yapıyı production’a taşıdığımızda, ekip içindeki karışıklık büyük ölçüde azalmıştı. Geliştiriciler artık production monitörlerini “yanlışlıkla” silemiyor çünkü o instance’a erişimleri yok.

API Token ile Salt Okunur Erişim

Uptime Kuma’nın REST API’si, okuma işlemleri için oldukça kullanışlı. Özellikle CI/CD pipeline’larında veya dahili dashboard’larınızda durum bilgisi çekmek istediğinizde API token’ları devreye giriyor.

API token oluşturmak için önce Uptime Kuma’ya giriş yapıp Settings > API Keys bölümüne gitmeniz gerekiyor. Buradan bir token oluşturduktan sonra:

# Tüm monitörlerin durumunu çek
curl -H "Authorization: Bearer YOUR_API_TOKEN" 
  https://uptime.sirketiniz.com/api/v1/monitor

# Belirli bir monitörün detaylarını getir
curl -H "Authorization: Bearer YOUR_API_TOKEN" 
  https://uptime.sirketiniz.com/api/v1/monitor/1

# Tüm status page'lerin listesi
curl -H "Authorization: Bearer YOUR_API_TOKEN" 
  https://uptime.sirketiniz.com/api/v1/status-page/list

Bu token’ları bir .env dosyasında saklayıp ekip üyelerine dağıtabilirsiniz. Okuma yapabiliyorlar, değişiklik yapamıyorlar. Basit ama etkili.

Bir Python scripti ile bu veriyi çekip başka sistemlere göndermek de mümkün:

#!/bin/bash
# monitor-status-check.sh
# Bu script critical monitörlerin durumunu kontrol edip Slack'e bildirim atar

API_TOKEN="${UPTIME_KUMA_TOKEN}"
BASE_URL="https://uptime.sirketiniz.com"
SLACK_WEBHOOK="${SLACK_WEBHOOK_URL}"

response=$(curl -s -H "Authorization: Bearer ${API_TOKEN}" 
  "${BASE_URL}/api/v1/monitor")

down_monitors=$(echo $response | jq '[.[] | select(.active == true and .status == 0)] | length')

if [ "$down_monitors" -gt "0" ]; then
  down_list=$(echo $response | jq -r '[.[] | select(.active == true and .status == 0) | .name] | join(", ")')
  
  curl -s -X POST "$SLACK_WEBHOOK" 
    -H 'Content-type: application/json' 
    -d "{"text": "UYARI: ${down_monitors} monitör down durumda: ${down_list}"}"
fi

Status Page ile Müşteri Bazlı Grup Yönetimi

Burası işin en pratik kısmı. Her müşteri veya ekip için ayrı bir Status Page oluşturup sadece ilgili monitörleri o sayfaya ekleyebilirsiniz. Bu, tam bir erişim izolasyonu sağlamasa da görünürlük açısından oldukça etkili.

Uptime Kuma API’si üzerinden programatik olarak status page oluşturmak:

# Yeni status page oluştur
curl -X POST 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  -d '{
    "slug": "musteri-a",
    "title": "Müşteri A Sistem Durumu",
    "description": "Müşteri A altyapısı izleme paneli",
    "theme": "dark",
    "published": true,
    "showTags": false,
    "customCSS": "",
    "footerText": "Teknik destek: [email protected]",
    "showPoweredBy": false,
    "monitorList": [1, 2, 5, 8]
  }' 
  https://uptime.sirketiniz.com/api/v1/status-page

Parola korumalı status page için password alanını eklemeniz yeterli. Müşteriye şifre veriyorsunuz, müşteri kendi servislerinin durumunu görebiliyor. Sizin admin panelinize erişimi yok.

Biz bunu bir müşteride şu şekilde organize ettik: Her müşteri için ayrı bir slug belirledik (musteri-a, musteri-b gibi), her slug için benzersiz bir parola atadık ve bu parolaları 1Password’de sakladık. Müşteri aradığında “şu an baktım, hepsinde yeşil” diyebiliyorlar artık kendi başlarına.

Tag Sistemi ile Monitör Gruplandırma

Uptime Kuma’da monitörleri tag’lerle gruplandırmak, özellikle tek instance üzerinde çok sayıda ekibi yönetirken hayat kurtarıcı. Tag’ler hem filtreleme hem de status page organizasyonu için kullanılıyor.

Tag oluşturma ve monitöre atama:

# Yeni tag oluştur
curl -X POST 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  -d '{
    "name": "production",
    "color": "#e74c3c"
  }' 
  https://uptime.sirketiniz.com/api/v1/tag

# Tag ID'sini öğrendikten sonra monitöre ata
curl -X POST 
  -H "Authorization: Bearer YOUR_API_TOKEN" 
  -H "Content-Type: application/json" 
  -d '{
    "monitorId": 5,
    "tagId": 2,
    "value": "api-service"
  }' 
  https://uptime.sirketiniz.com/api/v1/monitor/5/tag

Tag stratejisi olarak şu yapıyı öneriyorum:

  • Ortam bazlı: production, staging, development
  • Ekip bazlı: backend-team, frontend-team, infra-team
  • Müşteri bazlı: musteri-a, musteri-b
  • Servis tipi bazlı: database, api, cdn, email

Bir monitör birden fazla tag alabildiği için bu kategorileri kombine edebilirsiniz. production ve database tag’lerini taşıyan monitörler, veritabanı ekibinin status page’ine otomatik eklenebilir.

Çoklu Instance’ı Merkezi Yönetme: Uptime Kuma Exporter

Birden fazla Uptime Kuma instance’ınız varsa ve bunları Grafana veya Prometheus üzerinden merkezi olarak izlemek istiyorsanız, uptime-kuma-exporter projesi tam ihtiyacınıza karşılık veriyor.

# Docker ile uptime-kuma-exporter kur
docker run -d 
  --name uptime-kuma-exporter 
  -p 8080:8080 
  -e UPTIME_KUMA_URL=http://uptime-kuma:3001 
  -e UPTIME_KUMA_USERNAME=admin 
  -e UPTIME_KUMA_PASSWORD=gizli_sifre 
  --network monitoring 
  cartmanej/uptime-kuma-exporter:latest

Prometheus’a bu exporter’ı eklemek:

# /etc/prometheus/prometheus.yml içine ekle
scrape_configs:
  - job_name: 'uptime-kuma-prod'
    static_configs:
      - targets: ['localhost:8080']
    metrics_path: /metrics
    scrape_interval: 30s

  - job_name: 'uptime-kuma-staging'
    static_configs:
      - targets: ['localhost:8081']
    metrics_path: /metrics
    scrape_interval: 60s

Bu kurulumla Grafana’da tüm instance’larınızın verilerini tek bir dashboard’da görüntüleyebilirsiniz. Hangi monitör kaç kez down oldu, ortalama response time nedir, SLA yüzdesi kaç. Müşterilere aylık rapor hazırlarken bu veriler altın değerinde.

Backup ve Migration: Kullanıcı Verilerini Korumak

Çok instance’lı bir ortamda backup stratejisi kritik. Uptime Kuma SQLite kullandığı için yedekleme oldukça basit ama otomatize edilmesi şart.

#!/bin/bash
# uptime-kuma-backup.sh
# Cron ile her gece çalıştırın: 0 2 * * * /opt/scripts/uptime-kuma-backup.sh

BACKUP_DIR="/backup/uptime-kuma"
DATE=$(date +%Y%m%d_%H%M%S)
INSTANCES=("prod" "staging" "client-a" "client-b")

mkdir -p "$BACKUP_DIR"

for instance in "${INSTANCES[@]}"; do
  DATA_DIR="/opt/uptime-kuma/data/${instance}"
  BACKUP_FILE="${BACKUP_DIR}/uptime-kuma-${instance}-${DATE}.db"
  
  # SQLite veritabanını güvenli şekilde kopyala
  sqlite3 "${DATA_DIR}/kuma.db" ".backup '${BACKUP_FILE}'"
  
  if [ $? -eq 0 ]; then
    echo "$(date): ${instance} instance backup alındı -> ${BACKUP_FILE}"
    gzip "${BACKUP_FILE}"
  else
    echo "$(date): HATA - ${instance} instance backup alınamadı!" >&2
  fi
done

# 30 günden eski backupları sil
find "$BACKUP_DIR" -name "*.db.gz" -mtime +30 -delete

echo "$(date): Backup işlemi tamamlandı."

Instance’lar arası migration da benzer şekilde:

# Bir instance'dan diğerine kopyala
docker stop uptime-kuma-prod
cp /opt/uptime-kuma/data/prod/kuma.db /opt/uptime-kuma/data/prod-backup-$(date +%Y%m%d).db
docker start uptime-kuma-prod

Notification Routing: Doğru Uyarıyı Doğru Kişiye

Çok kullanıcılı ortamın belki de en kritik kısmı notification yönetimi. Backend ekibi kendi API’sinin down olduğunu bilmeli, frontend ekibi CDN probleminden haberdar olmalı. Her ekibin kendi Slack kanalına veya PagerDuty hesabına yönlendirme yapılmalı.

Uptime Kuma’da her monitöre farklı notification kanalları atayabiliyorsunuz. Bunu sistematik yapmak için şu yapıyı kurabilirsiniz:

  • Önce notification kanallarını oluşturun (Slack #backend-alerts, Slack #frontend-alerts, PagerDuty production)
  • Monitörleri oluştururken ilgili notification kanallarını seçin
  • Önem derecesine göre birden fazla kanal atayın (örneğin kritik bir monitor hem Slack hem de PagerDuty’ye gitsin)

Bu yapıyı API üzerinden otomatize etmek de mümkün ama Uptime Kuma’nın notification API’si henüz tam olarak belgelenmemiş. Web arayüzünden yapmak şimdilik daha güvenli.

Güvenlik: Uptime Kuma’yı Dışarıya Açarken

Uptime Kuma’yı internete açtığınızda, admin panelini korumak kritik önem taşıyor. Status page’ler public olabilir ama admin arayüzü kesinlikle korunmalı.

# Nginx ile IP bazlı kısıtlama ve basic auth katmanı ekle
server {
    listen 443 ssl;
    server_name uptime-admin.sirketiniz.com;

    # Admin paneli sadece VPN IP'lerinden erişilebilir
    location / {
        allow 10.0.0.0/8;      # VPN subnet
        allow 192.168.1.0/24;  # Ofis IP'leri
        deny all;
        
        proxy_pass http://localhost: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;
    }

    # Status page'ler herkese açık
    location /status/ {
        allow all;
        proxy_pass http://localhost:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
    }
}

Fail2ban ile başarısız giriş denemelerini engellemek de iyi bir ek katman:

# /etc/fail2ban/filter.d/uptime-kuma.conf
[Definition]
failregex = .*"POST /api/login HTTP.*" 401
ignoreregex =

# /etc/fail2ban/jail.local içine ekle
[uptime-kuma]
enabled = true
filter = uptime-kuma
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 300
bantime = 3600

Gerçek Dünya Senaryosu: 50 Sunuculu Bir Altyapıyı Organize Etmek

Geçen yıl 50’yi aşkın sunucusu olan, 3 farklı müşteriye hizmet veren bir şirkette bu yapıyı kurdum. Başlangıçta tek instance üzerinde 80’den fazla monitör vardı ve hiçbir organizasyon yoktu. Sysadmin ekibi hangi monitörün kime ait olduğunu bilmiyordu.

Çözüm şu şekilde oldu:

  • 3 müşteri için 3 ayrı instance (tamamen izole)
  • İç altyapı için 1 instance (VPN arkasında, sadece ekip erişimi)
  • Her instance için Nginx subdomain yönlendirmesi ve Let’s Encrypt
  • Müşteri instance’larında parola korumalı status page
  • Tüm instance’ların Prometheus exporter’ı Grafana’ya bağlı
  • Haftalık otomatik backup, S3’e push

İlk hafta kurulum sürdü, ikinci haftadan itibaren ekip rahatladı. “Hangi monitör down oldu, kimin sorumluluğunda?” sorusu artık sorulmuyordu.

Sonuç

Uptime Kuma, kurumsal bir monitoring çözümü iddiasında değil ve bu dürüstlük aslında bir güç. Sadeliği sayesinde çok hızlı kurulabiliyor, bakımı kolay ve kaynak tüketimi düşük. Ama “tek kullanıcılı araç” olarak sınıflandırmak da haksızlık olur.

Çoklu instance yaklaşımı, akıllı bir tag stratejisi ve status page kullanımının kombinasyonu ile gerçekten işlevsel bir çok kullanıcılı ortam kurabiliyorsunuz. Sihirli bir RBAC sistemi yok, evet. Ama düzgün tasarlanmış bir instance mimarisi ve network katmanındaki erişim kontrolleri bu açığı büyük ölçüde kapatıyor.

Eğer ekibiniz küçük ve monitör sayısı yönetilebilir ise tek instance yeterli. 20’yi aşan ekip sayısında veya farklı müşteriler söz konusu olduğunda çoklu instance yolunu seçin ve Nginx ile subdomain’leri organize edin. Backup scriptini ilk günden kurun, later regret etmeyin.

Uptime Kuma’nın roadmap’ine bakıldığında daha gelişmiş kullanıcı yönetimi özellikleri gündemde. Bu yazıyı okuduğunuz zaman belki bu özellikler çoktan gelmiş olacak. Ama şu an için burada anlattığım yaklaşım, Türkiye’deki pek çok sysadmin ekibinin ihtiyacını karşılayacak kapasitede.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir