.Net Core Eğitimleri

8 -) Logging ve AutoHistory

Logging ve AutoHistory

Bu yazı ile sistemimize, dosya sistemine loglama(logging on file) ve veritabanında değişikliğe uğrayan kayıtların versiyon versiyon geçmişini tutma yeteneklerini ekleyeceğiz. Loglama ve AutoHistory için ayrı nuget paketlerini projemize dahil edeceğiz. Önceki dersler işlemleri doğru yapıp yapmadığınızı kontrol etmek isterseniz bu link ile projenin son haline github üzerinden ulaşabilirsiniz.

Loglama(Logging)

Sistemimizde olup biten birtakım işlemleri saklamak, gerektiğinde kontroller yapmak ve oluşan hataları detaylıca görmek için loglama işlemleri yaparız. Loglamayı veritabanına, dosya sistemine, nosql bir veritabanına ya da bulut sistemlerine yapabiliriz. Bu örnekler arttırılabilir ancak genel olarak sıklıkla tercih edilen yöntemler bunlardır.  Bir sorunla karşılaşıldığında, şikayet alındığında ya da analiz yapılmak istendiğinde daha önceden yaratılan loglara ulaşmamız gerekebilir. Loglama stratejinizi kurguladığınız sistemin ihtiyaçlarına göre oluşturmalıyız. En önemli nokta loglama yaparken sistemin genel çalışmasının mümkün olduğunca az etkilenmesi ve performans sorunlarının ortaya çıkmamasıdır. Ben en çok tercih edilen loglama çeşitlerinin avantajları ve dezavantajlarından bahsetmeye çalıştım.

1-) Dosya Sistemine Loglama

Loglarımızı dosya sistemi üzerinde tutma işlemidir. Sistemden üretilen tüm loglar belirlenen formatta dosya sistemi üzerinde barındırılır. Dosya üzerine loglama işlemlerinde en önemli noktalardan bir tanesi log dosyasının boyut kontrolüdür. Eğer dosya boyutu kontrolsüz bir şekilde büyüyecek olursa, uygulamamız artık o dosya üzerine log yazmaya çalışırken oldukça fazla zaman harcayacak, belkide hiç loglama yapamayacak hale gelecektir. Bu duruma genelde log dosyasının şişmesi denir. Loglamayı sağlıklı yapamadığımız için sistemin diğer işlevlerinde sorunlar çıkabilir, çok basit işlemler uzun vakitler alabilir ve uygulamamızın geneli bu sorun nedeni ile işlevini yitirebilir. Dosya boyutu mutlaka kontrol edilmeli ve belirlenecek stratejiye göre belli bir boyutun üstüne çıktığında hemen yeni bir log dosyası açarak performans sorunlarının önüne geçilmelidir. Mümkün ise bu logları bir file server üzerine yazmalı ya da en azından farklı bir diske kaydetmemiz daha sağlıklı olacaktır.

Gereksiz loglamadan kaçınmalı ve ihtiyacımız olanı loglayacak şekilde planlama yapmalıyız.  Dosya sistemine aldığımız logların başkası tarafından silinmemesi için gerekli önlemleri almalıyız. Log dosyalarının boyutu sistemin diskini doldurmadan başka bir yere taşımalı ya da ilk yazılan logların otomatik olarak silinmesini sağlayacak şekilde kurallar oluşturmalıyız. Dosya sistemine yazdığımız logları belli bir ayırıcı ile ayırmalı ve programatik olarak okunabilecek seviyede bir veri seti olarak saklamalıyız. Bu logların okunması ve analiz edilmesi, veri tabanına (uygulamanın kendi veritabanı ya da elastiksearch ile nosql çözümleri gibi) yazılan logların analiz edilmesinden daha zor olacaktır ve daha fazla vakit gerektirecektir.

2-) Uygulamanın Veritabanın Loglama

Uygulamanın kendi veritabanına loglama yapma işlemi oldukça kritik işlemler ve kayıtlar için mantıklı olabilir ancak her türlü logun veri tabanına yazılması performans sorunlarına yol açabilir. Mssql veritabanı üzerinden konuşacak olursak, oluşturulan her bir işlemin(transaction) log kaydı veritabanımıza ait log dosyası üzerine yazılmaktadır. Eğer her türlü logu veritabanı yazacak olursak bu bizim için bir transaction olacak ve bizim loglarımız için mssql de log yazma işlemi gerçekleştirecek. Transaction loglar veritabanı için oldukça önemlidir, sistemde yaşanacak sorunlar yanlış yapılan işlemler gibi felaket durumlarında kurtarıcı olabilirler. Yukarıda anlattığım durumda biz bir log işlemi için sisteme iki adet log yazmış olacağız ki bu durumda bizim için maliyet anlamına geliyor. Log şişmesi durumu iyi kontrol edilmeyen ve profesyonel olarak yönetilmeyen veri tabanlarında sıklıkla karşılaşılabilecek bir durumdur. Bu durum ortaya çıktığında veri tabanında uygulamanın da performans sorunları baş gösterecektir.

