Yazılım loglama, performans testinden ayrı bir operasyon disiplindir. Bu rehberde KOBİ uygulamalarında hata, iş olayı ve uyarı sinyallerini hangi seviyede tutmanız gerektiğini sade adımlarla netleştiriyoruz.
Canlıya aldığınız uygulama bir süre sorunsuz çalışır; sonra kullanıcı “işlem tamamlanmadı” der, ekip de log klasöründe kaybolur. Yazılım loglama, bu belirsizliği azaltmak için hata, iş olayı ve uyarı sinyallerini bilinçli biçimde kaydetme işidir. Amaç her satırı saklamak değil; sorun anında “ne oldu, kim etkilendi, nereden başlayalım?” sorularına hızlı cevap verebilmektir.
Bu rehber performans testinden ayrı tutulur. Yük ve darboğaz senaryoları için ayrı bir plan gerekir; burada günlük operasyonda neyin tutulacağı, neyin tutulmayacağı ve hangi seviyede tutulacağı netleştirilir. KepezWeb ekiplerinin KOBİ projelerinde sık gördüğü kalıp şudur: ya çok az log vardır ya da gürültü o kadar fazladır ki gerçek hata görünmez.
Yazılım loglama ile izleme aynı şey mi?
Kısaca hayır. Loglama, uygulamanın ürettiği kayıtları (satır satır olaylar) tutmaktır. İzleme (monitoring) ise bu kayıtlar ve metrikler üzerinden sistemin sağlığını sürekli gözlemektir. İkisi birlikte çalışır ama karar noktaları farklıdır.
- Log: “Sipariş #4521 ödeme adımında zaman aşımına düştü.”
- Metrik/izleme: “Son 15 dakikada ödeme zaman aşımı oranı %8’e çıktı.”
- Uyarı: Eşik aşıldığında ekibe giden sinyal.
KOBİ ölçeğinde önce okunabilir log disiplinini kurmak, sonra uyarı eşiklerini sadeleştirmek genelde daha az maliyetli ve daha sürdürülebilir bir yoldur. Performans tarafındaki yük senaryolarını ayrıca planlamak isterseniz yazılım performans testi rehberine bakabilirsiniz.
KOBİ uygulamasında hangi log seviyeleri tutulmalı?
Seviye kararı, depolama maliyetinden çok okunabilirlik kararınıdır. Canlı ortamda her şeyi DEBUG seviyesinde bırakmak, aradığınız hatayı gürültüye boğar.
Önerilen seviye kullanımı
- ERROR: İşlem başarısız oldu, kullanıcı veya entegrasyon etkilendi. Mutlaka tutun.
- WARN: Henüz çökme yok ama bozulma sinyali var (yeniden deneme, yavaş yanıt, eksik alan, kota yaklaşımı).
- INFO: Anlamlı iş olayları: oturum açma denemesi sonucu, sipariş oluşturuldu, fatura kesildi, webhook alındı.
- DEBUG: Geliştirme ve kontrollü teşhis için. Canlıda sürekli açık tutmayın; kısa süreli açıp kapatın.
Pratik kural: Canlıda varsayılan INFO + WARN + ERROR olsun. DEBUG’ı yalnızca bir hatayı yeniden üretmek için, sınırlı süre ve sınırlı modül için açın. Bu yaklaşım, “her şeyi loglayalım” refleksinden daha ucuz ve daha kullanışlıdır.
Günlük hata loglarında mutlaka bulunması gerekenler
Hata logu “exception stack”ten ibaret olmamalıdır. KOBİ ekibinde gece yarısı bakacak kişi, bağlam olmadan ilerleyemez. Her ERROR kaydında şu alanlar mümkün olduğunca standart olsun:
- Zaman damgası (UTC veya net zaman dilimiyle)
- İstek/işlem kimliği (correlation id veya request id)
- Kullanıcı veya hesap kimliği (kişisel veri sızdırmadan, mümkünse dahili id)
- Modül veya uç nokta adı
- Hata kodu ve kısa mesaj
- Yeniden denenebilir mi bilgisi
- Bağımlı servis adı (ödeme, kargo, e-posta, ERP vb.)
Örnek iş diliyle: “Ödeme sağlayıcı 30 sn içinde yanıt vermedi; sipariş beklemede bırakıldı; kullanıcıya yeniden dene mesajı gösterildi.” Bu cümle, yalnızca “TimeoutException” satırından çok daha hızlı aksiyon üretir.
İş olayı logları: hata yokken de neyi kaydetmelisiniz?
Birçok KOBİ yalnızca çöken istekleri loglar. Oysa anlaşmazlık, destek ve denetim anında asıl ihtiyaç “başarılı ama tartışmalı” adımlardadır. İş olayı logu, uygulamanın iş kurallarını iz bırakan kaydıdır.
Önceliklendirilecek olay örnekleri:
- Kayıt oluşturma, güncelleme, iptal ve iade
- Yetki değişimi (rol atama, erişim açma/kapama)
- Ödeme başlatma, onay, başarısızlık ve iade
- Stok rezervasyonu ve rezervasyon düşümü
- Dış sisteme giden/gelen kritik webhook’lar
- Toplu içe aktarma veya toplu güncelleme işlemleri
Her iş olayında “kim / ne / ne zaman / hangi kayıt / sonuç” sorularını cevaplayan kısa bir yapı kullanın. Bu kayıtlar, destek ekibinin “müşteri böyle demiyor” tartışmasını dakikalar içinde netleştirir. Özel uygulama tarafında bu olay modeli, yazılım geliştirme sürecinin kabul kriterlerine de eklenebilir.
Uyarı sinyalleri: ne zaman alarm, ne zaman sadece log?
Her WARN satırı alarm olmamalıdır. Aksi halde ekip bildirim yorgunluğuna girer ve gerçek kesintiyi kaçırır. Uyarıyı log seviyesinden ayırın: log kayıt üretir, uyarı insanı harekete geçirir.
Alarm vermeye değer sinyaller
- Kritik akışta ardışık hatalar (ör. ödeme veya giriş)
- Kuyruk birikmesi veya işlenmeyen mesaj artışı
- Disk, bellek veya bağlantı havuzu tükenme eşiğine yaklaşma
- Zamanlanmış görevin atlanması veya aşırı gecikmesi
- Dış servis hata oranının kısa sürede sıçraması
Alarm vermeden logda tutulacaklar
- Tekil, kendiliğinden düzelen yeniden denemeler
- Kullanıcı kaynaklı doğrulama hataları (yanlış şifre, eksik form alanı)
- Beklenen iş kuralları (stok yetersiz, kupon geçersiz)
Başlangıç için üç alarm yeterlidir: kritik hata oranı, iş kuyruğu gecikmesi ve bağımlı servis erişilemezliği. Sonra gerçek olaylara göre eşiği sıkılaştırın; baştan onlarca alarm tanımlamayın.
Ne tutulmamalı? Gürültü ve riskli veri
İyi loglama, “daha fazla satır” değil “daha az ama doğru satır” demektir. Aşağıdakileri bilinçli biçimde dışarıda bırakın veya maskeleyin:
- Parola, token, API anahtarı, oturum çerezi
- Kart numarası, CVV, tam kimlik numarası gibi hassas alanlar
- Her istek için devasa istek/yanıt gövdesi (özellikle canlıda)
- Döngü içinde tekrarlayan aynı DEBUG satırı
- Kişisel veri içeren serbest metin alanları (gerekmedikçe)
KVKK ve müşteri güveni açısından “gerekli minimum veri” ilkesi loglara da uygulanmalıdır. Teşhis için gerçekten lazım olan kimlikleri dahili id ile tutun; ham kişisel veriyi varsayılan log akışına dökmeyin.
Saklama süresi, erişim ve operasyon rutini
KOBİ’lerde en sık atlanan kısım, logun “kim bakacak, ne kadar saklanacak, nasıl aranacak” sorularıdır. Teknik araç seçiminden önce bu operasyon çerçevesini yazın.
| Kayıt türü | Canlıda varsayılan | Arama ihtiyacı | Not |
|---|---|---|---|
| ERROR | Açık | Yüksek | Correlation id zorunlu |
| WARN | Açık | Orta | Eşik aşarsa alarma bağla |
| INFO (iş olayı) | Seçili olaylar | Yüksek | Destek ve denetim için kritik |
| DEBUG | Kapalı / geçici | Düşük | Süre ve modül sınırlı aç |
Saklama süresini “mümkün olan en uzun” diye açmak yerine iş ihtiyacına bağlayın: destek SLA’sı, muhasebe itiraz penceresi, entegrasyon partnerlerinin geri bildirim süresi. Erişimi de daraltın; herkesin üretim logunu indirmesi hem güvenlik hem gürültü riskidir.
Haftalık kısa bir rutin faydalıdır: en sık ERROR’lar, en gürültülü WARN’lar, alarm yanlış pozitifleri. Bu gözden geçirme, teknik borcun görünür hale gelmesine de yardım eder ve yazılım yol haritası içinde izleme iyileştirmelerine yer açar.
Uygulanabilir kurulum kontrol listesi
Yeni veya mevcut KOBİ uygulamasında şu sırayla ilerleyin:
- Kritik iş akışlarını listeleyin (giriş, sipariş, ödeme, iptal, entegrasyon).
- Her akış için ERROR, WARN ve INFO olaylarını tek sayfada tanımlayın.
- Correlation id’yi istek başından sonuna taşıyın.
- Canlı log seviyesini INFO+WARN+ERROR yapın; DEBUG’ı kapatın.
- Hassas alanlar için maskeleme kuralı koyun.
- En fazla 3–5 anlamlı alarm ile başlayın.
- Destek ekibine “şu id ile logda ara” talimatını yazın.
- İlk ay yanlış alarmları temizleyin; sonra eşiği sıkılaştırın.
Bu liste, pahalı bir platform satın almadan önce bile disiplini kurmanızı sağlar. Araç sonra gelir; önce neyin anlam ifade ettiği netleşmelidir. Riskli bir entegrasyonu denemeden önce kapsamı küçültmek isterseniz proof of concept yaklaşımı da yardımcı olur.
Sıkça Sorulan Sorular
Yazılım loglama performans testinin yerine geçer mi?
Hayır. Loglama günlük hata ve iş olaylarını görünür kılar; performans testi ise belirli yük altında darboğazı ölçer. İkisi birbirini tamamlar, birbirinin yerine konmaz.
Küçük bir ekipte merkezi log platformu şart mı?
Şart değildir. Önce tutarlı format, seviye politikası ve aranabilir dosya/akış disiplini kurun. Hacim ve ekip büyüdükçe merkezi arama ihtiyacı kendiliğinden netleşir.
Her kullanıcı tıklamasını loglamak gerekir mi?
Gerekmez. Anlamlı iş olaylarını ve hataları tutun. Her tıklama kaydı hem gürültü üretir hem de kişisel veri riskini büyütür.
DEBUG canlıda ne kadar süre açık kalabilir?
Yalnızca teşhis süresince ve ilgili modülle sınırlı kalmalıdır. İş bitince kapatın; aksi halde depolama şişer, gerçek hata kaybolur.
İş olayı logu ile denetim kaydı aynı mıdır?
Çoğu zaman örtüşür ama aynı şey olmak zorunda değildir. Denetim kaydı yetki, değişiklik ve sorumluluk izine odaklanır; iş olayı logu operasyonel akışı da kapsar. Kritik değişikliklerde ikisini de karşılayan alanlar kullanın.
Uygulamanızda yazılım loglama ve izleme çerçevesini sade, sürdürülebilir ve destek ekibinin gerçekten kullanacağı biçimde kurmak istiyorsanız KepezWeb ile ihtiyacınızı konuşabilirsiniz. Kapsamı netleştirmek ve size uygun yaklaşımı birlikte belirlemek için teklif al sayfasından bize ulaşmanız yeterli.
