To monitor, or not to monitor, that is the question

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:

1. 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.
2. 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.
3. 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.
4. Ağ ayarları: Ağ ayarları değişmiş olabilir; servisiniz erişilemez hale gelebilir.
5. 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.
6. 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.

Başka senaryolar da düşünebilirsiniz. Bunların çoğu testlerle yakalanamayan durumlardır. Birçok Web Servisi için detaylı testler de geliştirilmemiştir; çoğu test Postman veya benzeri bir araçla yapılan birkaç denemeyle sınırlıdır.

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ı?

Herhangi birine "Evet" cevabı verdiyseniz, API İzlemesi gerekli ve hatta zorunludur. Bir aksaklığın farkında değilseniz ve sorunu çözmezseniz, işin kritikliğine bağlı olarak üst düzey yönetime ulaşan e-postalar, telefon çağrıları ve şikayetler başlar; güvenilirlik, prestij veya müşteri kaybına yol açabilir.

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.

Adım 2 — Yanıt doğrulama

• 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.

Günlükler

Tüm izleme, doğrulama ve alarm günlüklerinin saklanması pratikte çok işe yarar. Sorunun ne zaman, hangi serviste hangi yöntemde meydana geldiği, hangi isteğin gönderildiği, hangi yanıtın alındığı, neden yanlış sayıldığı ve kimin hangi yöntemle bilgilendirildiği gibi bilgilere sonradan bakmak gerekebilir. Günlükler hızla artabileceği için bir saklama süresi belirleyip belirli bir süreyi geçen kayıtları silmek faydalı olabilir; disk alanı ve politikanıza göre karar verebilirsiniz.

Sonuç

API İzleme, işin sorunsuz çalışması için birçok durumda vazgeçilmezdir. Ancak burada bahsettiğim konularla tek tek uğraşmak için sıfırdan bir API İzleme uygulaması yazmanızı önermiyorum. Bu gerçek işiniz değilse, mevcut API İzleme çözümlerinden birini kullanmanız daha verimli ve ucuz olacaktır.

Apinizer ekibi olarak bizim de bir API İzleme ürünümüz var. Apinizer API Monitor'ün en iyi yönlerinden biri, Apinizer API Gateway ile doğrudan entegrasyonudur. Onu ayrı bir uygulama olarak değil, platformunuzun bir parçası olarak kullanabilirsiniz: API Proxy tanımlarken izleyicilerinizi kolayca tanımlayıp yönetebilir, oluşturduğunuz tanımları hemen izleme tanımlarına dönüştürebilir ve analitik için hazırladığınız günlük sorgularını izleme amaçları için kullanabilirsiniz.

Deneyimleyebilirsiniz: https://demo.apinizer.com