KertenKerem.NET

Datadog, New Relic veya BetterStack faturalarının her ay sonunda FinOps ekiplerinin masasında yarattığı kalp çarpıntısını hepimiz biliyoruz. Özellikle yüzlerce microservice veya edge endpoint barındıran altyapılarda, basit bir synthetic check ve alerting mekanizması için ödenen lisans bedelleri katlanılamaz seviyelere ulaşabiliyor. Bu noktada self-hosted bir monitoring altyapısı kurmak, doğrudan bir maliyet optimizasyonu hamlesine dönüşüyor. Bu rehberde, Uptime Kuma ve n8n ikilisini bir araya getirerek kurumsal ölçekte, yüksek esnekliğe sahip ve tamamen ücretsiz bir observability & auto-remediation stack’ini nasıl ayağa kaldıracağımızı inceliyoruz.

Neden Bu Stack? Mimari Kararlar

Piyasada Prometheus + Alertmanager veya Zabbix gibi devasa çözümler varken neden Uptime Kuma ve n8n? Cevap: Bakım maliyeti (operational overhead) ve olay müdahale hızı (MTTR).

Prometheus Blackbox Exporter güçlüdür ancak konfigürasyonu hantaldır; dashboard ve status page için Grafana şarttır. Uptime Kuma ise tek bir container içerisinde HTTP(s), gRPC, TCP, DNS, Ping ve Docker container healthcheck kabiliyetlerini native bir Status Page ile sunar. n8n ise Alertmanager’ın kısıtlı webhook yapısının ötesine geçerek; alert deduplication, payload zenginleştirme (enrichment) ve hatta SSH/Kubernetes API üzerinden otomatik iyileştirme (self-healing) workflow’ları çalıştırmamıza olanak tanır.

Adım 1: Production-Ready Docker Compose Mimarisi

Stack’imizi tek bir node üzerinde izole bir Docker network’ü, persistent storage ve resource limitleri ile ayağa kaldıralım. Reverse proxy olarak Traefik veya Nginx arkasında SSL terminate ettiğinizi varsayıyoruz; bu yüzden internal network üzerinden güvenli bağlantı kuracağız.

version: '3.8'

networks:
  monitoring-net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16

volumes:
  uptime-kuma-data:
    driver: local
  n8n-data:
    driver: local

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1.23.13-debian
    container_name: uptime-kuma
    restart: unless-stopped
    volumes:
      - uptime-kuma-data:/app/data
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - monitoring-net
    ports:
      - "127.0.0.1:3001:3001"
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1024M
        reservations:
          cpus: '0.2'
          memory: 256M
    healthcheck:
      test: ["CMD-SHELL", "node extra/healthcheck.js"]
      interval: 30s
      timeout: 10s
      retries: 3

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n-automation
    restart: unless-stopped
    environment:
      - N8N_HOST=n8n.internal.local
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      - GENERIC_TIMEZONE=Europe/Istanbul
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=168
    volumes:
      - n8n-data:/home/node/.n8n
    networks:
      - monitoring-net
    ports:
      - "127.0.0.1:5678:5678"
    deploy:
      resources:
        limits:
          cpus: '1.5'
          memory: 2048M
        reservations:
          cpus: '0.2'
          memory: 512M

Burada kritik olan iki parametre var: Uptime Kuma’ya Docker socket’i ro (read-only) bağlayarak yerel container state’lerini doğrudan izleyebiliyoruz. n8n tarafında ise EXECUTIONS_DATA_PRUNE=true ile SQLite veritabanının kontrolsüz büyümesini engelleyerek disk I/O darboğazlarının önüne geçiyoruz.

Servisleri ayağa kaldıralım:

docker compose up -d
docker compose ps

Adım 2: Uptime Kuma Konfigürasyonu ve Probing Stratejisi

