Healthchecks Nedir ve Cron İzleme Kurulumu

Bir sunucuda en sinsi arıza türü, hiçbir hata mesajı üretmeden sessizce duran işlerdir. Gece 03.00'te çalışması gereken yedekleme betiği çalışmadığında ekranınıza kırmızı bir uyarı düşmez; her şey normal görünür. Sorunun farkına genellikle çok geç, yani yedeğe gerçekten ihtiyaç duyduğunuz o kötü günde varırsınız. Cron işleri, kuyruk tüketicileri, sertifika yenileme betikleri ve veritabanı temizleme görevleri; çalıştıklarında ses çıkarmadıkları için çalışmadıklarında da ses çıkarmazlar. İşte bu "sessiz başarısızlık" problemini çözmek için tasarlanmış araç Healthchecks'tir.

Healthchecks, klasik "sunucu ayakta mı" izleme araçlarının tam tersi bir mantıkla çalışır. Bir web sitesini dışarıdan yoklamak yerine, izlemek istediğiniz işin kendisinden düzenli bir "ben çalıştım" sinyali bekler. Bu sinyal beklenen sürede gelmezse alarm çalar. Buna genellikle "dead man's switch" yani "ölü adam anahtarı" denir: sistem bir şey olmasını değil, olması gereken bir şeyin olmamasını izler. Bu yazıda Healthchecks'in çalışma mantığını, kendi sunucunuza nasıl kuracağınızı, kontrol oluşturmayı, süre aşımı bildirimlerini ve e-posta ile webhook entegrasyonlarını uçtan uca ele alacağız.

Healthchecks Tam Olarak Neyi Çözer#

Geleneksel izleme araçları dışarıdan içeriye bakar. Bir servisin IP adresine ping atar, 80 veya 443 portuna bağlanır, HTTP durum kodunu okur. Bu yaklaşım web siteleri ve API'ler için mükemmeldir ama zamanlanmış görevler için hiçbir şey ifade etmez. Çünkü cron işi bir port dinlemez, bir HTTP yanıtı döndürmez; sadece belirli bir anda başlar, işini yapar ve kapanır. Dışarıdan bakan bir izleyici bu işin hiç çalışıp çalışmadığını bilemez.

Healthchecks bu boşluğu doldurur. İzlediği her iş için benzersiz bir URL üretir. İşiniz başarıyla tamamlandığında bu URL'ye basit bir HTTP isteği (ping) gönderir. Healthchecks bu ping'leri bekler ve her kontrol için bir zamanlama tanımlar. Beklenen ping süresinde gelmezse, iş başarısız olmuş demektir ve bildirim tetiklenir. Mantık son derece basittir ama etkisi büyüktür: artık yedeğinizin dün gece gerçekten alındığını, kuyruğunuzun tüketildiğini, sertifikanızın yenilendiğini kesin olarak bilirsiniz.

Aşağıdaki tablo iki izleme felsefesini karşılaştırır:

Web sitelerinin erişilebilirliğini izlemek için Uptime Kuma rehberimize göz atabilirsiniz; Healthchecks onun tamamlayıcısıdır, rakibi değil. Çoğu ekip ikisini birlikte kullanır: biri servisin dışarıdan ayakta olduğunu, diğeri arka plandaki görevlerin çalıştığını doğrular.

Ping Tabanlı Mantık Nasıl İşler#

Healthchecks'in kalbi ping mantığıdır ve bu mantığı anlamak, aracın tamamını anlamak demektir. Her kontrolün bir "period" (beklenen aralık) ve bir "grace" (tolerans süresi) değeri vardır. Period, ping'lerin ne sıklıkla gelmesini beklediğinizi belirtir. Grace, gecikmelere ne kadar tahammül gösterileceğini söyler. Örneğin period bir gün, grace bir saat ise; Healthchecks her 24 saatte bir ping bekler ve ping bir saatten fazla gecikirse alarm çalar.

Her kontrol üç durumdan birinde olabilir. Yeni oluşturulan ve henüz ping almamış kontrol "new" durumundadır. Beklenen aralıkta ping alan kontrol "up" yani sağlıklıdır. Ping'i period artı grace süresini aşan kontrol "down" durumuna geçer ve bildirim gönderilir. Bu geçişler otomatiktir ve durum değişikliği anında bildirilir; sürekli tekrar eden gürültü üretilmez.

