Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
Uygulamamda health check için nasıl bir /health endpoint'i tasarlamalıyım?
Kısa cevap
Sağlık adresi hızlı ve hafif olmalı, kimlik doğrulama istememeli ve yönlendirme yapmamalıdır. Sağlıklıyken 200 ve sabit bir metin ya da JSON, sağlıksızken 503 gibi 2xx dışı bir kod dönmelidir. Uygulamanın bağımlılıkları (veritabanı, önbellek) kontrol edilecekse sonuçlar kısa süre önbelleğe alınmalıdır; bütün sunucuların paylaştığı bir bağımlılığı sert denetlemek, o bağımlılık düştüğünde bütün sunucuları aynı anda trafikten çıkarır ve kullanıcılar 503 alır. TR7 tarafında adres Path + Query, beklenen kod Expected Status Codes, içerik Content Check Mode alanında tanımlanır.
Nasıl Çalışır?
TR7'nin HTTP ya da HTTPS denetiminde sunucuya gönderdiği istek:
| Özellik | Değer |
|---|---|
| Adres | Kurum Servisinin IP'si ve portu (ya da Use Different IP for Health Check ile girilen adres) |
| Yol | Path + Query (boşsa /) |
| Yöntem | Method (varsayılan GET) |
| User-Agent | tr7-health-check/2.0 (HTTP Headers ile değiştirilebilir) |
| Host | Virtual Domain (Host/SNI) doluysa o ad, boşsa sunucunun adresi |
| Yönlendirme | İzlenmez; 301/302 de bir durum kodu olarak değerlendirilir |
| Beklenen kod | Varsayılan yalnızca 200 |
| Sıklık | Period aralığında (varsayılan her saniye); cluster'da her cihaz ayrı denetler |
| Bağlantı | Her denetimde yeni bağlantı (HTTPS'te yeni TLS bağlantısı) |
Tasarım Önerileri
- Hızlı yanıt: Profildeki Timeout'un (varsayılan 1 sn) rahatça altında yanıt verilir; gövde küçük tutulur.
- Açık durum kodu: Sağlıklıyken 200, sağlıksızken 503 döner. Hata durumunda 200 ile hata sayfası dönmek denetimi yanıltır.
- İçerik: Sabit bir metin (ör.
OK; büyük/küçük harf önemlidir) ya da JSON (ör.{"status":"UP"}) döner; JSON için JSONata ifadesi kullanılır (ör.body.status = "UP"). - Kimlik doğrulama yok: Uygulama mutlaka bir anahtar istiyorsa profildeki HTTP headers alanıyla başlık gönderilir.
- Yönlendirme yok: 301/302 dönen adres, bu kodlar Expected Status Codes listesinde değilse başarısız sayılır.
- Bağımlılıklar dikkatli: Sunucunun kendi yerel bağımlılıkları kontrol edilir; paylaşılan bağımlılıklar için sonuç önbelleğe alınır ya da yalnızca bilgi olarak raporlanır.
- Sanal barındırma: Sunucu aynı IP'de birden fazla site barındırıyorsa profildeki Virtual Domain (Host/SNI) doldurulur (Health Check'te Host / SNI belirtebilir miyim (Virtual domain)?).
- PROXY protokolü: Sunucu PROXY protokolü bekliyorsa sağlık adresi PROXY gerektirmeyen ayrı bir porttan sunulur ve Use Different IP for Health Check ile o porta yönlendirilir; health check PROXY başlığı göndermez.
- Loglar: Sağlık adresi ayrı bir yolda tutulur; böylece web sunucusunda bu yol loglardan kolayca dışlanır (Health Check istekleri backend loglarımı dolduruyor; ne yapabilirim?).
TR7'de
- Profil: Load Balancer → Profiles → Health Checks → Add; Check Type HTTP ya da HTTPS, Path + Query
/health. - Kod: Expected Status Codes listesinde 200 (varsayılan) seçili bırakılır (HTTP health check'te belirli bir status code'u (ör. 200, 302) nasıl beklerim?).
- İçerik: Content Check Mode Basic (string match) ise Expected Content Query alanına
OK, JSONata expression ise JSONata Query alanına ifade yazılır (Yanıt içeriğinde belirli bir metni (ör. "OK") nasıl doğrularım?, Health Check'te JSON yanıtını alan bazında doğrulayabilir miyim (Content Check Mode: JSONata Expression)?). - Atama: Profil Kurum Servisinin Health Check alanında seçilir.
Sık Karıştırılan Noktalar
- "Ana sayfayı sağlık adresi olarak kullanırım." Ana sayfa ağır olabilir, yönlendirme yapabilir; ayrı ve hafif bir adres önerilir.
- "Sağlık adresi bütün bağımlılıkları sert denetlemeli." Paylaşılan bir bağımlılık düştüğünde bütün sunucular aynı anda trafikten çıkar.
- "Hata durumunda 200 ile hata mesajı dönmek yeterli." Durum kodu 2xx dışı olmalı ya da içerik kontrolü yapılmalıdır.
Dokümantasyonda nasıl yapılır
