Uç Nokta Doğrulama ve Metin Analizi için API İzleme Aracı
HostTracker'ın API izleme aracı, uç noktalarınızdan alınan içerik için politikalar belirlemenizi sağlar. Aracı ilk kullandığınızda önce içerik türünün geçerli olduğunu kontrol eder, ardından içerik içinde belirlediğiniz değerleri arar.
Sadece çalışma süresini değil - API'lerinizin gerçekten çalıştığını doğrulayın
HostTracker, API uç noktalarınızı belirli aralıklarla kontrol eder; sadece sunucunun yanıt verip vermediğine değil, durum kodunu, içerik türünü ve yanıt içindeki değerleri de doğrular.
API İzleme Neden Önemlidir
API'lerinizi izlemek gerçekten önemlidir. Ne kadar iyi performans gösterdiklerini, ne kadar erişilebilir olduklarını ve beklendiği gibi çalışıp çalışmadıklarını takip etmenize yardımcı olur. Ayrıca performans standartlarını karşıladıklarından emin olmanızı sağlayarak olası sorunlardan kaçınmanıza yardımcı olur
Tek Kontrolde Çalışma Süresi ve Performans
Çalışma süresi izleme, temelde bir API uç noktasını belirli aralıklarla kontrol ederek ihtiyacınız olduğunda orada olduğundan ve iyi çalıştığından emin olmaktır. Performans izleme ise bir API'nin isteklere ne kadar hızlı ve güvenilir şekilde yanıt verdiğini ölçmekle ilgilidir.
Güvenilir API'lerin İş Üzerindeki Etkisi
API'lerin ne kadar iyi çalıştığı, kullanıcıların uygulamaları nasıl deneyimlediği, genel işleyiş kalitesi ve hatta işletmenin kârlılığı üzerinde büyük bir etkiye sahip olabilir.
Bir API monitörü her çalıştırmada neyi kontrol eder
REST API izleme, yüzeysel olarak çalışma süresi izlemeye benzer ama farklı bir iştir. Bir API, insanlar tarafından değil kod tarafından tüketilir ve kod, bir tarayıcının olmadığı şekillerde acımasızdır. İnsan bir ziyaretçi, biraz yanlış render edilen bir sayfaya tolerans gösterir; yanlış türde bir alan alan bir entegrasyon ise basitçe bozulur. Bu yüzden API izleme, "sunucu yanıt verdi mi"den daha fazla katmanı kontrol etmek zorundadır ve HostTracker bunları sırayla kontrol eder; tutmayan ilk katmanda başarısız olur.
| Katman | Neyin doğrulandığı | Yakaladığı arıza |
|---|---|---|
| 1 · Erişilebilirlik | DNS çözümlenir, TCP bağlantısı açılır, TLS el sıkışması tamamlanır | Uç nokta ortadan kalkmış, sertifikanın süresi dolmuş, ana bilgisayar dünyanın bir kısmından yönlendirilemiyor |
| 2 · Durum | HTTP durum kodu, kabul ettiğiniz veya açıkça hata olarak ele aldığınız kodlara karşı | Bir dağıtımdan sonra 500, süresi dolmuş bir kimlik bilgisinden 401, beklemediğiniz bir 429 |
| 3 · Zamanlama | Toplam yanıt süresi ve bunun bağlantı, TLS, başlıklar ve gövde arasındaki dökümü | Hâlâ çalışan ama sessizce 200 ms'den dört saniyeye çıkmış bir uç nokta |
| 4 · Biçim | İçerik türü ve başlıklar - bu gerçekten JSON mu, yoksa 200 giymiş bir HTML hata sayfası mı | Bir yükün olması gereken yerde sunulan bir hata sayfası veya bir giriş yönlendirmesi. Klasik sessiz API arızası |
| 5 · İçerik | Yükten seçilen bir değer veya tüm yanıt üzerinde serbest biçimli doğrulamalar | Bir şema değişikliğinden sonra eksik bir alan, boş bir sonuç kümesi, geri alınmış bir sürüm dizesi, başarılı bir yanıtın içinde beliren bir hata üyesi |
Bir ile üç arasındaki katmanlar, sıradan bir çalışma süresi kontrolünün size verdiği şeydir. Dört ve beş ise onu API izleme yapan katmanlardır - ve gerçek API olaylarının çoğunun aslında yaşadığı katmanlar bunlardır.
İsteği yapılandırmak
Herhangi bir şey doğrulanabilmeden önce, monitörün API'nizin beklediği isteği yapması gerekir. Tam istek yüzeyi bir API monitöründe kullanılabilir:
| Ayar | Onunla neler yapabilirsiniz |
|---|---|
| HTTP yöntemi | GET, HEAD, POST, PUT, PATCH veya DELETE |
| Özel başlıklar | İhtiyacınız olan herhangi bir ad-değer çifti - bir taşıyıcı jeton, bir API anahtarı, bir kiracı kimliği, bir Accept sürüm başlığı. Başlıklar, bir yönlendirme boyunca yalnızca aynı ana bilgisayara iletilir; bu yüzden bir kimlik bilgisi, uç noktanızın yönlendirdiği üçüncü bir tarafa asla sızmaz. |
| İstek gövdesi | POST, PUT ve PATCH için ham bir gövde veya form kodlu parametreler |
| HTTP kimlik doğrulama | Bağlantı üzerinde sunucunun istediği şemanın anlaşıldığı bir kullanıcı adı ve parola |
| Yönlendirmeler | Onları takip edin ya da etmeyin, kaç tanesinin takip edileceğini sınırlayın veya herhangi bir yönlendirmeyi bir arıza olarak ele alın - doğrudan yanıt vermesi gereken bir uç nokta için kullanışlıdır |
| Zaman aşımı | 40'ın varsayılan olduğu, en fazla 100 saniye - ve bir zaman aşımı bir kontrol arızasıdır; bu da bir SLA'sı olan bir uç noktadan tam olarak istediğiniz şeydir |
| Yanıt boyutu sınırı | Varsayılan olarak 1 MB'dır ve yükseltilebilir; böylece kontrolden çıkan bir yanıt kontrolü tüketemez |
| Kabul edilen ve reddedilen durum kodları | Yok sayılacak kodların ve hata olarak ele alınacak kodların listeleri - sözleşmesinin bir parçası olarak meşru şekilde 401 veya 404 yanıtı veren bir uç nokta için araç |
| DNS kontrolü | Belirli çözümleyiciler üzerinden çözümleyin, kontrol noktasının DNS önbelleğini atlayın ve ana bilgisayarın hangi IP adreslerine çözümlendiğini doğrulayın |
| TLS sıkılığı | Geçerli bir sertifika zinciri, TLS 1.2 veya üzeri, 128 bitin üzerinde şifrelemeler ve bir iptal kontrolü gerektirmeyi isteğe bağlı olarak açın - artı aynı bağlantı üzerinde sertifika süre sonu izleme |
Doğrulamalar (assertions): sağlıklı bir yanıtın neye benzediğini tanımlamak
Bir yanıtı doğrulamanın en anlatımlı yolu, onun için kurallar yazmaktır. Her kural tek bir satırdır, kurallar VE ile birleştirilir ve bir monitör bunlardan en fazla yirmi tane taşıyabilir. Bu, bir JSON API için doğrulanmış başlangıç paketidir:
status isOk
header("Content-Type") contains "json"
body.json.path("$.count") gt 0
time lt 5sDört satır ve aralarında önemli olan dört katmanı kapsarlar: uç nokta bir 2xx ile yanıt verdi, bir
hata sayfası yerine JSON ile yanıt verdi, yük boş değil gerçek bir sonuç içeriyor ve tüm bunları
bütçe içinde yaptı. Aynı katalogdan tek başına kullanışlı kurallar arasında, bir API'nin kendi sağlık
kararı için body.json.path("$.status") eq "ok", aksi hâlde başarılı bir yanıtta beliren
bir hata üyesi için body.json.path("$.error") absent, istenmeyen bir geri alma işlemini
yakalamak için body.json.path("$.version") eq "2.4.1", doğrudan yanıt vermesi gereken
bir uç nokta için redirects.count eq 0 ve aynı bağlantıdaki sertifika için
cert.days.left gt 14 bulunur.
Bir kural neyden bahsedebilir
Kurallar, yanıttan konuları okur ve onları karşılaştırır. Konular; durum kodunu, toplam yanıt süresini
ve bağlantı, TLS, DNS, başlık ve gövde bileşenlerini, boyutu ve bir özeti ile birlikte ham gövdeyi,
yükün içine JSON, XML, HTML veya YAML olarak yapılandırılmış sorguları, tek tek yanıt başlıklarını,
son ve orijinal URL'yi ve onların parçalarını, yönlendirme zincirini adım adım, sertifikanın kalan gün
sayısını, vereni ve adlarını, anlaşılan TLS protokolü ve şifrelemesini, DNS'in döndürdüğü adresleri ve
Set-Cookie'yi kapsar. Karşılaştırmalar, bariz olanlardan - eşit, küçük, büyük -
contains, startsWith, endsWith, düzenli bir ifade için
matches, bir küme için containsAny ve containsAll, kabul
edilebilir değerlerin bir listesi için in ve exists, isNumber
ile unique'e kadar çalışır.
Ayrıca bir değişiklik tespiti ekseni de vardır: bir kural, bu çalıştırmanın değerini bir önceki çalıştırmanınkiyle karşılaştırabilir; böylece bir sayacın asla geriye gitmediğini veya bir gövde özetinin değişmediğini doğrulayabilirsiniz - bu, bir kesintiyi değil, sessiz bir geri almayı veya yetkisiz bir içerik değişikliğini yakalayan kural biçimidir.
Yükten tek bir değer çekmek
Kural diliyle birlikte, burada uzun süredir API izlemenin bir parçası olan ve çoğu zaman bir kontrolün ihtiyaç duyduğu her şey olan daha basit, tek değerli bir yol da vardır. Monitöre gövdeyi nasıl ayrıştıracağını, ondan bir değeri nasıl seçeceğini ve o değerin ne olması gerektiğini söylersiniz:
- JSON olarak ayrıştırın, o zaman seçici bir JSONPath ifadesidir.
- XML olarak ayrıştırın, o zaman seçici bir XPath ifadesidir - SOAP ve diğer XML hizmetlerini kontrol etmeyi basit kılan şey budur.
- Düz metin olarak ele alın, o zaman seçici çok satırlı, büyük/küçük harfe duyarsız bir düzenli ifadedir (regular expression).
Seçilen değere uygulanan koşul; eşit ve eşit değil, hem katı hem kapsayıcı biçimlerde küçüktür ve büyüktür, kabul edilebilir bir değerler listesine üyelik veya bir listeden hariç tutulma, sayısal bir aralığın içinde veya dışında olma ve değerin tamamen null veya yok olup olmadığına dair bir testi kapsar.
Hatalı biçimlendirilmiş bir seçici, sabahın üçünde değil, kaydettiğinizde reddedilir. Seçici, doğrulama zamanında derlenir; bu yüzden bir JSONPath veya XPath'teki bir yazım hatası, oluşturduğunuz andan beri sessizce başarısız olan - veya sessizce geçen - bir monitör yerine formda bir hatadır.
Bir durum kodu kontrolünün göremediği arızalar
Bu tablodaki her arıza HTTP 200 döndürür. Bir API'yi yalnızca durum koduna göre izlemenin tüm sorunu budur: taşıma başarılı oldu, bu yüzden taşıma başarıyı raporlar.
| Ne yanlış gitti | Yanıt neye benziyor | Neyi yakalar |
|---|---|---|
| Bir yükün olması gereken yerde bir hata sayfası sunuluyor | 200, HTML ile | Bir içerik türü doğrulaması veya gövdenin JSON olarak ayrıştığına dair bir kural |
| Arama dizini yeniden oluşturulmayı durdurdu | 200, boş bir sonuç dizisiyle | Sonuç sayısının en az bir olduğuna dair bir kural |
| Bir şema değişikliğinde bir alanın adı değiştirildi | 200, geçerli JSON, eksik üye | Alanın var olduğuna dair bir kural |
| Kimse fark etmeden bir dağıtım geri alındı | 200, daha eski bir sürüm dizesi | Sürüm alanını sabitleyen bir kural |
| Bir başarı zarfının içinde bir hata üyesi beliriyor | 200, ayarlanmış bir hata üyesiyle | Hata üyesinin bulunmadığına dair bir kural |
| Akış aşağısındaki bir bağımlılık başarısız oluyor ve API zarifçe bozuluyor | 200, kısmi veya bayat veriyle | API'nin kendi sağlık alanı üzerinde bir kural veya yükteki bir tazelik değeri |
| Uç nokta artık iki yüz milisaniye yerine dört saniyede yanıt veriyor | 200, sonunda | Bir yanıt süresi kuralı |
| Kimlik doğrulama sessizce uygulanmayı durdurdu | 200, döndürmemesi gereken veriyi döndürüyor | Ayrılmış bir negatif monitör - 401 döndürmesi gereken, kimliği doğrulanmamış bir istek |
Son satırı bilinçli olarak yapmaya değer. Hiçbir kimlik bilgisi göndermeyen ve bir 401 üzerinde doğrulama yapan ikinci bir monitör, bir yetkilendirme katmanının kazayla devre dışı bırakıldığını öğrenmenin en ucuz yoludur - bu, hiçbir miktarda pozitif testin asla ortaya çıkaramayacağı bir arızadır.
Sahte alarmlar olmadan 300'den fazla konumdan kontrol
API monitörleri, HostTracker'ın genel kontrol noktası filosundan - 158 şehirde 300'den fazla kontrol noktası - çalışır ve belirli bir monitörün hangi konumları kullanacağını siz seçersiniz. Coğrafya, bir API için bir web sitesine göre daha önemlidir: bir CDN veya coğrafi yönlendirmeli bir yük dengeleyici tarafından önden karşılanan bir uç nokta Frankfurt'ta sağlıklı, São Paulo'da arızalı olabilir ve tek konumlu bir kontrolün bunu görmesinin bir yolu yoktur. Aynısı DNS için de geçerlidir - bayat veya yanlış yapılandırılmış bir kayıt genellikle eşit olmayan şekilde yayılır; bu da içeriden aralıklı bir kesinti, dışarıdan ise bölgesel bir kesinti gibi görünür.
Birçok yerden çalışmak bariz bir risk doğurur: daha fazla kontrol noktası, tek bir kararsız ağ yolunun boşuna alarm çalması için daha fazla şans demektir. HostTracker bunu bir onay çoğunluğu (kuorum) ile ele alır. Bir kontrol noktası bir arıza bildirdiğinde, kontrol ek bağımsız kontrol noktaları genelinde tekrarlanır ve durum değişikliği yalnızca onlar hemfikir olduğunda onaylanır - varsayılan olarak en fazla yedi ajan üzerinden en az üçünün gerektiği bir çoğunluk kararı. Sahte bir çağrının yavaş bir çağrıdan daha kötü olduğu bir uç nokta için, arızayı bildirmesi gereken belirli sayıda ajan gerektirerek veya aralarında tam uzlaşma isteyerek bunu daha sıkı hâle getirebilirsiniz.
Onaydan sonra, uyarı her kişinin seçtiği gecikmeyi izler - anında ya da 3, 5, 15, 30 veya 60 dakikalık ya da 3, 6, 12 veya 24 saatlik kesintisiz arızadan sonra - dokuz bildirim kanalı üzerinden: e-posta, SMS, sesli arama, webhook, Slack, web push ve Telegram, Discord ile Viber mesajlaşma uygulamaları. Uyarıların bir olay yönetimi aracına veya bir ekip sohbet aracına ulaşma yolu webhook kanalıdır.
REST, GraphQL, SOAP ve webhook alıcıları
Kontrol, yapılandırılabilir bir HTTP isteği artı yanıt analizidir; bu yüzden nelere uyduğu doğrudan bundan çıkar.
- REST ve JSON API'ler günlük durumdur ve çoğu hesabın önce kurduğu şey REST API izlemedir: bir GET veya POST, kimlik bilgisi için başlıklar ve yük üzerinde JSONPath veya doğrulama kuralları.
- GraphQL, sorgunun gövdede olduğu bir POST olarak ve ardından
dataiçine JSONPath olarak çalışır - GraphQL'in ünlü şekilde içinde hatalarla 200 yanıtı vermesi nedeniyleerrorsüyesinin bulunmadığını doğrulamaya değer. - SOAP ve XML hizmetleri, zarfın gövde olduğu ve seçicinin XPath olduğu bir POST'tur; bu, spesifikasyonun amaçladığı şekilde tam olarak yanıtın içine ulaşır.
- Webhook alıcıları ve geri çağırma (callback) uç noktaları, erişilebilirlik ve iyi biçimlendirilmiş bir isteğe verdikleri yanıt açısından kontrol edilebilir - değerlidir, çünkü teslimatları kabul etmeyi sessizce durdurmuş bir alıcı, kendi sisteminizde hiçbir yerde bir hata üretmez.
- Sağlık ve hazır olma uç noktaları, varsa hepsinin en yüksek değerli hedefidir: uygulamanız bağımlılıklarının sağlıklı olup olmadığını zaten bilir ve o karar üzerinde bir doğrulama, kendi bilgisini bir uyarıya dönüştürür.
Uymayan şey bir dizidir - bir jeton al, onu kullan, sonra kaynağı sil. Bir API monitörü, çalıştırma başına bir istek yapar. Gerçek bir çok adımlı yolculuk için tarayıcı tabanlı işlem kontrolü doğru araçtır; bir uç noktanın değil bir sayfanın zamanlaması için tarayıcı erişimi ve sayfa yükleme süresine bakın.
İlk API monitörünüzü kurmak
- Kurallar yazacağınız durumu, zamanlamayı ve yanıtı görebilmek için önce uç noktayı ücretsiz anlık HTTP kontrolü ile deneyin - giriş gerekmez.
- Bir monitör ekleyin ve API izleme türünü seçin. Yöntemi ayarlayın ve uç noktanın ihtiyaç duyduğu başlıkları veya gövdeyi ekleyin; monitöre bir kişininkini yeniden kullanmak yerine kendi kimlik bilgisini verin.
- Doğrulamaları yazın. Yukarıdaki dört satırlık paketle başlayın - durum, içerik türü, yükten anlamlı bir değer ve bir yanıt süresi bütçesi - bu, neredeyse her JSON API için gerçekten iyi bir varsayılandır.
- Bir dakika ile 24 saat arasında bir aralık seçin. Üç dakika varsayılandır ve makul bir başlangıç noktasıdır; bir dakikayı, kesintisi bir olay sayılan uç noktalar için ayırın.
- Konumları seçin. Tüketicilerinizin gerçekten bulunduğu iki veya üç bölge, tek bir bölgeden daha iyidir ve bölgesel bir arızayı görünür kılan şey budur.
- Kişileri ekleyin ve her birinin uyarı gecikmesini ayarlayın. Herkesin birinci dakikadan haberdar olması gerekmez.
- Bir gün çalışmasına izin verin, ardından zamanlama kuralını sıkılaştırmadan önce yanıt süresi geçmişine bakın. Gerçek veriden belirlenen bir bütçe tutar; bir tahminden belirlenen ise susturulur.
API izleme ile APM ve gözlemlenebilirlik
Bunlar birbirini tamamlar ve sıkça karıştırılır. Bir gözlemlenebilirlik veya APM platformu kodunuzu araçlarla donatır ve bir isteğin içinde ne olduğunu size söyler. Harici API izleme ise altyapınızın dışında durur ve bir tüketicinin gerçekte ne aldığını size söyler. İkisine de sahip olmaya değer; ikisi de birbirinin yerini tutmaz.
| Harici API izleme | APM / gözlemlenebilirlik | |
|---|---|---|
| Bakış noktası | Altyapınızın dışında, genel internet üzerinden | Uygulama sürecinizin içinde |
| Kod değişikliği gerektirir | Hayır - hiçbir yere hiçbir şey kurulmaz | Her hizmette bir aracı veya SDK |
| DNS, yönlendirme, TLS ve CDN sorunlarını görür | Evet - bunlar izlediği yol üzerindedir | Hayır - bunlar istek ulaşmadan önce gerçekleşir |
| Tüm platform çöktüğünde bile rapor vermeye devam eder | Evet - sizin tarafınızdan barındırılmaz | Genellikle hayır - raporlayan şey de çökmüştür |
| Bir isteğin kodunuzun içinde neden yavaş olduğunu açıklar | Hayır - zamanlama dökümünü görür, yığınınızı değil | Evet - tüm amacı budur |
| Bugün kimsenin çağırmadığı bir uç noktayı kapsar | Evet - onu bir zamanlamaya göre çağırır | Hayır - trafik yok, telemetri yok |
Çoğu ekibin vardığı model, tespit için harici izleme ve teşhis için dahili telemetridir: HostTracker size bir uç noktanın bozulduğunu, nereden bozulduğunu ve hangi kurala karşı bozulduğunu söyler, kendi izlemeniz ise nedenini söyler. Bunun yanında, bir veritabanı sorgu monitörü genellikle yavaşlayan bir API'yi açıklar ve sunucu yük izleme onun çalıştığı ana bilgisayarı açıklar.
Bilinmesi gereken sınırlar
- Çalıştırma başına bir istek. Jeton değişimi yok, zincirlenmiş çağrılar yok. Monitörü kimlik doğrulaması süresi dolmayan bir uç noktaya yönlendirin ve kanıtlamanız gereken şey bir diziyse bir işlem kontrolü kullanın.
- Monitör başına yirmi doğrulama kuralı. Pratikte bol bol yeterli - dört satırlık paket çoğu uç noktayı kapsar - ama yüz kurallık bir sözleşme testi planlamadan önce bilinmeye değer.
- Doğrulama modu, eski anahtar kelime ve durum ayarlarının yerini alır. İki model bir monitörde birleştirilemez; kural dilini veya eski anahtar kelime modunu seçin, ikisini birden değil.
- OpenAPI veya JSON-schema doğrulaması yoktur. Tüm bir şema belgesi üzerinde değil, belirli değerler ve yapılar üzerinde doğrulama yaparsınız.
- İstek gövdesinin bir uzunluk sınırı vardır, bu yüzden çok büyük bir POST yükü, bu kontrolün tasarlandığı biçim değildir.
- Bu izlemedir, test değil. Doğru hedef, salt okunur veya idempotent bir uç noktadır. Birkaç konumdan her üç dakikada bir veriyi değiştiren bir monitör, sonunda bir olayı tespit eden şey değil, bir olaya neden olan şey olacaktır.
Sıkça Sorulan Sorular
Bir API izleme aracı, sunucunun sadece yanıt verip vermediğini kontrol etmek yerine, API uç noktalarınıza belirli aralıklarla istek gönderir ve gelen yanıtı sizin tanımladığınız kurallara göre değerlendirir. HostTracker'ın API izleme özelliği önce uç noktanın erişilebilir olduğunu ve beklenen HTTP durum kodunu döndürdüğünü doğrular, ardından yanıtın içerik türünün beklenenle eşleştiğini kontrol eder (JSON, XML, düz metin vb.) ve son olarak yanıt gövdesinde yapılandırdığınız belirli değerleri veya kalıpları arar. Bu katmanlı yaklaşım, basit bir "çalışıyor mu" kontrolünün tamamen kaçıracağı sorunları yakalar - bir uç nokta, arka uçtaki bir hata, başarısız bir veritabanı sorgusu veya zincirin ilerisindeki bozuk bir entegrasyon nedeniyle bozuk, eksik veya güncel olmayan veri döndürürken bile normal bir 200 durum kodu verebilir. Baştan net doğrulama politikaları belirlemek, izleyicinin sizin API'niz için sağlıklı bir yanıtın gerçekte neye benzediğini bilmesini sağlar.
Web sitesi çalışma süresi izleme genellikle bir sayfanın yüklenip yüklenmediğini ve normal bir HTTP durum kodu döndürüp döndürmediğini kontrol eder; bu, tarayıcıda görüntülenmek üzere tasarlanmış sayfalar için iyi çalışır. API izleme daha ileri gider çünkü API'ler insanlar tarafından değil kod tarafından tüketilir, bu yüzden "çalışan" bir yanıtın sadece başarılı bir durum kodundan ibaret olmayan daha katı gereksinimleri karşılaması gerekir: doğru içerik türü, geçerli yapı ve yük içindeki doğru değerler. Bir uç nokta, gerçek veri yanlış, eksik veya bozuk olsa bile HTTP 200 döndürebilir ve geleneksel çalışma süresi kontrolleri tek başına sadece yanıt koduna baktığı için bunu yakalayamaz. HostTracker'ın API izleme özelliği, çalışma süresi izlemenin yaptığı gibi erişilebilirlik ve durum kodunu kontrol etmenin yanı sıra içerik türü doğrulaması ve yanıt gövdesinde beklenen değerlerin aranmasını da içerir - bu da bir API'nin gerçekten doğru çalışıp çalışmadığına dair çok daha net bir tablo sunar.
Evet, API izlemeyi basit bir çalışma süresi kontrolünden ayıran temel özellik tam olarak budur. HostTracker, uç noktanın yanıt verdiğini doğrulamanın ötesine geçen doğrulama politikaları belirlemenize olanak tanır: beklenen içerik türünü belirtebilir, böylece bir uç nokta beklenmedik şekilde JSON yerine HTML döndürmeye başladığında kontrol başarısız olur (gerçek veri yerine bir hata sayfası sunulduğunun yaygın bir belirtisi) ve yanıtın sağlıklı sayılması için bulunması gereken belirli değerleri yanıt içeriğinde arayabilirsiniz. Bu, HTTP durum kodu tamamen normal görünse bile bir kontrolün başarısız olabileceği anlamına gelir; böylece arka uçtaki bir hatanın veya bozuk bir alt sistem entegrasyonunun teknik olarak başarılı ama işlevsel olarak yanlış bir yanıt ürettiği durumlar yakalanır. Sadece bağlantıyı değil, gerçek içeriği doğrulamak, API izlemeyi diğer sistemlerin bağımlı olduğu uç noktalar için anlamlı kılan şeydir.
HostTracker'ın API izleme özelliği, bir uç noktanın yanıt verdiğini ve içerik türünün beklentinizle eşleştiğini doğruladıktan sonra, kontrolün doğrulama politikasının bir parçası olarak yapılandırdığınız belirli değerleri veya metin kalıplarını dönen içerik içinde arar. Bu sayede bir yanıtın, uç noktanın doğru çalıştığını gösteren belirli bir alanı, durum değerini veya veri parçasını içerdiğini doğrulayabilirsiniz - örneğin bir sağlık kontrolü uç noktasının yanıtının, 200 yanıtına sarılmış bir hata mesajı yerine beklenen bir durum değeri içerdiğini teyit etmek gibi. Beklenen içerik bulunamazsa, bağlantının kendisi başarılı olsa bile kontrol başarısız olarak işaretlenir ve yapılandırdığınız bildirim kanalları üzerinden uyarılırsınız. Bu tür içerik farkındalıklı kontrol, bir API'nin teknik olarak erişilebilir olduğu ancak sessizce eksik veya hatalı veri döndürdüğü kısmi arızaları yakalamak için özellikle kullanışlıdır.
Kontrol sıklığı yapılandırılabilir ve HostTracker'ın ücretli paketleri, tüm izleme türlerinde bir dakikaya kadar hızlı aralıkları destekler; böylece uygulamanızın çalışma süresi için kritik olan API uç noktaları neredeyse sürekli kontrol edilebilir. Kalıcı ücretsiz plan, en fazla iki monitör için her 30 dakikada bir kontrol yapar; bu, bir sorunun tespitindeki kısa bir gecikmenin maliyetli olmadığı düşük öncelikli veya dahili API'ler için makul bir sıklıktır. Canlı bir uygulamayı, bir ödeme akışını veya müşterilerinizin bağımlı olduğu bir entegrasyonu güçlendiren iş açısından kritik API'ler için daha kısa aralıklar, sorunların kullanıcıların fark edeceği daha büyük bir kesintiye dönüşmeden önce yakalanıp ele alınması anlamına gelir. Kredi kartı gerektirmeyen, 1 dakikalık kontrollere sahip 30 günlük tam özellikli deneme sürümü, kendi API'niz için tespitin ne kadar hızlı olması gerektiğini test etmenizi sağlar.
Evet. Bir API monitörü, uç noktanın isteği kabul etmesi için gereken her şeyi gönderebilir: bir taşıyıcı (bearer) jetonun, bir API anahtarı başlığının veya bir kiracı (tenant) kimliğinin sağlandığı yol olan rastgele özel başlıklar, artı HTTP kimlik doğrulaması için bir kullanıcı adı ve parola, POST, PUT veya PATCH için bir istek gövdesi ve GET ile HEAD'den POST, PUT, PATCH ve DELETE'e kadar herhangi bir HTTP yöntemi. Pratik öneri, herhangi bir otomatik istemci için olduğu gibidir: monitöre bir kişininkini yeniden kullanmak yerine kendi kimlik bilgisini verin, uç noktayı anlamlı şekilde test etmeye yetecek en dar kapsamı verin ve veriyi değiştiren herhangi bir şey yerine salt okunur bir uç noktayı veya ayrılmış bir sağlık rotasını tercih edin. Jetonlarınız kısa ömürlüyse, monitörün yapamayacağı bir jeton değişimi gerçekleştirmesini sağlamaya çalışmak yerine, kimlik doğrulaması süresi dolmayan bir uç noktaya - uzun ömürlü bir anahtarla korunan bir sağlık veya durum rotasına - yönlendirin.
API kontrolleri bir dakikadan 24 saate kadar bir aralıkta çalışır - 1, 2, 3, 5, 10, 15, 30 ve 45 dakika, ardından 1, 2, 4, 6, 12 ve 24 saat - ve yeni bir monitörün varsayılanı üç dakikadır. Bunlar, 158 şehirde 300'den fazla kontrol noktasını kapsayan HostTracker'ın genel kontrol noktası filosundan çalışır ve belirli bir monitörün hangi konumları kullanacağını siz seçersiniz. Birden fazla bölgeden çalışmak bir API için bir web sitesine göre daha önemlidir: bir CDN veya coğrafi yönlendirmeli bir yük dengeleyici tarafından önden karşılanan bir uç nokta bir bölgede tamamen sağlıklı, başka bir bölgede ise arızalı olabilir ve tek konumlu bir kontrol bunu göremez. Bu aynı zamanda sahte alarm kontrolünü de yönlendirir - bir kontrol noktası bir arıza bildirdiğinde, kontrol diğer bağımsız kontrol noktalarından tekrarlanır ve durum değişikliği yalnızca çoğunluk (kuorum) hemfikir olduğunda onaylanır; böylece bir veri merkezi ile sunucunuz arasındaki tek bir kararsız ağ yolu kimseyi çağırmaz.
Bir API izleme kontrolü başarısız olduğunda - uç nokta yanıt vermediği, beklenmedik bir içerik türü döndürdüğü veya doğrulama politikanızın gerektirdiği değerleri içermediği için - HostTracker; e-posta, SMS, sesli arama, webhook, Slack ve Telegram, Discord ile Viber gibi mesajlaşma uygulamaları dahil olmak üzere, yapılandırdığınız 9 bildirim kanalından biri üzerinden bir uyarı gönderir. Bu sayede ekibiniz, entegrasyon saatlerce sessizce arıza vermeye devam ettikten sonra bir destek talebiyle değil, sorun tespit edildiği anda bozuk veya kötüleşmiş bir API'den haberdar olur. Kontrol hem erişilebilirliği hem de içeriği değerlendirdiği için uyarı, sadece bir bağlantı sorununu değil, API'deki gerçek bir işlevsel sorunu yansıtır; bu da hem kaçırılan olayların hem de gereksiz gürültünün önüne geçmeye yardımcı olur.
HostTracker izlemeyi keşfetmeye devam edin
Çok adımlı ödeme ve giriş akışlarını simüle edin
Gerçek kullanıcı yolculuklarını modelleyin - giriş, arama, ödeme - ve akıştaki bir adım bozulduğu veya bir sayfa doğru yanıt vermeyi bıraktığı anda uyarı alın.
300'den fazla konumdan gerçek sayfa yükleme hızını izleyin
Sayfanıza gerçek bir tarayıcı ziyaretini otomatikleştirin ve belirlediğiniz politikaya göre yükleme süresini ölçün; böylece yavaşlamalar, ziyaretçiler ayrılmaya başlamadan önce ortaya çıkar.
HostTracker'ın tüm izleme özelliklerine göz atın
8 izleme türünün tümünü yan yana görün ve sitenize uygun kontrolleri bir araya getirin.
API Uç Noktalarınızı 7/24 İzleyin
Ücretsiz denemeye başlayın ve bir uç nokta yanlış durum döndürdüğünde, sözleşmesini bozduğunda veya yavaşladığında anında uyarılın.
HostTracker'ın web sitesi izleme hizmetinin bir parçası.