Büyük bir kurumda ya da karmaşık bir sistemin içinde çalışıyorsanız, izleme sistemlerinin ihtiyacını hissetmişsinizdir. Başka bir deyişle baskısına maruz kalmış olmanız da olası. Belirtmekte fayda var bu tarz işleri gönülden desteklesem de, sadece Uygulama geliştirme tarafında kalıyorsa, şahsen samimiyetine inanamıyorum. Ancak programcı gözüyle ne yapabiliriz dersek çeşitli “Trace tool” ları mevcut. Fakat bu gün aslında birazda bireysel gayretle neler yapılabilir bundan bahsetmek istiyorum.
Öncelikle, bu çabaları 2 ana başlıkta ele almak istiyorum;
1- (Monitoring service) Uygulamanızda bağlantı kurduğumuz farklı yapılar ve hizmetin devamlılığı adına kritik rol oynayan bir kaç kod parçacığı mevcut. Bu adımların her biri için başarı durumlarını, hizmetin ayakta olup olmadığını ve bağlantı bacaklarının durumları ile bağlantı performanslarını sürekli ve anlık olarak takip edebilmeniz için geliştirilen bir servis olarak düşünülebilir. Başka bir değiş ile Network katmanındaki SNMP servislerine benzer bir işlem görecek, tabii Management kavramı bu yazı kapsamından biraz uzak. Biz idare kısmını bir yana bırakıp izlemeye odaklanıyoruz.
2- (isAlive service) Aslen Monitoring için yapılan işlemleri içerir. Ancak amacı ve yapısı biraz daha farklı, Bu nedenle amacından başlamakta fayda var. Monitoring izleme odaklı iken, isAlive daha çok sadece ayakta mı, değil mi sorusunun cevabını verir. Asli görevi ağırlıklı olarak olağan bir problemde belirlenen bir aksiyonu tetiklemektir. isAlive servisinin de network teki Ping yapısına benzetilmesi yanlış olmaz.
Örneğin, Bir web uygulamanız var. Uygulamanızın hizmetine talep değişmekte, Bu noktada disk kullanımı, CPU ve Memory yeterlilikleri ya da bağlantı alt yapısının taleplere cevap verme noktasında yeterliliği ve benzer durumları takip ederek oluşturabilecek sorunları önceden takip etmek istiyorsunuz. Monitoring servisi ile bu bilgileri toplanabilir. Böylece istatistiklerin izlenmesi ya da tarihsel olarak tutulması ve sonrasında analiz edilebilmesi için kullanılabilir.
Diğer yandan farz edelim ki bu kısmı hallettiniz ya da çokta umurunuzda değil. 😂 Ancak sunucularınızda 1 tanesi gittiğinde, bu sunucuya gelebilecek olası istekleri farklı sunuculara paylaştırmak istiyorsunuz. Aslen Monitoring kısmındaki birçok kontrole ihtiyaç duyacak olsanız da dönüş olarak “True/False” şeklinde bir cevaba ihtiyacınız var. Böylece istediğiniz aksiyonu bir Load balancer ve/veya benzeri önceki bir noktada ilgili isAlive servisinizin cevabı ile oto matize edebilirsiniz.
Şimdi birazda bu işin metoduna bakalım:
– Öncelikle disk kullanımı, CPU ve Memory kullanımı gibi kısımlar için Performans counter bilgilerine ihtiyacınız var. Bu nedenle uygulamanızın altında çalıştığı kullanıcı için “Performance Monitor Users” yetkisinin tanımlı olduğundan emin olmalısınız.
– Entegrasyon noktalarının durum ve performans ölçümleri için ilgili sistem ya da servislerde bu amaçla kullanabilecek servislere ihtiyacınız olacak. Bu amaçla dummy (İş yapmayan, sorgu amaçlı) Web method ları ya da DB ler için Stored procedur ler kullanılabilir.
– Uygulamanızın içinden kritik class, sayfa, ya da methodları tespit edip dummy istekler yaratabilir ve cevaplarını yorumlayarak, servis devamlılığını kontrol edebilirsiniz. Web uygulamalarda yapılan en yaygın kontrol http:200 cevabının kontrolü olsa da, tek yöntem değil. İlaveten, Örneğin “js” dosyalarını ele alırsak, http:200 şeklinde dönen cevap sonrası, ilgili dosya içeriği için .NET kütüphanesi kullanılarak Syntax Validation gerçekleştirilebilir. Bu size, yapılan olası bir deployment hatasını ivedilikle tespit şansı verecektir.
– Session değerleri okunabilir ve böylece adetlere ilişkin bir sonuç üretilebilir. Ancak bu amaçla ilgili servisin IIS tarafında aynı Application pool da yer alması gerekir. Hatta ne kadar özele girdiğinize bağlı olarak aynı uygulamanın parçası olarak geliştirmek zorunda da kalabilirsiniz. Fakat basitinden uygulama cevap vermiyor ama acaba sebep DB bağlantısı mı? Bunun cevabını da ancak uygulamadan soyutlanmış bir servisle dışarıdan gerekli durumlarda aynı ayarları kullanarak, ilgili kontrolü kendisi de gerçekleştirebilecek şekilde tasarlarsanız elde edebilirsiniz.
Değerlendirdiğimiz hususları göz önüne alırsak naçizane tavsiyelerimi sıralamamda fayda var;
1- Birçok kontrolün ortak olduğunu düşünürsek 2 servis için ayrı method yapmakta ve inputa göre cevabı farklılaştırmakta fayda var.
2- Gereksiz ve amaçsız işlem yaparak, kaş yapalım derken göz çıkarmanın da manası yok. Bu nedenle gerek duyulan verilerin iyi tanımlanıp işlemlerin minimize edilmesi ve aynı şekilde kontrol sıklığının dikkatli seçilmesi faydalı olacaktır.
3- Dummy kontrol servislerinin kritik loglarınızı şişirmeyecek şekilde tasarlanması gerekir.
4- Ayrıca servisi uygulamaya mı gömmeliyim yoksa dışarıdan daha geniş bakış açısına sahip stand-alone bir yapı mı olmalı, sorusu duruma göre değişecek olsa da, şunu unutmayın dağınık bir yapı ile bir kaç katmanlı mimari ile 2 yapının getirileri de elde edilebilir.
Örneğin bir iç servis detay bilgileri hazırlayıp paylaşırken onun önüne oturabilecek bir yapı olası bir http:404 ve veya benzeri hata durumunda bağlantı kontrollerini kendisi yaparak ilave kontroller çalıştırabilir ve daha oturmuş bir izleme sisteminiz oluşturulmuş olur. Bu size ne sağlar derseniz sorun durumunda Bazı kontrol adımlarını hızlıca geçmenize ve daha hızlı sonuca ulaşmanıza fayda sağlayacaktır.