Skip to main content

Sağlık Kontrolü Servisi (Health Check Service)

Sistem Analizi

GözlemlenebilirlikPRODUCTION

Normal Davranış

Mikro servis uç noktalarına (endpoints) hafif periyodik sentetik problar (synthetic probes) göndererek, küme hazırlığını (cluster readiness) doğrulamak için iç durum (internal state) bayraklarını ve engelleyici olmayan (non-blocking) G/Ç (I/O) döngülerini onlarca milisaniye içinde doğrular.

Çöküş Davranışı

Sığ (shallow) bir prob HTTP 200 OK döndürür çünkü web çerçevesi dinleyici iş parçacığı (listener thread) canlıdır, oysa arka uç veritabanı havuzları tamamen tükenmiş, bellek bozulmuş ve arka plan kuyruk işçileri (queue workers) ölmüştür; bu da zombi örnekleri kullanıcı isteklerini emmeye ve trafiği düşürmeye bırakır.

İş Sonuçları

Yanlış yapılandırılmış veya başarısız bir sağlık kontrolü (health check) korkunç bir ikilik yaratır: ya yanlış bir şekilde sağlıklı raporu vererek trafiği ölü örneklere gönderir ve yaygın kullanıcı hatalarına neden olur ya da yanlış bir şekilde sağlıksız raporu vererek, yük dengeleyiciler (load balancers) mükemmel derecede iyi sunucuları sonlandırdığında kendi kendine verilen kademeli bir Hizmet Reddi'ni (Denial of Service - DoS) tetikler. Her ikisi de sistem kullanılabilirliğini (availability) yok eder.

Görsel Tezahür

"Yük dengeleyicilerin (load balancers) 'Hizmette' ('In Service') ve 'Hizmet Dışı' ('Out of Service') arasında sürekli gidip gelmesi (flapping), 502 Kötü Ağ Geçidi (502 Bad Gateway) hatalarında ani sıçramalar ve boş arka uç hedef grupları (backend target groups)."

Satirical Behavior

"A simple ping endpoint that successfully returns '200 OK' while the actual database it relies on has been on fire for the last 45 minutes."

Bilinen İsimler

Liveness ProbeReadiness Check

Teknik Terminoloji

Pinging endpointChecking statusDeep health check

Hata Göstergeleri

False positiveZombie processTimeout

Sistem Mimarisi

Click or hover to interact

Kullanan Karakterler

FAQ

Normalde nasıl davranır?

Mikro servis uç noktalarına (endpoints) hafif periyodik sentetik problar (synthetic probes) göndererek, küme hazırlığını (cluster readiness) doğrulamak için iç durum (internal state) bayraklarını ve engelleyici olmayan (non-blocking) G/Ç (I/O) döngülerini onlarca milisaniye içinde doğrular.

Nasıl çöker?

Sığ (shallow) bir prob HTTP 200 OK döndürür çünkü web çerçevesi dinleyici iş parçacığı (listener thread) canlıdır, oysa arka uç veritabanı havuzları tamamen tükenmiş, bellek bozulmuş ve arka plan kuyruk işçileri (queue workers) ölmüştür; bu da zombi örnekleri kullanıcı isteklerini emmeye ve trafiği düşürmeye bırakır.

İş sonuçları nelerdir?

Yanlış yapılandırılmış veya başarısız bir sağlık kontrolü (health check) korkunç bir ikilik yaratır: ya yanlış bir şekilde sağlıklı raporu vererek trafiği ölü örneklere gönderir ve yaygın kullanıcı hatalarına neden olur ya da yanlış bir şekilde sağlıksız raporu vererek, yük dengeleyiciler (load balancers) mükemmel derecede iyi sunucuları sonlandırdığında kendi kendine verilen kademeli bir Hizmet Reddi'ni (Denial of Service - DoS) tetikler. Her ikisi de sistem kullanılabilirliğini (availability) yok eder.

Why does performing deep synchronous database queries in Kubernetes liveness probes cause catastrophic cascading cluster restarts?

A liveness probe exists solely to detect unrecoverable process deadlocks requiring a container restart (SIGKILL). If a liveness probe synchronously queries an external database, a transient database query spike or network blip causes every replica's liveness check to fail simultaneously. Kubernetes immediately kills and restarts all service pods at once, overwhelming the database with bootup connection surges and turning a minor 5-second database slowdown into an unrecoverable cluster-wide outage.

How should modern microservices decouple readiness checks from liveness checks to achieve graceful zero-downtime deployments?

Liveness probes should only verify internal process state (e.g., checking if event loops are cycling or memory is below fatal limits) without evaluating external dependencies. Readiness probes should evaluate critical dependencies (e.g., cache connectivity and schema migration state) and flip to unhealthy to temporarily remove the pod from the load balancer rotation without triggering a process restart, allowing in-flight requests to drain cleanly.

AI özeti

Health Check Service is a OBSERVABILITY system in TinyCTO.tv. Dispatches lightweight periodic synthetic probes to microservice endpoints, verifying internal state flags and non-blocking I/O loops within tens of milliseconds to validate cluster readiness.