En temel entegrasyon, cron işinizin sonuna bir ping komutu eklemektir. Aşağıdaki örnekte gece yedekleme betiği başarıyla bittikten sonra Healthchecks'e sinyal gönderir:

#!/bin/bash
# /opt/scripts/yedek.sh
set -euo pipefail

PING_URL="https://hc.ornek.com/ping/8f2a1c9e-4b7d-11ef-9c3a"

# Yedekleme işlemi
pg_dump -U cloutr uygulama_db | gzip > /yedek/db-$(date +%F).sql.gz

# İş başarıyla bittiyse Healthchecks'e sinyal gönder
curl -fsS --retry 3 "$PING_URL" > /dev/null

Buradaki en kritik detay, ping'in set -euo pipefail sayesinde yalnızca betik hatasız tamamlandığında çalışmasıdır. pg_dump bir hata verirse betik oracıkta durur, ping hiç gönderilmez ve Healthchecks süre aşımıyla sizi uyarır. Yani başarısızlığı ayrıca yakalamanıza gerek yoktur; başarının yokluğu zaten alarmı tetikler.

Kurulum: Docker ile Kendi Sunucunuza Kurmak#

Healthchecks açık kaynak bir Django uygulamasıdır ve kendi sunucunuzda barındırmak oldukça kolaydır. En pratik yol Docker kullanmaktır. Konteynerlerinizi görsel bir arayüzden yönetmek isterseniz Portainer rehberimiz işinizi kolaylaştırır. Aşağıda PostgreSQL veritabanıyla birlikte çalışan bir docker-compose.yml örneği var:

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: healthchecks
      POSTGRES_USER: hc
      POSTGRES_PASSWORD: guclu-bir-parola
    volumes:
      - hc-db:/var/lib/postgresql/data

  healthchecks:
    image: healthchecks/healthchecks:latest
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8000:8000"
    environment:
      DB: postgres
      DB_HOST: db
      DB_NAME: healthchecks
      DB_USER: hc
      DB_PASSWORD: guclu-bir-parola
      SITE_ROOT: https://hc.ornek.com
      SITE_NAME: Clou.TR Healthchecks
      SUPERUSER_EMAIL: [email protected]
      SUPERUSER_PASSWORD: yonetici-parolasi
      ALLOWED_HOSTS: hc.ornek.com
      DEFAULT_FROM_EMAIL: [email protected]
      EMAIL_HOST: smtp.ornek.com
      EMAIL_PORT: "587"
      EMAIL_HOST_USER: [email protected]
      EMAIL_HOST_PASSWORD: smtp-parolasi
      EMAIL_USE_TLS: "True"

volumes:
  hc-db:

Bu dosyayı bir dizine kaydedip docker compose up -d komutuyla başlatabilirsiniz. Uygulama 8000 portunda ayağa kalkar. Doğrudan bu portu internete açmak yerine önüne bir ters vekil (reverse proxy) koymanızı ve HTTPS ile yayınlamanızı öneririm. Ücretsiz sertifika için Let's Encrypt kullanabilir, üretim ortamlarında ise SSL sertifikası çözümlerimizi değerlendirebilirsiniz.

Nginx tarafında basit bir ters vekil yapılandırması şöyle görünür:

server {
    listen 443 ssl http2;
    server_name hc.ornek.com;

    ssl_certificate     /etc/letsencrypt/live/hc.ornek.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/hc.ornek.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;
        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;
    }
}

SITE_ROOT değişkenini gerçek alan adınızla eşleştirmeyi unutmayın; ping URL'leri bu değere göre üretilir. Yanlış ayarlanırsa arayüzde gösterilen URL'ler çalışmaz. Uygulamayı barındırmak için kaynaklarını izole edebileceğiniz bir VDS sunucusu idealdir; küçük ekipler için bir sanal sunucu da fazlasıyla yeterlidir.

İlk Kontrolü Oluşturmak ve Zamanlamayı Ayarlamak#

Kurulumun ardından yönetici hesabınızla giriş yapıp ilk kontrolünüzü oluşturabilirsiniz. Arayüzde "Add Check" düğmesine bastığınızda size benzersiz bir ping URL'si atanır. Bu URL'yi cron işinize eklemeniz yeterlidir. Ardından iki zamanlama modundan birini seçersiniz.

