Loglarımızı nasıl tutmalıyız?

Yazının İngilizce versiyonu için bkz.

Son zamanlarda çok fazla log işlemleri ile uğraştığım için yazılımda loglamalar nasıl yapılmalı diye detaylı bir araştırma yapmak istedim. Bu kaynaklardan öğrendiklerimi kaybetmemek amacıyla bir yazı yazmanın ve bu öğrendiklerimi sizinle paylaşmanın iyi olacağını düşünüyorum. O zaman hadi başlayalım.

Log kayıtları, uygulamanın görebildiği hem iç hem de dış olaylarla ilgili bilgileri gösterir. Yazılımda bir hata, güvenlik ihlali veya anormallik olduğunda, log kayıtları olay ile ilgili doğru bir neden analizini yapmak için en yararlı ve güvenilir kaynaktır.

Log’un Tarihi

1980'lerde Sendmail’in bir parçası olarak syslog geliştirildi. Bu diğer geliştiriciler tarafından benimsendi ve standart haline geldi. O zamandan itibaren olgunlaştı gelişti birçok log kütüphanesi hayatımıza girdi.

Log tutmanın avantajları

Günlükleri bir çok farklı amaç için tutuyor olabiliriz. Log kayıtları tutmanın bazı avantajları aşağıdaki şekildedir.

• Sistemimize gelen giden isteklerin IP kaynağını görmek
• Sistemimizin yoğunluğunu anlamak(Kullanıcı Etkileşimleri)
• Sistem davranışlarını tespit etmek (Sistem başlangıç zamanları, durma zamanları)
• Performans istatistiklerini keşfetmek(istek yanıt süreleri)
• Tehditleri ve güvenlik açıklarını tespit etmek(Sürekli başarısız kullanıcı doğrulamaları)

Log Seviyeleri

Log tutarken karşılaşılan en zor şey logların hangi seviyede kaydedilmesi gerektiğidir. Bir hata ararken veya sadece bir uygulama hakkında fikir edinmeye çalışırken, günlüklerde hangi bilgileri bulmayı bekleyebileceğimizi bilmemiz çok yardımcı olur. Ancak, yalnızca log seviyelerini programlarken bir kurala uyduysak ne bekleyeceğimizi bileceğiz. Burada en sık kullanılan loglama seviyelerine bir göz atacağız.

Fatal

Fatal, ciddi bir sorundur. Muhtemelen uygulamanızın down olmasına yol açabilecek ciddi hatalardır. Gecenin bir yarısı olsa bile, derhal düzeltmesi için biri uyarılmalıdır. Production ortamında Fatal olayları için bir tür uyarı olması gerekir.

Error

Error ciddi bir sorundur Fatal’dan farklı olarak burada uygulama içerisindeki database bağlantısı veya bir hizmete erişeme durumu olarak değerlendirebilir.

Error, log düzeyini çok cömert kullanmamaya özen gösterin çünkü bu, günlüklere çok fazla bilgi kirliliği oluşturacak ve tek bir Error olayının önemini azaltacaktır. Ertesi sabaha kadar beklemiş olabilecek bir şey yüzünden gece yarısı uyandırılmak istemezsiniz, değil mi?

Warn

Şimdi daha gri alana giriyoruz. Warn seviyesi, olağandışı bir durum tespit ettiğinizi belirtmek için kullanmalısınız. Belki bir hizmeti çağırmaya çalışıyordunuz ve otomatik yeniden denemeden önce birkaç kez başarısız oldu. Beklenmedik ve olağandışıdır, ancak gerçek bir zararı yoktur ve sorunun devam edip etmeyeceği veya tekrar edip etmeyeceği bilinmemektedir. Biri müsait olduğunda sorunu araştırabilir.

Info

Info, uygulamadaki veya uygulama içindeki bazı nesnelerdeki durum değişikliklerini belgelemek için kullanılmalıdır .

Bu bilgi, geliştirme sırasında ve hatta bazen product ortamda, sistemde gerçekte neler olduğunu izlemek için yardımcı olabilir.

