Ana içeriğe atla
Tracing (İzleme), API Proxy’lerinizin mesaj işleme akışını gerçek zamanlı olarak izlemenizi ve analiz etmenizi sağlar. Trace işlemi API Proxy bazında yapılır ve her API Proxy için ayrı ayrı aktifleştirilir. Bu modül özellikle:
  • Politikaların nasıl çalıştığını anlamak
  • Performans sorunlarını tespit etmek
  • Hata ayıklama (debugging) yapmak
  • İstek/yanıt akışını incelemek
  • Dönüşümleri (transformations) doğrulamak
için kullanılır.

API Proxy Bazında Trace

Her API Proxy için ayrı ayrı trace oturumu başlatabilirsiniz

Detaylı İzleme

Her politikanın çalışmasını adım adım izleyebilir ve log kayıtlarını görüntüleyebilirsiniz

Performans Analizi

Zamanlama metriklerini analiz edebilir ve darboğazları tespit edebilirsiniz

Hata Ayıklama

Hataları kolayca tespit edebilir ve kök neden analizini yapabilirsiniz
Trace işlemi API Proxy bazında yapılır. Detaylı uygulama adımları için Adım Adım İzleme sayfasına bakabilirsiniz.

Trace Modunu Başlatma

Trace modu, her API Proxy için ayrı ayrı başlatılır. API Proxy’nin kendi sayfasından trace modunu aktifleştirebilirsiniz.

Ön Koşullar

Trace modunu başlatmadan önce:
1

API Proxy Yüklenmiş Olmalı

İzlemek istediğiniz API Proxy’nin en az bir Ortam’a yüklenmiş olması gerekir
2

API Proxy Sayfasına Gidin

Trace yapmak istediğiniz API Proxy’nin detay sayfasına gidin
3

Ortam Seçimi Yapın

API Proxy’nin yüklenmiş olduğu Ortam’lardan hangisi için izleme modu açılacaksa o Ortam seçilir
4

Başlat Butonuna Tıklayın

Başlat (Start) tuşuna tıklayarak trace modunu aktifleştirin
Trace Modunu Aktifleştirme
Ortam seçiminin yanındaki filtre alanından Custom Query ile sadece istenen veriler üzerinden özel olarak trace edilebilir.
Trace modu aktifleştirildiğinde:
  • Log kayıtlarının içeriği detaylı incelemeye izin verecek şekilde genişletilir
  • Log kayıtları MongoDB konfigürasyon veri tabanına yazılır
  • İşletilen tüm politikalar için ayrıntılı log kayıtları oluşturulur
  • Mod durdurulana ya da 5 dakika sonunda platform tarafından otomatik olarak kapatılana kadar bu şekilde saklanmaya devam eder

Trace Kayıtları

Trace modu aktifleştirildikten sonra, API Proxy’ye gelen istekler otomatik olarak izlenir ve detaylı kayıtlar oluşturulur. Trace Log Kayıtları
Görüntülenmekte olan log kayıtları otomatik olarak güncellenmez. Yeni kayıtları görmek için Logları Yenile (Refresh Logs) tuşunu kullanın.
Tabloda görünen log kayıtlarının her birisi, istemciden bu API Proxy’e gelen istek ve o isteğe verilen yanıt mesajına aittir.
API Çağrı Politikasının log kaydı ayrı olarak tutulduğu için aynı isteğe ait çift log gözükür. Bunların ilk akıştaki mesajın önceki ve sonraki halidir, ikinci ise API Çağrısından çıkan istek ve yanıt mesajıdır.

Trace Listesi

Trace listesinde her bir kayıt için aşağıdaki bilgiler görüntülenir:
BilgiAçıklama
Timestampİsteğin geldiği tarih ve saat
MethodHTTP metodu (GET, POST, PUT, DELETE, vb.)
Path / Endpointİstek path’i ve endpoint adı
Status CodeYanıt durum kodu (200, 404, 500, vb.)
DurationToplam işlem süresi (ms)
PoliciesÇalıştırılan politika sayısı
Correlation IDİsteğe özgü korelasyon kimliği
API Çağrı Politikası kullanıldığında, aynı isteğe ait çift log kaydı görünür:
  1. Ana akıştaki mesajın önceki ve sonraki hali
  2. API Çağrısından çıkan istek ve yanıt mesajı

Trace İşlemleri