Basit zamanlama modu period ve grace değerlerini elle girmenizi sağlar. Günde bir çalışan bir iş için period 1 gün, saatte bir çalışan bir iş için period 1 saat girersiniz. Grace değerini işin çalışma süresine ve ağ gecikmelerine göre belirleyin; on saniyede biten bir işe on dakikalık grace fazlasıyla yeterlidir, ama uzun süren bir yedeklemeye daha geniş bir tolerans gerekebilir.

Cron ifadesi modu ise daha güçlüdür. Sisteminizdeki gerçek cron zamanlamasını doğrudan Healthchecks'e tanıtırsınız. Böylece "her pazartesi 04.00" gibi karmaşık zamanlamaları da doğru izleyebilirsiniz. Aşağıdaki cron girdisi ve Healthchecks'teki karşılığı birbiriyle tam olarak eşleşmelidir:

# crontab -e
# Her gün 03:00'te yedekleme
0 3 * * * /opt/scripts/yedek.sh

# Her 15 dakikada bir kuyruk tüketici sağlık pingi
*/15 * * * * curl -fsS https://hc.ornek.com/ping/KUYRUK-UUID > /dev/null

Healthchecks'in güçlü bir özelliği de iş süresini ölçebilmesidir. Ping URL'sine /start ekleyerek işin başladığını, sade URL ile de bittiğini bildirebilirsiniz. Böylece her çalışmanın ne kadar sürdüğünü görür, giderek yavaşlayan bir işi erkenden fark edersiniz:

PING_URL="https://hc.ornek.com/ping/8f2a1c9e-4b7d-11ef-9c3a"

curl -fsS "$PING_URL/start" > /dev/null   # İş başladı
/opt/scripts/uzun-islem.sh
curl -fsS "$PING_URL" > /dev/null          # İş bitti

Bir işin başarısız olduğunu açıkça bildirmek isterseniz URL'ye /fail ekleyerek çıkış kodunu da iletebilirsiniz. Bu, süre aşımını beklemeden anında alarm almanızı sağlar ve hata ayıklamayı hızlandırır.

Süre Aşımı Bildirimleri ve Kaçırılan Ping Yönetimi#

Healthchecks'in en değerli davranışı, bir ping beklenen sürede gelmediğinde devreye girer. Kontrol "down" durumuna geçtiği anda tanımladığınız tüm bildirim kanalları tetiklenir. Burada önemli olan grace süresini doğru ayarlamaktır; çok kısa tutarsanız geçici ağ gecikmelerinde yanlış alarm alırsınız, çok uzun tutarsanız gerçek arızayı geç öğrenirsiniz.

Bir işi geçici olarak durdurmanız gerektiğinde, örneğin bakım penceresi sırasında, kontrolü arayüzden duraklatabilirsiniz. Duraklatılan kontrol ping beklemez ve alarm üretmez; işi tekrar başlattığınızda izleme kaldığı yerden devam eder. Bu, planlı kesintilerde gereksiz bildirim yağmurundan kaçınmanın en temiz yoludur.

Aşağıdaki tablo tipik iş türleri için önerdiğim zamanlama değerlerini özetliyor. Bunları başlangıç noktası olarak kullanıp kendi ortamınıza göre ince ayar yapabilirsiniz:

Kaçırılan ping'leri yönetirken dikkat edilmesi gereken bir nokta da tekrarlı bildirimlerdir. Healthchecks varsayılan olarak durum değiştiğinde bir kez bildirir, sizi aynı arıza için defalarca rahatsız etmez. Kritik işler için "nag" (dürtme) süresi tanımlayarak iş hâlâ down durumundaysa belirli aralıklarla hatırlatma alabilirsiniz. Bu, gözden kaçan bir arızanın günlerce fark edilmeden kalmasını engeller.

E-posta ve Webhook Entegrasyonları#

Bir bildirim aracı, ancak sizi doğru kanaldan uyarabildiği ölçüde işe yarar. Healthchecks çok sayıda entegrasyonu kutudan çıktığı gibi destekler. En temel kanal e-postadır ve docker-compose.yml içinde SMTP ayarlarını girdiyseniz zaten hazırdır. Her projeye birden fazla e-posta alıcısı ekleyebilir, ekip üyelerinin hepsini aynı anda haberdar edebilirsiniz.