Veritabanına loglama yapmak geriye dönük aramalarda ve analizlerde oldukça hız kazandıracaktır ancak her türlü loglamanın veritabanına yapılması ciddi bir veri tabanı yönetimi ve senaryolara göre ek maliyetler gerektirecektir.

3-) NoSQL Veritabanlarına Loglama(Elasticsearch)

Bu seçenek son zamanlarda gittikçe popülerleşen bir yaklaşım. Verilerinizi kibana gibi open source elastic search alt yapısına sahip sistemlerde saklayabilir ve MongoDB, Cassandra, CouchDB gibi nosql veritabanları kullanırlar. Başka derslerde bu veritabanlarının çalışma prensiplerinden, artı ve eksi yönlerinden bahsedeceğiz. Şimdilik ilişkisel olmaya şekilde verilerin tutulduğu ve yatay olarak genişleyebilen yapılar olduklarını bilsek yeterli. Bu şekilde loglama yapmak bize analiz ve geriye dönük aramalarda hız kazandıracaktır. Elasticsearch alt yapısı ile saklanan veriler kelime kelime indexlenerek saklanır ve büyük veriler içerisinde arama yapmak oldukça performanslı bir hale gelir.  Ancak bu şekilde bir alt yapı kurmak ve yönetmek ayrı bir maliyettir. Kuracağınız sistemler opensource olduğu için en azından bu sistemlerde oluşabilecek sorunlara müdehale edecek kadar bilgi sahibi olmanız ya da dış destek almanız gerekebilir.

Hangi Yönetimi Kullanmalıyım?

Yukarıda açıklamaya çalıştığım yöntemler dışında, bulut sistemlerine log yazmak, mail ile logları saklamak hatta kullanıcının bilgisayarında log saklamak bile bir yöntemdir ve yerine göre bu yöntemler işimize yarıyabilir. Hangi yönetimi kullanacağımıza, oluşturduğumuz sistemin geneline ve ihtiyaçlarına bakarak(yazılım alanının neredeyse her karşılaştırmasında olduğu gibi) karar vermeliyiz. Az kullanıcılı ve transaction sayısı az olan bir uygulamamız var ise veritabanına loglama yapmak daha akıllıca olabilir ancak işler biraz daha büyüdüğünde hayati loglamaları veritabanına geri kalanları dosya sistemine yapma seçeneğini kullanabiliriz ve artık log dosyalarımız big data seviyelerine gelmeye başladıysa ve geriye dönük olarak tümüne ihtiyacımız varsa elasticsearch yapısından yararlanmak kuvvetli bir seçenek haline gelebilir.

Geliştireceğimiz uygulamanın ne kadar uzun ömürlü olacağı ve kalite algısı bu tarz stratejik kararlara bağlıdır. Geliştirdiğiniz uygulamadan gururla bahsetmek yerine kötü stratejiler yüzünden uygulamanızdan nefret edebilirsiniz. Bir uygulama geliştirirken, desteği, bakımı ve sonradan eklenmesi olası özellikleri düşünerek stratejiler belirlemeli ve planlama aşamasında diğer tüm aşamalardan çok vakit harcamalıyız. Loglama diyerek bu konuyu küçümsemek çok büyük problemlere yol açabilir ve hatta uygulamanızın çalışmasını engelleyebilir.

Uygulamamızın Loglama Altyapısı

Biz uygulamamızda iki farklı seçenek kullanacağız. Stratejimizi veriler ve veriler üzerinde yapılan işlemlere göre iki ana başlıkta belirleyeceğiz. Veriler ile ilgili güncelleme,silme gibi değişiklikleri veri tabanında tutarken, istemcinin api ile haberleşmesi, sistem hata logları ve diğer custom logları dosya sisteminde saklayacağız. Veritabanına loglama için AutoHistory nuget paketini, dosya sistemine loglama için NetEscapades.Extensions.Logging nuget paketini kullanacağız.

.Net Core ile Dosyaya Loglama İşlemleri

Projenin başlangıcında kullandığım dosyaya loglama alt yapısı yerine kullanımı daha kolay olan farklı bir paket keşfettim, bu nedenle Common katmanımız içerisinde bulunan Logging klasörüne ihtiyacımız kalmadı. O klasörü projeden kaldırabiliriz. Daha sonra Solution Explorer üzerinden web api projemize sağ tıklıyoruz ve Manage Nuget Packages diyerek Nuget paket yöneticisini açıyoruz.

