2026'da Healthchecks'i Self-Host Etme: Cron Ping'leri, Uyarılar ve Veritabanı Yedekleri

Healthchecks'i self-host etmek, ilk docker run komutunda değil, ilk yeniden dağıtımda ilgi çekici hâle gelir. Cron job'ları dahili bir URL'ye ping gönderiyorsa veya email worker'ları çalışmıyorsa Docker yine de tamamen sağlıklı bir process bildirebilir. Aşağıdaki deployment gözlemlenebilir davranış etrafında düzenlenmiştir: bir test job'ından başlangıç, başarı ve hata ping'leri gönderin; ardından zamanlanmış bir ping'i atlayarak eksik job uyarısını alın.

Healthchecks'in amacı nettir: cron job'ları ve background task'leri dead-man monitoring ile izlemek. Bu tanım, hangi bileşenlerin public kalması, hangilerinin private olması ve bir yedeğin neleri yeniden oluşturması gerektiğini açıkça gösterir.

Healthchecks'in yeniden oluşturamayacağı durumu yedekleyin

Standart Healthchecks container'ı zorunlu bir application-data mount'u içermez. Yine de kurtarma kapsamı nettir: application database'i ve notification configuration. Deployment stateful görünsün diye boş bir volume oluşturmayın; bunun yerine tam image reference'ını ve gözden geçirilmiş configuration'ı koruyun.

Healthchecks'i boş bir host üzerinde yeniden oluşturun ve acceptance transaction'ı çalıştırın. Checks, schedules, integrations ve ping key'leri geri geldiğinde ve kasıtlı olarak eksik bırakılan bir ping beklenen uyarıyı oluşturduğunda kurtarma başarılıdır. Bağlı herhangi bir database veya collaboration service kendi application-consistent backup plan'ını izler; değiştirilebilir web container'ı ise code'dan yeniden oluşturulur. Git'ten production'a deployment rehberi bu yeniden üretilebilir sınırı açıklar.

Bilinen iyi image için bir checksum veya digest tutun ve güncellemelerden sonra yeniden test edin. Stateless bir service için başarılı bir rebuild, restore testidir; external state içinse Healthchecks runbook'u ayrı owner'ı ve recovery procedure'ı göstermelidir.

Değiştirilebilir bir Healthchecks container'ı oluşturun

Her önemli seçeneği açıkça gösteren bir command kullanın. Bu temel yapılandırma, Healthchecks'i host loopback'e bağlar, bilinen data mount'larını ekler ve ilk gerekli setting'i sağlar. Production alert'leri için gözden geçirilmiş Postgres connection ayarlarını ve çalışan email delivery yapılandırmasını ekleyin; private service'ler için private isimler kullanın.

docker run -d \
  --name healthchecks \
  --restart unless-stopped \
  -p 127.0.0.1:8000:8000 \
  -e SECRET_KEY=replace-with-a-long-random-value \
  -e SITE_ROOT=https://app.example.com \
  -e ALLOWED_HOSTS=app.example.com \
  -e DB=postgres \
  -e DB_HOST=postgres.internal \
  -e DB_NAME=healthchecks \
  -e DB_USER=healthchecks \
  -e DB_PASSWORD=replace-with-a-strong-database-password \
  healthchecks/healthchecks:latest

Değişken tag'leri test edilmiş bir version veya digest ile değiştirin. Başlangıçtan sonra docker logs --tail 200 healthchecks çıktısını inceleyin ve process'in 8000 portunu dinlediğini doğrulayın. Ardından Healthchecks acceptance action'ını çalıştırın; root page yanıtı, senaryonun tamamının başarılı olduğunu kanıtlayamaz: bir test job'ından başlangıç, başarı ve hata ping'leri gönderin; sonra zamanlanmış bir ping'i atlayarak eksik job uyarısını alın.

Healthchecks'in bağımlılıkları

Healthchecks çevresinde üç sınır belirleyin: 8000 portuna ingress, kalıcı state ve supporting requirements. Container değiştirilebilir; ancak diğer iki bileşenin owner'ları açıkça belirlenmelidir. Healthchecks'in network contract'ı, production alert'leri için Postgres ve çalışan email delivery'dir. Private endpoint'leri internal DNS üzerinde tutun, yalnızca gerekli outbound çağrılara izin verin ve Healthchecks'e scope'u sınırlandırılmış bir service credential verin.

