Teknik Muhabbetler #8 (Statping, Servis durumları, Uygulamaya ne oldu?)

“Sunucu düştü”, “Çalışmıyor”, “502 alıyorum”, “Uygulama patladı” ve daha niceleri. Bu cümleler bilişim alanında çalışan veya faaliyet gösteren tüm kuruluşların korkulu rüyasıdır. Geliştirdiğimiz uygulamaları monitör etmek, loglarını incelemek ve belirli periyotlarda davranışlarını görmek geliştiricilere ve bilişim alanında faaliyet gösteren kuruluşlara iyi bir veri sağlar. Eğer bu veriler doğru yorumlanırsa planlama ve mevcut durumu değerlendirme gibi pek çok konuda doğru yerlere odaklanmamızı sağlayabilir.

Geçen haftalarda ekip arkadaşım Tahacan Atak’ın (AWS Lover 💗) önerisi ile yeni bir uygulama ile tanıştım. Statping isimli bu uygulama üzerinde yaptığım PoC sonuçlarını topladım, daha iyi öğrenmek için localimde ve test sunucularımda çalıştırdım, bozdum, kırdım, düzelttim ve öğrendim. ⛏🧐 “Teknik Muhabbetler” serisinin bu yazısında Statping’i inceleyeceğiz, avantajlarından ve neden bu yaklaşımı kendi ürünlerimizde uygulamamız gerektiğinden bahsedeceğiz. Lafı fazla uzatmayalım. Hadi öğrenelim. 👨‍🎓

Geliştirdiğimiz uygulamalar bazen tek bir container içerisinde çalışan monolith yapılar bazen de büyük bir microservice mimarisine hizmet eden küçük bir servis olabiliyor. Deneyimlerime göre eğer monolith bir uygulamamız varsa uygulamanın durumunu takip etmek öncelikli işlerimizden olmuyor. Microservice mimarisinde, uygulama sayısı arttıkça yönetim ve monitoring zorlaşıyor. Zorlaşan bu süreci nasıl çözeriz diye düşündüğümüzde aklımıza ilk gelen ve bence en doğru yöntem; bütün uygulamaları tek bir merkeze bağlayarak yönetimi kolaylaştırmak oluyor.

“Microservice Cehennemi” ibaresini çok beğeniyorum. Bir çok kuruluş, iyi planlanmamış, modüler olmayan uygulamalarını microservice mimarisine geçirince tüm sorunlarından arınacağını düşünüyor. Tam bu noktada kendime bu ibareyi hatırlatıyorum. “Microservice Cehennemi”. Microservice mimarisinde uygulamalar ne kadar küçük olursa olsun, uygulama adedi fazla olduğu için yönetim, monolith uygulamalara göre daha zordur.
Microservice cehenneminde yaşanan temel bazı sorunları hatırlayalım.

Yukarıdaki maddelere yenileri eklenebilir. Günlük hayatta benim en çok sorun çözdüğüm maddeleri ekledim.

Bu yazıda monitoring kavramına değineceğiz. Statping bize bu konuda yardımcı olan güzel, sade ve bence en önemlisi esnek bir tool.

Statping sayesinde herhangi bir uygulamamızın durumunu izleyebiliyoruz.
Kullanımı oldukça basit. Dashboard üzerinden uygulamanızı eklemeniz yeterli. Statping servislerinizin hepsini tek bir arayüzde toplayarak size bir rapor sunuyor.
Bu rapor içerisinde;
Servislerinizin son 90 gün içerisinde yaşadığı aksaklıklar, son 24 saat ve 7 gün içerisinde yüzdesel olarak uptime değeri, avarage response time gibi bilgiler bulunuyor.
Daha detaylı bilgiler almak isterseniz;
- Son 7 gün içerisinde toplam fail sayısı,
- Son 7 gün içerisinde yaşanan en yüksek gecikme zamanı (ms cinsinde)
- Son 7 gün içerisinde yaşanan en az gecikme zamanı (ms cinsinde)
- Son 7 gün içerisinde yaşanan en yüksek ping süresi (μs cinsinde)
- Son 7 gün içerisinde yaşanan en düşük ping süresi (μs cinsinde)
gibi bilgilerde default olarak arayüzde sağlanıyor.

Kurulum aşamasına geçmeden önce küçük bir uyarı yapmakta fayda var. Statping uygulamasını mevcut cluster veya uygulamanızın çalıştığı örnek içerisine kurmayın. Sunucunuz veya cluster yapınızda oluşan bir hata sonucunda durum sayfanızda çalışmayacağı için hata senaryolarında kurguladığımız bu özelliğin hiçbir anlamı kalmayacaktır.

