ERP Application Monitoring ve Observability: Performans Metriklerini Doğru Okumak
Bir metriği görmek, problemin nedenini bilmek değildir. ERP performansını doğru okumak; kullanıcı deneyimi, uygulama, veritabanı ve altyapı sinyallerini aynı olayın farklı yüzleri olarak ilişkilendirmeyi gerektirir.
'Login süresi arttı' bir bulgudur. Root cause değildir. İyi observability, metriği gösterirken neden araştırmasının yolunu da açar.
İçindekiler
5 Dakikada Konu
Monitoring; metrik, log, alarm ve durum sinyallerini toplar. Observability ise beklenmeyen bir davranış görüldüğünde 'neden oldu?' sorusunu yeni kod yazmadan, yeterli bağlamla araştırabilme kapasitesidir. İkisi birlikte gerekir: görünmeyen sistem yönetilemez; ama tek başına dashboard da kök nedeni vermez.
Ana tez
Önce kullanıcı etkisini görün, sonra sinyalleri katmanlar arasında ilişkilendirin. CPU yüksek diye CPU sorun demek, login yavaş diye kimlik doğrulama sorun demek kadar eksik olabilir.
Mental Model: Kullanıcıdan Altyapıya
ERP performansını inceleme katmanları
- 1
User Experience
Kullanıcının hissettiği süre ve hata.
- 2
Application
İstekler, oturumlar, bellek, kuyruk ve connection pool.
- 3
Database
Sorgular, lock'lar, wait'ler ve bağlantı baskısı.
- 4
Infrastructure
CPU, bellek, disk, ağ ve çalışma ortamı sağlığı.
Login süresi artışını araştırma dalları
- 1
Login Duration ↑
Kullanıcıda görülen bulgu.
- 2
Authentication
Kimlik sağlayıcı veya yetki çağrısı.
- 3
Network / Application
Gecikme, kapasite, cache veya eşzamanlı yük.
- 4
Database
Sorgu, lock, wait veya bağlantı baskısı.
Hangi Metrik Hangi Katmanı Anlatır?
| Katman | Örnek sinyaller | İlk yorum |
|---|---|---|
| User Experience | Login süresi, işlem/açılış süresi, response time, algılanan gecikme | İş etkisini görünür kılar. |
| Application | Eşzamanlı oturum, request hacmi, bellek, cache, thread/worker, kuyruk, connection pool | Uygulamanın talebi nasıl taşıdığını gösterir. |
| Database | Query duration, lock, wait, connection pressure, pahalı operasyon | Veri katmanında bekleme veya kaynak yarışını işaret eder. |
| Infrastructure | CPU, bellek, disk, ağ, container/VM sağlığı | Çalışma ortamının kapasite ve hata sınırlarını gösterir. |
Katman
User Experience
Örnek sinyaller
Login süresi, işlem/açılış süresi, response time, algılanan gecikme
İlk yorum
İş etkisini görünür kılar.
Katman
Application
Örnek sinyaller
Eşzamanlı oturum, request hacmi, bellek, cache, thread/worker, kuyruk, connection pool
İlk yorum
Uygulamanın talebi nasıl taşıdığını gösterir.
Katman
Database
Örnek sinyaller
Query duration, lock, wait, connection pressure, pahalı operasyon
İlk yorum
Veri katmanında bekleme veya kaynak yarışını işaret eder.
Katman
Infrastructure
Örnek sinyaller
CPU, bellek, disk, ağ, container/VM sağlığı
İlk yorum
Çalışma ortamının kapasite ve hata sınırlarını gösterir.
Aynı anda üç katmanda hareket görmek, otomatik olarak neden-sonuç ilişkisi kurmaz. Zaman hizası, etkilenen kullanıcı grubu, sürüm/değişiklik bilgisi ve isteğin iş bağlamı incelenmelidir.
Metric, Symptom, Signal ve Root Cause
| Kavram | Kısa anlamı |
|---|---|
| Metric | Ölçülen sayısal değer: örneğin p95 response time. |
| Symptom | Kullanıcı veya sistemde görülen etki: yavaş login gibi. |
| Signal | Araştırmaya değer değişim veya örüntü. |
| Correlation | İki olayın birlikte hareket ettiğine dair gözlem; tek başına nedensellik değildir. |
| Root cause | Sorunu başlatan veya sürdüren temel neden. |
| Baseline | Normal davranışın karşılaştırma çizgisi. |
| Threshold | Dikkat ya da aksiyon gerektiren sınır. |
| Trend / saturation / anomaly | Zaman içindeki yön, kapasite sınırına yaklaşma veya beklenmeyen sapma. |
Kavram
Metric
Kısa anlamı
Ölçülen sayısal değer: örneğin p95 response time.
Kavram
Symptom
Kısa anlamı
Kullanıcı veya sistemde görülen etki: yavaş login gibi.
Kavram
Signal
Kısa anlamı
Araştırmaya değer değişim veya örüntü.
Kavram
Correlation
Kısa anlamı
İki olayın birlikte hareket ettiğine dair gözlem; tek başına nedensellik değildir.
Kavram
Root cause
Kısa anlamı
Sorunu başlatan veya sürdüren temel neden.
Kavram
Baseline
Kısa anlamı
Normal davranışın karşılaştırma çizgisi.
Kavram
Threshold
Kısa anlamı
Dikkat ya da aksiyon gerektiren sınır.
Kavram
Trend / saturation / anomaly
Kısa anlamı
Zaman içindeki yön, kapasite sınırına yaklaşma veya beklenmeyen sapma.
İyi alarm, yalnızca bir sayı eşiği geçince çalmaz. İş etkisini, kalıcılığı ve normal davranıştan anlamlı sapmayı da hesaba katar.
Ortalama Neden Tek Başına Yanıltıcıdır?
Ortalama, çoğu kullanıcının deneyimlediği gecikmeyi saklayabilir. p50 medyanı, yani tipik ortadaki deneyimi; p95 en yavaş yüzde 5'in sınırını; p99 ise uç kuyruktaki kötü deneyimi özetler. Ortalama stabil görünürken p95'in bozulması, belirli yoğunluk veya veri türlerinde ciddi kullanıcı etkisi olduğuna işaret edebilir.
| Bakış | Ne sorar? |
|---|---|
| p50 | Tipik kullanıcı deneyimi nasıl? |
| p95 | Kötü deneyim yaşayan anlamlı grup ne görüyor? |
| p99 | Uç durumlar kapasite veya hata sınırını mı işaret ediyor? |
| Trend | Sorun tekil mi, düzenli mi, büyüyor mu? |
Bakış
p50
Ne sorar?
Tipik kullanıcı deneyimi nasıl?
Bakış
p95
Ne sorar?
Kötü deneyim yaşayan anlamlı grup ne görüyor?
Bakış
p99
Ne sorar?
Uç durumlar kapasite veya hata sınırını mı işaret ediyor?
Bakış
Trend
Ne sorar?
Sorun tekil mi, düzenli mi, büyüyor mu?
Yüzdelikler performans hedefinin yerine geçmez. Hangi kullanıcı yolculuğunun, hangi iş saatinde ve hangi yük altında kritik olduğuyla birlikte yorumlanmalıdır.
Araştırırken Neye Bakmalıyım?
- En kritik kullanıcı yolculukları ve bunların normal süreleri tanımlı mı?
- Metrikler kullanıcı, uygulama, veritabanı ve altyapı katmanları arasında ilişkilendirilebiliyor mu?
- Log, metric ve trace aynı iş isteğine bağlanabiliyor mu?
- Baseline ve eşikler iş saati, dönem sonu veya planlı batch yükü gibi bağlamları dikkate alıyor mu?
- Alarmın sahibi, ilk inceleme adımı ve eskalasyon sınırı açık mı?
- Kapasite doygunluğu; kuyruk, pool, worker veya disk gibi hangi dar boğazlarda görülüyor?
- Hassas veri loglarda maskeleniyor, fakat teşhis için yeterli bağlam korunuyor mu?
Nerede Yanlış Anlaşılır?
| Anti-pattern | Neden risklidir |
|---|---|
| Sadece altyapı metriği izlemek | Kullanıcı etkisi ve uygulama davranışı görünmez kalır. |
| Her eşiği kritik alarm yapmak | Alarm yorgunluğu gerçek sinyalleri saklar. |
| Ortalama süreye bakmak | Kuyruktaki kötü kullanıcı deneyimi kaybolabilir. |
| Correlation'ı root cause saymak | Eşzamanlı görünen olaylar farklı bir ortak nedene bağlı olabilir. |
| İzleme verisini kimse sahiplenmemek | Dashboard oluşur, öğrenme ve iyileştirme oluşmaz. |
Anti-pattern
Sadece altyapı metriği izlemek
Neden risklidir
Kullanıcı etkisi ve uygulama davranışı görünmez kalır.
Anti-pattern
Her eşiği kritik alarm yapmak
Neden risklidir
Alarm yorgunluğu gerçek sinyalleri saklar.
Anti-pattern
Ortalama süreye bakmak
Neden risklidir
Kuyruktaki kötü kullanıcı deneyimi kaybolabilir.
Anti-pattern
Correlation'ı root cause saymak
Neden risklidir
Eşzamanlı görünen olaylar farklı bir ortak nedene bağlı olabilir.
Anti-pattern
İzleme verisini kimse sahiplenmemek
Neden risklidir
Dashboard oluşur, öğrenme ve iyileştirme oluşmaz.
Monitoring çözümü seçmek, panel seçmekten daha geniş bir karardır. Ölçüm sözlüğü, kullanıcı yolculuğu, veri saklama süresi, erişim, maliyet ve olay müdahale düzeni birlikte düşünülmelidir.
One Page Cheat Sheet
| Hatırla | Kısa karşılık |
|---|---|
| Metrik | Tek başına karar değil, araştırma başlangıcıdır. |
| Semptom | Kullanıcı etkisini tarif eder; nedeni söylemez. |
| Baseline | Normalin ne olduğunu bilmeden anomaliyi yorumlayamazsınız. |
| p95/p99 | Ortalamanın sakladığı kötü deneyimi görünür kılar. |
| Correlation | Araştırma yönü verir; nedenselliği kanıtlamaz. |
| Observability | Beklenmeyen davranışı bağlamla açıklayabilme kapasitesidir. |
Hatırla
Metrik
Kısa karşılık
Tek başına karar değil, araştırma başlangıcıdır.
Hatırla
Semptom
Kısa karşılık
Kullanıcı etkisini tarif eder; nedeni söylemez.
Hatırla
Baseline
Kısa karşılık
Normalin ne olduğunu bilmeden anomaliyi yorumlayamazsınız.
Hatırla
p95/p99
Kısa karşılık
Ortalamanın sakladığı kötü deneyimi görünür kılar.
Hatırla
Correlation
Kısa karşılık
Araştırma yönü verir; nedenselliği kanıtlamaz.
Hatırla
Observability
Kısa karşılık
Beklenmeyen davranışı bağlamla açıklayabilme kapasitesidir.
Mini glossary: latency = isteğin tamamlanma süresi; saturation = kaynağın kapasite sınırına yaklaşması; trace = bir isteğin katmanlar arası yolculuğu; anomaly = beklenen örüntüden anlamlı sapma.
TROIA Araştıranlar İçin Not
TROIA'nın kamuya açık geliştirici dokümantasyonunda JMX monitoring başlığı, izleme kavramlarının ürün ekosisteminde de güncel bir karşılığı olduğunu gösterir. Bu rehber ürün içi metrik, yönetim ekranı veya uygulama adımı öğretmez; performans sinyallerini mimari olarak nasıl okuyacağınızı açıklar. TROIA'ya özgü güncel ayrıntılar için özgün dokümantasyona başvurulmalıdır.
Sık sorulan sorular
- Monitoring ile observability arasındaki fark nedir?
- Monitoring bilinen metrikleri ve eşikleri izler. Observability, daha önce tanımlanmamış bir davranışı yeterli bağlamla araştırabilme yeteneğidir.
- CPU yükseldiyse sorun CPU'da mı demektir?
- Hayır. CPU artışı bir sonuç, eşlik eden yük veya başka bir katmandaki beklemenin etkisi olabilir. Kullanıcı etkisi ve zaman hizasıyla araştırılmalıdır.
- p95 hedefi her işlem için aynı mı olmalı?
- Hayır. Login, rapor, batch işlem ve kritik karar ekranlarının kullanıcı beklentisi ve iş etkisi farklıdır.
İlgili sayfalar:
İlgili içerikler
İlgili kaynak
Kaynaklar ve checklistler
Bu konuyu somut bir checklist, karar notu veya indirilebilir materyalle derinleştirmek için kaynaklar yüzeyine geçin.
Devam et →Temas
Bu konu aktif bir ihtiyaçsa konuşalım
Okuduğunuz konu bugünkü proje, sponsor kararı veya hazırlık baskısıyla örtüşüyorsa doğrudan temas kurabilirsiniz.
Devam et →Çerçeve
ERP çerçevesine geri dönün
Tek bir başlıktan daha geniş ERP resmine, sponsor gündemine ve delivery hattına geçmek için ERP yüzeyi doğru noktadır.
Devam et →