Info düzeyinin kullanımına ilişkin örnekler şunlardır:

• Yeni bir kayıt (örneğin bir kullanıcı) oluşturuldu veya bilgisi değişti.
• Belirli bir kaydın durumu (örneğin bir siparişin) “kargolandı”tan “tamamlandı”ya değişti
• Düzenli olarak çalışan bir Job başlatıldı.

Debug

Debug, hata ayıklama amacıyla kullanılan özel ve ayrıntılı bilgileri belirtir. Bu loglar, kodda adım adım ilerlememize yardımcı olur.İşlemin başlaması, bitmesi, geçen zaman, sorgu için kullanılan parametreler görülebilir.

Trace

Trace, Çok ayrıntılı bilgilerdir, yalnızca geliştirme amaçlı kullanılır. Belirli bir olay hakkında en fazla bilgiyi sağlamak için kullanılır. Bu günlükler değişken değerlerine kadar incelemenize yardımcı olur. Production ortamında deployment sonrasında kısa bir süre için trace mesajlarını tutabilirsiniz, ancak bu log ifadelerini geçici olarak kaydedin, bu kayıtlar sonunda kapatılmalıdır.

Log Tutarken dikkat etmemiz gerekenler

Anlamlı log mesajları yazın

Muhtemelen en önemli konulardan biri loglarının anlamlandırılmasıdır. Bir yazılımcı log kaydı oluştururken genelde direkt exception mesajını loglama eğilimindedir. Ancak önemli olan ilk bakışta hatanın nereden ve neden kaynaklandığını tespit etmekdir.

Transaction failed
Record not found
User operation succeeds

Bu tür bir log mesajından daha kötü bir şey yoktur. Uygun anlamlandırılabilen alanlar olmadan bu log mesajı sadece loglarınızın kalabalık olmasını sağlar.

Aşağıdaki şekilde bir log mesajı yukarıdaki mesajdan çok daha değerlidir.

Transaction failed: Phone 'abcabc' information is incorrect
Product with the id ’12121’ was not found
User 123456 successfully registered a cell phone.

Bu nedenle mesajları daha okunabilir ve anlamlandırabilir halde yazmamız önemlidir.

Mesajlardaki dataları ayrıştırabilir formatta yazmak daha kolay ve anlaşılır olacaktır.

Transaction failed: Phone information is incorrect {User: 123456, Phone: abcabc}
Product with the id ’12121’ was not found {Product: 12121}
User successfully registered a cell phone {User: 123456, Phone: 5*********}

Logları birbirinden ayırmak için bir patern kullanabilirsiniz. Örnek vermek gerekirse APP-S-SUB-CODE şeklinde sırasıyla;
APP: Uygulama adınızın kısaltması
S: 1 harf ile önem derecesi(Örn. D: Debug, I: Info…)
SUB: Kodun ilgili olduğu uygulamanın alt kısmı
CODE: Söz konusu hataya özel sayısal kod

ABC-E-USR-111 - Transaction failed: Phone information is incorrect {User: 123456, Phone: abcabc}
ABC-W-PRD-121 - Product with the id ’12121’ was not found {Product: 12121}
ABC-I-USR-123 - User successfully registered a cell phone {User: 123456, Phone: 5*********}

Şimdi ilk haliyle karşılaştırdığımızda log kayıtlarımız daha anlamlı ve anlaşılır olduğunu farkedebilirsiniz.

Log mesajlarını ingilizce yazın

Bu garip bir tavsiye gibi görünebilir ancak ingilizcenin teknik dile daha uygun olduğunu düşünüyorum. Ancak teknik açıdan inceleyecek olursak. İngilizce mesajlarınızın ASCII karakterleriyle loglara kayıt olacağı anlamına gelir. Mesajınız UTF-8 kullanıyorsa doğru bir şekilde işlenmeyebilir, en kötüsü okunamaz hale gelebilir.

