Java Uygulama Sunucularında Temel Performans Metrikleri ve JavaMelody Kurulumu

Uygulama Sunucularında İzlenen Temel Performans Metrikleri

Aşağıdaki metrikler, hem anlık sorun tespiti hem de kapasite planlama ve ölçek stratejisi için kritik öneme sahiptir.

1. Hafıza Kullanımı (Memory)

JVM bellek kullanımını takip etmek, özellikle de OutOfMemoryError (OOM) hatalarını önlemek açısından zorunludur. Heap ve non-heap kullanımındaki ani sıçramalar, kaçak (leak) veya gereğinden fazla obje yaşam süresine işaret edebilir.

2. Çöp Toplama (Garbage Collection - GC)

Sadece GC’nin çalışıp çalışmadığı değil, GC sıklığı ve duraksama süresi (pause time) izlenmelidir. Uzayan stop-the-world duraksamaları; kullanıcı isteklerinde gecikme, hatta zaman aşımı olarak yansır. GC log analizi ve doğru heap/GC ayarları ile bu süreler minimize edilmelidir.

3. Thread Kullanımı

Aşırı eşzamanlılık (çok fazla aktif thread) CPU’yu doyuramadığı durumlarda bile context switching maliyeti yüzünden sistemi yavaşlatabilir. Thread havuzlarının (Tomcat thread pool vb.) boyutunu izlemek ve uygun limitlerde tutmak gerekir.

4. Request Throughput

Request throughput, birim zamanda işlenen istek sayısını ifade eder. Ani düşüşler, arkadaki bir bağımlılıkta (DB, cache, üçüncü parti servis) sorun olduğuna işaret edebilir. Ölçek ihtiyacı da genellikle bu metriğe bakılarak belirlenir.

5. Session Kullanımı

Aktif oturum sayısı, oturumların ortalama yaşam süresi ve boyutu, özellikle stateful uygulamalarda önemlidir. Aşırı session kullanımı; bellek baskısı, seri hale getirme maliyeti ve replikasyon yükü oluşturur.

6. Tepki Süresi (Response Time)

Kullanıcı deneyimi denince ilk akla gelen metrik tepki süresidir. Hem ortalama (avg/mean) hem de p95/p99 kuyruk gecikmelerini izlemek gerekir. Artan tepki süreleri genellikle:

• Yoğun GC duraksamaları,
• Doyan thread havuzları,
• Yavaşlayan SQL sorguları,
• Harici servis gecikmeleri

gibi kök nedenlere işaret eder.

7. DB Connection Pool

Veritabanı bağlantı havuzu (HikariCP, DBCP, vb.) boyutu ve anlık doluluk oranı, performansın kalbidir. Pool tükenmesi durumunda istekler kuyrukta bekler; bu da tüm sistemi yavaşlatır. “Max pool size”, bekleme süreleri ve zaman aşımı oranları mutlaka takip edilmelidir.

8. Hata Sıklığı (Error Rate)

Uygulama istisnaları (Exception) ve HTTP hata kodları (5xx/4xx) için oransal izleme yapılmalıdır. Toplam isteğe oranla hata yüzdesinin artması, performans sorunu veya fonksiyonel bir hataya işaret eder.

9. UpTime (Kesintisiz Çalışma Süresi)

Özellikle üretim ortamında uptime, SLA taahhütleriyle doğrudan ilişkilidir. Sık restart veya beklenmedik çöküşler, JVM ayarları, memory leak, GC tuning veya altyapı problemlerine işaret ediyor olabilir.

Bu metrikler, hem anlık sorunları yakalamak hem de orta–uzun vadeli kapasite tahmini yapmak için referans noktasıdır.

JavaMelody Kurulumu (Spring Boot + Tomcat)

JavaMelody, Java uygulama sunucularında performans izleme için hafif ve etkili bir araçtır. Spring Boot + Tomcat üzerinde kurulumu oldukça basittir.

1) Maven Bağımlılığı

pom.xml dosyanıza aşağıdaki bağımlılığı ekleyin:

<dependency>
  <groupId>net.bull.javamelody</groupId>
  <artifactId>javamelody-spring-boot-starter</artifactId>
  <version>1.92.0</version>
</dependency>
    

2) application.properties Ayarları

Aşağıdaki örnek konfigürasyon, temel bir JavaMelody kurulumu için yeterlidir:

javamelody.enabled=true
javamelody.excluded-datasources=secretSource,topSecretSource
javamelody.spring-monitoring-enabled=true
javamelody.init-parameters.log=true

server.port=8081
    

• javamelody.enabled: JavaMelody’i aktif eder.
• javamelody.excluded-datasources: İzlenmesini istemediğiniz veri kaynakları.
• javamelody.spring-monitoring-enabled: Spring bean çağrılarını izler.
• server.port: Uygulamanın dinleyeceği port (örnekte 8081).

JavaMelody İzleme Paneline Erişim

Uygulama ayağa kalktıktan sonra, JavaMelody paneline aşağıdaki URL ile ulaşabilirsiniz:

http://localhost:8081/monitoring

Bu panel üzerinden:

• CPU ve bellek kullanımı,
• İstek sayısı ve tepki süreleri,
• SQL sorguları ve yavaş sorgu analizleri,
• Aktif oturumlar ve thread durumu

gibi metrikleri grafiklerle detaylı şekilde görebilirsiniz.

Üretim Ortamında /monitoring Endpointini Nasıl Korurum?

/monitoring endpointini doğrudan internete açık bırakmak güvenlik riski doğurur. Üretim ortamında şu önlemlerden en az birkaçı uygulanmalıdır:

• Temel Kimlik Doğrulama (Basic Auth) ile kullanıcı adı/şifre koruması eklemek,
• IP kısıtlama ile sadece belirli IP aralığından erişime izin vermek,
• Bir reverse proxy (Nginx, Apache) arkasında endpointi saklayıp, erişimi burada yönetmek,
• Spring Security kullanarak role bazlı yetkilendirme tanımlamak.

Sık Sorulan Sorular

Üretimde /monitoring endpointini açmak güvenli mi?

Evet, ama mutlaka kimlik doğrulama ve yetkilendirme ile korunmalıdır. En azından Basic Auth + IP kısıtlama kombinasyonu, daha ideal olarak Spring Security üzerinden sadece yetkili rollere açık bir yapı tercih edilmelidir.

Hangi metrikler probleme hızlı işaret eder?

Aşağıdaki metriklerdeki ani değişimler, genellikle ilk alarm sinyalleridir:

• Ani artan tepki süresi (özellikle p95/p99),
• Yükselen hata oranı (5xx/Exception artışı),
• DB connection pool tükenmesi ve artan bekleme süreleri,
• Uzayan GC duraksamaları ve aşırı bellek kullanımı.

Bu metrikleri JavaMelody ile sürekli izleyerek, performans problemlerini kullanıcı şikâyetine dönüşmeden yakalayabilirsiniz.