Log Seviyeleri: Neden Önemli?
Sistemlerimizde yaşadığımız sorunları teşhis etmenin ve performanslarını optimize etmenin temel yolu, ürettikleri logları doğru bir şekilde analiz etmekten geçer. Ancak her şeyin logunu tutmak, bir samanlıkta iğne aramaktan farksız bir duruma yol açabilir. Tersine, çok az log tutmak ise sorunun kaynağını bulmamızı imkansız hale getirebilir. İşte tam bu noktada, log seviyeleri stratejimiz devreye giriyor.
Bu yazıda, farklı log seviyelerinin ne anlama geldiğini, hangi durumlarda hangisini kullanmamız gerektiğini ve bu stratejiyi kendi projelerimde nasıl uyguladığımı detaylıca ele alacağım. Amacım, hem gereksiz gürültüyü azaltarak sistemlerimizi daha verimli hale getirmek hem de kritik durumlarda ihtiyacımız olan tüm bilgiyi eksiksiz bir şekilde elde etmek.
Yaygın Log Seviyeleri ve Anlamları
Loglama, sistemlerin ve uygulamaların çalışma durumlarını kaydetme işlemidir. Farklı seviyeler, kaydedilen bilginin önem derecesini ve detaylılık seviyesini belirtir. Bu seviyeleri doğru anlamak, etkili bir loglama stratejisi oluşturmanın ilk adımıdır.
Genel olarak kabul görmüş log seviyeleri şunlardır:
- TRACE (En Detaylı): Genellikle geliştirme aşamasında veya çok spesifik bir hatayı ayıklamak için kullanılır. Her fonksiyon çağrısını, değişken değerini ve akış kontrolünü kaydedebilir. Production ortamında kullanılması genellikle önerilmez çünkü aşırı miktarda veri üretir.
- DEBUG (Hata Ayıklama): Geliştiricilerin uygulamaların normal çalışma akışını anlamalarına yardımcı olur. Bu seviyede kaydedilen bilgiler, uygulamanın hangi yolları izlediğini, hangi koşulların gerçekleştiğini gösterir.
- INFO (Bilgi): Uygulamanın normal çalışma durumunu gösteren önemli olayları kaydeder. Örneğin, bir kullanıcının giriş yapması, bir işlemin başarıyla tamamlanması gibi. Production ortamında genellikle varsayılan seviye budur.
- WARN (Uyarı): Potansiyel sorunlara işaret eden ancak uygulamanın çalışmasını doğrudan durdurmayan durumları belirtir. Örneğin, bir kaynağın geçici olarak kullanılamaması veya bir konfigürasyonun varsayılan değerlerle çalışması gibi.
- ERROR (Hata): Bir işlemin veya isteğin başarısızlıkla sonuçlandığını gösterir. Bu seviyedeki loglar, uygulamanın düzgün çalışmadığı durumları belirlemek için kritiktir.
- FATAL (Kritik Hata): Uygulamanın veya sistemin çökmesine neden olan, acil müdahale gerektiren ciddi hataları belirtir. Bu seviyede bir log alındığında, genellikle sistemin çalışması durur.
Log Seviyeleri ve Sistem Performansı
Log seviyesini değiştirmek, doğrudan sistem performansını etkileyebilir. Örneğin, TRACE veya DEBUG seviyesinde yoğun bir logging yapmak, diske sürekli yazma işlemi gerektireceği için I/O performansını düşürebilir. Ayrıca, oluşturulan büyük log dosyaları disk alanını hızla tüketebilir ve bu da dolaylı olarak performans sorunlarına yol açabilir.
Strateji Geliştirme: Ne Zaman Ne Kullanmalı?
Etkili bir loglama stratejisi, projenin yaşam döngüsüne, mevcut altyapıya ve izleme ihtiyaçlarına göre şekillenir. Tek bir “doğru” strateji yoktur; en iyisi, projenin gereksinimlerine en uygun olanıdır.
Geliştirme Ortamı (Development Environment)
Geliştirme aşamasında, hataları hızla bulmak ve düzeltmek esastır. Bu nedenle, genellikle daha detaylı log seviyeleri tercih edilir.
- TRACE / DEBUG: Bu seviyeler, kodun akışını anlamak, değişkenlerin değerlerini kontrol etmek ve beklenmedik davranışları tespit etmek için paha biçilmezdir. Örneğin, bir API çağrısının neden başarısız olduğunu anlamak için
DEBUGseviyesindeki loglar, isteğin tam olarak nasıl gönderildiğini ve sunucudan gelen yanıtın ne olduğunu gösterebilir. - INFO: Normal akışın izlenmesi için kullanılır.
Bu ortamda aşırı loglama maliyeti düşüktür, çünkü genellikle yerel makinelerde veya test sunucularında çalışılır. Ancak yine de, aşırı TRACE loglamanın performansı olumsuz etkileyebileceği unutulmamalıdır.
Test Ortamı (Staging/Testing Environment)
Test ortamı, production ortamını taklit etmeli, ancak yine de hata ayıklama için bir miktar esneklik sunmalıdır.
- DEBUG / INFO: Bu seviyeler, uygulamanın farklı senaryolarda nasıl davrandığını görmek için uygundur. Örneğin, yük testleri sırasında veya entegrasyon testlerinde
DEBUGseviyesi, olası darboğazları veya hatalı entegrasyon noktalarını belirlemeye yardımcı olabilir. - WARN / ERROR: Bu seviyeler, test senaryolarının başarısız olduğu durumları tespit etmek için kullanılır.
Production Ortamı (Production Environment)
Production ortamında öncelik, sistemin kararlılığı, performansı ve güvenliğidir. Bu nedenle, loglama seviyeleri daha muhafazakar olmalıdır.
- INFO: Normal operasyonel durumları izlemek için kullanılır. Bir kullanıcının başarıyla oturum açması, bir isteğin başarıyla işlenmesi gibi bilgiler bu seviyede kaydedilir. Bu, genel sistem sağlığını anlamak için yeterli bilgiyi sağlar.
- WARN: Potansiyel sorunları erkenden tespit etmek için önemlidir. Örneğin, bir veritabanı bağlantısının zaman aşımına uğraması ama ardından tekrar kurulabilmesi gibi durumlar uyarı olarak kaydedilebilir.
- ERROR: Gerçekleşen hataları ve bunların etkilerini kaydetmek için kullanılır. Bir isteğin işlenememesi, bir modülün çökmesi gibi durumlar bu seviyede loglanır.
- FATAL: Uygulamanın veya sistemin tamamen durmasına neden olan kritik hatalar için saklanır.
Bu seviyelerde tutulan loglar, hem performans üzerinde minimum etkiye sahiptir hem de sorun giderme için gerekli temel bilgileri sağlar. Gerekli olduğunda, sorun giderme amacıyla geçici olarak daha detaylı log seviyelerine geçiş yapılabilir.
Gerçek Dünya Senaryoları ve Uygulamalarım
Kendi projelerimde ve danışmanlık yaptığım firmalarda, log seviyeleri konusunda çeşitli deneyimlerim oldu. Bu deneyimler, stratejimin evrimleşmesine katkı sağladı.
Senaryo 1: Üretim ERP’sinde Sevkiyat Hataları
Bir üretim ERP sistemi üzerinde çalışırken, sevkiyat raporlarının zaman zaman eksik geldiğini fark ettik. Başlangıçta INFO seviyesinde loglama yapılıyordu. Sorunu tespit etmek için log seviyesini geçici olarak DEBUG seviyesine çıkardık. Bu sayede, sevkiyat işleminin hangi adımlarda takıldığını ve hangi verilerin eksik olduğunu detaylı olarak görebildik.
DEBUG seviyesinde, normalde gizli kalan veritabanı sorgusu görünür hale geldi; sorunun bu sorgunun belirli koşullar altında boş sonuç döndürmesinden kaynaklandığını fark ettik. Sonuç olarak, sorguyu optimize ederek ve eksik veriler için daha fazla hata kontrolü ekleyerek sorunu çözdük. Production’da tekrar INFO seviyesine döndük, ancak bu tür kritik modüller için özel uyarı (WARN) logları ekledik.
Senaryo 2: Kendi Yan Ürünümdeki Performans Sorunları
Kendi geliştirdiğim finansal hesaplayıcı uygulamasının backend’inde, yoğun kullanımlarda yavaşlamalar gözlemledim. Başlangıçta INFO seviyesi yeterli görünüyordu, ancak performans darboğazını bulmak için DEBUG seviyesine geçtim.
Logları incelediğimde, belirli bir hesaplama fonksiyonunun beklenenden çok daha fazla tekrarlandığını gördüm. Bu durum, önbellekleme (caching) mekanizmasında bir hata olduğunu gösteriyordu. DEBUG logları, aynı anahtar için art arda yinelenen “cache miss” kayıtlarını ortaya çıkardı; bu da önbelleğin doğru şekilde güncellenmediğini veya anahtarın yanlış oluşturulduğunu gösteriyordu. Önbellek anahtarını düzelttikten ve güncelleme mantığını iyileştirdikten sonra performans sorunu ortadan kalktı. Production’da INFO ve bazı kritik hesaplamalar için WARN seviyelerini kullanmaya devam ediyorum.
Senaryo 3: Diagnostik Sağlamayan Dış Platformlar
Üçüncü taraf bir platformla (örneğin bir uygulama mağazasının yayınlama süreci) çalışırken sık karşılaşılan bir durum, platformun bir işlemi reddetmesi ama nedenini açıkça söylememesidir. Böyle durumlarda dış sistemden anlamlı bir geri bildirim gelmediği için, çözüm tek başına kendi uygulamanızın loglarına kalır: yayınlama/entegrasyon adımlarını kaydeden özel bir DEBUG katmanı eklemek, hangi alanın ya da isteğin reddedildiğini görünür kılar. İlke basit: diagnostiğini kontrol edemediğiniz bir sistemle konuşuyorsanız, kendi tarafınızdaki loglama tek penceredir; bu yüzden dış entegrasyon noktalarını baştan loglanabilir tasarlamak gerekir.
İleri Düzey Loglama Teknikleri ve Araçlar
Temel log seviyelerinin ötesinde, daha gelişmiş loglama teknikleri ve araçları, sistemlerimizi daha derinlemesine izlememize olanak tanır.
Yapılandırılmış Loglama (Structured Logging)
Geleneksel düz metin (plain text) loglar yerine, yapılandırılmış loglama (örneğin JSON formatında) kullanmak, logların analizini ve sorgulanmasını çok daha kolay hale getirir. Her log girdisi, anahtar-değer çiftleri şeklinde yapılandırılır, böylece belirli alanlara (örneğin user_id, request_id, error_code) göre filtreleme ve arama yapmak çok daha verimli olur.
Örnek bir yapılandırılmış log çıktısı:
{
"timestamp": "2026-05-28T15:00:00Z",
"level": "ERROR",
"service": "auth-service",
"request_id": "abc123xyz789",
"user_id": "user_456",
"message": "Authentication failed: Invalid credentials",
"details": {
"ip_address": "192.168.1.100",
"attempt_count": 3
}
}Bu format, log analiz araçları (örneğin Elasticsearch, Splunk, Loki) tarafından kolayca işlenebilir ve görselleştirilebilir.
Centralize Logging Sistemleri
Dağıtık sistemlerde, farklı servislerden gelen logları tek bir yerde toplamak, genel bir bakış açısı kazanmak için şarttır. Elasticsearch, Logstash, Kibana (ELK Stack) veya Grafana Loki gibi merkezi loglama sistemleri, tüm log verilerini tek bir platformda birleştirerek arama, analiz ve görselleştirme imkanı sunar.
Bu sistemler, sadece logları toplamakla kalmaz, aynı zamanda logları filtreleme, desenleri tanıma ve anormallikleri tespit etme gibi gelişmiş özellikler de sunar. Örneğin, belirli bir hata kodunun belirli bir zaman diliminde ne kadar sık oluştuğunu kolayca görebilirsiniz.
Korelasyon ID’leri (Correlation IDs)
Dağıtık sistemlerde, tek bir isteğin birden fazla servisten geçtiği durumlar yaygındır. Bu isteklerin uçtan uca izlenmesi için korelasyon ID’leri kullanılır. Bir istek ilk servise ulaştığında benzersiz bir ID oluşturulur ve bu ID, isteğin geçtiği tüm sonraki servislere iletilir.
Her servis, kendi loglarında bu korelasyon ID’sini kaydederek, tek bir isteğin yaşam döngüsünü tüm sistem boyunca takip etmeyi mümkün kılar. Bu, bir isteğin hangi serviste takıldığını veya geciktiğini anlamak için hayati önem taşır.
Sonuç: Dengeli Bir Yaklaşım
Log seviyeleri, sistemlerimizin hem sağlığını izlemek hem de olası sorunları çözmek için kullandığımız güçlü bir araçtır. Ancak bu aracın etkili kullanılabilmesi için dengeli bir yaklaşım benimsemek şarttır. Geliştirme ortamında detaylı bilgilere ulaşmak, production ortamında ise sistemi gereksiz yükten ve bilgi kirliliğinden korumak esastır.
Yapılandırılmış loglama, merkezi loglama sistemleri ve korelasyon ID’leri gibi ileri düzey teknikler, log verilerinden maksimum faydayı sağlamamıza yardımcı olur. Unutmamalıyız ki, en iyi loglama stratejisi, projenin ihtiyaçlarına en uygun, sürdürülebilir ve ölçeklenebilir olandır. Bu dengeyi kurarak, sistemlerimizi daha güvenilir, performanslı ve yönetilebilir hale getirebiliriz.