Temiz bir client bir test job'ından başlangıç, başarı ve hata ping'leri gönderebildiğinde, ardından zamanlanmış bir ping'i atlayarak eksik job uyarısını alabildiğinde diagram tamamlanmış olur. Check sayısı, grace period'lar, notification fan-out, email delivery ve database write'ları için timing ve resource verilerini kaydedin. Transaction başarısız olursa, belgelenen şekilde davranmayan ilk sınır; routing, local capacity veya supporting service'lerden hangisini incelemeniz gerektiğini gösterir.

HTTPS konusunda Healthchecks'i yanıltmayacak şekilde yönlendirin

Kullanıcılar callback'leri veya client ayarlarını kaydetmeden önce nihai Healthchecks hostname'ını seçin; ardından SITE_ROOT ve ALLOWED_HOSTS değerlerini external HTTPS adresine ayarlayın. Platform route'u TLS'i bir kez sonlandırmalı ve private port 8000'i hedeflemelidir.

Acceptance transaction'ı external olarak çalıştırın. Client Healthchecks'e hiç ulaşamıyorsa DNS ve certificate kontrolleri için SSL doğrulama kontrol listesini kullanın. İstek Healthchecks'e ulaşıyor ancak cron job'ları dahili bir URL'ye ping gönderiyor veya email worker'ları çalışmıyorsa proxy redirect'lerini değiştirmeyi bırakın ve bunun yerine application-specific boundary'yi inceleyin.

Healthchecks yayına alınmadan önce toplanacak kanıtlar

Küçük ve disposable bir Healthchecks fixture'ı oluşturun ve her release için saklayın. Fixture gerçek workflow'u çalıştırmalıdır: bir test job'ından başlangıç, başarı ve hata ping'leri gönderin; ardından zamanlanmış bir ping'i atlayarak eksik job uyarısını alın. Image digest'ini, external hostname'ı, dependency address'ini ve beklenen sonucu kaydedin; böylece sonraki bir operator bu rehberi yorumlamak zorunda kalmadan testi tekrarlayabilir.

Fixture'ı üç kez çalıştırın. İlkinde fresh deployment'ı kullanın. İkincisinde kalıcı state'e dokunmadan container'ı değiştirin. Üçüncüsünde backup'ı boş bir environment'a restore edin. Üçüncü çalıştırma yalnızca checks, schedules, integrations ve ping key'leri geri geldiğinde ve kasıtlı olarak eksik bırakılan bir ping beklenen uyarıyı oluşturduğunda başarılıdır. Her çalıştırmada check sayısı, grace period'lar, notification fan-out, email delivery ve database write'ları çevresindeki latency ve resource kullanımını kaydedin; bunlar rastgele bir CPU yüzdesi yerine alert'ler için baseline oluşturur.

Son olarak negative path'i kasıtlı olarak test edin: test identity'sinin Postgres'e ve production alert'leri için çalışan email delivery'ye erişimini geçici olarak reddedin. Healthchecks'in state'i bozmadan görünür biçimde başarısız olduğunu doğrulayın, doğru koşulu geri yükleyin ve başarılı transaction'ı tekrarlayın. Bu dört sonucu içeren bir release kaydı, bir dashboard screenshot'ından veya tek seferlik bir curl yanıtından daha güçlü kanıttır.

Healthchecks için failure drill'leri

Healthchecks'in gerçekleştirdiği çalışmayı gözlemleyin: check sayısı, grace period'lar, notification fan-out, email delivery ve database write'ları. Bu çalışma için headroom bırakarak limitler belirleyin ve onunla rekabet eden bir liveness probe kullanmaktan kaçının. Operator check'i yine bir test job'ından başlangıç, başarı ve hata ping'leri göndermeyi; ardından zamanlanmış bir ping'i atlayarak eksik job uyarısını bir schedule üzerinden almayı denemelidir.