Daha esnek entegrasyon için webhook kanalını kullanabilirsiniz. Kontrol down veya up durumuna geçtiğinde Healthchecks sizin belirlediğiniz bir URL'ye HTTP isteği gönderir. Bu sayede kendi sisteminize, bir sohbet uygulamasına ya da olay yönetim platformuna alarm iletebilirsiniz. Healthchecks, URL ve gövde içinde kullanabileceğiniz değişkenler sunar; $NAME kontrolün adını, $STATUS durumunu, $NOW zaman damgasını temsil eder.

Aşağıda bir sohbet kanalına biçimlendirilmiş mesaj gönderen örnek bir webhook gövdesi var. Healthchecks bu JSON'u POST yöntemiyle ilettiğinde alıcı platform mesajı gösterir:

{
  "text": "Healthchecks alarm: $NAME durumu $STATUS oldu ($NOW)"
}

Kendi arka ucunuza gönderilen webhook'ları imzayla doğrulamak isterseniz, alıcı tarafta gelen isteği kabul etmeden önce kaynağı IP allowlist veya paylaşılan bir gizli anahtarla teyit etmenizi öneririm. Böylece sahte bir alarmın sisteminizi tetiklemesini engellersiniz. Healthchecks ayrıca Slack, Telegram, Discord, PagerDuty, Opsgenie ve Pushover gibi hazır entegrasyonlar da sunar; bunları arayüzden birkaç tıklamayla eklersiniz.

Farklı kanalların güçlü ve zayıf yönlerini kısaca karşılaştıralım:

Pratik bir strateji, aynı kritik iş için birden fazla kanal tanımlamaktır. Örneğin gecelik yedek başarısız olduğunda hem e-posta hem de bir sohbet kanalı bildirimi göndermek, mesajın kaçırılma ihtimalini azaltır. Uygulamayı ve ilişkili servisleri güvence altına almak için düzenli yedekleme ve gerektiğinde profesyonel sunucu yönetimi desteği almanız, izlemenin verdiği huzuru tamamlar.

Gerçek Senaryolarda Healthchecks Kullanımı#

Aracı somutlaştırmak için birkaç gerçek senaryoya bakalım. En yaygın kullanım, veritabanı yedeklemelerini izlemektir. Yedek betiğinizin sonuna bir ping ekler, period'u yedekleme sıklığınıza ayarlarsınız. Artık bir gece yedek alınmadıysa sabaha kalmadan haberdar olursunuz. Bir hosting sağlayıcısı olarak müşteri verilerinin güvenliği açısından bu senaryoyu kritik önemde görüyoruz.

İkinci yaygın senaryo, SSL sertifikası yenilemedir. Let's Encrypt sertifikaları 90 günde bir yenilenir ve otomatik yenileme betiği sessizce başarısız olursa siteniz bir gün aniden sertifika hatası vermeye başlar. Yenileme betiğine bir ping ekleyerek bu riski ortadan kaldırırsınız. Benzer şekilde WordPress bakım görevlerini, önbellek temizleme işlerini ve zamanlanmış içerik yayınlarını da izleyebilirsiniz; WordPress bakım hizmetimiz bu tür otomasyonları güvenle yönetir.

Üçüncü senaryo, arka plan kuyruklarıdır. Bir e-posta gönderim kuyruğu ya da görüntü işleme kuyruğu takılıp kaldığında uygulamanız çalışıyormuş gibi görünür ama işler birikir. Kuyruk tüketicinize düzenli bir sağlık pingi ekleyerek tüketicinin gerçekten aktif olduğunu doğrularsınız. Bu üç senaryo bile Healthchecks'in neden hafif ama vazgeçilmez bir araç olduğunu gösterir. Uygulamayı ve izlediği işleri barındırmak için ölçeklenebilir hosting paketleri ve dilerseniz güçlü bir sunucu altyapısı bu senaryoların tamamını rahatlıkla taşır.

Sıkça Sorulan Sorular#

Healthchecks ile Uptime Kuma arasındaki fark nedir#