Loglama için gerekli nuget paketi yükleme ekranı - Mehmet Ali EROL
Loglama için gerekli nuget paketi yükleme ekranı

Daha sonra aşağıdaki adımları takip ederek ilgili paketi WebApi projemize dahil ediyoruz.

Loglama için gerekli nuget paketi yükleme ekranı 2 - Mehmet Ali EROL
Loglama için gerekli nuget paketi yükleme ekranı 2

Paketi ekledikten sonra projemize bir appsettings.json dosyası ekleyeceğiz. Bu dosyanın içinde loglama ile ilgili ayarları saklayacağız. Bunun için aşağıdaki ekran görüntülerini takip ederek gerekli işlemleri yapalım.

appsettings.json dosyasının projeye eklenmesi - Mehmet Ali EROL
appsettings.json dosyasının projeye eklenmesi
appsettings.json dosyasının projeye eklenmesi 2 - Mehmet Ali EROL
appsettings.json dosyasının projeye eklenmesi 2

WebApi projemize eklediğimiz appsettings.json dosyasına çift tıklayalım ve içeriğini aşağıdaki şekilde düzenleyelim. FileSizeLimit içinde yazan değer 20 megabyte ın byte değeridir ve 20 * 1024 * 1024 şeklinde hesaplanabilir.

WebApi projesi içinde bulunan Startup.cs dosyasına çift tıklayarak aşağıdaki şekilde düzenlemeler yapalım.

Başlangıç projesini WebApi yapmak için Solution Explorer üzerinden WebApi projemize sağ tıklayalım ve Set as Startup Project diyelim. Daha sonra klavyeden F5 tuşuna basabilir ya da Debug menüsünden Start Debugging diyerek projeyi çalıştırabilirsiniz. Proje çalıştığında output tabında çeşitli mesajlar görünecektir. Projeyi durdurarak appsettings.json dosyası içinde Logging segmentinin içinde bulunan “Microsoft”: “Warning” değerini “Microsoft”: “Information” olarak değiştirelim ve tekrar projeyi çalıştıralım. İki şekilde de output tabında görünen değerleri inceleyelim. Information yazdığımızda microsoft ismi ile gelen logların arttığını görebilirsiniz. Daha sonra Solution Explorer kısmına baktığınızda LogFiles klasörünün oluşturulduğunu ve içine bir adet log dosyası yazıldığını görmemiz gerekiyor. Bu dosyanın adı bizim belirttiğimiz gibi applicationLog- ile başlıyor ve bugünün tarihini ile sonlanıyor. Belirttiğimiz sınıra geldiğinde ise aynı isimle yeni bir dosya açılacak ve loglama o dosya üzerinden devam edecek.

Dosyaya loglama alt yapısını oluşturduk ve test ettik. Projenin ilerleyen bölümlerinde custom olarak nasıl log yazacağımızı göreceğiz.

Auto History

Entitylerimiz üzerinde değişiklikler olduğunda bunların loglanması ve geçmişe dönük analiz edilerek gerektiği durumlarda kanıt ya da yol gösterici olarak çekilmesi önemlidir. Bu işlemi kaydın versiyonlarını tutmak da diyebiliriz. İlgili kaydın ilk eklenme zamanından son haline kadar geçirdiği değişimleri saklamak oldukça önemli bir konudur. Özellikle kurumsal projelerde bu kayıt neden değişti ya da bu zamana kadar bu kayıt üzerinde ne değişiklikler yapıldı gibi sorulara cevap vermek hayati önem taşır.

Peki biz bu değişimleri neden dosya sistemine loglamıyoruz? Aslında istersek dosya sisteminde de saklayabiliriz ancak geriye dönük arama yapmak analizlerde kullanmak biraz daha zahmetli bir hal almaya başlayacaktır. Bu loglar ile diğer loglar karışabilir ve aradığımızı bulamaz noktaya gelebiliriz. Bu nedenle bu projede kayıt değişikliklerini AutoHistory ile veri tabanında bir tabloda tutacağız.

İlk olarak Solution Explorer’dan en üstte bulunan Solution adına (Company.Application) sağ tıklayarak nuget paket yöneticisini açıyoruz ve aşağıdaki paketi seçerek Data projesine dahil ediyoruz.

AutoHistory nuget paketinin projeye dahil edilmesi - Mehmet Ali EROL
AutoHistory nuget paketinin projeye dahil edilmesi
AutoHistory nuget paketinin projeye dahil edilmesi 2 - Mehmet Ali EROL
AutoHistory nuget paketinin projeye dahil edilmesi 2

Son olarak Data projemiz altında bulunan Context klasöründeki ApplicationDbContext.cs dosyasına çift tıklıyoruz ve içeriğini aşağıdaki şekilde düzenliyoruz.

Sonuç

