APM Nedir? Uygulama Performans İzleme Rehberi

Yavaşlayan bir başvuru ekranı

Saat 10.40. Çağrı merkezi, kredi başvuru ekranının açılmasının sekiz saniye sürdüğünü bildiriyor. Altyapı panelleri temiz görünüyor: CPU yüzde 40'ta, bellek düz, yeniden başlayan pod yok. İstek düzeyinde veri yoksa sonraki bir saat, herkesin kendi bileşeninin sağlıklı olduğunu anlattığı bir toplantı köprüsünde geçer.

APM varsa nöbetçi mühendis başvuru uç noktasını açar ve p95 gecikmenin 10.24'te 350 ms'den 7,6 saniyeye çıktığını görür. O dakikalardan bir yavaş trace, sürenin dağılımını verir: web katmanında 25 ms, başvuru servisinde 70 ms, ardından skorlama servisine yapılan tek bir çağrıda 7,3 saniye. Bu çağrının içinde tek bir SQL cümlesi 7,2 saniye tutuyor. Skorlama servisinin son dağıtımı 10.22'de yapılmış. Konuşma "kimin suçu?" sorusundan "bu sorguda ne değişti?" sorusuna geçer.

Bu örnek kurgu, ama APM'nin işi tam olarak budur: kullanıcının gördüğü bir belirtiyi koddaki veya bir bağımlılıktaki belirli bir noktaya bağlamak.

Çalışan bir tanım

APM (application performance monitoring), uygulamaların üretimdeki davranışını isteklerin izini sürerek ölçme pratiğinin ve bu işi yapan araçların genel adıdır. Türkçede "uygulama performans izleme" veya "uygulama izleme" denir. APM ürünlerinin çoğu şunları toplar:

servis ve uç nokta başına istek sayısı, hata oranı ve gecikme
her isteğin servisler ve bağımlılıklar üzerindeki yolunu gösteren dağıtık trace'ler
aynı hatanın tek kayıt olarak görünmesi için gruplanmış hata ve istisnalar
hangi servisin hangisini çağırdığını gösteren harita
metot süreleri, çöp toplama veya iş parçacığı havuzu durumu gibi çalışma zamanı ayrıntıları
üreten trace'e bağlanmış loglar

Birçok ürün buna tarayıcı tarafında gerçek kullanıcı izleme, sentetik prob ve altyapı görünümleri de ekler, çünkü "bu neden yavaş?" sorusu çoğu zaman o alanlara da taşar.

Veri nasıl toplanır?

Enstrümantasyon

Kodunuz çalışırken bir şeyin onu gözlemlemesi gerekir. Üç yaygın yol var:

Otomatik enstrümantasyon. Bir ajan çalışma zamanına bağlanır ve HTTP sunucusu, veritabanı sürücüsü, mesajlaşma istemcisi gibi bilinen kütüphaneleri sarar. JVM'de -javaagent, .NET'te profil API'si bu işi görür; Python ve Node.js'te modüller yüklenirken sarılabilir. Kod değişmez.
Elle enstrümantasyon. Geliştiriciler iş operasyonlarının etrafına SDK ile span ekler. Daha zahmetlidir, ama indirim-uygula gibi adlar ve müşteri segmenti gibi öznitelikler ancak böyle gelir.
Metot düzeyi yakalama. Bazı araçlar çalışma zamanındaki tek tek metotların süresini ölçer. Otomatik enstrümantasyonun gördüğü giriş ve çıkış noktalarının arasında zamanın nereye gittiğini böyle görürsünüz. Örnek için kod değiştirmeden izleme yazısına bakın.

Gerçek kurulumların çoğu ilk ikisini karıştırır. OpenTelemetry bu konuda üreticiden bağımsız ortak standart hâline geldi, böylece enstrümantasyon sizi tek bir arka uca bağlamaz.

Bağlam taşıma

Bir trace'in birden çok servisi kapsaması için her servisin giden çağrılarında trace kimliğini aktarması gerekir. Yaygın standart, W3C Trace Context'in tanımladığı traceparent HTTP başlığıdır. Tek bir halka başlığı düşürürse trace ikiye bölünür. Konunun tamamı dağıtık izleme nedir yazısında.

Arka uç