Çok fazla veya Çok az log Kaydı oluşturmayın

Log kayıtları için doğru bir denge vardır. Çok fazla log ve ondan herhangi bir değer elde etmek zor olacaktır. Bu tür loglara manuel göz atarken, çok fazla karmaşa ortaya çıkacaktır. Çok az log kaydında ise sorunu giderememe riskiniz vardır. Sorun giderme zor bir bulmacayı çözmek gibidir, bunun için yeterli materyalinizin olması gerekir.

Ne yazıkki, neyi loglamak için kodlama yaparken sihirli bir kural yoktur.

Örneğin bir android robotunuz olduğunu hayal edin ve ona bugün ne yaptığını sorduğunuzu düşünün.

Senaryo 1: Uyandım, başımı üç santim sağa kaydırdım…
Senaryo 2: Uyandım, taksiye bindim…

Genellikle, robotumuzun yaptığı her şeyi bilmemiz gerekmez. Ancak arızalanmaya başladığında Senaryo 1'i incelemek isteyebiliriz.

Uygulamanız production ortama çıktığında oluşturulan logların analizini yapın ve bulunan problemlere göre log kayıt sayınızı azaltın veya arttırın. Özellikle sorun giderme sırasında, uygulamanın daha detaylı log kaydının olmasını istediğiniz kısımları gözden geçirin. Tabi bu konu operasyon ve geliştirici ekibi arasında bir iletişim gerektirir.

Hasas bilgileri loglarınızın arasına kayıt etmeyin!!!

Log kayıtları sadece hata ayıklama için değil, uyumluluk, denetim içinde faydalıdır. Genelde herşeyi günlüğe kaydedelim eğilimimiz olduğundan, inanılmaz bir bilgi kaynağı olabilirler.

Log kayıtlarımız kullanıcı adları, parolalar, token bilgileri veya diğer hassas bilgiler içeriyorsa bu bir güvenlik açığına neden olabilir. Bu nedenle, log kayıtlarını hassas olarak görmeli ve onları güvende tutmalıyız. Muhtemelen aşağıdaki bilgileri kaydetmemeyi zaten biliyoruz.

• Kredi kartı numaraları
• TC kimlik numaraları
• Şifreler

Ancak aşağıdaki bilgileride kayıt etmemeliyiz.

• Token
• Kişisel isimler
• Telefon numaraları
• Session bilgileri

SONUÇ

Sonuç olarak Log kaydetme karmaşık bir iş olmasa da, bunu doğru yapmak için çok fazla incelik ve denge vardır. Çok az bilgi yetersiz olacaktır. Çok fazla bilgi, alakalı değilse ve uygun bir şekilde kaydedilmezse bunaltıcı olabilir.

Log kayıtları isteğe bağlı değildir. Yeterli log kaydı olmadan uygulamanız karanlıkta çalışıyor olacaktır.

Log analizi gibi kavramları öğrenerek , log kaydetmenin sorun gidermede bir yardımdan çok daha fazlası olabileceğini anlayacaksınız. Gerektiği zaman log dosyalarınızda uykuda olan bilgileri çıkarabilirsiniz. Bu tür bilgilerle donanmış olarak daha iyi kararlar verebilir ve hatta sorunların oluşmasını önleyebilirsiniz. Bu size sihir gibi geliyorsa, değil. Bu, log yönetimini benimseyerek kazanacağınız yetenektir.

Kaynaklar

Wikipedia — Syslog
Tom Hombergs — Tip: Use Logging Levels Consistently
Thilina Ashen Gamage — Enterprise Application Logging Best Practices (A Support Engineer’s Perspective)
Dave Swersky — C# Logging best practices in 2021 with examples and tools
Priscill Orue — Python Logging Guide — Best Practices and Hands-on Examples
SentinelOne — Java Exceptions and How to Log Them Securely
SentinelOne — Logging Best Practices: The 13 You Should Know
Tomasz Nurkiewicz — 10 Tips for Proper Application Logging