Bu ders ile projemize dosyaya loglama ve veritabanına loglama yeteneklerini eklemiş olduk. Buraya kadar yaptığımız işlemleri kontrol etmek isterseniz bu link ile github üzerinden projeye ulaşabilirsiniz. Bu kısım için yaşadığınız bir sorun ya da sormak istediğiniz bir soru varsa yorum kısmında ya da mail adresim üzerinden iletebilirsiniz.
Mail adresim : mehmetalierol@windowslive.com

<- Önceki Post – Sonraki Post ->

.Net Core Eğitimleri

1) .Net Core Nedir?

.Net Core

.Net Core, Microsoft ‘un açık kaynak kodlu olarak piyasaya sürdüğü bir “framework” tür.

Core öncesinde Microsoft tabanlı ortamlarda geliştirdiğiniz uygulamaları başka platformlar üzerinde koşturmak ya mümkün değildi ya da ekstra uygulamalar ve yöntemler gerektiriyordu. Microsoft, .Net Core ile birlikte bu sorunu ortadan kaldırmakla kalmadı aynı zamanda .Net Framework ile çalışırken karşılaşılan çeşitli sorunları da temizledi diyebiliriz. Örneğin dependency injection yapmak için Core öncesinde 3. parti çözümler kullanmak ve bir sürü ayar yapmak gerekebiliyordu ama artık Core içerisinde dependency injection gibi daha pek çok hayat kurtaran özellik gömülü bir şekilde geliyor. Olay sorunların giderilmesi ile sınırlı kalmıyor, bunların yanında performans üzerinde ciddi iyileştirmeler yapılmış ve tabi tüm bu iyileşmenin altında açık kaynak kod topluluğunun ciddi bir etkisi olduğunu söylemek gerekiyor. Bu link ile önceki sürümler ve .Net Core arasında performans karşılaştırmalarına göz atabilirsiniz.

Artık microsoft tabanlı bir işletim sistemi kullanmadan, visual studio geliştirme ortamına ihtiyaç duymadan gerekli geliştirmeleri yapabilir ve geliştirdiğiniz uygulamaları yine microsoft platformlarına bağımlı kalmaksızın başka ortamlarda çalıştırabiliriz. Core ‘un sürümlerine, sürümler içerisinde ne gibi farklılıkların bulunduğuna Microsoft’un sitesinden bakabilir ve gelişimi detaylıca görebilirsiniz.

Kısaca .Net Core’un temel özelliklerinden bahsettik, fazla detaya girerek gereksiz bilgiler vermek istemiyorum, daha detaylı bilgiye sahip olmak isteyenler mutlaka Microsoft’un sitesinden araştırma yapmalı ve gelinen son noktayı tecrübe etmeli.

Yazı Serisinin Amacı

Bu eğitim adım adım kurumsal bir backend projesinin nasıl yapılacağı ile ilgili bilgi vermek amacı ile hazırlanmıştır. Projeyi en baştan ekran görüntüleri ile birlikte oluşturacağız ve aşağıdaki özellikleri içerecek şekilde tamamlayarak hep birlikte yayına alacağız. Daha sonrasında angular 6 ile frontend tarafında geliştirmeler yapacağız. Ancak o başka bir ders konusu altında olacak. Aşağıda bulunan adımları içeren örnek projeyi bugün itibari ile bitirdim fakat yazıları yazmak ve yayınlamak biraz vaktimi alacak, bu nedenle eğer aşağıda bulunan konulardan herhangi birine ihtiyacınız var ise benimle iletişime geçebilirsiniz, örnek kodları sizinle paylaşabilirim.

Projenin Tanıtımı

Proje Adımları;
1- )    Projemizin oluşturulması ve gereklilikler
2- )    Projenin ana bilgilerini saklayacak common katmanının oluşturulması
3- )    .Net Core Identity ‘nin aktif hale getirilmesi ve code first ile veritabanı tasarımı
4- )    Data Transfer Object (Dto) ‘ların oluşturulması ve Auto Mapper
5- )    Repository ve UnitofWork tasarım desenlerinin eklenmesi
6- )    Web Api projesinin oluşturulması
7- )    ILogger ile dosya sistemine loglama ve AutoHistory ile değişiklik geçmişi
8- )    Usermanager ve Rolemanager ile Identity üzerinde kullanıcı işlemleri
9- )    Jwt token alt yapısı ile kullanıcı authentication alt yapısının kurulması
10- ) Rol bazlı authorization işlemleri
11- ) Web cache kullanımı ve projeye implemente edilmesi
12- ) Web api üzerinde paging alt yapısının kurulması
13- )  SignalR ile canlı veri akışının sağlanması
14- )  Unit testlerin yazılması ve Moq kullanımı
15- ) Swagger

<- Önceki Post – Sonraki Post ->