Telemetri, onu saklayan ve yüzdelik gibi toplamları hesaplayan bir arka uca gider. Bu başkasının bulut servisi de olabilir, kendi donanımınızdaki bir sistem de. Bu seçimi kurum içi mi bulut mu yazısında ele alıyoruz.

Bir servise bakarken sıralama

Yeni başlayanlar grafikler arasında kaybolabilir. Bir servis için şu sırayı izleyin:

Trafik normal mi? Trafik düşerken gecikmenin iyileşmesi, kullanıcıların size ulaşamadığı anlamına gelebilir.
Hata oranı ne, tek hata mı çok hata mı? Gruplanmış hatalar sıçramanın tek bir yeni istisnadan gelip gelmediğini söyler.
p50, p95 ve p99 nasıl? p50 düzken p99 iki katına çıktıysa isteklerin bir bölümü yavaşlamıştır. Sebep sıklıkla kilit, soğuk önbellek veya belirli bir veri parçasıdır.
Süre hangi bağımlılıkta? Trace, zamanın kodunuzda mı, veritabanında mı, başka bir serviste mi geçtiğini gösterir.
Ne değişti? Sıçramayı dağıtımlar ve ayar değişiklikleriyle yan yana koyun. Olay incelemeleri çoğu zaman yakın tarihli bir değişikliğe çıkar, o yüzden bunu erken kontrol edin.

Ortalama neden yanıltır: kısa bir örnek

200 istek düşünün: 190'ı 120 ms, 10'u 3.000 ms sürüyor.

Ortalama: (190 × 120 + 10 × 3.000) / 200 = 264 ms
p50: 120 ms
p95: 120 ms (sıralandığında 190. istek hâlâ hızlı)
p99: 3.000 ms

264 ms kimsenin gerçek deneyimini anlatmaz. Çoğu kullanıcı için durum iyidir, yirmide biri ise çok kötü bir an yaşar. Üstelik bir sayfa 20 arka uç çağrısı yapıyorsa, her çağrının birbirinden bağımsız olduğu varsayımıyla en az bir yavaş çağrıya denk gelme olasılığı 1 - 0,95^20 ≈ yüzde 64'tür. Kuyruktaki gecikme, yüzdenin düşündürdüğünden çok daha fazla kişiye dokunur.

APM ve yakın kavramlar

Kavram	Odağı	APM ile ilişkisi
Gözlemlenebilirlik	Sistemin çıktılarından yeni sorular sorabilme becerisi	Daha geniş bir fikir; APM bunun uygulamalar için ana yollarından biri
Altyapı izleme	Sunucu, düğüm, konteyner, disk, ağ	Platformun sağlığını söyler, isteklerin sağlığını değil
Log yönetimi	Log olaylarını toplama ve arama	Trace'te olmayan ayrıntıyı verir; trace hangi logu okuyacağınızı söyler
Dağıtık izleme	Tek isteği servisler boyunca izleme	Modern APM'nin temel veri türü
Gerçek kullanıcı izleme	Tarayıcıda hissedilen performans	Arka ucun göremediğini gösterir
Sentetik izleme	Bilinen noktalardan betikli problar	Gerçek kullanıcı yokken de kesintiyi yakalar
AIOps	İstatistik ve makine öğrenmesini operasyon verisine uygulama	APM'nin topladığı veri üzerine kurulur

APM'nin bedeli

İzleme çalışma anında bedava değildir ve bunu varsaymak yerine ölçmelisiniz.

Çalışma zamanı ek yükü. Ajanlar süreç başına CPU ve bellek, istek başına biraz gecikme ekler. Miktar çalışma zamanına, span sayısına ve istenen ayrıntıya bağlıdır. Kendi servisinizde gerçekçi yük altında ölçün.
Açılış süresi. Bytecode işleyen ajanlar JVM açılışını belirgin biçimde uzatabilir. Bu da readiness problarını ve otomatik ölçeklemeyi etkileyebilir.
Veri hacmi. Trace'ler büyük yer tutar. Örnekleme bu yüzden vardır.
Hassas veri. URL'ler, SQL metinleri ve log mesajları kişisel veri taşıyabilir. Türkiye'deki kurumlar için bunun KVKK tarafı ayrı bir yazıda anlatılıyor. Barındırılan bir araç kullanıyorsanız bu veri ağınızdan da çıkar.
Dikkat. Kötü seçilmiş alarmlar nöbetçiyi yıpratır. İyi APM kullanımı daha çok değil, daha az ve daha iyi alarm demektir.