Her trace kaydı için aşağıdaki işlemler yapılabilir:
İncelenmek istenen istek mesajına ait satırın sonundaki tuşlardan ilki, o mesajın log kayıtlarını görüntüleyen bir pencere açar.Detaylı Görüntüleme ButonuAçılan pencerede loglar, mesaj akışına ilişkin bölümlere ayrılmıştır. İncelenmek istenen bölümün adına tıklandığında bu alana ilişkin log kayıtları görüntülenir. Varsayılan olarak Genel Bakış bölümü açıktır.Detaylı Görüntüleme Dialog

Politika Akışını İzleme

Apinizer’ın adım adım izleme modundayken API Proxy için işletilen politikalara ilişkin tuttuğu ayrıntılı log kayıtlarını görüntülemek için Seç tuşuna tıklanır. Seçme Bu tuşa tıklandığında log kayıtlarını içeren tablonun altında yeni bir bölüm açılır. Bu bölüm, seçilen mesaj için işletilen, varsa API Proxy Grup’tan da gelen bütün politikaları işletildikleri sırada gösterir. Her bir politikanın ve Backend API’nin yanında o adımın başarılı işletilip işletilemediğini gösterecek şekilde küçük ikonlar bulunur. Böylece eğer mesaj akışı beklendiği gibi gerçekleşmemişse sorunun hangi politikadan kaynaklandığı görünür.
Bütün politikaların başarıyla işletildiği durum:Başarılı Politika Akışı

Politika Execution Detayları

İstek geldiğinde ilk olarak işletilen politikalar:
  • Politika Adı: Çalıştırılan politikanın adı
  • Execution Time: Politikanın çalışma süresi (ms)
  • Status: Başarılı / Başarısız durumu
  • Changes: Politikanın mesajda yaptığı değişiklikler (header, body, variable değişiklikleri)
Örnekler: Kimlik doğrulama, rate limiting, IP kontrolü
Backend API’ye yönlendirme adımı:
  • Selected Upstream: Seçilen upstream target
  • Load Balancing Decision: Load balancing algoritması kararı
  • Connection Time: Backend’e bağlanma süresi (ms)
  • Backend Response Time: Backend’in yanıt süresi (ms)
  • Retry/Failover: Retry veya failover durumu
Backend’den yanıt geldikten sonra işletilen politikalar:
  • Politika Adı: Çalıştırılan politikanın adı
  • Execution Time: Politikanın çalışma süresi (ms)
  • Status: Başarılı / Başarısız durumu
  • Changes: Yanıt mesajında yapılan değişiklikler
Örnekler: Response transformation, cache writing, logging
Hata durumunda çalıştırılan politikalar:
  • Error Type: Hata türü (authentication, routing, policy, vb.)
  • Error Message: Hata mesajı
  • Handler Policies: Çalıştırılan hata yakalayıcı politikalar
  • Final Response: İstemciye döndürülen son yanıt
Fault Handler sadece hata oluştuğunda çalışır ve hata yanıtını özelleştirmenizi sağlar.

Detaylı Log Kayıtları

Bir log kaydının seçilmesi ile görüntülenen bölüm, mesaj akışının başarılı olup olmadığını ve başarısız olmuşsa bunun hangi noktada gerçekleştiğinin özetini sunar. Detaylı Log Kayıtları Detaylı log kayıtlarını görüntülemek için aşağıdaki bağlantılar kullanılabilir:
Detaylı log kayıtları, mesaj akışının her adımını izlemenize ve sorunların kaynağını hızlıca tespit etmenize olanak sağlar.
İstemci yazısı bir bağlantıdır. Buna tıklandığı zaman istemciden giden ve istemciye dönen mesajların detaylarının görüntülenebileceği bir pencere açılır.İstemcinin gönderdiği HTTP mesajının detayları:İstemci Log 1İstemciden API Proxy’e gönderilen mesajın detayları:İstemci Log 2API Proxy’den istemciye döndürülen mesajın detayları:İstemci Log 3
2 numaralı bölgedeki bir politika ikonunun üzerine ya da 4 numaralı bölgede ilgili politikanın yanındaki ok işaretine tıklandığında, o politikaya gelen ve o politikadan giden mesaj içeriğini gösteren log kayıtları açılır.Politika Log Kayıtları
API yazısı bir bağlantıdır. Buna tıklandığı zaman Backend API’ye gelen ve Backend API’den dönen mesajların detaylarının görüntülenebileceği bir pencere açılır.API Proxy’den gelen mesajın detayları:Backend API Log 1Backend API’ye yapılan yönlendirme detayları (yönlendirme seçenekleri için HTTP Yönlendirme sayfasına bakabilirsiniz):Backend API Log 2Backend API’den API Proxy’e döndürülen mesajın detayları:Backend API Log 3