Uptime Kuma arayüzüne (http://localhost:3001) eriştikten sonra ilk işimiz probe stratejisini kurgulamak. Sadece HTTP 200 OK kontrolü yapmak production seviyesinde yetersizdir.

1. HTTP Keyword Check & Payload Validasyonu

Endpoint sadece 200 dönüyor olabilir ancak arka planda database connection pool tükenmiş ve boş bir JSON array render ediyor olabilir. Monitor tipini HTTP(s) – Keyword seçerek response body içinde beklenen bir string (örneğin "status":"healthy") aratmalısınız.

2. Dynamic Certificate Monitoring

TLS sertifikalarının bitişine 14 gün kala alert tetiklemek için TLS/SSL probe ayarlarını aktifleştirin. Bu, Let’s Encrypt botlarının cert-manager veya ACME renewal hatalarında hayat kurtarır.

3. Webhook Entegrasyonu (n8n Köprüsü)

Settings > Notifications > Setup Notification adımlarını izleyin:

• Notification Type: Webhook
• Post URL: https://n8n.yourdomain.com/webhook/uptime-kuma-alerts
• Request Method: POST
• Content-Type: application/json

Uptime Kuma olay anında n8n’e şu formata benzer zengin bir payload fırlatır:

{
  "heartbeat": {
    "monitorID": 4,
    "status": 0,
    "time": "2024-03-24 14:32:10.123",
    "msg": "HTTP 502 Bad Gateway",
    "ping": 142
  },
  "monitor": {
    "name": "Auth-Service-Prod",
    "url": "https://auth.internal.domain/healthz",
    "type": "http",
    "tags": [{"name": "tier-1"}, {"name": "team-core"}]
  },
  "msg": "[Auth-Service-Prod] is Down: HTTP 502 Bad Gateway"
}

Adım 3: n8n ile Event-Driven Remediation ve Alert Routing

Basit bir bildirim göndermek yerine n8n üzerinde incident management iş akışı kuralım. Senaryomuz: Servis düştüğünde alerti Slack/Telegram kanalına at, ardından servisin kurtarılması için SSH üzerinden staging/prod ortamına safe-restart komutu gönder.

1. Webhook Trigger ve Status Filtreleme

n8n üzerinde bir Webhook Node oluşturup path’i uptime-kuma-alerts yapın. Ardından gelen veriyi kontrol eden bir Switch Node ekleyin:

• {{ $json.heartbeat.status }} === 0 -> Incident (DOWN)
• {{ $json.heartbeat.status }} === 1 -> Recovery (UP)

2. Payload Enrichment (Code Node)

Alert metnini güzelleştirmek ve etiketlere göre on-call mühendisi etiketlemek için araya bir Code (JavaScript) node koyuyoruz:

const monitor = $input.first().json.monitor;
const heartbeat = $input.first().json.heartbeat;

const isTier1 = monitor.tags && monitor.tags.some(t => t.name === 'tier-1');
const severity = heartbeat.status === 0 ? (isTier1 ? 'CRITICAL' : 'WARNING') : 'INFO';
const mention = isTier1 ? '' : '@oncall-dev';

return {
  json: {
    serviceName: monitor.name,
    targetUrl: monitor.url,
    errorMessage: heartbeat.msg,
    timestamp: heartbeat.time,
    severity: severity,
    mentionTarget: mention,
    rawPayload: $input.first().json
  }
};

3. Auto-Remediation: Safe Container Restart

Eğer düşen servis stateless bir worker veya memory leak yaşayan bir microservice ise, gece 03:00’te nöbetçiyi uyandırmadan önce kontrollü bir restart denemek mantıklıdır.

n8n’deki SSH Node‘u kullanarak ilgili host üzerinde minimum yetkili bir service user ile remote command çalıştırıyoruz:

# n8n SSH Execution Node Komutu
docker restart {{ $json.serviceName.toLowerCase() }} || systemctl restart {{ $json.serviceName.toLowerCase() }}

Bu adımdan sonra n8n’e bir Wait Node (60 saniye) koyup Uptime Kuma API’sine veya doğrudan servise probe atarak sorunun çözülüp çözülmediğini teyit edebilirsiniz. Düzelmediyse escalasyon yaparak PagerDuty/Opsgenie veya Telegram sesli arama botunu tetikleyebilirsiniz.

Production Hardening: Monitoring Altyapısını Kim İzleyecek?

Monitoring sisteminin kendisi çökerse ne olur? Single point of failure (SPOF) riskini bertaraf etmek için iki kritik adımı atlamayın:

1. Dead Man’s Snitch (Heartbeat Monitoring)

Uptime Kuma içerisinde Push tipi bir monitor oluşturun. n8n üzerinden her 5 dakikada bir bu endpoint’e curl atan bir Cron Workflow tanımlayın. Eğer n8n veya network giderse Uptime Kuma alarm üretir. Aynı şekilde harici, tamamen ücretsiz bir dış servise (örn. Cronitor veya Healthchecks.io) Uptime Kuma’nın kendisinden periyodik ping atın.

# n8n cron node içinden dış heartbeat servisine ping
curl -m 10 --retry 3 https://hc-ping.com/your-uuid-token

2. SQLite WAL Modu ve Otomatik Backup

Uptime Kuma varsayılan olarak SQLite kullanır. Yoğun monitor sayısında (500+) database lock yaşamamak için SQLite WAL (Write-Ahead Logging) modunun aktif olduğundan emin olun:

# Uptime Kuma data dizininde
sqlite3 kuma.db "PRAGMA journal_mode=WAL;"

Veritabanı yedeğini her gece S3 uyumlu bir object storage’a rclone veya restic ile şifreli olarak senkronize edin:

docker exec uptime-kuma sqlite3 /app/data/kuma.db ".backup '/app/data/kuma-backup.db'"
rclone copy /var/lib/docker/volumes/uptime-kuma-data/_data/kuma-backup.db remote-s3:monitoring-backups/

Özet ve Maliyet Karşılaştırması

Bu mimariyi Hetzner veya DigitalOcean üzerindeki 4-5 USD’lik bir VPS üzerinde rahatlıkla çalıştırabilirsiniz. Ticari bir SaaS çözümünde 200 endpoint, multi-step healthcheck’ler ve custom webhook otomasyonları için ayda 150 – 400 USD arasında bir fatura ödemeniz gerekirken; bu stack ile hem tüm verinizi kendi altyapınızda tutuyor hem de n8n’in geniş ekosistemi sayesinde sınırsız auto-remediation senaryosu üretebiliyorsunuz.