İki araç farklı problemleri çözer ve genellikle birlikte kullanılır. Uptime Kuma web sitelerini ve API'leri dışarıdan yoklar, yani servisin erişilebilir olup olmadığını izler. Healthchecks ise cron işleri ve arka plan görevleri gibi dışarıdan görünmeyen işlerin çalışıp çalışmadığını, o işlerin gönderdiği ping'lerle izler. Bir sitenin ayakta olması yedeğinin alındığı anlamına gelmez; bu yüzden çoğu ekip ikisini bir arada tutar.

Ping URL'sini bilen biri sahte sinyal gönderebilir mi#

Teknik olarak evet, ping URL'sini ele geçiren biri sahte bir başarı sinyali gönderip alarmı bastırabilir. Bu yüzden ping URL'lerini gizli bilgi gibi ele almalı, herkese açık depolara veya istemci tarafı koda koymamalısınız. Betikleri sunucuda uygun dosya izinleriyle saklayın ve mümkünse Healthchecks örneğinizi yalnızca kendi sunucularınızın erişebileceği bir ağda tutun. URL rastgele bir UUID içerdiği için tahmin edilemez, ama sızması durumunda arayüzden yeniden üretebilirsiniz.

Kendi sunucumda barındırmak yerine hazır servisi kullanmalı mıyım#

Bu tercih ekibinizin önceliklerine bağlıdır. Kendi sunucunuzda barındırmak veriniz üzerinde tam kontrol sağlar, sınırsız kontrol oluşturmanıza izin verir ve dış bağımlılığı ortadan kaldırır. Ancak Healthchecks'in bulunduğu sunucu da çökebileceği için izleme aracının kendisini de düşünmeniz gerekir. İdeal çözüm, uygulamalarınızdan bağımsız ayrı bir küçük sunucuda barındırmak ve o sunucunun kendisini de dışarıdan bir uptime aracıyla izlemektir.

Healthchecks çalışması için ne kadar kaynağa ihtiyaç duyar#

Healthchecks son derece hafiftir ve mütevazı donanımlarda rahatça çalışır. Bir Django uygulaması ve bir PostgreSQL veritabanından ibaret olduğu için genellikle bir gigabayt RAM ve tek çekirdek yeterlidir. Binlerce kontrolü olan büyük kurulumlarda veritabanına ve arka plan gönderim işçisine biraz daha kaynak ayırmanız yeterli olur. Küçük ve orta ölçekli çoğu ekip için en uygun fiyatlı sanal sunucu bile fazlasıyla yeter.

Bir cron işi bazen uzun sürüyorsa yanlış alarm alır mıyım#

Bu durum grace süresini doğru ayarlayarak kolayca çözülür. Grace, ping'in ne kadar gecikebileceğini belirleyen tolerans süresidir; işinizin en uzun çalışma süresini rahatça kapsayacak bir değer seçerseniz normal dalgalanmalar alarm üretmez. Ayrıca işin başında /start, sonunda sade ping göndererek Healthchecks'in çalışma süresini ölçmesini sağlayabilir, giderek uzayan bir işi grace'i aşmadan önce fark edebilirsiniz. Yani doğru yapılandırıldığında uzun süren işler yanlış alarma yol açmaz.

Kapanış#

Healthchecks, izleme dünyasının çoğu zaman gözden kaçan ama en kritik parçasını dolduran zarif bir araçtır. Web sitenizin ayakta olup olmadığını izlemek önemlidir; ancak arka planda sessizce çalışması gereken yedekleme, sertifika yenileme ve kuyruk işlerinin gerçekten çalıştığını doğrulamak çoğu zaman daha da önemlidir. Dead man's switch mantığı sayesinde bir işin yokluğunu bile fark eder ve sizi tam da fark etmeniz gereken anda uyarır. Kurulumu birkaç dakika, sağladığı huzur ise kalıcıdır.

Bu tür açık kaynak izleme ve otomasyon araçlarını barındırmak için güçlü ve kararlı bir altyapıya ihtiyaç duyarsınız. Clou.TR olarak esnek hosting paketleri, performanslı VDS sunucuları ve dilediğinizde yanınızda olan sunucu yönetimi hizmetleriyle bu araçları güvenle çalıştırmanız için gereken zemini sağlıyoruz. İzlemeye başlamak için önce sağlam bir sunucuya, sonra Healthchecks gibi doğru araçlara ihtiyacınız var; ikisini de birlikte kurmanıza memnuniyetle yardımcı oluruz.