Araç seçerken sorulacak sorular

Her demo iyi görünür, siz kendi zor durumlarınızı götürün:

Gerçek çalışma zamanlarınızı kapsıyor mu? Eski uygulama sunucuları ve sıra dışı çatılarda boşluklar çıkar.
Veri nerede duruyor? Mevzuat veya ağ tasarımı dışarı çıkışı engelliyorsa birçok değerlendirme bu soruda biter.
Enstrümantasyon taşınabilir mi? OpenTelemetry desteği birinci sınıf mı, yoksa sadece bir alım ucu mu?
Ajan hangi yetkileri istiyor? OpenShift'te hangi SCC gerektiğini sorun.
Ajan arızalanırsa ne olur? İzleme, uygulamanızı kendisiyle birlikte düşürmemeli.
Trace, log ve değişiklikleri nasıl bağlıyor? Hazır senaryoyla değil, yaşadığınız gerçek bir olayla test edin.
Erişim nasıl denetleniyor? SSO, grup eşleştirme ve denetim kaydını sorun.

APM'ye ihtiyacınız olmayabilir

Birkaç kullanıcılı tek bir monolit çoğu zaman iyi loglar, birkaç metrik ve veritabanının yavaş sorgu kaydıyla idare eder. Toplu işler için istek izlemeden çok iş süresi takibi gerekir. APM, istekler birkaç servisi aştığında, sorumluluk ekipler arasında paylaşıldığında veya üretim sorunlarını bulmak düzeltmekten uzun sürmeye başladığında karşılığını verir. Henüz o noktada değilseniz en yoğun servisinize OpenTelemetry ekleyerek küçük başlayın.

Wrentrix APM'ye nasıl yaklaşıyor?

Wrentrix, OpenShift, Kubernetes veya Linux üzerinde çalışan, telemetrisini ağınızdan çıkarmayan bir kurum içi APM ve AIOps platformudur. OpenTelemetry tabanlıdır, OTLP trace ve log kabul eder; canlı servis haritası, uç nokta başına p50/p95/p99, gruplanmış hatalar ve trace'e bağlı loglar sunar. Örnek veriyle ekranları canlı demoda gezebilirsiniz.

Sık sorulan sorular

APM ne demek?

APM, application performance monitoring ifadesinin kısaltmasıdır, Türkçesi uygulama performans izlemedir. Bazen "application performance management" olarak da açılır. İkisi de uygulamaların üretimdeki davranışını istekleri izleyerek ölçmeyi anlatır.

APM ile gözlemlenebilirlik arasındaki fark nedir?

Gözlemlenebilirlik, bir sistemin iç durumunu çıktılarından ne kadar iyi anlayabildiğinizi, önceden planlamadığınız soruları da sorabilmenizi anlatır. APM ise uygulama isteklerine odaklanan pratik bir araç kategorisidir ve gözlemlenebilirliğe ulaşmanın yaygın yollarından biridir. Bugün birçok ürün iki kelimeyi örtüşen yetenekler için kullanıyor.

APM ile log izleme aynı şey mi?

Hayır. Loglar kodunuzun yazdığı tek tek olaylardır ve ne olduğunun ayrıntısını verir. APM ise isteği bütün olarak ölçer, süreyi ve servisler arası ilişkiyi gösterir. En iyisi birlikte kullanmaktır: trace nereye bakacağınızı, ona bağlı log orada ne olduğunu söyler.

APM uygulamamı yavaşlatır mı?

Genellikle biraz yavaşlatır, ne kadar olduğu çalışma zamanına, ajan ayarlarına ve yakalanan ayrıntıya bağlıdır. Çok sayıda span üretmek veya yoğun metot ölçümü daha pahalıdır. Güvenilir cevap, kendi servisinizde ajanlı ve ajansız yapılan yük testinden gelir.

APM açık kaynak araçlarla yapılabilir mi?

Evet. Enstrümantasyon için OpenTelemetry ile açık kaynak bir tracing arka ucu, metrik yığını ve panel aracı temel ihtiyaçları karşılayabilir. Ancak bunları entegre etmek, işletmek ve servisler değiştikçe sinyaller arasındaki bağları tutarlı tutmak sizin işiniz olur.