Sayfa Reklamı

sağlam bahis siteleri
Genel

Uygulamanızın Canlı Versiyona Geçildikten Sonraki Süreç Nasıl Olmalı?

Bir startup proje üzerinde çalışıyorsunuz ve sonlara yaklaştığınızda belli bir stres oluşuyor olabilir, bu stresi en etkili biçimde yönetmek aslında size bağlı diyebiliriz. Yazılım sürecinde ekip olarak ya da tek başınıza epey bir stres yaşadığınızı düşünebilirsiniz ama aslında proje canlıya çıktıktan sonra sizi daha stresli bir süreç bekleyecektir. Biz bu süreci en etkili bir biçimde nasıl kordinasyon edeceğimizi en basit haliyle göstermeye çalışacağım.

Önceliğimiz Loglama Nasıl Olmalı?

Uygulamalarınızı en basit şekilde log üzerinden takip etseniz de loglamak hem uygulama hızı açısından hem sistem gereksinimleri açısından pahalıdır. Logladığınız her satır, çoğu uygulama da zaten az bulunan IO kaynağını tüketecektir (dosyaya yazdığınızı varsayıyorum). Yetmediği gibi aşırı loglama yaptığınızda disk boyutlarınız yetmemeye başlayacak ve hele ki uygulamalarınızı geçmiş yıllar bazında tutmak istiyorsanız, uygulamanızın maliyeti bir hayli atacaktır. Bu sebepten neyi ne kadar logladığınız çok önemli. Loglarınız hem maliyeti arttırmayacak kadar az, hem de bir hata anında sizi bilgilendirecek kadar çok olmalıdır.

Ben loglama yaparken “bugfix” yapan geliştirici açısından bakmaya çalışıyorum. Örneğin; basit bir kullanıcı servisiniz : kullanıcı eklenip, listelenip, güncellenebildiğini farzedin. Müşteriden “Ben bhdrkn isimli kullanıcıyı güncelleyemiyorum” şeklinde bir bug geldiğinde, geliştirici loglardan hatanın kaynağının çıkarabilmeli. Eğer çıkaramıyorsa yeteri kadar loglama yapmıyorsunuz demektir.

Bir diğer dikkat ettiğim nokta ise, uygulamayı savunup savunamayacağım oluyor. Şöyle örnek vereyim. 3-4 farklı sistemle konuşan bir uygulamanız olduğunu düşünün. Konuştuğunuz her servis sizin için risk oluşturuyor. Fakat sizin uygulamanız müşterinin işlem yaptığı uygulama ise Bug doğruca size geliyor. Böyle bir durumda kendinizi savunabilecek loglarınızın olması gerekiyor. “Hata bende değil şu sistem bana yanlış cevap döndü” diyebilmelisiniz. Yine aksi bir durumda yeterince loglama yapmıyorsunuz demektir.

Bu ikisi haricinde diğer tüm logları olabildiğince kısabilirsiniz. Ben uygulamanın düzgün çalıştığını gösteren bir iki basit satırı bırakıp gerisini olabidiğince “debug” seviyesine çekmeye çalışıyorum.

Logların Toplanması

Loglarla ilgili diğer bir konu ise logların toplanması. Canlı sisteminizin 10 farklı makinede çalıştığını düşünün. Eğer loglarınızı sadece dosyaya kaydediyorsanız, şimdiden söyleyeyim işiniz var. Bir hata olduğunda loglamanızı düzgün de yapıyor olsanız, 10 farklı makineyi tarayıp logu çıkarmanız gerekecek. Hele ki hata zamanı hakkında, müşterinizin çok bir fikri yoksa (ki genelde olmaz), vay halinize.  Bir hayli vaktinizi alacaktır.

Bunu kolaylıkla Logstash türü uygulamalarla çözebilirsiniz. Böylelikle tek bir arayüzden istediğiniz tarih aralığındaki işlemleri görebilir ve hatanızı çok daha çabuk yakalayabilirsiniz. Logstash ve onu nasıl kuracağınız ile ilgili daha detaylı bilgiyi bu yazıdan bulabilirsiniz.

Logların Taranması

Logstash ve benzeri log toplamak için kullanılan uygulamaların, tek mahareti logların taoplanması değil tabiki de, bu tip uygulamaları çok daha akıllıca kullanabilirsiniz. Loglarınızı düzgün şekilde yapıyorsanız, bir hata durumunda müşterinizin size dönmesinizi beklemek zorunda değilsiniz. Loglarınızı tarayarak müşteriyi beklemeden de ticket ya da issue’larınızı kendiniz üretebilirsiniz.

