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 (aslında Heimdall'ın daha karizmatik olduğunu düşünüyorum), 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.

 Önceki yazıda , belirtildiği gibi, API Gateway sorununu 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" ve SOAP ile çalışırken "metotlar" belirtilir. Ben bu ayrımı gözetmeksizin hepsini "metot" olarak adlandıracağımı da belirtmek isterim.

Biz geliştiriciler de elbette böyle süper kahramanlara sahip olmak isterdik. Onlardan birini, yazılı API/Web Servisi izlemek ve dinlemek, hatta bir 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. Başımızın ağrımasını hiç istemeyiz ve neler olup bittiğini hiç bilmeyiz. Ancak elbette, gerçek hayatta bu süper güçlere sahip karizmatik 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. Şimdiye kadar herhangi bir sorun yaşamadık." diyen biri var mı? İtiraf edin, aklınızdan böyle bir şey geçti, değil mi? İşte bu yüzden önce, "API İzlemesi nedir? Gerçekten gerekli midir?" gibi sorularınıza olası senaryolar aracılığıyla cevap aramak istiyorum ve 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 (en azından biz öyle düşünüyoruz). Test Driven Development gibi yöntemleri geçiyorum. Programlamayı yeni öğreniyorsanız bile, yazdığınız kodu ilk olarak çalıştırır, birkaç farklı değer girer ve işinizi doğru şekilde yapıp yapmadığını görürsünüz. API/Web Servisi geliştirirken de durum farklı değildir. Detaylı ve tekrarlayan testler sistemli ve profesyonel yöntemlerle gerçekleştirilir veya en azından çalışan servise bir istek gönderilir ve erişilebilir olup olmadığı ve beklenen değeri döndürüp döndürmediği kontrol edilir. Testler yapıldıktan sonra da erişim adresi, kullanıcı bilgileri, dokümantasyonu gibi gerekli bilgiler müşterilere verilir ve API/Web Servisi 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 bir durum meydana gelir ve zaman zaman veya sürekli olarak bir müşteriye gönderdiği parametredeki verilerden kaynaklanan bir yanlışlıktan dolayı hata dönebilir.

2- Sunucunuz bir nedenle yavaşladı, bu nedenle API/Web Servisi algoritmik olarak iyi olsa da zaman aşımına uğruyor ve müşterileriniz sık sık hata alıyor.

3- API/Web Servisi, bir veya daha fazla Web Servisine istemci olur ve onlardan dönen verileri kullanır. Servisiniz çalışsa bile, istemci olduğunuz servislerden herhangi birine yanıt verememe veya zaman aşımına uğrama, servisinizin yanıt verememesi olarak dışarıya yansır.

4- Ağ ayarları değişmiş olabilir, bu nedenle servisiniz erişilemez hale gelebilir.

5- Sunucunuz bir şekilde hizmet veremez hale gelmiş olabilir. Bu durumda, API/Web Servisinizin ne kadar iyi çalıştığının bir önemi yoktur, çünkü müşterileriniz erişemez.

6- Diyelim ki API/Web Servisi bir veritabanından veri döndürüyor veya güncelliyor. Aynı veritabanını kullanan/besleyen başka bir uygulamanın dikkatsiz bir geliştiricisi tablo yapısını değiştirdiğinde, servisinizin bazı metotları kullanılamaz hale gelecektir. Bu durumun özellikle geliştirme aşamasındaki sistemler için beklediğinizden daha sık karşılaşılan bir sorun olduğunu söyleyebilirim.

Başka senaryolar da düşünebilirsiniz. Emin olabilirsiniz ki, bunlar gerçekleşebilecek durumlar ve Web Servisleri ile çalışan herkes zaman zaman bu veya benzeri durumlarla karşılaşır. Dikkat ederseniz, senaryoların çoğunun testlerle yakalanamayan durumlar olduğunu göreceksiniz. Diğer yandan, birçok Web Servisi için detaylı testler geliştirilmemiştir. Çoğu test, programcının Postman veya benzeri bir araçla birkaç deneme yapmasıyla sınırlıdır.

Şimdi, bu bölümün başında sorduğumuz soruları cevaplama zamanı geldi.

API İzlemesi nedir?

Bu soruya "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 (örneğin, e-posta veya SMS gönderme, alarm oluşturma) çalıştırarak yapılan işin adıdır." şeklinde cevap verebiliriz.

API İzlemesi gerçekten gerekli mi?

Öncelikle kendinize şu iki soruyu sorun:

• Başka kurumlar/şirketler veya kurumunuzun/şirketinizin içindeki diğer projeler veya 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 bir soruya "Evet" cevabı verdiyseniz, API İzlemesi gerekli ve hatta zorunludur. Çünkü, bir aksaklığın farkında değilseniz ve bir şekilde sorunu çözmezseniz, işin kritikliğine bağlı olarak üst düzey yönetim seviyelerine ulaşabilen epostalar, telefon çağrıları ve şikayetler yağmaya başlar. Bu tür durumların sık sık meydana gelmesi ve bir çözümün olmaması veya çok geç kalınması işleri aksatabilir ve güvenilirlik, prestij, müşteri veya para kaybına gibi sorunlara neden olabilir.

API İzlemesi nasıl yapılır?

Şimdi bunu nasıl yapılacağını açıklamanın zamanı geldi. Tanımı hatırlarsanız, işin iki kısmı bulunmaktadır. Bunlara bir göz atalım.

İzleme ve sorun giderme

İlk kısımda, izleme/dinleme ve herhangi bir sorunu tespit etme işlemi gerçekleştirilmektedir. Kullanılan yöntemleri yaklaşık olarak 3 grupta belirtebiliriz.

Aktif İzleme

Bu, izlenen API/Web Servisine düzenli aralıklarla önceden hazırlanmış istekler gönderme mantığıyla çalışır ve dönen yanıtları doğrulama mantığına dayanır. Bunun nasıl çalıştığını aşağıdaki resimle özetlemeye çalışalım:

Aktif izleme: 1- İstek gönder, 2- Dönen yanıtı, yanıt süresi, HTTP durum kodu ve mesaj içeriği/yapısı ile doğrulama

Eğer fark ettiyseniz, burada iki adım bulunmaktadır. İlk adımda bir istek göndereceğiz; ikinci adımda ise dönen yanıtı doğrulayacağız. Bu adımlara daha yakından bakalım:

Adım 1 — İstek gönderme

Şimdi sorular şunlar: İstek nereye gönderilecek? API/Web Servisi geliştirilirken bunun için özel bir geliştirme mi yapacağız? Eğer yapmadıysak veya servisi geliştirmemişsek, o servisi nasıl izleyeceğiz?

Belirli bir yönteme (örneğin, /healthCheck) istek gönderme: Bu yöntemde, API/Web Servisi geliştirilirken özel bir yöntem eklenir ve bu yönteme yapılan isteklere basit bir HTTP 200 (her şeyin iyi olduğu anlamına gelir) yanıtı döndürülür. Böylece, herhangi bir zamanda basit bir istek göndererek API/Web Servisinin çalışıp çalışmadığını öğrenebilirsiniz. Yöntem adı size bağlıdır. Genellikle /health, /healthcheck, /ok, /status, /check gibi isimler kullanılır.

Aktif izlemede en yaygın kullanılan yöntem olmasına rağmen, genellikle gözden kaçan bir nokta vardır: bu yöntem, API/Web Servisinin çalıştığını tespit edebilir ancak yöntemlerden herhangi birinin çökmesini tespit edemez. Örneğin, yukarıda listelenen senaryolardan 1, 3 veya 6 için bu yöntem yetersizdir.

Seçilen yöntemlere istek gönderme: En kritik yöntemler (istediğiniz tüm yöntemler) seçilir ve her biri için ayrı bir izleme tanımı yapılır. Bir izleme tanımı, belirli bir yönteme özel olarak gönderilecek istek mesajı ve yöntemin döndürmesi beklenen yanıta göre hazırlanan doğrulama yönteminden/yöntemlerinden oluşur. Bu yöntemle, Web Servisinin çalıştığı ancak bir veya daha fazla yöntemin sorunlu olduğu durumlar da yakalanabilir (örneğin, senaryolar 1, 3 veya 6 gibi). Her yönteme istek göndermenin performans kaybına neden olabileceğini düşünebilirsiniz. Ancak, birkaç dakikada bir veya her birkaç dakikada bir birkaç istek, hizmetlerinizin performansını çok fazla etkilemeyecektir. Öte yandan, olası bir hata anında yakalamak, sizleri çok daha ciddi sorunlardan kurtaracaktır. Belki de bu yöntemin en önemli noktası, veriyi güncelleyen yöntemlere gönderilecek isteklerin iyi düşünülmesidir.

Yöntemlere sırasıyla istek gönderme: Servisin beklendiği gibi çalışıp çalışmadığını test etmek için bazen birbirini takip eden birkaç belirli yöntemi arka arkaya çağırmanız ve/veya bir yöntem tarafından döndürülen değeri bir sonraki yönteme parametrelendirerek bir istek göndermeniz gerekebilir. Mantığa bağlı olarak, dönüşlerin sonunda, bir veya daha fazla seçilen adımdan sonra veya tüm akışın sonunda dönüşlerin doğrulanmaya çalışılması sağlanır. Tasarım ve uygulama açısından diğerlerine göre daha karmaşık ve daha az kullanılan bir yöntem olmasına rağmen, bazı özel senaryolar için mantıklı olabilir.

Adım 2 — Yanıt Doğrulama

İsteği gönderdiniz. Şimdi dönen yanıtı doğrulamanın zamanı geldi. Bunun için şu yaklaşık yöntemleri verebiliriz:

Zaman aşımı: Doğrulama yapılabilmesi için yanıtın dönmesi gerekmektedir. Eğer servis veya yöntem yanıt döndüremiyorsa, sonsuza kadar bekleyemeyiz. Bu, belirli bir süre içinde (örneğin, 30 saniye) bir yanıt dönmesi gerektiği anlamına gelir.

Zaman aşımını doğrularken hemen bir karar vermeye acele etmemenin faydalı olduğunu belirtmek isterim. Bazen gönderdiğimiz bir istek, örneğin, ağdaki geçici bir yavaşlama nedeniyle zaman aşımına uğrayabilir. İlk hatada hemen alarmlar çalmak (şimdi açıklayacağım) elbette bir seçenektir. Ancak sorun geçiciyse ve ikinci denemede düzeltiliyorsa, yanlış bir alarm ayarlamış olabilirsiniz. Sunucu çalışıyor, hizmetleri ve yöntemleri düzgün çalışıyor ve belki de bir anlık ağ yavaşlaması nedeniyle bir hata arayışına (belki de kendinizi) boşuna sokmuş olabilirsiniz. Ancak bir veya iki kez daha denemiş olsaydınız (tabii ki bir sınır olmalı, örneğin, en fazla 3 veya 5 kez deneyin), belki de sorun tekrar etmeyecek ve yanlış alarmlar olmayacaktı. Bu denemeler sonucunda aynı sorunun devam etmesi durumunda, alarmları en yüksek sesle çalın, servisinizde bir sorun var demektir!

HTTP Durum Kodu: Web Servis yanıtları bir HTTP kodu içerir -----(detaylar için buraya bakın). HTTP kodları, 200 "OK/Her şey yolunda", 400 "Kötü İstek", 404 "Sayfa Bulunamadı", 500 "İç Sunucu Hatası" gibi bazıları genel olarak anlaşılan ve yaygın olarak kullanılan 3 basamaklı sayılardır. Servisleriniz için yeni kodlar tanımlayarak onlara özel anlamlar atayabilir ve belgelerde ne olduğunu açıklayarak HTTP kodlarını müşterilere anlamlı mesajlar döndürmek için etkili bir şekilde kullanabilirsiniz.

Bu doğrulama yönteminde, dönen HTTP kodunun beklenen kod olup olmadığı kontrol edilir. Örneğin, isteğin döndürmesi beklenen kod 201 ise ancak 500 döndürüyorsa, o yöntemde bir sorun olduğu anlaşılır.

Yanıt İçeriği ve Yapısı: Bir istek gönderdiniz. Belirtilen zaman aşımı süresi dolmadan bir yanıt döndü. Dönen yanıtın HTTP kodu da beklediğiniz gibidir. Peki, dönen mesaj beklediğiniz içeriğe mi yoksa beklediğiniz yapıdaki bir mesaja mı sahip? Belki de farkında olmadığınız bir kod hatası vardır ve doğru HTTP kodunu döndürmekle birlikte yanlış içeriği döndürmektedir. Bu durum da kontrol edilmelidir. Bunun için, dönen mesajın tamamının veya bir kısmının beklediğiniz içerik veya yapıda olup olmadığı kontrol edilir.

Pasif İzleme

Bu yöntemi "dinleme" olarak adlandırmak daha doğru olabilir. Bu yöntem, sizin API/Web Servislerine istek göndermenize dayanmaz, ancak onlardan gelen istekleri bekler. İyi olan şey, bu yöntemde hizmet açamayan sistemleri de izleyebilmenizdir.

Çalışmanın mantığına bir örnek ile açıklamaya çalışayım. Diyelim ki bir yakınınız -belki de çocuğunuz- başka bir şehre/ülkeye gidiyor ve ona ulaşabileceğiniz bir telefon numarası yok. Bu durumda, bir haber almak istediğinizde, sadece diyemezsiniz ki “Bekle, onu arayayım. İyi mi? Neşeli mi? Sağlıklı mı?”. Bu durumda ne yapardınız? "Oğlum, her birkaç gün arayın ve nasıl olduğunuzu bize bildirin." diyebilirsiniz. Biraz telaşlı bir ebeveynseniz, sürekli telefon başında olabilirsiniz. Ben yatılı okula gittim. O zamanlar cep telefonları yoktu. Tam bir araç kutusu boyutunda araba telefonları vardı, ancak tabii ki bende yoktu ve işte tam olarak bu durumdu. 🙂

İşte pasif izleme böyle çalışır. İzlemek istediğiniz her sistem için özel bir Web Servisi veya yöntem oluşturursunuz (bu bir API/Web Servisi veya eski bir uygulama olabilir) ve izlediğiniz sisteme adresini verirsiniz ve bunun bu servise veya yönteme periyodik olarak istek göndermesini beklersiniz (örneğin, bunu cron + curl ile kolayca yapabilirsiniz). İstek sadece gelmeye devam ettiği sürece yeterlidir, hatta cevap vermenize bile gerek yoktur. İzlediğiniz sistem istek gönderebiliyorsa her şey yolundadır. Bu, sistemin düzgün çalıştığı anlamına gelir. Belirlediğiniz zaman diliminde istek gelmezse, izlediğiniz sistemde bir sorun olabileceğini düşünebilirsiniz.

Mesaj Trafiği Günlüklerini İzleme

API/Web Servislerinizi veya istemcilerinizi izlemenin bir yolu, gelen ve giden mesajların günlüklerini incelemektir. Bu yöntem, özünde bir izleme işi olduğundan, API Analitiği (ki bu benim bir sonraki makalemin konusu) ile ayrı düşünülmemelidir, ancak burada açıklamayı uygun buluyorum.

Hizmetlerin ne kadar iyi çalıştığını sürekli olarak günlükleri inceleyerek izlemek mümkündür. İstek/yanıt trafiğinin kayıtları, HTTP kodları, yanıt süresi, içerik, gönderen IP, kullanıcı, hata kodu, erişilen yöntem türü, mesaj boyutu gibi kriterler aracılığıyla periyodik olarak filtre edilebilir. Benzer kriterlerle filtrelenen değerler, önceden belirlenmiş eşik değerlerle karşılaştırılabilir. Böylece, beklenmedik durumlar yakalanabilir ve ilgili kişilere bildirilebilir.

Bildirim

Bir API/Web Servisi artık erişilemez durumdaysa, sunucuda bir sorun varsa, bir yöntem arızalandıysa veya dinlediğiniz eski bir uygulama artık size istek göndermiyorsa, bu durumu programlı olarak çözmek mümkün değildir. Bu durumda yapılacak en iyi şey, alarmı çalmak ve ilgili kişileri bir şekilde bilgilendirmektir.

İlk bakışta, bu oldukça basit görünüyor. Örneğin, daha önceden kayıt ettiğiniz adreslere bir e-posta gönderebilir veya telefon numaralarına bir SMS gönderebilirsiniz. Ancak, bu yeterli olmayabilir. Eğer bir Çağrı ve Alarm Yönetimi uygulaması kullanıyorsanız (örneğin, Opsgenie, PagerDuty), o uygulamada doğrudan bir alarm oluşturmak daha etkili olacaktır. Ayrıca, daha önceden kurum/şirket içinde benzer görevler için geliştirdiğiniz bir uygulamanın veritabanına bir kayıt yapabilirsiniz. Bunlardan biri veya hepsi yapılabilir. API İzleme mekanizmasını kuracaksanız, esnek bir yapı tasarlamak ve yeni bildirim yöntemlerinin kolayca eklenmesine dikkat etmek faydalı olacaktır.

Günlükler

Yukarıda bahsetmediğim başka bir konu -ancak gerçek hayatta çok yararlı bulacağınız- tüm izleme, doğrulama ve alarm günlüklerinin saklanması olacaktır. Çünkü sonuçta, bir sorunu rapor etmek yeterli değil, aynı zamanda kayıtları da tutmanız gerekecektir. Sorunun ne zaman meydana geldiği, hangi servisin hangi yönteminde olduğu, hangi isteğin gönderildiği, hangi yanıtın alındığı, neden yanıtın yanlış olduğu ve bu durum hakkında kimin hangi yöntemle bilgilendirildiği gibi bilgilere bakmak gerekecektir.

Günlüklerin çok hızlı bir şekilde artmasıyla ilgili yaygın bir sorun vardır. Bu nedenle, günlükler için bir saklama süresi belirlemek ve belirli bir süreden geçen kayıtları silmek faydalı olacaktır. Tabii ki, bu size kalmış bir şeydir. Yeterli disk alanınız varsa veya günlükleri silmek istemiyorsanız, bu size kalmış bir iştir.

Sonuç

 API İzleme, işin sorunsuz bir şekilde çalışması için birçok durumda vazgeçilmezdir. Ancak, burada bahsettiğim konularla tek tek uğraşmak için oturup kod yazmanızı ve bir API İzleme uygulaması oluşturmanızı önermiyorum. Çünkü o zaman bir API İzleme uygulaması yazmış olacaktınız. Eğer bu gerçek işiniz değilse, böyle büyük bir işe girişmek yerine mevcut API İzleme uygulamalarından birini almanı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 (henüz okumadıysanız, Önceki yazıya göz atmanızı öneririm). Onu ayrı bir uygulama olarak değil, platformunuzun bir parçası olarak kullanabilirsiniz. Böylece API Proxy tanımlarken, izleyicilerinizi kolayca tanımlayabilir ve 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.

Şimdi deneyimleyebilirsiniz: https://demo.apinizer.com