Actuator ve Gözlemlenebilirlik — Sağlık, Metrik, İz
Önce şunu oku: Auto-configuration — Bu Bean Nereden Geldi?
30 saniyede özet
Uygulaman iki farklı soruya cevap verir: 'yaşıyor musun?' (liveness) ve 'iş alabilir misin?' (readiness). Veritabanını ilk soruya bağlamak, küçük bir kesintiyi bütün uygulamanın yeniden başlamasına çevirir.
Veritabanı beş dakika kapalı kaldı. Sonra uygulama on beş dakika açılmadı. Arada bir satır bile kod değişmedi — sadece sağlık kontrolü yanlış yere konmuştu.
-
Bayt: Veritabanı beş dakika kapalı kaldı, uygulama ise on beş dakika açılmadı!
-
Sen: Veritabanı dönünce uygulama da dönmedi mi?
-
Bayt: Dönmedi! Pod'lar durmadan yeniden başlıyordu.
-
Bayt: Hastane iki ayrı soru sorar: yaşıyor mu, ve ziyaretçi alabilir mi? Hangisini yanlış cevapladık?
Actuator: uygulama kendini anlatır
spring-boot-starter-actuator, uygulamaya “nasılsın?” diye sorulabilecek adresler ekler: health, info, metrics, prometheus. Boot 3’te dışarıya varsayılan olarak yalnızca /actuator/health açıktır.
env, heapdump gibi uç noktalar ayarları ve belleği gösterir. Açacaksan ayrı bir management portunda, kimlik doğrulamanın arkasında aç.
Kafam karıştı, daha basit anlat
Actuator, uygulamaya “nasılsın” diye sorabileceğin kapılar açar. Sağlık kapısı herkese açık olabilir. Ayarları ve belleği gösteren kapılar ise kilitli durmalı.
spring-boot-starter-actuator ekledin ve hiçbir ayar yazmadın. Spring Boot 3'te HTTP üzerinden hangi uç nokta açılır?
Güvenlik taramasında /actuator/env ve /actuator/heapdump uç noktalarının internete açık olduğu görüldü. Asıl risk ne?
Liveness ve readiness
Veritabanı kontrolü liveness'ta. Veritabanı düştü ve liveness art arda üç kez başarısız oldu. Kubernetes ne yapar — bu veritabanını düzeltir mi? Cevabı göster
Pod’ları yeniden başlatır. Veritabanına dokunmaz, onu düzeltmez. Açılan pod’lar da aynı veritabanına bakıp yeniden düşer.
Adım adım oku
- Veritabanı düşer.
- Veritabanı kontrolü liveness'a bağlıysa Kubernetes sağlıklı pod'ları ölü sanıp durmadan yeniden başlatır.
- Kontrol readiness'a bağlıysa pod ayakta kalır; yalnızca trafikten çıkarılır.
- Veritabanı dönünce readiness yeniden olumlu olur ve ayakta bekleyen pod hemen iş almaya başlar.
| Düşerse Kubernetes ne yapar | Neye bakmalı | |
|---|---|---|
| liveness probeKubernetes'in "bu süreç hâlâ çalışabilir durumda mı?" sorusu. Art arda düşerse pod yeniden başlatılır; bu yüzden yalnızca yeniden başlatmanın düzelteceği şeylere bakmalı.Sözlükte gör → | Pod’u yeniden başlatır | Yalnızca yeniden başlatmanın düzelteceği şeylere |
| readiness probeKubernetes'in "bu pod şu an trafik almaya hazır mı?" sorusu. Düşerse pod yeniden başlatılmaz, yalnızca load balancer'dan çıkarılır.Sözlükte gör → | Pod’u trafikten çıkarır | O pod’a özgü geçici durumlara |
Liveness’ı düşürmek “beni yeniden başlat” demektir. Dış bir bağımlılık yeniden başlatmayla düzelmez. Boot’un varsayılan liveness grubu bu yüzden dış sistemlere bakmaz.
Kafam karıştı, daha basit anlat
Liveness, “beni yeniden başlat” demektir. Readiness ise “şu an müşteri alamıyorum” demektir. Veritabanı çöktüyse yeniden başlamak işe yaramaz, müşteri almayı bırakmak yeter.
Kubernetes'te liveness ve readiness probe'ları düştüğünde ne olur?
Kendin gör
Liveness ve readiness — veritabanı düşünce pod'lara ne olur?
Tohum 280193| Periyot | Veritabanı | 3 pod | Karşılanan |
|---|
Oynat ya da adımla.
Şu an ne oldu?
3 pod, 5 periyotluk veritabanı kesintisi
Kesinti 2. periyotta başlıyor. İsteklerin yarısı veritabanı, yarısı önbellek istiyor.
Görevler0/3
Veritabanı kesintisini bir yeniden başlatma fırtınasına çeviraçık
İpucu
Kubernetes liveness düşen pod'u yeniden başlatır. Veritabanı, açılan pod'lar yeniden düşecek kadar uzun kapalı kalsın.
Veritabanı gerektirmeyen istekleri de reddettir — ama pod'ları yeniden başlatmadanaçık
İpucu
Pod'ların hepsi aynı anda "trafik almaya hazır değilim" derse?
Uzun bir kesintiyi hiçbir isteği load balancer'da kaybetmeden atlataçık
İpucu
Kesinti en az 5 periyot sürsün. Hiçbir sağlık grubu veritabanına bakmasın.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. Veritabanı iki grupta da: önce trafik kesiliyor, sonra üç pod birden yeniden başlıyor.
- Kesintiyi 9 periyot yap. Açılan pod’lar yeniden düşüyor: fırtına.
- Liveness’ı “yalnızca uygulama” yap. Yeniden başlatma yok — ama load balancer yine her şeyi reddediyor.
- Readiness’ı da “yalnızca uygulama” yap. Önbellekten gelen istekler kesinti boyunca karşılanıyor.
Liveness grubuna veritabanı sağlık kontrolü eklendi. Veritabanı 5 dakika kapalı kalırsa ne olur?
Metrik, iz ve log
| Sinyal | Cevapladığı soru | Araç |
|---|---|---|
| Metrik | ”Genel olarak nasılız?” | Micrometer + Prometheus |
| İz (trace) | “Bu istek zamanını nerede geçirdi?” | Micrometer Tracing |
| Log | ”Tam olarak ne oldu?” | Yapılandırılmış log + traceId |
Timer.builder("orders.place") .tag("status", result.name()) // sonlu bir küme .publishPercentileHistogram() // p95/p99 Prometheus'ta hesaplanır .register(registry) .record(duration);Ortalama, yavaş istekleri gizler. Kullanıcıların şikâyet ettiği yavaş istekler en yavaş %1’lik dilimdedir (p99) ve ortalamada kaybolur. Metrik etiketlerinin alabileceği değer sayısı (cardinalityBir metriğin etiket değerlerinin kaç farklı kombinasyon ürettiği. Her kombinasyon ayrı bir zaman serisidir; userId gibi sınırsız bir etiket metrik sistemini çökertir.Sözlükte gör →) da sınırlı kalmalı: her farklı değer ayrı bir veri serisi demektir.
Kafam karıştı, daha basit anlat
Ortalama, sıradaki en yavaş birkaç kişiyi gizler. En yavaş yüzde birlik dilime bakarsan, kimin gerçekten beklediğini görürsün.
Her soruyu en iyi cevaplayan sinyale yerleştir.
Panoda ortalama cevap süresi 80 ms, ama kullanıcılar yavaşlıktan şikâyet ediyor. En olası açıklama?
Tuzaklar
Paylaşılan bağımlılık readiness’ta. Bütün pod’lar aynı anda trafikten çıkar; veritabanı istemeyen sayfalar da kapanır.
Etikette kullanıcı kimliği. Her kullanıcı için ayrı bir veri serisi oluşur ve izleme sistemi (Prometheus) bu yükün altında ezilir.
Herkese açık Actuator. env ve heapdump şifreleri ve kullanıcı verisini gösterebilir.
Ağır sağlık kontrolü. Probe birkaç saniyede bir çalışır. Her seferinde pahalı bir sorgu atan kontrol, kendi başına bir yük olur.
Bu metrik eklendikten birkaç gün sonra Prometheus'un belleği tükeniyor. Hangi satır?
Aşağıdaki örnek bir bankanın kart provizyon servisinden: probe’lar için doğru health grupları, kart ağı bağlantısı için kendi health kontrolün, kart numarası taşımayan düşük kardinaliteli metrikler ve actuator’ı dışarıya kapatan ayrı bir port.
Derinleş · Kart provizyon servisinin gözlemlenebilirliği 5 dosya · ~117 satır · ilk okumada atlayabilirsin
Kendini sına
Liveness, uygulamanın yeniden başlatılması gerekip gerekmediğini sorar.
Veritabanı kontrolü readiness grubunda. Bütün pod'lar aynı veritabanını kullanıyor ve veritabanı düştü. Veritabanı gerektirmeyen, önbellekten verilen katalog sayfası ne olur?
Aklında kalacak üç şey
- 1 Liveness yalnızca yeniden başlatmanın düzelteceği şeylere bakmalı. Dış bir bağımlılığı oraya koymak, onun arızasında bütün pod'ları yeniden başlatır.
- 2 Readiness pod'u yalnızca trafikten çıkarır. Bütün pod'ların paylaştığı bir bağımlılığı oraya koymak, onun arızasını tam bir kesintiye çevirir.
- 3 Metrik etiketleri sınırlı sayıda değerden gelir ve gecikme ortalamayla değil yüzdelikle izlenir. Tek bir isteğin ayrıntısı log ve trace'in işidir.
5 kart sonraki derste seni bekliyor
Bu dersin üstüne kurulanlar
Bunlar bu dersi temel alıyor; hazır olduğunda devam edebilirsin.
- Spring Boot EkosistemiGraceful Shutdown — Deploy Sırasında Kaç İstek Düşer?Yeni sürüm çıkarken yarım kalan istekler ne oluyor?Derse git
- Spring Boot EkosistemiYapılandırılmış Loglama — Gece 2'de Doğru Satırı BulmakGece 2'de bir havale başarısız oldu. Üç servisin logunda 9 satır '42' içeriyor. Hangisi gerçekten o müşterinin?Derse git
- Mikroservisler & Design PatternsDağıtık Tracing — Bir İsteği Beş Servis Boyunca İzlemekBir istek beş servisten geçti ve biri hata verdi. Beş ayrı log dosyasında aynı isteği nasıl bulursun?Derse git