Sunucu Sağlık Kontrolü (Health Check) Nasıl Yapılandırılır

Health Check (Sağlık Kontrolü) Nedir ve Neden Önemlidir?

Health check, bir sunucunun veya üzerinde çalışan bir servisin ayakta olup olmadığını ve beklenen şekilde yanıt verip vermediğini otomatik olarak, düzenli aralıklarla kontrol etme sürecidir. Basitçe söylemek gerekirse, sisteme sürekli "iyi misin?" diye soran ve cevabı değerlendiren bir mekanizmadır.

Bunun neden önemli olduğunu anlamak için health check olmayan bir senaryoyu düşünmek yeterli. Bir e-ticaret sitesinin arka planındaki ödeme servisi çökmüş olsun. Otomatik bir kontrol mekanizması yoksa bu durum ancak kullanıcılar şikayet etmeye başladığında ya da satış raporlarında bir düşüş fark edildiğinde ortaya çıkar. Bu da kesintinin dakikalarca, hatta saatlerce fark edilmeden sürmesi anlamına gelir.

Bu noktada proaktif izleme ile reaktif müdahale arasındaki fark devreye girer. Reaktif yaklaşımda sorun zaten oluşmuş, kullanıcıyı etkilemiş ve ekip bu bilgiyi dışarıdan (müşteri şikayeti gibi) almıştır. Proaktif yaklaşımda ise sistem, sorunu kullanıcıdan önce kendisi tespit eder ve ilgili ekibe haber verir. Health check, bu proaktif yaklaşımın temel taşlarından biridir ve genel kesinti yönetimi süreçlerinin de başlangıç noktasını oluşturur; bir sorunu ne kadar erken tespit ederseniz, müdahale süreniz de o kadar kısalır.

Health Check Türleri

Health check tek bir kontrol değil, farklı katmanları hedefleyen birden fazla kontrol türünün bir arada kullanılmasıyla anlam kazanır.

Temel ping/erişilebilirlik kontrolü: En basit seviyedir. Sunucunun ağ üzerinden erişilebilir olup olmadığını, yani "ayakta" olup olmadığını kontrol eder. Ancak bu kontrol tek başına yetersizdir; sunucu ayakta olabilir ama üzerindeki uygulama çökmüş olabilir.

Uygulama seviyesi kontrol: Servisin sadece açık olup olmadığını değil, beklenen şekilde çalışıp çalışmadığını sorgular. Örneğin bir web sunucusunun sadece bağlantı kabul etmesi değil, doğru içerikle yanıt vermesi kontrol edilir.

Veritabanı bağlantı kontrolü: Çoğu uygulama bir veritabanına bağımlıdır. Uygulama çalışıyor görünse bile veritabanına bağlanamıyorsa fonksiyonel olarak çalışmıyor demektir. Bu nedenle uygulamanın veri katmanıyla iletişimi ayrıca doğrulanmalıdır.

Kaynak kullanımı kontrolü: Sunucunun donanım kaynaklarının (CPU, bellek, disk) sınırlarına ne kadar yaklaştığını izler. Bu, henüz bir kesinti oluşmadan önce olası sorunları öngörmeye yarar.

Bu dört tür birbirinin yerine geçmez, birbirini tamamlar. Yalnızca ping kontrolüyle yetinen bir sistem, uygulamanın "yarı çökmüş" durumlarını kaçırabilir; yalnızca kaynak kullanımına bakan bir sistem ise servisin fiilen yanıt verip vermediğini bilemez.

İzlenmesi Gereken Temel Metrikler

Sağlıklı bir health check yapılandırması, doğru metrikleri izlemekle başlar.

• CPU kullanımı: Sürekli yüksek CPU kullanımı, verimsiz kod, artan trafik veya arka planda beklenmeyen bir işlemin çalışması gibi nedenlerden kaynaklanabilir.
• RAM kullanımı: Bellek kullanımının zamanla sürekli artması, bellek sızıntısı (memory leak) olasılığına işaret edebilir; bu durum fark edilmezse sunucu zamanla yanıt vermez hale gelebilir.
• Disk kullanımı: Disk doluluk oranı kritik eşiklere yaklaştığında hem uygulama hem de işletim sistemi seviyesinde ciddi sorunlar yaşanabilir; bu nedenle disk alanı önceden takip edilmelidir.
• Ağ gecikmesi (latency): Sunucu ile istemci veya sunucular arası iletişimdeki gecikme, kullanıcı deneyimini doğrudan etkiler; yüksek gecikme genellikle ağ altyapısındaki bir sorunun habercisidir.
• Servis/süreç durumu: İlgili uygulamanın process olarak fiilen çalışıp çalışmadığının kontrolü, en temel ama en kritik kontrollerden biridir.

Bu metrikler yalnızca anlık durumu görmek için değil, aynı zamanda kapasite planlama kararları için de değerlidir. Örneğin CPU ve RAM kullanımındaki artış trendi, ne zaman ek kaynak veya ölçeklendirme gerekeceğini önceden tahmin etmeye yardımcı olur.

