API izleme, üretim ortamındaki API uç noktalarını sürekli olarak test ederek bu uç noktaların erişilebilir, hızlı yanıt veren, işlevsel olarak doğru ve kabul edilebilir eşikler içinde çalıştığını doğrulama pratiğidir. Ekibinizin dağıttığı kod ile kullanıcılarınızın gerçekte yaşadığı deneyim arasında konumlanan güvenilirlik katmanıdır. Bir API yavaşladığında veya çöktüğünde sonuçlar hızla yayılır; çünkü API'ler ön yüzleri arka uçlara, mikro servisleri birbirine ve ürünleri üçüncü taraf sistemlere bağlar. İzleme, bu arızaları müşteriyi etkileyen olaylara dönüşmeden önce görünür kılar.
Ancak tek başına izleme yeterli değildir. Neyi ölçtüğünüz, izlemenizin güvenilirlik sorunlarını gerçekten öngörüp önleyip önlemediğini ya da yalnızca gürültü üretip üretmediğini belirler. Seçtiğiniz metrikler; ekibinizin bozulmayı nasıl tespit ettiğini, müdahaleyi nasıl önceliklendirdiğini ve her servis için “sağlıklı” kavramını nasıl tanımladığını şekillendirir. Yanlış metrikleri takip etmek sahte bir güven duygusu yaratır. Doğru metrikleri takip etmek ise ekibinize sorunları erken yakalama, bağlamla müdahale etme ve en önemli servisleri koruma imkânı verir.
Bu rehber, API izlemenin ne olduğunu, pratikte nasıl çalıştığını ve güvenilirliği önemseyen ekipler için hangi metriklerin en çok önem taşıdığını açıklamaktadır.
API İzleme Gerçekte Ne Yapar?
API izleme, uç noktalarınıza düzenli aralıklarla sentetik istekler göndererek ve sonuçları değerlendirerek çalışır. Her kontrol genellikle uç noktanın yanıt verip vermediğini, yanıtın ne kadar sürdüğünü, hangi durum kodunun döndüğünü ve yanıt gövdesinin beklenen kriterlerle eşleşip eşleşmediğini ölçer. Daha gelişmiş izleme ayrıca yanıt şemalarını doğrular, çok adımlı iş akışlarını test eder, kimlik doğrulama yollarını kontrol eder ve birden fazla coğrafi konumdan çalışır.
Amaç üç sorun kategorisini tespit etmektir:
- Erişilebilirlik arızaları: Uç nokta erişilemez durumdadır, zaman aşımına uğruyordur veya sunucu hataları döndürüyordur.
- Performans bozulması: Uç nokta yanıt verir, ancak kabul edilebilir bir kullanıcı deneyimi için fazla yavaştır.
- Doğruluk arızaları: Uç nokta başarılı bir kodla hızlıca yanıt verir, ancak veriler yanlış, eksik veya yapısal olarak bozuktur.
Bu kategorilerin her birinin farklı güvenilirlik etkileri vardır ve her birini etkili biçimde tespit etmek farklı metrikler gerektirir. Yalnızca erişilebilirliği kontrol eden bir izleme sistemi, genellikle en kafa karıştırıcı ve en zararlı olaylara yol açan performans ve doğruluk arızalarını kaçıracaktır.
Güvenilirlik İçin Metrik Seçimi Neden Önemlidir?
Güvenilirlik tek bir sayı değildir. Zaman içinde erişilebilirlik, hız, doğruluk ve tutarlılığın kesişimidir. Bir API erişilebilir ama yavaş olabilir. Hızlı olup yanlış veri döndürüyor olabilir. Çoğu zaman doğru çalışıp yük altında öngörülemez davranabilir. Bu arıza modlarının her biri kullanıcıları farklı şekilde etkiler ve her birinin tespiti farklı bir metrik gerektirir.
Çalışma süresi yüzdesi veya ortalama yanıt süresi gibi tek bir metriğe güvenen ekipler, sorunları çoğu zaman çok geç fark eder. API panoda sağlıklı görünür, ancak müşteriler zaten arızalar yaşıyordur. Metrik görünürlüğü ile gerçek kullanıcı deneyimi arasındaki bu boşluk, güvenilirlik riskinin bulunduğu yerdir. Doğru metrik kombinasyonunu seçmek bu boşluğu kapatır.
Metrik 1: Erişilebilirlik Oranı
Erişilebilirlik, API güvenilirliğinin en temel metriğidir. Uç noktanın erişilebilir olduğu ve hata içermeyen bir yanıt döndürdüğü izleme kontrollerinin yüzdesini ölçer. API erişilebilir değilse başka hiçbir şeyin önemi kalmaz.
Erişilebilirlik genellikle bir zaman aralığı üzerinden yüzde olarak ifade edilir: 30 gün boyunca %99,9 erişilebilirlik, API'nin kontrol aralıklarının %99,9'unda çalıştığının doğrulandığı anlamına gelir. Kalan %0,1, arıza bütçesini temsil eder ve bu da ayda yaklaşık 43 dakikalık izin verilen kesinti süresine karşılık gelir.
Erişilebilirliği incelikli kılan şey “erişilebilir” kavramının tanımıdır. Basit bir kontrol, herhangi bir HTTP yanıtını erişilebilir sayabilir. Daha anlamlı bir kontrol ise başarı sınıfında bir durum kodu, zaman aşımı eşiği içinde bir yanıt ve gövdede geçerli içerik gerektirir. Ekipler erişilebilirliği yalnızca bir TCP bağlantısının kurulup kurulmadığına göre değil, her uç nokta için başarılı bir yanıtın gerçekte neye benzediğine göre tanımlamalıdır.
Erişilebilirlik, en acil uyarıları tetikleyen metriktir. Erişilebilirlik düştüğünde olay genellikle zaten müşteriyi etkiliyordur. Ancak erişilebilirlik tek başına API'nin gerçekten güvenilir olacak kadar hızlı, doğru veya tutarlı olup olmadığını söyleyemez.
Metrik 2: P50, P95 ve P99'da Yanıt Süresi
Yanıt süresi, bir istek gönderildikten sonra API'nin eksiksiz bir yanıt döndürmesinin ne kadar sürdüğünü ölçer. Kullanıcının algıladığı hızı en doğrudan yansıtan metriktir. Ancak yanıt süresini nasıl ölçtüğünüz, metriğin faydalı mı yoksa yanıltıcı mı olacağını belirler.
Ortalamalar Neden Yeterli Değildir?
Ortalama yanıt süresi en sık takip edilen gecikme metriğidir ve güvenilirlik açısından en az faydalı olanıdır. Bir API, isteklerin önemli bir kısmı çok daha uzun sürerken sağlıklı bir ortalamaya sahip olabilir. P50 değeri 120 ms, p99 değeri ise 4 saniyeyse, her 100 kullanıcıdan biri medyandan 30 kat daha uzun bekliyor demektir. Bu deneyim ortalamada görünmez.
P50: Tipik Deneyim
- yüzdelik, medyan yanıt süresini temsil eder. İsteklerin yarısı daha hızlı, yarısı daha yavaştır. P50, normal performansın temel göstergesi olarak faydalıdır. P50 yukarı kaydığında temel bir şey değişmiştir: yeni bir kod yolu, daha ağır bir sorgu, baskı altındaki bir veritabanı veya yavaşlamış bir bağımlılık.
P95: Bozulma Sinyali
- yüzdelik, isteklerin en yavaş %5'inin deneyimini yakalar. Performans bozulması genellikle ilk olarak burada görünür hâle gelir. Yükselen bir p95 çoğu zaman kaynak çekişmesine, çöp toplama baskısına, bağlantı havuzu doygunluğuna veya henüz isteklerin çoğunluğunu etkilemeyen ama gerçek kullanıcıları şimdiden etkileyen aralıklı bağımlılık yavaşlamalarına işaret eder.
P95, bir API'nin performans olayına doğru gidip gitmediğini en güvenilir şekilde öngören metriktir. P95'i yakından izleyen ekipler, ortalamanın değişmesini bekleyen ekiplerden daha erken sorun yakalar.
P99: Kuyruk Riski Göstergesi
- yüzdelik, isteklerin en yavaş %1'ini yakalar. P99, en uç gecikmelerin bulunduğu yerdir. Yüksek p99 değerleri çoğu zaman zaman aşımı zincirlerine, yeniden deneme fırtınalarına, soğuk başlatmalara, önbellek ıskalamalarına, serileştirme darboğazlarına veya paylaşılan ortamlardaki gürültülü komşular gibi altyapı düzeyindeki sorunlara işaret eder.
P99 özellikle arama, ödemeler, canlı panolar ve kimlik doğrulama akışları gibi gerçek zamanlı etkileşimlere hizmet eden API'ler için önemlidir. Bu durumlarda kullanıcıların yalnızca %1'inin çok saniyelik gecikmeler yaşaması bile destek taleplerine, yarıda bırakılan oturumlara ve gelir kaybına yol açabilir.
Güvenilirlik açısından p50, p95 ve p99 kombinasyonu performans sağlığına katmanlı bir bakış sunar. P50 temel seviyeyi gösterir. P95 ortaya çıkan bozulmayı gösterir. P99 kuyruk riskini gösterir. Birlikte, ekiplere performans sorunlarını her şiddet aşamasında tespit etme ve bunlara müdahale etme imkânı verirler.
Metrik 3: Hata Oranı
Hata oranı, arıza durumu döndüren API yanıtlarının yüzdesini ölçer. Buna HTTP 5xx sunucu hataları, beklenmeyen davranışa işaret eden 4xx istemci hataları, zaman aşımı hataları ve 200 durum koduyla gelen ancak hata yükü içeren uygulama düzeyindeki hata yanıtları dahildir.
Hata oranı, API sağlığının en doğrudan göstergelerinden biridir. Hata oranındaki ani bir artış neredeyse her zaman bir şeyin bozulduğu anlamına gelir: bir dağıtım hata getirmiştir, bir bağımlılık çökmüştür, bir veritabanı bağlantı havuzu tükenmiştir veya bir yapılandırma değişikliği hatalı şekilde devreye girmiştir.
Hata Türlerini Ayırt Etmek
Tüm hatalar aynı güvenilirlik ağırlığını taşımaz. Sunucu hataları (5xx), API'nin ele alamadığı ve istemcinin düzeltemeyeceği sorunlara işaret eder. Bunlar yüksek önem dereceli sinyallerdir. İstemci hataları (4xx), bazen beklenen geçersiz isteklere işaret edebilir. Ancak 4xx hatalarındaki ani bir artış; geriye dönük uyumsuz bir API değişikliğine, yanlış yapılandırılmış bir istemciye veya incelenmesi gereken bir sözleşme ihlaline de işaret edebilir.
Zaman aşımı hataları özel ilgiyi hak eder; çünkü en kötü kullanıcı deneyimini temsil ederler: istemci beklemiş, hiçbir şey almamış ve ne olduğuna dair hiçbir bilgiye sahip değildir. Yüksek zaman aşımı oranları çoğu zaman alt akış bağımlılık arızalarıyla veya altyapı doygunluğuyla ilişkilidir.
Sessiz Hatalar
Bazı API'ler, yanıt gövdesinde bir hata mesajıyla birlikte 200 OK döndürür. Bu “sessiz hatalar”, yalnızca durum koduna bakan izleme için görünmezdir. Bunları tespit etmek; hata anahtar kelimelerini, boş sonuç kümelerini, eksik zorunlu alanları veya beklenmeyen değerleri kontrol eden yanıt gövdesi doğrulaması gerektirir. Sessiz hatalar, temel izlemeden tamamen kaçtıkları için en tehlikeli API güvenilirlik sorunları arasındadır.
Metrik 4: İlk Bayta Kadar Geçen Süre
İlk bayta kadar geçen süre (TTFB), bir isteğin gönderilmesi ile yanıtın ilk baytının alınması arasında geçen süreyi ölçer. Sunucu tarafındaki işleme süresini ve ağ geçişini, yanıtın tamamının indirilmesinden ayırır. TTFB, istek yaşam döngüsünün iki farklı aşamasını birbirinden ayırdığı için toplam yanıt süresinden daha ayrıntılı bir metriktir.
Toplam yanıt süresi sağlıklıyken TTFB'nin yüksek olması, sunucunun veri göndermeye başlamadan önce işlemeye çok fazla zaman harcadığını gösterebilir. Bu durum yavaş veritabanı sorgularına, engelleyici işlemlere veya kaynak kilidi çekişmesine işaret edebilir. Tersine, düşük TTFB ile yüksek toplam yanıt süresi, sunucunun hızlı yanıt verdiğini ancak yükün büyük ya da ağ yolunun yavaş olduğunu düşündürür.
TTFB, performans sorunlarının teşhisinde özellikle değerlidir; çünkü ekiplerin darboğazın sunucu işlemede mi, yük boyutunda mı yoksa ağ teslimatında mı olduğunu belirlemesine yardımcı olur. Güvenilirlik açısından, daha önce kararlı olan bir uç noktada sürekli yükselen TTFB, arka ucun giderek artan bir baskı altında olduğuna dair erken bir uyarıdır.
Metrik 5: Verim (Throughput)
Verim, bir API'nin birim zamanda işlediği istek sayısını ölçer ve genellikle saniye başına veya dakika başına istek olarak ifade edilir. Bir kalite metriğinden çok kapasite ve talep metriğidir, ancak güvenilirlik bağlamında kritik bir rol oynar.
Ani verim değişiklikleri çoğu zaman güvenilirlik olaylarından önce gelir veya onlara eşlik eder. API'nin kapasitesini aşan bir trafik artışı gecikme artışlarına, hata oranı sıçramalarına ve nihayetinde erişilebilirlik arızalarına neden olabilir. Ani bir verim düşüşü ise üst akış sistemlerinin API'yi çağırmayı bıraktığını gösterebilir; bu da bir istemci arızası, bir yönlendirme değişikliği veya bir DNS sorunu anlamına gelebilir.
Verimi gecikme ve hata oranıyla birlikte izlemek, ekiplerin performans değişikliklerinin yük değişikliklerinden mi yoksa iç bozulmadan mı kaynaklandığını anlamasına yardımcı olur. Geçen hafta kaldırdığı aynı verim altında yavaşlayan bir API'nin iç bir sorunu vardır. Verim iki katına çıktığı için yavaşlayan bir API'nin ise kapasite sorunu vardır. Her birine verilecek yanıt farklıdır ve bunları ayırt eden metrik verimdir.
Metrik 6: Zaman Aşımı Oranı
Zaman aşımı oranı, API yapılandırılmış zaman aşımı penceresi içinde yanıt vermediği için başarısız olan isteklerin yüzdesidir. Genel hata oranından ayrı takip edilmeyi hak eder; çünkü zaman aşımları kendine özgü ve özellikle zararlı bir arıza modunu temsil eder.
Bir istek zaman aşımına uğradığında istemci, hiç gelmeyen bir yanıtı beklerken zaman ve kaynak harcamıştır. Mikro servis mimarilerinde zaman aşımları zincirleme etki yaratabilir: A servisi B servisini bekler, B de C'yi bekler. C zaman aşımına uğrarsa B de zaman aşımına uğrayabilir ve A yeniden deneyerek zaten zorlanan bir sistemin yükünü artırabilir.
Yükselen zaman aşımı oranı, yaklaşan bir zincirleme arızanın en güçlü öngörücülerinden biridir. Zaman aşımı oranını ayrı takip eden ekipler, bu zincirleri tam kesintilere dönüşmeden önce tespit edebilir. Metrik ayrıca zaman aşımı eşiklerinin ayarlanmasına da yardımcı olur: isteklerin önemli bir kısmı sürekli olarak zaman aşımı sınırına yaklaşıyorsa eşik çok dar olabilir veya uç noktanın optimize edilmesi gerekebilir.
Metrik 7: Yanıt Doğrulama Başarı Oranı
Yanıt doğrulama başarı oranı, HTTP durum kodunun ötesindeki içerik düzeyi doğrulamalarını geçen API yanıtlarının yüzdesini ölçer. Buna şema doğrulama, zorunlu alan kontrolleri, veri türü doğrulaması, değer aralığı kısıtlamaları ve iş mantığı doğrulamaları dahildir.
Bu metrik güvenilirlik açısından önemlidir; çünkü hızlı ve 200 durum kodlu yanıtlarla yanlış veri döndüren bir API, erişilebilirlik ve gecikme metrikleri sağlıklı görünse bile işlevsel olarak bozuktur. Doğrulama başarı oranı, bu sessiz doğruluk arızalarını yakalayan metriktir.
Örneğin her ürün fiyatı için sıfır döndüren bir fiyatlandırma API'si, erişilebilirlik ve gecikme kontrollerini geçer ancak gerçek bir iş zararına yol açar. Dolu veriler yerine boş diziler döndüren bir kullanıcı profili API'si, ağ düzeyinde sağlıklı görünür ancak bozuk bir uygulama deneyimi yaratır. Doğrulama başarı oranı, yalnızca API'nin yanıt verip vermediğini değil, API sözleşmesine uyulup uyulmadığını ölçerek bu sorunları yakalar.
Ekipler en kritik uç noktaları için doğrulama kuralları tanımlamalı ve başarı oranını erişilebilirlik ve gecikmenin yanında birinci sınıf bir güvenilirlik metriği olarak takip etmelidir.
Metrik 8: DNS Çözümleme ve Bağlantı Süresi
Bir API yanıt verebilmeden önce birkaç ağ düzeyi işlemin tamamlanması gerekir: DNS çözümleme, TCP bağlantısının kurulması ve TLS el sıkışması. Bunlar genellikle hızlıdır, ancak bozulduklarında o uç noktaya yapılan her istek aynı anda etkilenir.
DNS çözümleme süresi, API'nin ana makine adının bir IP adresine çözümlenmesinin ne kadar sürdüğünü ölçer. DNS çözümleme süresindeki bir sıçrama; DNS sağlayıcısı sorunlarına, yanlış yapılandırılmış kayıtlara veya TTL kaynaklı önbellekleme sorunlarına işaret edebilir. Bağlantı süresi ise TCP el sıkışmasının süresini ölçer ve ağ yolu bozulmasını, güvenlik duvarı sorunlarını veya sunucu tarafında bağlantı kabul sorunlarını ortaya çıkarabilir.
Bu metrikler özellikle CDN'ler, yük dengeleyiciler veya çok bölgeli mimariler üzerinden sunulan ve istemci ile kaynak sunucu arasındaki ağ yolunun değişebildiği API'ler için değerlidir. DNS'ten veya bağlantı kurulumundan kaynaklanan bir gecikme artışı, uygulama işlemeden kaynaklanan bir artıştan farklı bir sorundur ve çözümü de buna göre farklıdır.
Metrik 9: Coğrafi Performans Farklılığı
Coğrafi farklılık, API performansının izleme konumları arasında nasıl değiştiğini ölçer. Bir API, yakın bir bölgeden 100 ms'lik yanıtlar sunarken uzak bir bölgeden 800 ms'lik yanıtlar verebilir. Her iki bölge de üretim trafiğine hizmet ediyorsa, o kullanıcılar için gerçek güvenilirliği belirleyen uzak bölgedeki deneyimdir.
Performansı bölgeye göre takip etmek; ekiplerin CDN yanlış yapılandırmalarını, yönlendirme asimetrilerini, bölgesel altyapı sorunlarını ve belirli pazarları etkileyen yayılma gecikmelerini tespit etmesine yardımcı olur. Ayrıca küresel yük dengeleme, uç önbellekleme ve bölgesel yük devretmenin amaçlandığı gibi çalıştığını doğrulamaya da yardımcı olur.
Uluslararası kullanıcıları olan kuruluşlar için coğrafi farklılık bir güvenilirlik metriğidir; çünkü önemli bir pazardaki zayıf performans, işlevsel olarak kısmi erişilemezlikle eşdeğerdir. Küresel ortalamalar sağlıklı görünse bile o bölgedeki kullanıcılar bozulmuş bir hizmet deneyimler.
Bu Metrikler Birlikte Nasıl Çalışır?
Tek bir metrik, API güvenilirliğinin tam bir resmini sunmaz. Değer, kombinasyonda ve her metriğin diğerlerinin ortaya koymadığı neyi ortaya koyduğunu anlamakta yatar.
Erişilebilirlik, API'nin ayakta olup olmadığını söyler. Gecikme yüzdelikleri, gerçek kullanıcılar için yeterince hızlı olup olmadığını söyler. Hata oranı, arıza verip vermediğini söyler. TTFB, darboğazın nerede olduğunu söyler. Verim, talebin değişip değişmediğini söyler. Zaman aşımı oranı, sizi zincirleme arızalara karşı uyarır. Doğrulama başarı oranı, verilerin doğru olup olmadığını söyler. DNS ve bağlantı süresi, ağın sağlıklı olup olmadığını söyler. Coğrafi farklılık ise güvenilirliğin pazarlar arasında tutarlı olup olmadığını söyler.
Bu metrikler birlikte takip edilip ilişkilendirildiğinde ekipler sorunları daha hızlı teşhis edebilir, müdahaleyi gerçek kullanıcı etkisine göre önceliklendirebilir ve güvenilir hizmetin tam tanımını yansıtan hizmet düzeyi hedefleri oluşturabilir.
API Metrik Seçiminde Sık Yapılan Hatalar
En yaygın hata, yalnızca erişilebilirliği ve ortalama yanıt süresini takip etmektir. Bu kombinasyon kuyruk gecikmesini, sessiz hataları, doğruluk arızalarını ve kapasiteye bağlı bozulmayı gözden kaçırır.
İkinci hata, tüm uç noktalara eşit davranmaktır. Kimlik doğrulama, ödemeler veya temel kullanıcı yolculuklarına hizmet eden iş açısından kritik API'ler, düşük trafikli dahili uç noktalara göre daha sıkı eşiklere ve daha ayrıntılı metriklere sahip olmalıdır.
Üçüncü hata, metrikleri ilişkilendirmemektir. Verim artışıyla aynı zamana denk gelen bir gecikme sıçraması, normal verimdeki bir gecikme sıçramasından farklı bir hikâye anlatır. İlişkilendirme olmadan ekipler yanlış kök nedeni araştırır.
Dördüncü hata, yanıt doğrulamayı göz ardı etmektir. Yalnızca durum koduna bakan izleme, API'lerin hiçbir uyarı tetiklemeden saatlerce veya günlerce yanlış veri döndürebildiği büyük bir kör nokta bırakır.
Son Düşünceler
API izleme, API'lerin üretimde erişilebilir, hızlı, doğru ve tutarlı olduğunu doğrulamaya yönelik sürekli bir pratiktir. Güvenilirlik açısından en önemli metrikler, gerçek sorunları müşteriyi etkileyen olaylara dönüşmeden önce tespit eden metriklerdir: erişilebilirlik oranı, p50, p95 ve p99'da gecikme, hata oranı, ilk bayta kadar geçen süre, verim, zaman aşımı oranı, yanıt doğrulama başarı oranı, DNS ve bağlantı süresi ile coğrafi performans farklılığı.
Her metrik, API sağlığının farklı bir boyutunu ortaya koyar. Birlikte, ekiplere güvenilir hizmetin gerçekte ne anlama geldiğini tanımlamak, ne zaman bozulduğunu tespit etmek ve kullanıcılar etkilenmeden önce müdahale etmek için gereken görünürlüğü sağlarlar. Kapsamlı metrik kapsamına yatırım yapan ekipler, en çok kesintiyi önleyen, en güçlü hizmet düzeylerini koruyan ve API'lerine bağımlı kullanıcılar ve sistemlerle en fazla güveni inşa eden ekiplerdir.
Ürününüz API'lere bağımlıysa API izleme isteğe bağlı bir altyapı değildir. Temel bir güvenilirlik pratiğidir. Ve takip etmeyi seçtiğiniz metrikler, bu pratiğin gerçekten işe yarayıp yaramadığını belirleyen şeydir.