İstek/Yanıt Karşılaştırma

Trace modu, mesajın akış boyunca nasıl değiştiğini gösterir:

Öncesi/Sonrası

Her politika için mesajın önceki ve sonraki halini karşılaştırabilirsiniz

Transformation Analizi

Dönüşüm (transformation) politikalarının etkisini görebilirsiniz

Header Değişiklikleri

Eklenen, değiştirilen veya silinen header’ları görebilirsiniz

Body Değişiklikleri

JSON/XML dönüşümlerini ve içerik değişikliklerini görebilirsiniz

Performans Analizi

Trace modu, performans sorunlarını tespit etmek için detaylı zamanlama metrikleri sağlar.

Zamanlama Metrikleri (Timing Metrics)

Her trace kaydı için aşağıdaki metrikler görüntülenir:
MetrikAçıklama
Total Durationİsteğin giriş-çıkış süresi toplamı (ms)
Pre-flow DurationPre-flow politikalarının toplam çalışma süresi
Route DurationBackend’e bağlanma ve yanıt alma süresi
Backend DurationBackend API’nin yanıt süresi (net)
Post-flow DurationPost-flow politikalarının toplam çalışma süresi
Gateway OverheadApinizer Gateway’in eklediği süre (Total - Backend)
Gateway Overhead yüksekse, politika optimizasyonu yapılabilir. Backend Duration yüksekse, backend API optimize edilmelidir.

Politika Performans Analizi

Politikaların performansını analiz etmek için:

En Yavaş Politikalar

En uzun süre alan politikaları belirleyebilir ve optimize edebilirsiniz

Politika Sayısı

Çalıştırılan toplam politika sayısını görebilir, gereksiz politikaları kaldırabilirsiniz

Ortalama Politika Süresi

Her politikanın ortalama çalışma süresini izleyebilirsiniz

Politika Çalışma Sırası

Politikaların sırasını değiştirerek performansı artırabilirsiniz
Optimizasyon Önerileri:
  • Cache Politikası: Backend çağrılarını azaltmak için cache kullanın
  • Conditional Flow: Gereksiz politikaları koşullu olarak atlayın
  • Script Optimizasyonu: Script politikalarında yavaş işlemleri optimize edin
  • Transformation: Gereksiz transformation’ları kaldırın

Backend Performans Metrikleri

Backend API’nin performansını izlemek için:
MetrikAçıklama
Connection TimeBackend sunucusuna TCP bağlantı süresi
SSL Handshake TimeHTTPS bağlantısı için SSL handshake süresi
Response TimeBackend’in yanıt oluşturma süresi
Total Backend TimeConnection + Response toplam süresi
Backend StatusBackend çağrısının başarı durumu
Retry/Failover CountRetry veya failover yapılma sayısı
Yüksek Connection Time backend sunucusunun yavaş veya ağ sorunlu olduğunu gösterir. Yüksek Response Time ise backend API’nin optimize edilmesi gerektiğini gösterir.

Kullanım Senaryoları

Senaryo 1: Performans Sorunu Tespiti

Durum: Bir API Proxy’nin yanıt süreleri beklenenden yüksek.
1

Trace Başlatın

API Proxy sayfasından trace modunu aktifleştirin
2

Yavaş İstekleri İnceleyin

Trace kayıtlarında yavaş istekleri (örn. >1000ms) bulun
3

Politika Akışını İnceleyin

Seç tuşu ile politika akışını görüntüleyin ve en yavaş politikaları tespit edin
4

Darboğazları Tespit Edin

  • Backend API yavaş mı? → Backend optimize edilmeli
  • Politikalar yavaş mı? → Script/transformation optimize edilmeli
  • Database sorgusu yavaş mı? → Cache kullanılabilir
5

Optimizasyon Yapın

Tespit edilen sorunları çözün ve trace ile tekrar test edin

Senaryo 2: Hata Ayıklama

Durum: Bazı istekler 500 hatası veriyor ve nedeni bilinmiyor.
1

Trace Başlatın

API Proxy sayfasından trace modunu aktifleştirin
2

Hatalı İstekleri Bulun

Trace kayıtlarında 5xx hatalarını bulun
3

Hata Oluşan Politikayı Bulun

Seç tuşu ile politika akışını görüntüleyin ve kırmızı işaretli politikayı bulun
4