Health Check Endpoint'i Tasarlarken Dikkat Edilmesi Gerekenler

Uygulama seviyesinde health check yapmak için genellikle ayrı bir /health veya /status endpoint'i oluşturulur. Bunun pratik bir nedeni vardır: bu endpoint, uygulamanın normal işlevlerinden bağımsız, sadece durum bilgisi döndürmek için tasarlanmış hafif bir kapı görevi görür.

Bu endpoint tasarlanırken dikkat edilmesi gereken birkaç nokta vardır:

• Hafif olmalı: Endpoint, sunucuya ek yük bindirmemelidir. Karmaşık sorgular veya ağır işlemler içermemelidir; aksi halde health check'in kendisi performans sorununa dönüşebilir.
• Yüzeysel ile derin kontrol dengesi: Endpoint yalnızca "200 OK" döndürüyorsa bu, uygulamanın gerçekten sağlıklı olduğu anlamına gelmeyebilir. Öte yandan her bağımlılığı (veritabanı, önbellek, dış servisler) her seferinde derinlemesine kontrol etmek de yavaşlığa yol açabilir. Bu ikisi arasında, ihtiyaca göre bir denge kurulmalıdır; örneğin hafif bir kontrol sık aralıklarla, daha kapsamlı bir kontrol daha seyrek çalıştırılabilir.
• Hassas bilgi sızıntısına dikkat: Endpoint yanıtında sürüm numarası, iç mimari detayları veya hata yığın izleri gibi bilgiler yer almamalıdır; bu tür bilgiler kötü niyetli kişiler için faydalı olabilir.
• Erişim kısıtlaması: Duruma göre bu endpoint'in yalnızca izleme araçlarının veya belirli iç ağların erişimine açık tutulması güvenlik açısından tercih edilebilir.

Kontrol Sıklığı (Interval) ve Zaman Aşımı (Timeout) Belirleme

Health check'in ne sıklıkla yapılacağı (interval) ve bir yanıtın ne kadar süre beklenmeden başarısız sayılacağı (timeout), yapılandırmanın en kritik ayarlarından biridir.

Çok sık kontrol yapmak, sunucuya ve ağa gereksiz ek yük bindirebilir; çok seyrek kontrol yapmak ise bir sorunun geç fark edilmesine yol açar. Bu nedenle interval belirlerken servisin kritikliği göz önünde bulundurulmalıdır: ödeme sistemi gibi kritik bir servis daha sık kontrol edilirken, daha az kritik bir arka plan servisi daha seyrek kontrol edilebilir.

Timeout değeri ise gerçekçi yanıt sürelerine göre ayarlanmalıdır. Çok kısa bir timeout, normalde sağlıklı olan ama biraz yavaş yanıt veren bir servisi hatalı şekilde "başarısız" olarak işaretleyebilir; çok uzun bir timeout ise gerçek bir sorunun tespitini geciktirir.

Ayrıca farklı health check türleri için farklı interval ve timeout değerleri uygun olabilir. Basit bir ping kontrolü saniyeler içinde sık sık yapılabilirken, veritabanı bağlantısını da içeren daha kapsamlı bir kontrol biraz daha uzun aralıklarla çalıştırılabilir.

Başarısız Kontrollerde Uyarı (Alert) Mekanizması Kurgulama

Bir health check başarısız olduğunda, bu bilginin bir yerde kaybolmaması, otomatik olarak bir uyarı sürecini tetiklemesi gerekir. Ancak burada dikkat edilmesi gereken, uyarının doğru kişilere veya ekiplere doğru kanaldan (örneğin ilgili ekibin takip ettiği bir bildirim kanalı) ulaşmasıdır. Yanlış kişiye ulaşan veya kaybolan bir uyarı, hiç uyarı olmamasıyla neredeyse aynı sonucu doğurur.

Kademeli bir uyarı mantığı kurmak genellikle faydalıdır: ilk başarısızlıkta düşük öncelikli bir bilgilendirme gönderilirken, başarısızlık tekrarlandıkça uyarının önceliği artırılıp kritik seviyeye taşınabilir. Bu sayede hem geçici dalgalanmalar gereksiz paniğe yol açmaz hem de gerçek ve kalıcı sorunlar gerektiği ciddiyetle ele alınır.

Bu uyarı mekanizması, izole bir sistem olarak değil, genel kesinti yönetimi sürecinin bir parçası olarak tasarlanmalıdır; yani bir uyarı geldiğinde kimin, hangi adımları hangi sırayla atacağı önceden tanımlanmış olmalıdır.

Yanlış Pozitifleri Azaltmak: Eşik Değerleri ve Retry Mantığı

Health check sistemlerinin en yaygın sorunlarından biri yanlış pozitif uyarılardır: sistem aslında sağlıklıyken geçici bir dalgalanma nedeniyle "başarısız" olarak işaretlenmesi. Bu durum sıkça yaşandığında ekiplerde "alarm yorgunluğu" oluşur; sürekli yanlış alarmlarla karşılaşan ekipler, zamanla gerçek uyarılara da daha az dikkat etmeye başlayabilir.