Güncellemelerde, application migration'larının ve worker configuration'ın birlikte yükseltilmesi gerektiğini unutmayın; böylece web page bozuk alert delivery'yi gizlemez. Aday version'ı restore edilmiş bir kopyaya deploy edin ve bilinen testi tekrarlayın. Cron job'ları dahili bir URL'ye ping gönderiyor veya email worker'ları çalışmıyorsa hangi varsayımın değiştiğini bulmak için runtime log'larını ve gerçek network request'ini kullanın.

Healthchecks trust boundary'sini seçin

İlk trusted administrator oluşturulur oluşturulmaz bootstrap window'u kapatın. Healthchecks'in somut tuzağı, her restart'ta değişen generated secret kullanmaktır; daha güvenli sınır, sabit bir SECRET_KEY kullanmak, project membership'ı kısıtlamak ve ping URL'lerini credential olarak değerlendirmektir.

SECRET_KEY'i bir kez oluşturun, Git dışında tutun ve recovery manifest ile birlikte koruyun; çünkü bu değerin değiştirilmesi encrypted veya signed application state'i geçersiz kılabilir. Private networking dependency credential'larını taşımalı, Healthchecks içindeki role'ler ise gerekli en küçük action'ı vermelidir. Hassas request body'lerini ve provider response'larını rutin log'ların dışında tutun.

Dockup deployment'ı yine de bir Healthchecks acceptance testi gerektirir

Dockup, değiştirilebilir platform parçalarını üstlenebilir: trafiği 8000 portuna yönlendirmek, domain ve certificate sağlamak, secret'ları inject etmek, persistent storage bağlamak ve Healthchecks'i managed veya privately attached service'lere bağlamak. Bunu Dockup infrastructure'ı üzerinde veya bağladığınız bir server'da yapabilir.

Healthchecks acceptance çalışması açıkça tanımlı kalır. One-click deployment sonrasında SITE_ROOT ve ALLOWED_HOSTS değerlerini external HTTPS adresine ayarlayın, Postgres ile production alert'leri için çalışan email delivery'yi bağlayıp test edin ve şu senaryoyu çalıştırın: bir test job'ından başlangıç, başarı ve hata ping'leri gönderin; ardından zamanlanmış bir ping'i atlayarak eksik job uyarısını alın. Bu ayrım bilinçlidir: Dockup tekrarlanan infrastructure kurulumunu ortadan kaldırır; ancak application role'lerinin, provider credential'larının veya restore policy'nin kendiliğinden seçildiği izlenimini vermez.

Sık sorulan sorular

Production deployment için Healthchecks'in neye ihtiyacı vardır?

Healthchecks container'ını tek bir HTTPS origin üzerinden 8000 portuna yönlendirin. Supporting network requirement, Postgres ve production alert'leri için çalışan email delivery'dir. Bir test job'ından başlangıç, başarı ve hata ping'leri gönderip ardından zamanlanmış bir ping'i atlayarak eksik job uyarısını alamıyorsanız Healthchecks'i hazır kabul etmeyin.

Healthchecks'in hangi verileri backup'a dahil edilmelidir?

Standart Healthchecks image'ı zorunlu bir application-data mount'u içermez. Deployment configuration'ını koruyun ve bağlı state'i ayrı olarak yedekleyin; checks, schedules, integrations ve ping key'leri geri geldiğinde ve kasıtlı olarak eksik bırakılan bir ping beklenen uyarıyı oluşturduğunda recovery başarılıdır.

Reverse proxy arkasında Healthchecks HTTPS gerektirir mi?

Public Healthchecks origin için HTTPS kullanın ve 8000 portunu internal route üzerinde tutun. Healthchecks setting'ini doğru uygulayın: SITE_ROOT ve ALLOWED_HOSTS değerlerini external HTTPS adresine ayarlayın. Healthchecks açısından HTTPS, credentials veya user content'in aktarım sırasında korunmasını ve origin-sensitive client davranışının tutarlı kalmasını sağlar.

Healthchecks upgrade'i nasıl test edilmelidir?

Mevcut Healthchecks state'ini izole bir deployment'a restore edin, aday version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Application migration'larının ve worker configuration'ın birlikte yükseltilmesi gerektiğinden özellikle dikkatli olun; böylece web page bozuk alert delivery'yi gizlemez. Data migration ve rollback boundary'si anlaşılana kadar önceki Healthchecks image'ını saklayın.