NetScaler Health Monitor: Service UP Ama Uygulama Gerçekten Sağlıklı mı?

Citrix ADC / NetScaler troubleshooting sırasında yalnızca TCP portunun açık olması, uygulamanın gerçekten sağlıklı olduğu anlamına gelmez.

Örneğin backend sunucu:

10.10.20.15:443

TCP bağlantısını kabul ediyor olabilir.

TCP 443 → UP

Ama uygulama tarafında:

HTTP 500

veya:

HTTP 503

dönüyor olabilir.

Bu nedenle Health Monitor tasarımı kritik hale gelir.

TCP Monitor

TCP monitor temel olarak ilgili porta bağlantı kurulup kurulamadığını kontrol eder.

Yani:

Port açık mı?

sorusuna cevap verir.

Ama uygulamanın gerçekten çalışıp çalışmadığını tek başına doğrulamaz.

HTTP / HTTPS Monitor

HTTP veya HTTPS monitor kullanıldığında NetScaler belirli bir HTTP isteği gönderip beklenen response code’u kontrol edebilir.

Örneğin uygulamanın health endpoint’i:

GET /health

ve beklenen cevap:

200 OK

ise monitor buna göre tasarlanabilir. NetScaler HTTP monitor’larında httpRequest ve respCode parametreleri kullanılabilir. docs.netscaler.com

Örnek:

add lb monitor MON_WEB HTTPS -httpRequest "GET /health" -respCode 200

ServiceGroup’a bağlamak için:

bind serviceGroup SG_WEB -monitorName MON_WEB

NetScaler custom monitor’ların service veya service group’lara bağlanmasını destekler. docs.netscaler.com

Request / Response Kontrolü Neden Önemli?

Sadece:

TCP 443

kontrol etmek yerine gerçek uygulama endpoint’ini izlemek daha anlamlıdır.

Örneğin:

/health
/ready
/status

gibi endpoint’ler kullanılabilir.

Daha gelişmiş senaryolarda sadece HTTP status code değil, dönen response içeriği de kontrol edilebilir. NetScaler’ın HTTP-ECV monitor tipi belirli bir request gönderip beklenen response string’i doğrulayabilir. docs.netscaler.com

Troubleshooting Zinciri

Ben NetScaler troubleshooting sırasında şu zinciri takip ederim:

VIP → LB vServer → ServiceGroup → Member → Monitor → SNIP → Backend

Çünkü problem her zaman backend uygulamada olmayabilir.

Örneğin:

• LB vServer DOWN olabilir.
• ServiceGroup member yanlış portta olabilir.
• Monitor yanlış endpoint’i kontrol ediyor olabilir.
• SNIP üzerinden backend’e erişim olmayabilir.
• Backend TCP’yi kabul ediyor ama uygulama hata dönüyor olabilir.

En Kritik Nokta

Load Balancer’ın görevi yalnızca:

“Port açık mı?”

sorusuna cevap vermek değildir.

Asıl hedef:

“Bu backend şu anda gerçekten kullanıcı trafiği almaya uygun mu?”

sorusunu doğru health monitor ile cevaplayabilmektir.

Bu nedenle production ortamlarında yalnızca TCP monitor yerine, uygulamanın gerçek sağlık durumunu gösterebilen HTTP/HTTPS application-level monitor kullanmak çoğu zaman daha doğru bir yaklaşımdır.