Yukarıdaki iki çizgi roman kahramanının, kıyafetli, havalı ve sert duruşlarından başka ortak noktaları nedir? Fazla uzatmadan: Batman Gotham’ı izler ve Heimdall Dokuz Diyarı izler ve dinler. Batman şüphesiz biraz daha popülerdir, Heimdall ise Thor’un gölgesinde kalmış gibi gözükür, ancak bunlar bizim durumumuz için önemsizdir. Önemli olan şey şudur: İkisi de olaya hem izleyerek hem de dinleyerek müdahale edebilmek için bu işlemi yaparlar.
API/Web Servisleri için bu izleme ve dinleme işlemini yaptığınızda ve bir sorun çıktığında sorumluları dövmek(!) yerine onları bilgilendirdiğinizde, bu API İzlemesi olarak adlandırılır.
API Gateway konusunu ele alırken, küçük farklılıklarına bakılmaksızın API ve Web Servis terimlerini aynı anlamda kullanacağımı belirtmek isterim. Ayrıca REST ile çalışırken hizmetin “uç noktalar”, SOAP ile çalışırken “metotlar” belirtilir; ben bu ayrımı gözetmeksizin hepsini “metot” olarak adlandıracağım.
Biz geliştiriciler de elbette böyle süper kahramanlara sahip olmak isterdik. Onlardan birini, yazdığımız API/Web Servisini izlemek ve dinlemek, hatta Web Servisi olmayan sistemleri bile izlemek için görevlendirebilirdik. Bir hata oluştuğunda sorunu ele alsın, çözsün ve her şeyi rayında tutsun. Ancak gerçek hayatta bu süper güçlere sahip kahramanlar yok; API dünyasında da böyle bir şey yok. Bu nedenle, API İzlemesi için kahramanların gelmesini beklemek yerine, bunu kendimiz yapmalıyız.
“Şimdi, neden böyle bir izleme ve dinleme ihtiyacı olacak ki? Sonuçta kodu yazdık, test ettik, yayınladık ve müşteriler bir süredir bunu kullanıyorlar.” diyen biri var mı? İşte bu yüzden önce “API İzlemesi nedir? Gerçekten gerekli midir?” gibi sorulara olası senaryolar aracılığıyla cevap aramak, ardından “Bunu nasıl yapabiliriz?” diyenlere birkaç yöntem anlatmak istiyorum.
API İzlemesi nedir? Gerçekten gerekli mi?
Her geliştirici yazdığı kodu önce test eder. API/Web Servisi geliştirirken de durum farklı değildir: detaylı testler yapılır veya en azından çalışan servise bir istek gönderilir, erişilebilir olup olmadığı ve beklenen değeri döndürüp döndürmediği kontrol edilir. Testler yapıldıktan sonra erişim adresi, kullanıcı bilgileri, dokümantasyonu gibi gerekli bilgiler müşterilere verilir ve servis hizmete alınır. Peki, tüm bu testlerden sonra açtığımız servisleri izlemenin ne anlamı var? Aklıma ilk gelen birkaç senaryoyu listeleyeyim:- Testlerde öngörülemeyen durum: Zaman zaman veya sürekli olarak bir müşterinin gönderdiği parametredeki verilerden kaynaklanan bir yanlışlıktan dolayı hata dönebilir.
- Sunucu yavaşlaması: Sunucu bir nedenle yavaşladığında, API/Web Servisi algoritmik olarak iyi olsa da zaman aşımına uğruyor ve müşteriler sık sık hata alıyor.
- Bağımlı servisler: Servisiniz bir veya daha fazla Web Servisine istemci olur. İstemci olduğunuz servislerden herhangi birinin yanıt verememesi veya zaman aşımına uğraması, sizin servisinizin de yanıt verememesi olarak dışarıya yansır.
- Ağ ayarları: Ağ ayarları değişmiş olabilir; servisiniz erişilemez hale gelebilir.
- Sunucu arızası: Sunucu bir şekilde hizmet veremez hale gelmiş olabilir. Bu durumda API/Web Servisinizin ne kadar iyi çalıştığının bir önemi yoktur.
- Veritabanı/ortak kaynak değişikliği: Aynı veritabanını kullanan başka bir uygulamanın tablo yapısını değiştirmesi, servisinizin bazı metotlarını kullanılamaz hale getirebilir.
API İzlemesi nedir?
API/Web Servislerinin izlenmesi, sürekli olarak beklenen yanıtları ve süreleri döndürüp döndürmediklerini kontrol etmek ve herhangi bir aksaklık durumunda ilgili tarafları bilgilendirmek için önceden tanımlanmış görevleri (e-posta, SMS, alarm oluşturma vb.) çalıştırarak yapılan işin adıdır.API İzlemesi gerçekten gerekli mi?
Önce kendinize şu soruları sorun:- Başka kurumlar/şirketler veya kurumunuzun içindeki diğer projeler/ekipler, API/Web Servislerinizi kullanıyor mu?
- API/Web Servisleriniz kritik mi?
- Kesinti, zaman aşımı veya zaman zaman yanlış yanıt dönme gibi herhangi bir sorun var mı?
API İzlemesi nasıl yapılır?
Tanımda iki kısım vardır: izleme/sorun tespiti ve bildirim. Önce izleme yöntemlerine bakalım.İzleme ve sorun giderme
İzleme/dinleme ve sorun tespiti yaklaşık olarak 3 grupta toplanabilir.Aktif İzleme
İzlenen API/Web Servisine düzenli aralıklarla önceden hazırlanmış istekler gönderilir ve dönen yanıtlar doğrulama mantığına göre kontrol edilir.
Adım 1 — İstek gönderme
- Belirli bir yönteme istek (örn. /healthCheck): Servise özel bir metot eklenir (örn.
/health,/healthcheck,/ok,/status) ve basit bir HTTP 200 döndürülür. Servisin çalışıp çalışmadığını anlarsınız. Ancak tek bir metotun çökmesini (senaryo 1, 3 veya 6) tespit edemez. - Seçilen yöntemlere istek: En kritik metotlar seçilir, her biri için ayrı izleme tanımı (istek mesajı + beklenen yanıta göre doğrulama) yapılır. Bir veya daha fazla yöntemin sorunlu olduğu durumlar da yakalanır. Birkaç dakikada bir birkaç istek performansı ciddi etkilemez; olası hatayı anında yakalamak ise çok daha değerlidir. Veriyi güncelleyen yöntemlere gönderilecek isteklerin iyi düşünülmesi önemlidir.
- Yöntemlere sırasıyla istek: Birbirini takip eden metotları arka arkaya çağırıp, bir yöntemin dönüşünü sonrakine parametre olarak vererek akışı test etmek. Daha karmaşık ve daha az kullanılan; bazı özel senaryolar için mantıklı olabilir.
- Zaman aşımı: Belirli bir süre (örn. 30 saniye) içinde yanıt dönmesi gerekir. İlk hatada hemen alarm çalmak bir seçenektir; ancak geçici ağ yavaşlaması gibi durumlarda birkaç deneme (örn. en fazla 3–5) yapıp aynı sorun devam ediyorsa alarm vermek, yanlış alarmları azaltır.
- HTTP durum kodu: Dönen kodun beklenen kod olup olmadığı kontrol edilir (200, 400, 404, 500 vb.). Beklenen 201 iken 500 dönüyorsa o yöntemde sorun var demektir.
- Yanıt içeriği ve yapısı: HTTP kodu doğru olsa bile dönen mesajın beklenen içerik/yapıda olup olmadığı kontrol edilir; böylece doğru kodu döndürüp yanlış içerik veren hatalar da yakalanır.
Pasif İzleme
Bu yöntemi “dinleme” olarak adlandırmak daha doğrudur. Siz API/Web Servislerine istek göndermezsiniz; onlardan gelen istekleri beklersiniz. İyi tarafı: hizmet açamayan sistemleri de izleyebilmenizdir. Çalışma mantığı: İzlemek istediğiniz her sistem için özel bir Web Servisi veya metot oluşturursunuz ve izlediğiniz sisteme bu adresi verirsiniz; sistemin bu servise periyodik olarak istek göndermesini beklersiniz (örn. cron + curl). İstek geldiği sürece sistemin çalıştığı anlaşılır; cevap vermenize gerek bile olmayabilir. Belirlenen sürede istek gelmezse, izlediğiniz sistemde sorun olabileceği düşünülür.
Mesaj trafiği günlüklerini izleme
Gelen ve giden mesajların günlükleri incelenerek API/Web Servislerinizi veya istemcilerinizi izleyebilirsiniz. İstek/yanıt trafiği kayıtları, HTTP kodları, yanıt süresi, içerik, gönderen IP, kullanıcı, hata kodu, erişilen metot, mesaj boyutu gibi kriterlerle filtrelenebilir; önceden belirlenen eşik değerlerle karşılaştırılarak beklenmedik durumlar yakalanıp ilgili kişilere bildirilebilir.
Bildirim
Servis erişilemezse, sunucuda sorun varsa, bir yöntem arızalandıysa veya pasif izlediğiniz uygulama artık istek göndermiyorsa, bunu programlı olarak çözmek mümkün olmayabilir. Yapılacak en iyi şey alarmı çalmak ve ilgili kişileri bilgilendirmektir.
E-posta veya SMS göndermek tek başına yeterli olmayabilir. Opsgenie, PagerDuty gibi çağrı ve alarm yönetimi uygulamalarında doğrudan alarm oluşturmak daha etkili olabilir. Kurum içi bir uygulamanın veritabanına kayıt yapmak da mümkündür. API İzleme mekanizmasını kurarken esnek bir yapı tasarlayıp yeni bildirim yöntemlerinin kolayca eklenmesine dikkat etmek faydalıdır.