To monitor, or not to monitor, that is the question.
Yukarıdaki iki çizgi roman kahramanının kostümlü, havalı ve sert duruşları dışındaki ortak noktası nedir?
Fazla uzatmadan söyleyeyim: Batman Gotham’ı, Heimdall da 9 diyarı izliyor ve dinliyor. Batman şüphesiz biraz daha popüler, Heimdall ise biraz Thor’un gölgesinde kalmış (aslında bence daha karizmatik) ama bizim konumuz açısından bunlar önemsiz. Önemli olan şu: ikisi de İZLİYOR ve DİNLİYOR ki, bir sorun çıkarsa hemen müdahale edebilsinler.
Bu izleme ve dinleme işini API/Web Servisler için yaptığınızda, bir de sorun varsa gidip sorumluları pataklamak (!) yerine birilerine haber verdiğinizde buna API Monitoring deniyor.
Bir önceki yazımda API Gateway konusunu ele alırken de belirttiğim gibi bu yazıda da API ve Web Servis terimlerini aralarındaki küçük farkları umursamadan aynı anlamda kullanacağım. Ayrıca, REST ile çalışılırken servisin “endpoint”lerinden, SOAP ile çalışılırken ise “metod”larından bahsedilir. Aşağıda hepsine metod diyeceğimi de belirteyim.
Gönül ister ki biz geliştiriciler için de böyle süper kahramanlar olsun; bir tanesi de her yazılan API/Web Servisi, hatta Web Servisi bile olmayan sistemleri izlesin, dinlesin. Bir hata durumunda konuya el atsın, sorunu çözsün, herşey yolunda gitsin, hiç başımız ağrımasın ve hatta ne olduğundan haberimiz bile olmasın. Ama tabi gerçek hayatta bu süper güçlere sahip karizmatik kahramanlar olmadığı gibi, API dünyasında da yok. Dolayısıyla API Monitoring işini kahramanlardan beklemek yerine bizim yapmamız gerekiyor.
“İyi de neden ihtiyaç olsun ki böyle bir izleme ve dinleme işine? Sonuçta kodları yazdık, test ettik, canlıya aldık ve istemciler de bir süredir zaten kullanıyorlar, şu ana kadar bir sorun yaşamadık.” diyenler var mı? İtiraf edin, içinizden buna benzer bir şey geçti değil mi? İşte bu yüzden, önce “API Monitoring nedir? Gerçekten gerekli midir?” sorularına muhtemel senaryolar üzerinden yanıt arayıp, sonra da “Bunu nasıl yapabiliriz?” diyenler için birkaç yöntem anlatmak istiyorum.
API Monitoring nedir? Gerçekten gerekli mi?
Her geliştirici yazdığı kodu önce bir test eder. TDD gibi yöntemleri geçiyorum, programlamayı yeni öğreniyor bile olsanız, yazdığınız kodu önce bir çalıştırır, birkaç farklı değer girip çalışıyor mu, işini doğru yapıyor mu diye bir bakarsınız. API/Web Servis geliştirirken de durum farklı değildir. Sistematik ve profesyonel yöntemlerle detaylı ve tekrarlı testler yapılır ya da en azından çalıştırılan servise bir istek gönderilip erişilebiliyor mu, beklenen değeri döndürüyor mu diye bir kontrol edilir. Testler yapıldıktan sonra istemcilere erişim adresi, kullanıcı bilgileri, dokümantasyon gibi gerekli bilgiler verilerek API/Web Servis hizmete açılır.
Peki bunca testten sonra açtığımız servisleri izlemeye ne gerek var?
Hemen ilk akla gelen birkaç senaryoyu listeliyorum:
1- Testlerde öngöremediğiniz bir durum oluşuyor ve sadece belirli bir istemciye, gönderdiği parametrenin içerdiği veriden dolayı zaman zaman ya da belki sürekli hata dönüyor olabilir.
2- Sunucunuz bir nedenle yavaşlamıştır, bunun sonucunda da API/Web Servis algoritmik olarak sorunsuz olsa bile zaman aşımına uğruyor ve istemcileriniz sık sık hata alıyordur.
3- API/Web Servis başka bir ya da daha fazla Web Servise istemci oluyor, onlardan dönen verileri kullanıyordur. Sizin servisiniz çalışıyor olsa bile istemci olduğunuz servislerden herhangi birinin yanıt dönememesi ya da zaman aşımına uğraması, dışarıya sizin servisin yanıt dönememesi olarak yansıyordur.
4- Network ayarları değiştirilmiş, bu nedenle servisiniz artık erişilemez hale gelmiş olabilir.
5- Sunucunuz bir şekilde hizmet veremez hale gelmiş olabilir. Bu durumda API/Web Servisinizin ne kadar başarılı çalıştığının bir önemi kalmaz, çünkü istemcileriniz ona erişemez.
6- API/Web Servis bir veri tabanındaki verileri dönüyor ya da güncelliyor diyelim. Aynı veri tabanını kullanan/besleyen başka bir uygulamanın özensiz geliştiricisi tablo yapısını değiştirdiği anda sizin servisin bazı metodları çakılmaya başlayabilir. Özellikle geliştirmesi devam eden sistemlerde beklediğinizden daha sık ortaya çıkan bir sorun olduğunu söyleyebilirim.
Başka senaryolar da düşünebilirsiniz. Emin olun bunlar gerçekten oluşabilecek durumlar ve Web Servisler ile çalışan herkes zaman zaman bunlar ya da benzerleriyle karşılaşıyor. Dikkat ederseniz, maddelerin çoğu da testler ile yakalanamayacak durumlardan oluşuyor. Öte yandan, birçok Web Servis için o kadar detaylı test geliştirilmediğinden de emin olabilirsiniz. Çoğu test, programcının Postman gibi bir araçla birkaç deneme yapmasından ibaret.
Şimdi gelelim bölümün başında sorduğumuz soruların yanıtlarına.
“API Monitoring nedir?”
Bu soruya; “API/Web Servisleri izleyen, beklenen sürelerde beklenen yanıtları dönüp dönmediklerini sürekli kontrol eden ve herhangi bir aksaklık durumunda önceden tanımlanmış görevleri çalıştırarak (e-posta göndermek, SMS atmak, alarm oluşturmak gibi) ilgililere haber verme işine verilen addır.” şeklinde net bir yanıt verebiliriz.
“API Monitoring gerçekten gerekli midir?”
Önce kendinize şu soruları sorun:
· API/Web Servislerinizi başka kurum/firmalar ya da sizin kurum/firma içindeki başka projeler ya da ekipler kullanıyor mu?
· API/Web Servisleriniz kritik mi?
· Zaman zaman oluşabilecek durma, zaman aşımına uğrama ya da hatalı yanıt dönme gibi durumlar sorun olur mu?
Eğer bu sorulardan herhangi birine “Evet.” diyorsanız API Monitoring gereklidir, hatta zorunludur. Çünkü herhangi bir aksaklıktan hemen haberdar olup bir şekilde sorunu çözmezseniz, işin kritiklik seviyesine bağlı olarak e-posta ve telefonlar gelmeye, üst yönetim kademelerine kadar ulaşabilen şikayetler yağmaya başlar. Böyle durumların sık yaşanması ve çözüm üretilmiyor ya da çok geç kalınıyor olması, işlerin aksamasına, buna bağlı olarak da güvenilirlik, prestij, müşteri ya da para kayıplarına neden olabilir.
API Monitoring nasıl yapılır?
Şimdi sıra geldi bu işin nasıl yapılacağına. Tanımı hatırlarsanız, işin iki bölümü var. Bunlara bakalım.
1. Bölüm: İzleme ve sorun tespiti
Birinci bölümde izleme/dinleme ve herhangi bir sorun varsa bunu tespit etme işi yapılıyor. Kullanılan yöntemleri kabaca 3 grupta toplayabiliriz.
Aktif İzleme
İzlenecek API/Web Servise belirli aralıklarla önceden hazırlanmış istekler gönderip, dönen yanıtların doğrulanması mantığıyla çalışır. Şu görsel ile özetlemeye çalıştım:
Dikkat ederseniz burada iki adım var. İlk adımda bir istek göndereceğiz, ikinci adımda da dönen yanıtı doğrulayacağız. Şimdi bu adımlara biraz yakından bakalım:
1. Adım — İstek gönderme
Şimdi sorular şunlar: İsteği nereye göndereceğiz? API/Web Servis geliştirirken buna özel geliştirme mi yapacağız? Eğer yapmamışsak ya da servisi biz geliştirmemişsek o servisi nasıl izleyeceğiz?
Önceden bu amaçla hazırlanmış belirli bir metoda (örn. /healthCheck) istek gönderilmesi: Bu yöntemde API/Web Servis geliştirilirken özel bir metod eklenir ve bu metoda gelen isteklere basitçe HTTP 200 (“herşey yolunda” anlamında) yanıtı döndürülür. Böylece API/Web Servisin ayakta olup olmadığını istediğiniz zaman, basit bir istek göndererek öğrenebilirsiniz. Metod adı size kalmış. Genelde /health, /healthcheck, /ok, /status, /check gibi adlar kullanılır.
Aktif izlemede en yaygın kullanılan yöntem olsa da, genellikle gözden kaçırılan bir nokta var: bu yöntemle yalnızca API/Web Servisin ayakta olduğunu yakalanabilir, ancak herhangi bir metodunun çakılması durumu yakalanamaz. Örneğin yukarıda listelediğim senaryolardan 1, 3 ya da 6. senaryolar için bu yöntem yetersizdir.
Seçilen metodlara istek gönderilmesi: En kritik metodlar (istiyorsanız bütün metodlar) seçilerek herbirisi için ayrı bir izleme tanımı yapılır. Bir izleme tanımı, o metoda özel olarak gönderilecek istek mesajını ve metodun döndürmesi beklenen yanıta göre hazırlanmış doğrulama yöntem(ler)inden oluşur. Bu yöntemle, Web Servisin ayakta olduğu ama bir ya da daha fazla metodun sorunlu olduğu durumlar da yakalanabilir (1, 3 ya da 6. senaryolar gibi). Burada aklınıza her metoda istek göndermenin performans kaybına neden olabileceği gelebilir. Ancak dakikada ya da birkaç dakikada bir gelecek birkaç istek, servislerinizin performansına pek de etki etmeyecektir. Öte yandan muhtemel bir aksaklığın hemen yakalanması sizi çok daha ciddi sorunlardan kurtaracaktır. Bu yöntemde belki en önemli nokta, veri güncellemesi yapan metodlara gönderilecek isteklerin iyi düşünülmesi zorunluluğudur.
Metodlara sırayla istek gönderilmesi: Bazen servisin beklendiği gibi çalışıp çalışmadığını sınamak için belirli birkaç metodu arka arkaya sırayla çağırmanız ve/veya bir metodun döndürdüğü değeri bir sonraki metoda parametre yaparak istek göndermeniz gerekebilir. Kurulan mantığa bağlı olarak dönen yanıtlar her adımın sonunda, seçilen bir ya da daha fazla adımın sonunda ya da akışın tamamının sonunda doğrulanmaya çalışılır. Tasarlama ve uygulama açısından diğerlerinden daha karmaşık ve daha az kullanılan bir yöntem olsa da bazı özel senaryolar için anlamlı olabilir.
2. Adım — Yanıt Doğrulama
İsteği gönderdiniz. Şimdi sıra dönen yanıtı doğrulamakta. Bunun için de kabaca aşağıdaki yöntemler var:
Zaman Aşımı (timeout): Doğrulamanın yapılabilmesi için önce yanıtın dönmesi lazım. Eğer servis ya da metod yanıt dönemiyorsa sonsuza kadar bekleyecek halimiz yok. Demek ki belirli bir süre (örneğin 30 saniye) içerisinde bir yanıt dönmesi lazım.
Zaman aşımı doğrulaması yaparken karar vermekte acele etmemekte fayda olduğuna dikkat çekmek istiyorum. Bazen gönderdiğimiz bir istek, örneğin ağdaki geçici bir yavaşlamadan dolayı zaman aşımına uğrayabilir. İlk hatada hemen alarmları çalmak (birazdan anlatacağım) elbette bir seçenek. Ama sorun geçiciyse ve ikinci denemede düzelecekse yanlış alarm vermiş de olabilirsiniz. Sunucu ayaktadır, servis ve metodları düzgün çalışıyordur ve anlık bir ağ yavaşlamasından dolayı birilerini (belki kendinizi) sonuçsuz bir hata arama çalışmasının içine sokmuş olabilirsiniz. Oysa bir iki kez daha denemiş (elbette bir sınırı olmalı, örneğin en fazla 3 ya da 5 kez deneyin) olsaydınız belki sorun tekrarlamayacaktı ve yanlış alarm oluşmayacaktı. Eğer bu denemelerin sonucunda hala aynı sorun devam ediyorsa alarmları gönül rahatlığıyla en yüksek ses ile çalın zaten; servisinizde bir sorun var!
HTTP Durum Kodu: Web Servis yanıtları bir HTTP kodu içerir (detay için şuraya bakabilirsiniz). HTTP kodları kabaca, bazıları yaygın kullanılan ve herkesçe aynı şekilde anlaşılan 3 haneli sayılardır. Örneğin 200 kodu “Tamam/Herşey Yolunda (OK)”, 400 kodu “Kötü İstek (Bad Request)”, 404 kodu “Sayfa Bulunamadı (Not Found)”, 500 kodu “Sunucu Hatası (Internal Server Error)” anlamına gelir. Servisleriniz için yeni kodlar tanımlayıp, bunlara size özel anlamlar yükleyip, dokümantasyonda ne olduğunu açıklayarak HTTP kodlarını istemcilere anlamlı mesajlar dönmek için etkin bir şekilde kullanabilirsiniz.
Bu doğrulama yönteminde; dönen HTTP kodunun beklenen kod olup olmadığı kontrol edilir. Örneğin istek gönderilen metodun 201 kodunu dönmesi beklenirken 500 dönerse, o metod ile ilgili bir sorun olduğunu anlaşılır.
Yanıt İçeriği ve Yapısı: Bir istek gönderdiniz. Belirlenen zaman aşımı süresi dolmadan bir yanıt döndü. Dönen yanıtın HTTP kodu da beklediğiniz gibi. Peki dönen mesaj, gerçekten beklediğiniz içeriğe sahip ya da beklediğiniz yapıda bir mesaj mı? Belki kodda farkında olmadığınız bir bug var ve doğru HTTP kodunu ama yanlış içeriği döndüyor. İşte bu durumun da kontrol edilmesi gerekir. Bunun için, mesajın tamamı ya da belirli bir kısmının sizin beklediğiniz içerik ya da yapıda olup olmadığına bakılır.
Pasif İzleme
Aslında buna “dinleme” demek daha doğru olabilir. Bu yöntem, sizin API/Web Servislere istek göndermenize değil, onlardan istek gelmesini beklemenize dayanır. Güzel tarafı, bu yöntemde herhangi bir servis aç(a)mayan sistemleri de izleyebilirsiniz.
İşin mantığını bir örnekle açıklamaya çalışayım. Diyelim ki bir yakınınız, belki çocuğunuz başka bir şehre/ülkeye gidiyor ve ona ulaşabileceğiniz bir telefon numarası yok. Yani canınız istediğinde “Dur bir arayayım. İyi mi? Keyfi yerinde mi? Sağlıklı mı?” diyemiyorsunuz. Bu durumda ne yaparsınız? “Evladım, birkaç günde bir ara da bizi haberdar et.” dersiniz. Biraz telaşlı bir ebeveynseniz bir kulağınız sürekli telefonda olabilir. Ben liseyi yatılı okudum. Henüz cep telefonları yoktu. Takım sandığı büyüklüğünde araç telefonları vardı ama haliyle bende yoktu ve durum tam olarak buydu. :)
Pasif izleme aynen böyle çalışır. İzlemek istediğiniz her sistem (bu bir API/Web Servis ya da legacy uygulama olabilir) için özel bir Web Servis ya da metod oluşturursunuz ve o bunun adresini sadece izleyeceğiniz sisteme verir ve bu servise ya da metoda belirli aralıklarla istek göndermesini (örneğin cron + curl ile bu iş kolayca yapılabilir) beklersiniz. İsteğin gelmeye devam etmesi yeterlidir, yanıta vermenize bile gerek yoktur. İzlediğiniz sistem istek gönderebildiği sürece herşey yolunda, sistem düzgün çalışıyor demektir. Eğer belirlediğiniz zaman aralığında istek gelmezse, izlediğiniz sistemle ilgili bir sorun olduğu sonucuna varabilirsiniz.
Mesaj Trafiği Loglarını İzleme
Sunduğunuz API/Web Servisleri ya da istemcilerinizi izlemenin bir yolu da gelip giden mesajların loglarını incelemektir. Aslında bu yöntemi API Analytics’ten (bir sonraki yazımın konusu) bağımsız düşünmemek lazım ama özünde bir izleme işi olduğu için burada anlatmayı doğru buluyorum.
Loglar sürekli incelenerek servislerin ne kadar sağlıklı çalıştığına ilişkin bir izleme yapmak mümkündür. İstek/yanıt trafiğine ilişkin kayıtlar periyodik olarak HTTP kodları, yanıt süresi, içerik, gönderen IP, kullanıcı, hata kodu, erişilen metod tipi, mesaj büyüklüğü ve benzeri kriterler üzerinden filtrelenerek bulunan değerler önceden belirlenen eşik değerleri (threshold) ile karşılaştırılabilir. Böylece beklenmeyen durumların yakalanması ve ilgili kişilerin uyarılması sağlanabilir.
2. Bölüm: Haber verme
Sunucuda sorun olduğu için bir API/Web Servise artık erişilemiyor, bir metod hatalı çalışıyor ya da dinlediğiniz eski bir uygulama artık size istek göndermiyorsa, programatik olarak çözüm üretmek pek mümkün değildir. Bu durumda yapılacak en iyi şey alarm çanlarını çalmak ve ilgili kişilere bir şekilde haber vermektir.
İlk bakışta bu iş gayet basit. Örneğin önceden kaydettiğiniz adreslere bir e-posta gönderebilir ya da telefon numaralarına SMS atabilirsiniz. Ancak bu yeterli olmayabilir. Eğer bir Çağrı ve Alarm Yönetimi uygulaması kullanıyorsanız (örn: Opsgenie, PagerDuty), doğrudan o uygulamada bir alarm oluşturmak daha etkin olacaktır. Kurum/firma içinde benzer işler için önceden geliştirmiş olduğunuz bir uygulamanın veri tabanına bir kayıt da düşebilirsiniz. Bunların herhangi biri ya da hepsi yapılabilir. Eğer API Monitoring mekanizmasını siz kuracaksanız, esnek bir yapı tasarlayıp yeni haber verme yöntemlerinin kolayca eklenebilir olmasına dikkat etmekte fayda var.
3. Bölüm: Loglar
Yukarıda bahsetmediğim ama gerçek hayatta çok faydasını göreceğiniz bir başka konu da bütün izleme, doğrulama ve alarm loglarının saklanması olacaktır. Çünkü sonuçta bir sorunu haber vermeniz yetmez, kayıtlarını da tutmanız gerekir. O sorun ne zaman, hangi servisin hangi metodunda olmuş, ne istek gönderilmiş, ne yanıt alınmış, yanıt neden hatalıymış, bu durum kimlere hangi yöntemle haber verilmiş gibi bilgilere bakılması gerekecektir.
Logların bir başka çok önemli faydası da, özellikle sorun sizden kaynaklanmıyor da sizin istemci olduğunuz başka bir servisten kaynaklanıyorsa bunu ispatlamanıza yardım etmesi. Sorumluluğun sizde değil de bir başkasında olduğunu bilmek, hiç olmazsa stresinizi azaltacaktır. :)
Loglarla ilgili genel sorun, kayıt sayısının çok hızlı artması. Dolayısıyla loglara bir yaşam süresi (retention) belirleyip, üzerinden belirli bir süre geçmiş olan kayıtları silmekte fayda var. Burası tabi ki size kalmış. Disk alanınız yeterliyse ya da logları silmek istemiyorsanız o sizin bileceğiniz iş.
Sonuç
API Monitoring yapılan işin düzgün olması, sağlıklı çalışması açısından birçok durumda olmazsa olmazdır. Ancak oturup kod yazarak burada değindiğim konuları tek tek ele almaya kalkmanızı önermem. Çünkü o zaman bir API Monitor uygulaması yazmış olursunuz. Eğer gerçek işiniz bu değilse böyle büyük bir işe kalkışmak yerine, var olan API Monitoring uygulamalarından birisini almak daha verimli ve daha ucuz olacaktır.
Apinizer ekibi olarak bizim de bir API Monitoring ürünümüz var. Apinizer API Monitor ürününün en güzel yanlarının başında Apinizer API Gateway (henüz okumadıysanız önceki yazıma bir göz atmanızı öneririm) ile doğrudan entegre çalışması geliyor. Fazladan ayrı bir uygulama gibi değil, platformunuzun bir parçası olarak kullanabiliyorsunuz. Böylece API Proxy tanımlarken kolayca monitörlerinizi de tanımlayıp yönetebiliyor, test için oluşturduğunuz tanımları hemen monitör tanımlarına dönüştürebiliyor, analytics için hazırladığınız log sorgularını izleme amaçlı kullanabiliyorsunuz.
Denemek isteyenler için: https://demo.apinizer.com