Bunu azaltmanın en yaygın yollarından biri retry (tekrar deneme) mantığıdır. Tek bir başarısız kontrolde hemen alarm vermek yerine, kısa aralıklarla birkaç kez daha kontrol yapılır; yalnızca ardışık birkaç başarısızlık sonrasında gerçek bir uyarı tetiklenir. Bu, geçici bir ağ titremesi ile gerçek bir kesintiyi ayırt etmeye yardımcı olur.

Benzer şekilde, kaynak kullanımı gibi metrikler için de tek bir eşik değeri yerine süreyle birlikte düşünülen eşikler kullanmak mantıklıdır. Örneğin CPU kullanımının yüksek bir seviyeyi geçmesi tek başına anlamlı olmayabilir, ama bu durumun birkaç dakika boyunca sürmesi gerçek bir soruna işaret edebilir. Bu tür eşik ve süre kombinasyonları, geçici dalgalanmaları gerçek sorunlardan ayırmanın pratik bir yoludur.

Load Balancer ve İzleme Araçlarıyla Entegrasyon

Health check verileri, tek başına bir izleme paneli için değil, altyapının diğer bileşenleriyle etkileşim için de kullanılır.

Load balancer'lar (yük dengeleyiciler), trafiği birden fazla sunucu arasında dağıtırken genellikle her sunucunun health check durumuna bakar. Bir sunucu sağlıksız olarak işaretlendiğinde, yük dengeleyici bu sunucuya trafik göndermeyi geçici olarak durdurur ve trafiği sağlıklı sunuculara yönlendirir. Bu mekanizma, tek bir sunucudaki sorunun tüm kullanıcıları etkilemesini önler.

İzleme araçları ise farklı sunuculardan ve servislerden gelen health check sonuçlarını toplayarak genel bir sistem görünürlüğü sağlar. Bu sayede tek tek sunuculara bakmak yerine, altyapının bütününe dair bir durum resmi elde edilir.

Bu entegrasyonun mantığı belirli bir ürüne bağlı değildir; hangi araç kullanılırsa kullanılsın temel prensip aynıdır: health check sonuçları, ağ altyapısındaki yönlendirme kararlarını ve izleme sistemlerindeki durum göstergelerini besleyen bir girdi kaynağıdır.

Sonuçların Loglanması ve Geçmişe Dönük Analiz

Health check sonuçlarını yalnızca anlık olarak değerlendirmek, sistemin sunduğu potansiyelin yalnızca bir kısmından yararlanmak anlamına gelir. Bu sonuçların zaman içinde kaydedilmesi (loglanması), çok daha değerli bir analiz katmanı açar.

Geçmişe dönük loglar sayesinde tekrarlayan sorunlar veya trendler fark edilebilir. Örneğin belirli bir saatte tekrar eden kısa süreli yavaşlamalar, tek bir olay olarak değil, bir örüntü olarak görülebilir ve kök nedenine daha kolay ulaşılabilir.

Bu veriler aynı zamanda kapasite planlama kararlarına doğrudan girdi sağlar. Kaynak kullanımının zamanla nasıl arttığını gösteren loglar, ne zaman ek sunucu, bellek veya disk kapasitesi gerekeceğine dair somut bir temel oluşturur.

Ayrıca bir kesinti sonrasında yapılan kök neden analizinde (post-mortem), health check logları önemli bir kanıt kaynağıdır; sorunun ne zaman başladığını ve hangi bileşenlerin etkilendiğini net biçimde ortaya koyar.

Health Check Verilerini Kesinti Yönetimi Süreciyle İlişkilendirme

Health check verileri ile kesinti yönetimi süreci birbirinden bağımsız düşünülmemelidir. Bir kesinti yaşandığında, health check geçmişi genellikle kesintinin tam olarak ne zaman başladığını ve ne kadar sürdüğünü belgeleyen en güvenilir kaynaklardan biridir.

Birden fazla bileşenin bulunduğu bir sistemde, health check verileri hangi bileşenin sorundan ilk etkilenen olduğunu anlamaya da yardımcı olur. Örneğin veritabanı health check'i başarısız olmadan önce ağ gecikmesi metriklerinde bir artış görülüyorsa, bu bilgi sorunun kaynağına dair önemli bir ipucu sunar.

Kesinti sonrası yapılan değerlendirme toplantılarında (post-incident review) da health check verileri, olayların zaman çizelgesini netleştirmek ve gelecekte benzer sorunların nasıl daha erken tespit edilebileceğini tartışmak için kullanılır.

Sonuç olarak, iyi yapılandırılmış bir health check sistemi tek başına kesintileri önlemez, ama sorunları erken tespit ederek etkilerini sınırlar ve müdahale sürecini hızlandırır. Doğru metriklerin seçilmesi, makul interval ve timeout değerleri, yanlış pozitifleri azaltan retry mantığı ve sonuçların düzenli olarak loglanması bir araya geldiğinde, sistemin uzun vadeli güvenilirliğine somut bir katkı sağlar.