Dökümanı tararken ilk göze çarpan özelliği Lightweight olması. Go ile yazılan bu tool oldukça hafif ve hızlı. Raspberry Pi’da bile çalıştırabilirsiniz. Hafif oluşunu docker image boyutundan bile anlayabilirsiniz. Sadece 16MB. 🎈

Her zaman bilgisayar başında olamayabilirsiniz. Bunun için Statping mobil uygulamasını kullanabilirsiniz. App Store ve Google Play’de ücretsiz olarak mevcut. Mobil uygulaması sayesinde servislerinizde oluşan hatalarda veya durumunun değişiminde bildirim alırsınız. Yapmanız gereken tek şey, kendi statping uygulamanızda ayarlar altında bulunan QR kodunu taratmak.

Uygulamayı istediğiniz bir ortamda ayaklandırabilirsiniz. Ben kişisel projelerimde docker image kullanarak ayaklandırdım. Ancak Tahacan Atak ile AWS EC2 içerisinde ayaklandırdık. Instance olarak t2.nano üzerinde çalıştırdık. Fiyatları merak ediyor musunuz? 🦝

Yaklaşık aylık 5$ gibi bir maliyet ile AWS EC2 t2.nano instance üzerinde statping uygulamasını ayaklandırabilirsiniz.

Hadi kuralım şu uygulamayı. 🤩

docker run -it -p 8080:8080 statping/statping

Docker run komutu ile statping uygulamasını 8080 portunda ayaklandırabilirsiniz.
Veya

docker-compose up -d

http://localhost:8080 adresine gittiğinizde sizi setup ekranı karşılayacak. 3 farklı data storage seçeneğiniz var. SQLite, PostgreSQL ve MySQL. Ben localimde SQLite tercih ettim ancak test sunucularımda PostgreSQL üzerinde çalıştırdım. İstediğiniz data storage seçebilirsiniz. Seçtikten sonra bilgilerinizi girmeniz yeterli.

İşte bu kadar. Bizim için örnek bir status page oluştu bile. Yukarıda videoda örnek page içerisinde hızlıca gezindim.

/dashboard üzerinden istediğiniz kadar servis ekleyebilirsiniz.
Bundan sonrası oldukça kolay ve anlaşılır. Benim için oldukça önemli tek bir kısım var. Ayarlar altındaki notification channel sayısı. Oldukça fazla channel desteği var. Ekibinizi farklı kanallardan hata senaryolarında bilgilendirebilirsiniz.

Makalenin bu kısmına kadar geldiysen ve kendine go dilinde güveniyorsan o zaman sana mükemmel bir fırsat sunuyorum. Gördüğün gibi notifier channels arasında Microsoft Teams yok. Aslında çok basit. Slack gibi bir webhook ile çalışıyor. Akıllara şu soru gelebilir. “Eeee zaten webhook var neden teams?”
Slack’te incoming web hook ile çalışıyor ancak eklentisi var. Belki sen de bu projeye contributition yapabilirsin. Bence hemen forkla ve teams için eklentini yaz. ✨

Son olarak status sayfalarının öneminden biraz bahsetmek istiyorum.
SaaS bir ürün geliştiriyorsanız ve entegrasyon kaslarınız güçlüyse mutlaka ama mutlaka bir status sayfanız olmalı. Sizi tercih edecek olan kullanıcılara bunu göstermelisiniz. İş ortaklarınız teknik olarak kabiliyetlerinizi ve son x günde olan uptime sürelerini görmeli.

Geliştiricileri düşünelim. Uygulamanızda bir payment servisi yazacaksınız. Ancak tüm süreçleri siz yönetmek istemiyorsunuz. Sektörde bu işi yapan bir provider kullanmak istediniz. Karşınıza birden çok provider çıkabilir. Tercihinizi neye göre yaparsınız?
Ben tercihimi son x günde en fazla uptime ve en az avarage response time değeri olan sağlayıcıdan yana kullanırım.
Bahsettiğim bu senaryo community için önemli ancak ekip içerisinde uygulamalarımızın durumunu bilmek daha önemli. Bu nedenle status sayfalarımız yoksa hemen harakete geçelim. 🏃‍♂️

Biz ekip olarak statping uygulamasını kurduk ve kullanıyoruz.
Örnek olması için bazı kuruluşlarında status page adreslerini buraya bırakıyorum.

Solution Developer — I want to change the world, give me the source code.