Tipik sağlık kontrolü bir endpoint'e istek gönderir, 200 yanıtı görür ve servisi sağlıklı kabul eder. Ancak modern uygulamalarda bu yeterli değildir. Uygulama ana sayfası cevap verebilir, fakat veritabanı bağlantısı yavaşlamış, cache katmanı bozulmuş, downstream bağımlılığı düşmüş veya oturum açma akışı çalışmaz hale gelmiş olabilir. Yük dengeleyici bu farkı göremezse trafiği "cevap veren ama iş yapamayan" kurum servislerine göndermeye devam eder.
Tek aşamalı kontroller oturum tabanlı protokollerde daha da yetersiz kalır. FTP, LDAP, Oracle veya özel TCP protokollerinde yalnızca portun açık olması gerçek sağlık anlamına gelmez. Login yapmak, komut göndermek, beklenen cevabı almak, gerekirse çıkış yapmak ve sonuç içeriğini doğrulamak gerekir. Aksi halde servis ulaşılabilir görünür ama gerçek kullanıcı işlemi başarısız olur.
İçerik doğrulaması da yalnızca düz metin eşleşmesine bırakıldığında kırılgan hale gelir. Bir API her zaman "OK" kelimesini döndürebilir; fakat JSON içindeki dependency durumu, gecikme metriği veya iş kuralı başarısız olabilir. Sağlık kontrolü yanıtın anlamını sorgulayamadığında, uygulama seviyesi bozulmalar geç fark edilir.
Doğru yaklaşım, sağlık denetimini protokol derinliği, çok adımlı senaryo, içerik sorgusu ve ayarlanabilir rise/fall eşikleriyle birlikte ele almaktır. Probe işlemleri ana trafik akışından izole çalışmalı; yavaş veya takılan sağlık kontrolleri kullanıcı trafiğini geciktirmemelidir.
TR7 Aktif Sağlık İzleme bu modeli sunar: 11 protokolü tek konfigürasyonla denetler, çok adımlı senaryoları çalıştırır, JSONata ile içerik anlamını doğrular ve yalnızca gerçekten sağlıklı hedefleri rotasyonda tutar.
TR7, sağlık denetimini tek protokol kontrolünden çıkarıp çok protokollü, senaryo tabanlı ve içerik doğrulamalı bir karar sistemine dönüştürür.
TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS ve Oracle kontrolleri aynı sağlık denetimi nesnesinden yönetilir. Seçilen checkType değerine göre yalnızca ilgili alanlar görünür ve operatör gereksiz parametrelerle uğraşmaz.
TCP, UDP ve Oracle gibi kontrollerde send, expect, regex ve wait adımlarıyla sıralı kontrol akışı oluşturulur. Herhangi bir adım başarısız olursa probe başarısız sayılır ve hedefin sağlık durumu buna göre değerlendirilir.
HTTP ve HTTPS kontrollerinde JSONata sorguları kullanılarak JSON yanıtın içindeki gerçek durum okunabilir. Servis yalnızca 200 dönmekle sağlıklı sayılmaz; dependency, skor, latency veya iş durumu gibi alanlar da kontrol edilebilir.
Sağlıklıdan bozuğa geçiş için gerekli başarısız yanıt sayısı ve bozuk durumdan sağlıklıya dönüş için gerekli başarılı yanıt sayısı ayrı ayrı ayarlanır. Bu yapı geçici ağ dalgalanmalarının hedefi sürekli rotasyona sokup çıkarmasını azaltır.
Aktif Sağlık İzleme, farklı servis tiplerini aynı editörde tanımlanabilir, test edilebilir ve operasyonel eşiklerle yönetilebilir hale getirir.
TR7; TCP, UDP, HTTP, HTTPS, PING, DNS, FTP, FTPS, LDAP, LDAPS ve Oracle sağlık kontrollerini destekler. Operatör Oracle veritabanı, LDAP dizini, DNS sunucusu, FTPS deposu veya HTTP API için ayrı araç kullanmak zorunda kalmaz. Seçilen protokol tipine göre ilgili alanlar açılır, ilgisiz alanlar gizlenir. Bu model, heterojen kurum servislerinde sağlık kontrolünü standart ve yönetilebilir kılar.
TCP kontrollerinde sendText, expectText, expectRegex ve wait adımları sıralı biçimde çalıştırılabilir. SMTP banner, IMAP yetenek sorgusu, Redis PING/PONG, MQTT yanıtı veya özel TCP protokol mesajları bu modelle test edilebilir. Tek bağlantı açma kontrolü yerine gerçek protokol diyaloğu yürütülür. Her adım beklenen sonucu üretmezse hedef sağlıksız kabul edilir.
UDP kontrollerinde send, wait, expectText ve expectRegex adımları kullanılabilir. Gönderilecek veri text, hex veya base64 formatında tanımlanabilir; bu da binary protokol probe'ları için esneklik sağlar. DNS, NTP, RADIUS, SIP veya benzeri UDP servislerinde yalnızca portun açık olması değil, beklenen protokol cevabı doğrulanır. Bu sayede UDP servisleri de aktif ve anlamlı biçimde izlenebilir.
HTTP/HTTPS sağlık kontrollerinde metod, URI, özel header listesi, request body ve virtual host değeri tanımlanabilir. API endpoint'i Authorization header'ı, JSON body veya özel Host başlığıyla probe edilebilir. Kabul edilebilir status kodları tek değer olmak zorunda değildir; 200, 204 veya 304 gibi birden fazla yanıt sağlıklı sayılabilir. Bu yapı sağlık kontrolünü gerçek uygulama kullanımına yaklaştırır.
contentCheckMode jsonata seçildiğinde response body JSON olarak değerlendirilir ve JSONata ifadesi çalıştırılır. Örneğin servis durumu, dependency sonucu, veritabanı gecikmesi veya iş metriği tek ifade içinde kontrol edilebilir. İfade truthy sonuç üretirse hedef sağlıklı, falsy üretirse başarısız kabul edilir. JSONata hataları loglanarak yanlış ifade veya beklenmeyen response yapısı görünür hale gelir.
JSONata gerekmeyen basit senaryolarda contentQuery ile response body içinde metin araması yapılabilir. "Welcome", "UP", "Service Ready" veya uygulamaya özel marker metinler hızlı biçimde kontrol edilir. Bu mod, sade health endpoint'leri veya eski uygulamalar için düşük karmaşıklıklı bir çözüm sunar. Operatör ihtiyaca göre basic kontrol ile JSONata arasında seçim yapar.
LDAP/LDAPS kontrolleri yalnızca port erişimini değil, gerçek bind operasyonunu da test edebilir. Kullanıcı adı ve parola ile yapılan bind sayesinde dizin servisi kimlik doğrulama seviyesinde doğrulanır. Port açık olsa bile bind kuyruğu, yetki veya servis problemi varsa hedef sağlıksız kabul edilebilir. Bu özellikle AAM ve kurumsal erişim akışları için kritik görünürlük sağlar.
Oracle sağlık kontrollerinde bağlantı bilgisi, kullanıcı, parola ve senaryo adımları tanımlanabilir. executeCmd ile SQL çalıştırılır, beklenen metin veya minimum satır sayısı kontrol edilir. Basit bağlantı testi yerine gerçek veri erişimi ve iş metriği sorgulanabilir. Bu yaklaşım, veritabanı erişimi var mı sorusunu uygulama açısından anlamlı hale getirir.
Sağlık denetimleri; zamanlama, timeout, eşik, senaryo birleşimi, instance kimliği ve sistem içi özel kontrollerle birlikte işletilir.
testInterval 0.5 ile 3600 saniye arasında ayarlanabilir; varsayılan değer 1 saniyedir. timeout 0.01 ile 3600 saniye arasında yapılandırılabilir. Agresif timeout hızlı failover sağlar, fakat yanlış pozitif riskini artırabileceği için servis davranışına göre ayarlanmalıdır.
requiredFailure varsayılan olarak 2, requiredSuccess varsayılan olarak 3 değerini kullanır. Bu eşikler servislerin ne kadar hızlı rotasyondan çıkarılacağını ve ne kadar temkinli geri alınacağını belirler. Geçici dalgalanmaları filtrelemek için iki yönlü eşik ayrı ayrı yönetilir.
Bir sağlık denetimi birden fazla atomik kontrolü AND/OR mantığıyla birleştirebilir. Bu sayede yalnızca tek probe sonucu değil, birden fazla bağımlılık veya protokol adımı birlikte değerlendirilebilir. Karmaşık servis sağlığı daha gerçekçi biçimde modellenir.
Aynı sağlık kontrolü farklı kurum servislerinde ayrı state tutar. Health check instance kimliği, kontrol ve hedef bilgisiyle ayrıştırılır. Böylece aynı test profili birden fazla hedefe uygulansa bile her hedefin sağlık geçmişi bağımsız izlenir.
negate ayarı ile normal başarı mantığı tersine çevrilebilir. Bu mod, belirli bir URL'nin kapalı olması, belirli cevabın dönmemesi veya bir servis yolunun erişilemez kalması gereken senaryolarda kullanılır. Başarılı yanıt fail, başarısız yanıt success olarak yorumlanır.
Gateway monitor ve cluster IP bağlantı kontrolleri gibi sistem içi sağlık denetimleri otomatik üretilebilir. Bu kontroller yalnızca uygulama servislerini değil, TR7'nin çevresindeki bağlantı ve upstream erişilebilirlik durumunu da izlemek için kullanılır. GTM tarafında datacenter check gibi ek kontrol tipleriyle model genişleyebilir.
E-ticaret ekibi, HTTP check ve JSONata ile sepet servisinin yalnızca 200 dönmesini değil, veritabanı gecikmesi ve kullanılabilirlik durumunu da doğrulayabilir. Yavaş veya bağımlılığı bozuk kurum servisi otomatik olarak rotasyondan çıkarılır.
Banka ekipleri Oracle check ile bağlantı açmanın ötesine geçip gerçek SQL sorgusu çalıştırabilir. Beklenen satır sayısı veya sorgu sonucu sağlanmıyorsa hedef sağlıksız kabul edilir ve trafik güvenli hedeflere yönlendirilir.
Kamu uygulamaları, dizin servisinin yalnızca port seviyesinde değil, gerçek bind işlemiyle çalıştığını doğrulayabilir. Port açık fakat kimlik doğrulama başarısızsa sistem bunu sağlık problemi olarak algılar.
Telekom ekipleri DNS check ile kritik domain için gerçek kayıt sorgusu çalıştırabilir. DNS portunun açık olması yeterli kabul edilmez; resolver'ın beklenen cevabı üretmesi sağlıklı sayılır.
11 protokol, çok adımlı senaryolar ve JSONata içerik doğrulamasıyla trafik kararlarınızı güvenilir sağlık verisine dayandırın. Kendi servislerinizle canlı bir kurulumda gezdirelim.