Bir üretim ERP’sini geliştirirken, geç sevkiyat raporunun hep eksik gelmesiyle uğraşıyorduk. Sebebini bulmak ciddi zaman almıştı. Benzer şekilde, servis bazlı izleme yaparken de kritik iş akışlarındaki aksaklıkları anında tespit etmekte zorlandığımız zamanlar oldu. İşte bu deneyimler, RED (Rate, Errors, Duration) metriklerini tasarlarken “Servis bazlı mı, yoksa iş akışı bazlı mı?” sorusunu sürekli gündeme getirdi. Bu iki yaklaşımın kendine göre avantajları ve dezavantajları var ve hangisinin daha uygun olduğunu belirlemek, sisteminizin karmaşıklığına ve önceliklerinize bağlı. Gelin bu konuyu derinlemesine inceleyelim.
Bu makalede, RED metriklerini hem servis bazlı hem de iş akışı bazlı olarak nasıl tasarlayabileceğimize bakacağız. Hangi yaklaşımın ne zaman daha uygun olduğunu, somut örneklerle ve gerçek senaryolarla açıklayacağım. Amacım, bu metrikleri daha etkili kullanmanıza yardımcı olmak ve olası tuzaklardan kaçınmanızı sağlamak.
Servis Bazlı RED Metrikleri: Temel Yapı Taşları
Servis bazlı RED metrikleri, genellikle tekil servislerin performansını ve sağlığını izlemek için kullanılır. Her bir servis kendi metrik setine sahip olur. Bu yaklaşım, dağıtık sistemlerin temel yapı taşlarını anlamak ve yönetmek için oldukça pratiktir. Bir servise odaklanmak, o servisin ne kadar talep aldığını (Rate), ne kadar hata ürettiğini (Errors) ve bu talepleri ne kadar sürede işlediğini (Duration) net bir şekilde görmemizi sağlar.
Örneğin, bir kullanıcı kimlik doğrulama servisi (authentication service) düşünelim. Bu servisin günlük olarak milyonlarca istek aldığını, belirli bir hata oranına sahip olduğunu ve ortalama yanıt süresinin milisaniyeler mertebesinde olması gerektiğini varsayalım. Servis bazlı RED metrikleri ile bu değerleri kolayca izleyebiliriz. prometheus gibi araçlar, bu servisten gelen metrikleri toplar ve görselleştirir.
# Örnek Prometheus sorgusu: Authentication servisi için hata oranı
sum(rate(http_requests_total{service="auth-service", status=~"5..|4..", environment="production"}[5m]))
/
sum(rate(http_requests_total{service="auth-service", environment="production"}[5m]))Bu sorgu, son 5 dakikadaki toplam 5xx ve 4xx hatalarının, toplam isteklere oranını verir. Bu, servisin sağlığı hakkında hızlı bir fikir verir. Ancak, bu metrikler tek başına yeterli olmayabilir. Bir servisin kendi içindeki performans sorunlarını veya birden fazla servisi içeren daha karmaşık iş akışlarındaki sorunları gözden kaçırabiliriz. Örneğin, servis kendi içinde hızlı yanıt verse bile, bağımlı olduğu başka bir servis yavaşsa, genel kullanıcı deneyimi olumsuz etkilenebilir.
Bu yaklaşımın temel avantajı, her servisin kendi performansını bağımsız olarak değerlendirebilmesidir. Bir serviste ani bir hata artışı veya yavaşlama olduğunda, sorunun kaynağını hızla belirleyebiliriz. Bu, özellikle monolitik mimarilerden mikroservislere geçiş yapan veya hizmetleri daha küçük, yönetilebilir parçalara ayıran ekipler için kritik öneme sahiptir. Ancak, bu yaklaşımın en büyük dezavantajı, servisler arasındaki etkileşimi ve bu etkileşimlerin genel kullanıcı deneyimi üzerindeki etkisini tam olarak yansıtamamasıdır.
İş Akışı Bazlı RED Metrikleri: Kullanıcı Deneyimini Merkeze Almak
İş akışı bazlı RED metrikleri, kullanıcıların bir görevi tamamlamak için gerçekleştirdiği adımları izler. Bu, “kullanıcı neyi başardı?” sorusuna odaklanır. Örneğin, bir e-ticaret sitesinde “ürün sepete ekleme” iş akışını ele alalım. Bu iş akışı, ön uç kullanıcı arayüzünden başlar, ürün bilgisi servisine bağlanır, stok kontrol servisiyle etkileşime girer, sepet servisine güncellemeyi gönderir ve nihayet kullanıcıya bir onay mesajı gösterir.
Bu akışın her adımı kendi içinde bir servisi temsil edebilir veya birden fazla servisi kapsayabilir. İş akışı bazlı metrikler, bu tüm adımların birlikte nasıl performans gösterdiğini ölçer. Böylece, bir kullanıcının işlemi tamamlamasının ne kadar sürdüğünü, bu süreçte ne kadar hata oluştuğunu ve hangi adımların bu süreyi veya hatayı artırdığını anlayabiliriz. Bu, kullanıcı deneyimini en doğru şekilde yansıtan yaklaşımdır.
Bir üretim ERP’sinde “sipariş oluşturma” iş akışını düşünelim. Bu akış, müşteri bilgilerinin alınması, ürün seçimi, stok kontrolü, fiyatlandırma, onay mekanizmaları ve nihayetinde siparişin kaydedilmesi gibi birçok adımı içerir. Bu adımların her biri farklı servisler tarafından yönetilebilir. İş akışı bazlı metrikler, tüm bu adımların toplam süresini, bu süreçte yaşanan genel hata oranını ve bir siparişin başarıyla tamamlanma oranını izlememizi sağlar.
Bu yaklaşımın en büyük zorluğu, doğru iş akışlarını tanımlamak ve bu akışları uçtan uca izlemek için gerekli altyapıyı kurmaktır. Her adımın doğru şekilde etiketlenmesi ve metriklerin tutarlı bir şekilde toplanması kritik öneme sahiptir. Örneğin, bir kullanıcının bir işlemi başlatmasından başarıyla tamamlamasına kadar geçen süreyi ölçmek için dağıtık izleme (distributed tracing) araçlarına ihtiyaç duyabiliriz. Bu araçlar, farklı servislerdeki istekleri birbirine bağlayarak tüm iş akışını bir bütün olarak görmemizi sağlar.
Trade-off’lar: Servis mi, İş Akışı mı?
Her iki yaklaşımın da kendine özgü avantajları ve dezavantajları vardır. Hangisini seçeceğimiz, büyük ölçüde sistemimizin mimarisine, iş gereksinimlerimize ve izleme altyapımızın yeteneklerine bağlıdır. Genellikle, en iyi çözüm bu iki yaklaşımı birleştirmektir.
Servis bazlı metrikler, temel altyapının sağlığını anlamak için mükemmeldir. Bir servisin kendi içinde aşırı yüklenip yüklenmediğini, veritabanı bağlantılarında sorun olup olmadığını veya bellek sızıntısı olup olmadığını anlamak için servis bazlı metrikler kritik öneme sahiptir. Örneğin, bir veritabanı servisi (PostgreSQL) için WAL (Write-Ahead Logging) bloat oranı gibi metrikler, doğrudan servis bazlıdır ve veritabanının sağlığı hakkında önemli bilgiler verir.
-- PostgreSQL WAL boyutu izleme için örnek sorgu (basitleştirilmiş)
-- pg_ls_waldir() pg_wal dizinindeki segment dosyalarını listeler
SELECT
pg_size_pretty(sum(size)) AS total_wal_size
FROM
pg_ls_waldir();Bu tür metrikler, belirli bir servisin performansını anlamak için hayati önem taşır. Ancak, bu veritabanı servisinin kullanıldığı bir iş akışındaki genel yavaşlığı tek başına açıklamaz. Belki de iş akışındaki başka bir servis aşırı istek gönderiyor ve veritabanını zorluyordur.
Öte yandan, iş akışı bazlı metrikler, son kullanıcı deneyimini anlamak için en iyi yoldur. Bir kullanıcının ödeme işlemini tamamlamasının uzun sürmesi, tek bir servisteki sorundan kaynaklanabileceği gibi, birden fazla servisin etkileşimindeki bir darboğazdan da kaynaklanabilir.
Bu nedenle, genellikle hibrit bir yaklaşım en etkili olanıdır. Temel servislerin sağlığını izlemek için servis bazlı metrikleri kullanırken, kritik iş akışlarının uçtan uca performansını ve kullanıcı deneyimini anlamak için iş akışı bazlı metrikleri de dahil etmek gerekir. Bu, hem altyapı sorunlarını hızlıca tespit etmemizi hem de kullanıcıların karşılaştığı genel sorunları çözmemizi sağlar.
Gerçek Senaryolar ve Uygulamalar
Deneyimlerime dayanarak, bu iki yaklaşımın farklı senaryolarda nasıl kullanılabileceğine dair birkaç örnek vermek istiyorum.
Bir üretim ERP’si projesinde çalışırken, sipariş onay süreçlerinin beklenenden uzun sürdüğünü fark ettik. Servis bazlı metrikler, onay servisi, stok servisi ve bildirim servisi gibi ilgili servislerin kendi içlerinde normal çalıştığını gösteriyordu. Ancak, bir siparişin onaylanması için geçen toplam süre (iş akışı süresi) oldukça yüksekti. Detaylı incelemeler sonucunda, onay servisi ile stok servisi arasındaki iletişimde, özellikle belirli ürün grupları için yapılan karmaşık stok sorgularının yavaş çalıştığını tespit ettik. Bu sorgular, servisin kendi başına “hatalı” değil, ancak iş akışının tamamını yavaşlatıyordu. Burada, iş akışı bazlı izleme (örneğin, dağıtık izleme ile her bir adımın süresini ölçerek) sorunun kök nedenini bulmamızı sağladı.
Benzer bir durum, bildirim gönderme gibi üçüncü parti bir sağlayıcıya dayanan özelliklerde sıkça görülür. Arka uç servisinin kendi metrikleri (istek sayısı, hata oranı, yanıt süresi) gayet iyi görünse bile, kullanıcılar bildirimlerin geciktiğini veya hiç gelmediğini raporlayabilir. Çünkü sorun çoğu zaman arka uç servisinde değil, bildirimi ileten üçüncü parti sağlayıcının (örneğin Firebase Cloud Messaging gibi) belirli bölgelerdeki ağ sorunlarından kaynaklanır. Bu durumda, iş akışı bazlı metrikler — bildirimin gönderilme isteğinden cihaz tarafından alınmasına kadar geçen süre — sorunu çok daha net ortaya koyar.
Bu tür senaryolar, sadece tek bir yaklaşıma bağlı kalmanın yetersizliğini açıkça gösteriyor. Aynı ilke, bir hesaplama modülü ile veritabanı arasındaki iletişimi optimize etmeye çalışırken de geçerlidir: servis bazlı metrikler hesaplama modülünün CPU kullanımını ve bellek tüketimini gösterse de, veritabanı sorgularının ne kadar sürdüğünü veya ne kadar kaynak tükettiğini ayrı ayrı izlemek, performans darboğazını bulmak için tek başına yeterli değildir. Bu noktada, veritabanı (PostgreSQL) özelindeki performans izleme araçlarını ve iş akışı bazlı olarak bir hesaplama isteğinin başlangıcından veritabanı sorgularının tamamlanıp sonucun döndürülmesine kadar geçen süreyi izlemek, kök nedeni bulmada kritik rol oynar.
Teknik Derinlik: Metrikleri Nasıl Toplarız ve Analiz Ederiz?
İster servis bazlı ister iş akışı bazlı olsun, RED metriklerini etkili bir şekilde toplamak ve analiz etmek için doğru araçlara ve tekniklere ihtiyacımız var.
Servis Bazlı Metrikler İçin Araçlar
Servis bazlı metrikler için en popüler araçlardan biri Prometheus’tur. Prometheus, zaman serisi veritabanı (time-series database) olarak çalışır ve HTTP üzerinden metrikleri scraping (kazıma) yöntemiyle toplar. Uygulamalarımız, belirli metrikleri bir HTTP endpoint’i üzerinden Prometheus’a sunacak şekilde yapılandırılır. Örnek olarak, bir web sunucusunun (Nginx) istek sayısı, yanıt süreleri ve hata kodları gibi metrikleri Prometheus’a göndermesi sağlanabilir.
# Nginx'te Prometheus metriklerini etkinleştirmek için örnek yapılandırma (ngx_http_prometheus_module ile)
location /metrics {
prometheus;
prometheus_bucket_interval 0.001; # Milisaniye hassasiyeti için
}Grafana gibi görselleştirme araçları, Prometheus’tan gelen verileri çekerek anlaşılır dashboard’lar oluşturmak için kullanılır. Bu dashboard’lar, servis bazlı RED metriklerini (Rate, Errors, Duration) gerçek zamanlı olarak izlememizi sağlar. Örneğin, bir servisin saniyedeki istek sayısını (Rate), 5xx hata oranını (Errors) ve ortalama istek süresini (Duration) gösteren paneller oluşturabiliriz.
İş Akışı Bazlı Metrikler İçin Araçlar
İş akışı bazlı metrikler, genellikle dağıtık izleme (distributed tracing) araçları kullanılarak toplanır. Jaeger, Zipkin veya OpenTelemetry gibi projeler, farklı servislerdeki istekleri ve bu isteklerin birbirine nasıl bağlandığını izleyerek uçtan uca bir görünüm sunar. Bir isteğin bir servisten diğerine geçerken ne kadar zaman harcadığını, hangi servislerin süreyi uzattığını veya hangi adımlarda hata oluştuğunu bu araçlarla görebiliriz.
Örneğin, bir kullanıcının web sitesinde gezinmesi sırasında gerçekleşen bir dizi olayı düşünelim: Ana sayfayı yükleme, bir ürüne tıklama, sepete ekleme ve ödeme yapma. OpenTelemetry ile bu adımların her biri için “span”ler oluşturulur. Bu span’ler, isteğin başlangıç ve bitiş zamanını, işlem kimliğini ve işlemle ilgili meta verileri içerir. Bu veriler toplandıktan sonra, belirli bir iş akışının toplam süresini, ortalama süresini ve hata oranını hesaplayabiliriz.
Bu araçları kullanarak, servis bazlı metrikler için http_requests_total gibi sayaçlar ve http_request_duration_seconds gibi histogramlar toplarken, iş akışı bazlı metrikler için de dağıtık izleme verilerinden elde edilen toplam işlem süreleri ve hata oranları gibi metrikleri hesaplayabiliriz. Örneğin, bir sipariş oluşturma iş akışının ortalama süresini hesaplamak için, bu iş akışını temsil eden tüm span’lerin sürelerini toplayıp ortalamasını alabiliriz. Bu, sadece servislerin değil, tüm iş akışının sağlığını ölçmemizi sağlar.
Hangi Durumda Hangisi? Karar Verme Süreci
Doğru yaklaşımı seçmek, sistemimizin karmaşıklığına ve iş hedeflerimize bağlıdır. Basit bir monolitik uygulamada, sadece servis bazlı metrikler yeterli olabilir. Ancak, mikroservis tabanlı, karmaşık ve yüksek trafikli bir sistemde, iş akışı bazlı metrikler kesinlikle gereklidir.
Servis Bazlı Metriklerin Tercih Edildiği Durumlar:
- Basit Monolitik Uygulamalar: Tek bir kod tabanı üzerinde çalışan uygulamalarda, servis bazlı metrikler genellikle yeterli görünürlük sağlar.
- Temel Altyapı İzleme: Veritabanları, mesaj kuyrukları veya önbellek servisleri gibi temel bileşenlerin sağlığını izlerken.
- Geliştirme Aşamasındaki Yeni Servisler: Servis henüz tam olarak iş akışlarına entegre edilmemişken, kendi performansını anlamak için.
- Maliyet Kısıtlamaları: Kapsamlı dağıtık izleme altyapısı kurmak için yeterli kaynak olmayan durumlar.
İş Akışı Bazlı Metriklerin Tercih Edildiği Durumlar:
- Mikroservis Mimarileri: Birden fazla servisin etkileşimde bulunduğu karmaşık sistemlerde.
- Kritik Kullanıcı İş Akışları: Kullanıcıların bir görevi tamamlamak için gerçekleştirdiği adımların (örneğin, ödeme, sipariş verme, kayıt olma) performansı kritik olduğunda.
- Uçtan Uca Performans Sorunları: Servislerin kendi başlarına iyi çalışmasına rağmen genel sistemin yavaş olduğu durumları teşhis etmek için.
- Kullanıcı Deneyimi Odaklılık: Son kullanıcının yaşadığı deneyimi en iyi şekilde anlamak ve iyileştirmek istendiğinde.
Genellikle, en dengeli yaklaşım, her iki yöntemi de birleştirmektir. Kritik servisler için servis bazlı metrikleri toplarken, en önemli kullanıcı iş akışları için de dağıtık izleme verilerini kullanarak RED metriklerini hesaplamak, en kapsamlı ve etkili izleme stratejisini oluşturur. Bu, hem altyapının sağlığını hem de kullanıcı deneyimini garanti altına almanızı sağlar. Örneğin, bir serviste ani bir hata artışı olduğunda, servis bazlı metrikler sorunun kaynağını hızla bulmanıza yardımcı olurken, bu hatanın hangi iş akışlarını etkilediğini anlamak için iş akışı bazlı metrikleri kullanırsınız.
Sonuç: Pragmatik Bir Bakış Açısı
RED metriklerini tasarlarken servis bazlı mı yoksa iş akışı bazlı mı olacağı sorusu, “en iyi” tek bir cevabı olmayan bir sorudur. Her iki yaklaşımın da kendine göre güçlü ve zayıf yönleri vardır. Pragmatik bir mühendis olarak benim gördüğüm, bu iki yaklaşımı birbirinin alternatifi olarak değil, birbirini tamamlayıcı olarak görmektir.
Unutmamak gerekir ki, izleme sadece veri toplamak değildir; bu verileri anlamlı bilgilere dönüştürmek ve bu bilgilerle sistemimizi iyileştirmektir. Hangi yaklaşımı seçerseniz seçin, metriklerinizin anlaşılır, eyleme geçirilebilir ve sisteminizin sağlığını gerçekten yansıtır olduğundan emin olun. Daha önceki Observability Temelleri yazımda da bahsettiğim gibi, doğru metrikler, sisteminizin nabzını tutmanızı sağlar.
Sonuç olarak, servis bazlı metrikler yapı taşlarını anlamamıza yardımcı olurken, iş akışı bazlı metrikler bu yapı taşlarının bir araya geldiğinde nasıl çalıştığını, yani gerçek kullanıcı deneyimini gösterir. Bu ikisini dengeli bir şekilde kullanmak, hem sağlam bir altyapı hem de mutlu kullanıcılar elde etmenin anahtarıdır.