Politika Detaylarını İnceleyin

  • Politikaya gelen mesajı inceleyin (Öncesi)
  • Hata mesajını okuyun
  • Detaylı log kayıtlarını inceleyin
5

Kök Neden Analizini Yapın

  • Veri formatı yanlış mı?
  • Header eksik mi?
  • Script hatası mı?
  • Backend ulaşılamıyor mu?
6

Düzeltme Yapın ve Test Edin

Sorunu düzeltin ve trace ile tekrar test edin

Senaryo 3: Transformation Doğrulama

Durum: JSON to XML transformation’ının doğru çalışıp çalışmadığını kontrol etmek.
1

Trace Başlatın

API Proxy sayfasından trace modunu aktifleştirin
2

Test İsteği Gönderin

Test Console’dan örnek bir JSON request gönderin
3

Transformation Politikasını Seçin

Seç tuşu ile politika akışını görüntüleyin ve transformation politikasına tıklayın
4

Öncesi/Sonrası Karşılaştırın

  • Before: Gelen JSON mesajı
  • After: Dönüştürülmüş XML mesajı
  • Dönüşümün doğru olup olmadığını kontrol edin
5

Backend'e Giden Mesajı Kontrol Edin

Backend API log kayıtlarında giden mesajın XML formatında ve doğru olduğunu doğrulayın

Senaryo 4: Conditional Flow Testi

Durum: Koşullu politikaların doğru çalışıp çalışmadığını test etmek.
1

Trace Başlatın

API Proxy sayfasından trace modunu aktifleştirin
2

Farklı Koşullar İçin İstekler Gönderin

  • Premium user için istek
  • Normal user için istek
  • Misafir için istek
3

Her İstek İçin Trace İnceleyin

Seç tuşu ile politika akışını görüntüleyin ve hangi politikaların çalıştığını görün
4

Koşul Değerlendirmesini Kontrol Edin

  • Condition expression neydi?
  • Değerlendirme sonucu ne oldu?
  • Doğru politikalar mı çalıştı?
5

Gerekirse Koşulları Düzeltin

Yanlış koşulları düzeltin ve tekrar trace ile test edin

En İyi Uygulamalar

Trace Kullanımı

Development Ortamında Sık Kullanın

  • Geliştirme sırasında sürekli trace edin
  • Yeni politikalar eklerken mutlaka trace ile test edin
  • API değişikliklerini trace ile doğrulayın

Production'da Dikkatli Olun

  • Production’da sadece gerektiğinde trace aktifleştirin
  • Trace otomatik olarak 5 dakika sonra kapanır
  • Performans etkisini göz önünde bulundurun

Custom Query Kullanın

  • Ortam seçiminin yanındaki filtre alanından Custom Query ile filtreleme yapın
  • Sadece ilgili endpoint’leri trace edin
  • Gereksiz trace kayıtlarını minimize edin

API Proxy Bazında Kullanın

  • Her API Proxy için ayrı ayrı trace başlatın
  • İlgili API Proxy’nin sayfasından trace modunu aktifleştirin
  • Trace kayıtları MongoDB’de saklanır

Performans İzleme

Performans Baseline Oluşturun:
  • Normal koşullarda API’nin ortalama yanıt süresini ölçün
  • Her politikanın ortalama çalışma süresini kaydedin
  • Baseline’dan sapmaları izleyin ve alarm kurun
Düzenli İzleme:
  • Haftada bir performans trace çalıştırın
  • Trend analizleri yapın
  • Yavaşlamaları erken tespit edin
Optimizasyon Döngüsü:
  1. Trace ile darboğazları tespit edin
  2. Optimizasyon yapın
  3. Trace ile iyileşmeyi doğrulayın
  4. Sonuçları dokümante edin

Hata Ayıklama

Tekrarlanabilir Test Senaryoları:
  • Trace başlatmadan önce test senaryolarını hazırlayın
  • Aynı test verisini kullanarak tutarlı sonuçlar alın
  • Edge case’leri test edin
Sistematik Yaklaşım:
  1. Sorunu izole edin (hangi endpoint, hangi koşulda?)
  2. Trace ile detaylı bilgi toplayın
  3. Kök neden analizini yapın
  4. Düzeltme yapın
  5. Trace ile doğrulayın
  6. Süreci dokümante edin
Öncesi/Sonrası Karşılaştırması:
  • Her politika için giriş/çıkış mesajlarını karşılaştırın
  • Beklenmeyen değişiklikleri tespit edin
  • Transformation doğruluğunu kontrol edin

İlgili Kaynaklar