Uygulamalarımızda biz uyurken bile ne olaylar yaşandığını öğrenebiliriz. Bazı uygulamalar geliştirerek ya da servisler kullanarak 7×24 sağlıklı şekilde kullanılabilir olduğumuzuda takip edebilir, olası bir aksilikte anında kurduğumuz alarmlar sayesinde haberimiz olmasını sağlayabiliriz. Hatta nerede performans sorunları yaşıyoruz onu bile görebiliriz… Peki ya bunlar nasıl mümkün oluyor ve yapılıyor?
Bir uygulamanın (bu yazıda uygulama olarak bir web projesine atıfta bulunuyor olacağız) tam olarak izlenebilir olması noktasında yazılım katmanında yapılması gereken önemli işler vardır. Sizde mevcut projelerinizde aşağıdaki adımları kontrol ederek eksik olduğunu tespit ettiğiniz noktalarda iyileştirme yapabilir ya da yeni projenizde bu hususları dikkate alarak daha izlenebilir ürünler ortaya çıkartabilirsiniz.
Log (Günlük) Yönetimi ve Kayıt Altına Alınması
Eğer log kelimesi size biraz da olsa yabancı geliyorsa o zaman kesinlike Log (Kütük) Kayıtları Nedir? makalesini okumanızı tavsiye ederim.
Öncelikle uygulama içerisinde doğru ve standardize edilmiş bir log yönetimi altyapısı oluşturmalıyız. Sonrasında uygulama içerisinde üretilen olay/hata/performans loglarını anlamlandırıp mümkün olduğunca bunların gruplanabilir olmasını sağlamamız gerekir. Ki böylece bu kayıtlar üzerinden alarmlar oluşturabilelim ya da bir alarm aldığımızda detaylı inceleme sağlamaya gerek kalmadan olayın nerede oluştuğunu görüp, aksiyon önceliğini hızlıca belirleyebilelim. (Burada alınacak aksiyonlar bazen 4 Key Metrics (bkz: cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance) içerisindeki Time to Restore Service {TRS} etkileyebilir.) Uygulamanın ürettiği tüm logları (eğer validation vs. değilse {ki bazen ürüne bağlı olarak onları bile kaydetmek gerekebiliyor)) zaten bir logging tool (bkz: graylog, logstash, rollbar, application insight, sentry) kullanarak kaydetmeli ve saklamalıyız.
Burada günlük (log) olarak bahsettiğimiz şey bizim için önemli olan INFO level’da tuttuğumuz kayıtları, eventleri (olayları), oluşan hataları, performans ölçümlerini içeriyor olabilir.
Artık elimizde loglarımız olduğuna (ki yoksa ya da olmasaydı sonraki aşamalarda yapabileklerimiz çok kısıtlı olurdu) göre bunlar üzerinden alarmlar ve başarı/başarısızlık raporları çıkartabiliriz.
Alarmlar çoğunlukla hata logları üzerinden kurgulanır. Fakat diğer loglar üzerinden de alarmlar kurgulayabiliriz. Alarmların bağlı olduğu bir eylem olması gerekir. Bu eylemlere örnek vermek gerekirse; Slack mesaj gönder, uygulama üzerinden mobil bildirim gönder, web üzerinden bildirim gönder, e-posta gönder, sms at, sanal santral üzerinden çağrı oluştur, vs.
Örnek #1
Son 15 dakika içerisinde X koduna sahip hata logu ya da ABC başlığına sahip hata logu sayısı >0 ise alarm oluşturabiliriz.
Örnek #2
Gruplamak ya da tekrar oluşmasını beklemek yerine X tipindeki hata oluştuğu anda alarm oluşturabiliriz.
Örnek #3
Sipariş Oluşturma eylemi için son 30 dakika içerisinde hiç log oluşmamışsa şartlarına sahip bir alarm oluşturabiliriz.
Örnek #3
X operasyonu için başarı oranı %75’in altına düşerse şartına sahip bir alarm oluşturabiliriz.
Özetle elimizde kayıt olduktan sonra istediğimiz şartlara bağlı sınırsız alarm oluşturabilir ve uygulamamızı yakından takip edebiliriz. Anlamlı kayıt tutmanın bu işin özünü oluşturduğunu ifade ettikten sonra şimdi gelelim başka neler yapabileceğimize?
PERFORMANS
Uygulamamızın performansını elle topladığımız kayıtlar üzerinden kendimiz ölçüp/değerlendirebileceğimiz gibi Newrelic gibi (Nisan 2021’de yazılmış www.softwaretestinghelp.com/top-10-application-performance-monitoring-tools/ yazısında popüler APM araçlarının listesini bulabilirsiniz) ürünleride kullanabiliriz. Hatta ben bu olgunlaşmış ürünleri kullanmanızı tavsiye ederim 🙂 (Sonuçta Amerika zaten keşfedilmiş…)
Performans takibi ile uygulamamızda nerelerde dar boğaz (bottleneck) yaşandığını ya da daha iyileştirebileceğimiz noktaları tespit etmemiz çok kolay olacaktır. Tespitleri gerçekleştirdikten sonra ise artık sorunumuzu çözmek için aksiyon alabiliriz.
Yaşasın daha hızlı uygulamalar! 🚀
Şimdi size sihirli bir kelimeden bahsetmek istiyorum…
TEST
Test, test, test… Gözümüzün nuru test 🙂
Halil Şafak KILIÇ
Öncelikle yine yazılım katmanında bir sağlık (health) ya da kontrol (check) servisimizin olması gerekir. Bu servis içerisinde uygulamanın bağımlılıkları test edilmeli ve her şey yolunda ise dışarıya ben sağlıklı ve kullanılabilir durumdayım diyebilmelidir. Sonrasında artık bu servis üzerinden erişilebilirlik testi yapabiliriz.
Erişilebilirlik Testleri
Özellikle bir web uygulaması için her zaman ulaşılabilir durumda olmak çok önemli bir konudur. Uygulamamızın erişilebilirliğini www.statuscake.com ya da uptimerobot.com gibi servisler üzerinden kontrol edebileceğimiz gibi kendi topolojimiz içerisinde özel bir uygulama hazırlayarakta kontrol edebiliriz. Bu tür servis/uygulamalar ile Ping Kontrolü, Port Kontrolleri, HTTP Kontrolleri yapılabilir.
HTTP protokolünde hizmet sunan bir servis için ne gibi kontroller sağlayabileceğimize dair bir kaç örneği aşağıda bulabilirsiniz.
- Yanıt kodunun 200 olduğunun kontrolü (uygulamanın anasayfasının adresi ya da Health/Status servisi adresi üzerinden)
- Yanıt içeriğinin X’e eşit olması ya da X’i içermesi (örn: JSON response şuna eşit olmalı)
- Yanıt üst bilgisinde X başlığının olması
- SSL sertifikasının geçerli olduğunu ya da bitimine X zaman (örn: 15 gün) kaldığının kontrolünü
- Yanıt süresinin X zaman (örn: 3 saniye) altında olduğunun kontrolünü
- Alanadı süresinin bitimine X zaman (örn: 45 gün) kaldığının kontrolünü
- Farklı lokasyonlardan erişilebilirlik durumunun kontrolü (örn: uygulamanın Almanya’dan erişilebilirliği)
Kullanıcı Geri Bildirimleri
Uygulamanızı kullanan kişilerden bir şekilde (mümkünse anonim olarak) geri bildirim almanız çok ama çok önemlidir. Bu nedenle uygulamanızın her zaman görünür ya da kolay erişilebilir bir yerinde “Geri Bildirimde Bulun” gibi bir bağlantı ya da form koymanızı şiddetle tavsiye ederim.
Peki ama buna ne gerek var? Biz zaten ürünümüzü o kadar kurumsal kadrolardaki çalışanlar olarak şekillendiriyoruz… Demeyeceğinizi bildiğim için anlatmaya devam ediyorum 🙂
Biz her yere log koysak, yüzlerce test senaryosu üretsek, performansımızın mükemmel olduğunu düşünsek bile her durumu kapsayamamış olabiliriz. İşte tam olarak bu noktada açık kalan kısım için ürünün asıl sahibi olan kullanıcılarımızdan uygulamamız ile ilgili geri bildirimler alabilmeli ve bu aldığımız geri bildirimleri aktif olarak değerlendirip, gerekiyorsa aksiyon maddeleri çıkartmalıyız.
Tabi uygulamamızın koşmasına imkan sunan network, sunucu vs. kaynaklarıda izlememiz ve takip etmemiz gerektiğini söylemeye gerek yoktur sanırım…
Uygulamamızı nasıl izleyeceğimize dair kafamızda bir şeyler oluştu ya da anlam kazandı diye düşünüyorum 🙂 Eğer bu satıra kadar geldiyseniz ve hala log tutmaya ne gerek var vs. diye aklınızda minikte olsa bir soru işareti var ise lütfen bu sayfayı kapatın ve çiçeklerinizi sulayın 🙂
Siz uyurkende çalışan, hotfix çıkmanızın çok gerekmediği, hotfix çıksanız bile hızlı ve kolay release edebildiğiniz, olabildiğince az kaynak tüketen fakat çok log ve fayda üreten uygulamalarda beraber kod yazmak dileğiyle, sağlıklı kalın…