Örneğin Logstash’in jira eklentisi bulunuyor. Bu eklentiyi kullanarak farklı log satırları için farklı issue’lar açabilirsiniz. Mesela, ORA-???? ile başlayan hataları alıp veritabanı ile ilgilenen takıma açmanız mümkün. Ya da tüm ERROR tipindeki satırlar için issue açabilirsiniz. İlgili log satırınızda elinizde olduğundan, müşterinizin açacağından çok daha anlamlı issue’larınız oluyor.

Sisteminizin Değerlerinin İzlenmesi

Loglarınızın haricinde genel olarak tüm sisteminizin de izlenmesi yerinde olacaktır. Sisteminizin izlenmesinden kastım ise her bir sunucunuzun ( ya da sanal makinenizin) en azından CPU, bellek, Network ve IO değerlerinin anlık olarak izlenmesi. Eğer veritabanı kullanıyorsanız, veritabanınızın anlık bağlantı ve transaction sayısını da takip etmeniz yerinde olacaktır. Bunu Nagios gibi araçlar kullanarak kendiniz de yönetebileceğiniz gibi, NewRelic ve AppDynamics gibi bulut tabanlı uygulamalar da kullanabilirsiniz.

Örneğin NewRelic, yükleyeceğiniz bir agent ile ücretsiz olarak size CPU, Bellek, Network ve IO değerlerini sunuyor. Üstelik bu değerlerden biri ya da bir kaçı belli bir değerin üzerine çıktığında (CPU %90’ın üzerine çıktığında gibi) alarm üretebiliyor. Bu alarmları isterseniz yine Jira üzerinde issue’lara çevirmeniz de mümkün. Böylelikle sisteminiz gerekli yükü kaldıramadığında, müşterinizden “Sistem çok yavaşladı” şeklinde uyarılar almak yerine, neden yavaşladığı ile ilgili bir ayrıntılı issue alabiliyorsunuz. Bu da sorununuzu çözmenizde çok işinize yarıyor.

Uygulama Özelindeki Değerlerin İzlenmesi

Bu zamana kadar genel olarak uygulamaların nasıl izleneceğinden bahsettik. Fakat uygulama özelinde baktığınızda daha başka bir çok değerin de önemli olduğunu görüyoruz. Örneğin servisinizin cevap verme süresi önemli olabiliyor. Hangi servis cevabına ne kadar sürede yanıt verdiğinizi ölçüp, eğer beklenilenin çok üzerindeyse alarm üretebilirsiniz. Bunu yine sistem değerlerinizi takip ettiğiniz araçlar üzerinden yapabilirsiniz. Mesela NewRelic bize uygulama özelindeki değerleri (Custom Metrics) takip etmemize olanak sağlıyor. Yani sizin için kritik olan servisinizin ne kadar sürede cevap verdiği bilgisini NewRelic’e bildirebilirsiniz. Daha sonra NewRelic üzerinden yeni izlemeye başladığınız değer için alarm üretebiliyorsunuz. Bu alarmı da daha sonra ister jira’ya bağlayın isterseniz mail attırın, tamamen size kalmış.

Başka bir örnek verelim : SMS gönderen ve asenkron çalışan bir sisteminiz olsun. Kullanıcı binlerce SMS’i size tek bir istekle gönderiyor, siz de bunları bir kuyrukta işleyip tek tek gönderiyorsunuz. Fakat kuyruğunuzun belli sürede işlenmesi gerekiyor. Sürekli artması ya da belli bir değerin üzerine çıkması siz de soruna yol açabilir. Kuyruğunuzun RabbitMQ olduğunu düşünecek olursak, RabbitMQ bir rest servis üzerinden size kuyruk durumlarını bildirebiliyor. Kuyruk durumlarınızı bu servis yardımıyla yine NewRelic’e özel bir değer olarak bildirebilir ve alarm üretebilirsiniz.

Son

Canlı uygulamaları izlemek, ekstra bir yük gibi gözükebilir ama inanın sisteminizin sorunsuz çalıştığına güvenmeniz stresinizi bir hayli azaltıyor. Örnekleri verirken olabildiğince araçlardan ve geliştirilen yazılımdan bağımsız olmaya çalıştım. Umarım başarılı olabilmişimdir.

Previous Post Next Post

You Might Also Like

No Comments

Bir Cevap Yazın

%d blogcu bunu beğendi: