Basic Observability Awareness
Bu modülde MiniBank'in production'da anlaşılabilir hale gelmesini konuşuyoruz: Actuator endpoint'leri, custom health sinyalleri, liveness/readiness, runtime log level yönetimi ve correlation ID yaklaşımı.
Bu modülde kullanacağımız terimler
Observability
Uygulamanın içeride ne yaptığını dışarıdan anlayabilme yeteneğidir.
Spring Boot'ta log, metric, health ve trace sinyalleriyle pratik hale gelir.
Monitoring
Toplanan sinyalleri izleme ve alarm üretme pratiğidir.
Monitoring iyi çalışsın diye uygulamanın önce doğru sinyal üretmesi gerekir.
Actuator
Spring Boot uygulamasının runtime bilgisini endpoint olarak açan modüldür.
Health, metrics, info ve loggers gibi endpoint'leri eğitimde hızlıca gözlemlememizi sağlar.
Health endpoint
Uygulamanın çalışabilir durumunu gösteren endpoint'tir.
Load balancer, Kubernetes ve destek ekipleri için ilk kontrol noktasıdır.
Info endpoint
Uygulama hakkında basit metadata dönen endpoint'tir.
Versiyon, modül veya checkpoint bilgisini görünür yapmak için kullanılır.
Metrics endpoint
Uygulama ve JVM davranışına ait sayısal ölçümleri gösterir.
Latency, memory ve request sayısı gibi konuların izlenmesine zemin hazırlar.
Loggers endpoint
Logger seviyelerini runtime'da görmeye ve değiştirmeye yarar.
Production'da restart etmeden geçici DEBUG açma ihtiyacını anlatır.
HealthIndicator
Custom health bilgisi üreten Spring Boot bileşenidir.
MiniBank'e özel bağımlılık veya repository durumunu health response'a ekler.
Liveness
Process'in canlı olup olmadığını anlatan health sinyalidir.
Yanlış tasarlanırsa platform gereksiz restart yapabilir.
Readiness
Uygulamanın trafik almaya hazır olup olmadığını anlatır.
Startup, dependency veya geçici bakım durumlarında trafik yönlendirmeyi etkiler.
Correlation ID
Bir request'i loglarda takip etmeye yarayan ortak kimliktir.
Dağınık log satırlarını aynı kullanıcı isteğine bağlamayı kolaylaştırır.
MDC
Log satırlarına thread-local context bilgisi ekleme mekanizmasıdır.
Spring MVC request loglarında correlation ID taşımak için pratik bir araçtır.
Observability ile monitoring aynı şey mi?
Hayır. Observability, uygulamanın anlamlı sinyaller üretme yeteneğidir. Monitoring ise bu sinyalleri takip etme, dashboard'a koyma ve alarm üretme pratiğidir. Uygulama doğru sinyal üretmiyorsa en pahalı monitoring aracı bile sadece belirsizliği daha güzel gösterir.
Monitoring sorusu
Servis ayakta mı? Hata oranı yükseldi mi? Alarm üretmeli miyiz?
Observability sorusu
Bu hata hangi request'te oldu? Hangi dependency yavaştı? Uygulama trafik almaya hazır mı?
Actuator endpoint mantığı
spring-boot-starter-actuator, uygulamanın runtime bilgisini HTTP endpoint'leri üzerinden görünür yapar.
Bu endpoint'ler business API değildir; uygulamanın kendisini anlamak, ölçmek ve yönetmek için kullanılır.
Health / info / metrics / loggers
/actuator/health
Uygulamanın genel sağlık durumunu gösterir. Custom health detayları buraya eklenebilir.
/actuator/info
Uygulama adı, modül, checkpoint veya build bilgisini göstermek için uygundur.
/actuator/metrics
JVM, HTTP, datasource ve uygulama metric isimlerini görmemizi sağlar.
/actuator/loggers
Logger seviyelerini okumayı ve uygun izinle runtime'da değiştirmeyi sağlar.
management:
endpoints:
web:
exposure:
include: health,info,metrics,loggers
endpoint:
health:
probes:
enabled: true
show-details: always
Metric'lere yüksek-kardinaliteli etiket (userId, IBAN, requestId gibi sınırsız değerler) eklemek her benzersiz değer için ayrı time-series üretir; bellek ve metric backend zamanla patlar. Etiketleri sınırlı, sabit kümeli boyutlarda tut (örn. endpoint, status, region); kimlik bilgisini metric'e değil log'a / trace'e koy.
Custom HealthIndicator neden kullanılır?
Default health endpoint bize datasource, disk ve process gibi temel bilgileri verir. Fakat her ürünün kendi kritik bağımlılıkları vardır. MiniBank için external fraud client config'i, customer repository durumu veya risk servis bağlantısı health response içinde görünür olabilir.
Liveness
Process yaşıyor mu sorusudur. Genelde sadece uygulamanın kilitlenip kilitlenmediğine bakar. Dış servis geçici kapalı diye process restart etmek çoğu zaman doğru değildir.
Readiness
Uygulama trafik almaya hazır mı sorusudur. Dependency hazır değilse platform bu instance'a trafik göndermeyebilir.
Liveness'i dış bağımlılıklara (DB, fraud servisi) bağlama. Dış servis geçici düştüğünde liveness DOWN dönerse platform process'i gereksiz yere restart eder; bu, geçici bir aksaklığı yeniden başlatma fırtınasına çevirir. Liveness yalnızca "process kilitlendi mi"ye baksın; bağımlılık sağlığı readiness'e veya ayrı bir custom health'e gitsin.
@Component
class CustomerHealthIndicator implements HealthIndicator {
private final CustomerRepository customerRepository;
CustomerHealthIndicator(CustomerRepository customerRepository) {
this.customerRepository = customerRepository;
}
@Override
public Health health() {
int customerCount = customerRepository.findAll().size();
return Health.up()
.withDetail("customerRepository", "READY")
.withDetail("sampleCustomerCount", customerCount)
.build();
}
}
Runtime log level ve Correlation ID
Log seviyesi production'da dikkatli yönetilir. Bazen bir incident sırasında kısa süreli DEBUG açmak gerekir; uygulamayı restart etmeden bunu yönetebilmek önemlidir. Correlation ID ise tek bir request'in log satırlarını birbirine bağlar.
Runtime log level
/actuator/loggers/com.definex.minibank ile mevcut level okunabilir; uygun izinle POST request ile değiştirilebilir.
Correlation ID
X-Correlation-Id request header'ı response'a taşınır ve MDC üzerinden log pattern içine yazılır.
MDC thread-local'dır: correlation ID yalnızca isteği işleyen thread'de görünür. İş bir @Async metoda, thread-pool'a, CompletableFuture'a veya reactive zincire geçtiğinde MDC otomatik taşınmaz; o log satırları correlation ID'siz kalır. Async sınırında bağlamı elle taşı (TaskDecorator / context propagation) ve filter'da MDC.remove'u finally'de yap — yoksa havuzdaki bir sonraki isteğe sızar.
MiniBank Case 11 — Actuator, Custom Health & Correlation ID
Bu case bir sürpriz debug görevi değildir. Eğitmenle birlikte MiniBank'e production gözlenebilirliği için temel sinyaller eklenir. Görev listesi, doğrulama komutları, kod adımları ve kabul kriterleri Lab Dashboard'da.
Lab sırasında geride kalırsan lab-11-complete branch'ine geçip herkesle aynı noktadan devam edebilirsin. lab-11-complete eğitimin final kod durumudur.
Bu modülden akılda kalması gerekenler
Observability production gereksinimidir.
Uygulama içeride ne yaptığını anlatamıyorsa incident yönetimi zorlaşır.
Monitoring araçtan önce sinyal ister.
Health, metric ve log sinyalleri bilinçli tasarlanmalıdır.
Actuator güçlü ama hassastır.
Endpoint exposure ve security birlikte düşünülmelidir.
Health sadece UP/DOWN değildir.
Liveness ve readiness farklı operasyonel sorulara cevap verir.
Runtime log level dikkatli kullanılmalıdır.
DEBUG geçici açılır, sonra kapatılır; aksi halde veri ve performans riski doğar.
Correlation ID logları anlamlı hale getirir.
Tek bir request'in izini birçok log satırı arasında takip etmeyi kolaylaştırır.
Kısa kontrol soruları
1. Observability ile monitoring arasındaki fark nedir?
Observability uygulamanın anlamlı sinyal üretme yeteneğidir. Monitoring bu sinyalleri izleme, dashboard'a koyma ve alarm üretme pratiğidir.
2. Actuator ne işe yarar?
Spring Boot uygulamasının health, info, metrics ve loggers gibi runtime bilgilerini endpoint olarak açmasını sağlar.
3. Liveness ve readiness neden ayrı düşünülür?
Liveness process canlı mı sorusudur; readiness ise uygulama trafik almaya hazır mı sorusudur. Her dependency sorunu process restart sebebi değildir.
4. Custom HealthIndicator ne zaman kullanılır?
Uygulamaya özel repository, external client veya domain bağımlılığı health response içinde görünür yapılmak istendiğinde kullanılır.
5. Runtime log level yönetimi neden dikkat ister?
DEBUG logları faydalı olabilir ama performans, veri güvenliği ve log maliyeti riski taşır. Geçici açılıp kontrollü kapatılmalıdır.
6. Correlation ID hangi problemi çözer?
Aynı request'e ait log satırlarını ortak bir kimlikle ilişkilendirir; hata takibini ve destek sürecini hızlandırır.