E-Ticarette Log Analizi: 4xx/5xx ve Ödeme Hataları

E‑ticarette Log Analizi Neden Bu Kadar Önemli?

E‑ticarette büyümeyi değerlendirirken dönüşüm oranı ve yarım kalan sepetler önemli inceleme başlıklarıdır. Trafik satın alır, kampanyalar kurgular, tasarımı iyileştirirsiniz; fakat bazı kullanıcılar tam ödeme adımında ayrılabilir. Analytics araçları size belli bir seviyeye kadar yol gösterir, ancak teknik sorunları anlamak için sunucu loglarını uygulama kayıtları, ödeme raporları ve kullanıcı akışı verileriyle birlikte değerlendirmek gerekir.

Loglama yapılandırmasına bağlı olarak hangi URL’nin hangi durum koduyla yanıtlandığını ve, süre alanı kaydediliyorsa, yanıtın ne kadar sürdüğünü görebilirsiniz. Ödeme callback hatalarını ilgili siparişle eşleştirmek veya bir isteğin gateway’e ulaşıp ulaşmadığını araştırmak için uygulama kayıtları ve sağlayıcı raporları da gerekir. Bu kayıtlar dönüşüm kaybına yol açabilecek teknik sorunları araştırmaya yardımcı olur; tek başına kayıp satış miktarını göstermez.

Bu yazıda DCHost ekibi olarak, e‑ticaret sitelerinde loglardan 4xx/5xx ve ödeme hatalarını nasıl araştırabileceğinizi, bu bulguları dönüşüm kaybı riskiyle nasıl ilişkilendirebileceğinizi anlatacağız. Apache/Nginx erişim loglarından uygulama ve ödeme loglarına, basit komutlarla hızlı analizden merkezi loglama ve alarm kurallarının planlanmasına kadar pratik bir yol haritası paylaşacağız.

Dönüşüm Kaybını Anlamak İçin Hangi Loglara Bakmalısınız?

Önce resme yukarıdan bakalım: E‑ticaret sitenizde kullanıcı yolculuğu kabaca şöyle işler:

• Ürün listeleme ve detay sayfaları
• Sepete ekleme
• Sepet görüntüleme
• Ödeme/checkout adımları
• Ödeme sonucu (başarılı/başarısız)

Bu yolculuğun her adımında farklı loglar devreye girer. Dönüşüm kaybının kök nedenini bulmak için bu logları birlikte okumak gerekir.

1. Web sunucu erişim logları (access.log)

Apache veya Nginx erişim logları, loglama kapsamına alınan HTTP isteklerini satır satır kaydeder. Alanlar yapılandırılan formata bağlıdır; tipik bir combined formatındaki satırda şunlar bulunur:

• IP adresi
• Tarih ve saat
• HTTP metodu (GET/POST vb.)
• İstenen URL ve query string
• HTTP durum kodu (200, 301, 404, 500 vb.)
• Cevap boyutu
• Referer (hangi sayfadan gelmiş)
• Kullanıcı ajanı (tarayıcı bilgisi)

Bu loglar sayesinde:

• Sepet ve ödeme URL’lerinde kaç istek yapıldığını,
• Bu URL’lere gelen isteklerin ne kadarının 4xx/5xx ile sonuçlandığını,
• Hangi saatlerde hata oranının yükseldiğini

hızlıca görebilirsiniz. Apache/Nginx formatlarını ve 4xx/5xx okumayı daha temelden öğrenmek istiyorsanız, ayrıntılı bir başlangıç için Apache ve Nginx ile 4xx–5xx hatalarını teşhis rehberi yazımıza da mutlaka göz atın.

2. Web sunucu hata logları (error.log)

Erişim logları bize “ne oldu”yu söyler; web sunucusu, PHP çalışma ortamı ve uygulama hata logları ise çoğu zaman “neden oldu”yu araştırmaya yardımcı olur. Yapılandırmaya bağlı olarak farklı dosyalarda bulunabilecek örnekler:

• PHP fatal error nedeniyle patlayan ödeme sayfası
• 3. parti ödeme API’sine bağlanamayan cURL çağrıları
• Veritabanı bağlantı hataları (too many connections, timeout vb.)

Ödeme adımında kullanıcı 500 hatası görüyorsa, ayrıntılar error.log dosyasında veya ayrı çalışma ortamı ve uygulama loglarında bulunabilir. Bu yüzden access.log kayıtlarını aynı zaman aralığındaki ilgili hata kayıtlarıyla eşleştirmek gerekir.

3. Uygulama ve framework logları

Eğer WooCommerce, Laravel, Symfony, custom PHP veya Node.js tabanlı bir e‑ticaret uygulamanız varsa, uygulama seviyesi loglar işin röntgeni gibidir. Loglama yapılandırmasıyla kaydedilebilecek örnekler:

• “cart_add”, “checkout_started”, “payment_initiated”, “payment_success”, “payment_failed” gibi olay logları
• Hata detayları (exception mesajları, stack trace)
• Kullanıcı veya sepet ID’si, sipariş numarası gibi korelasyon alanları

Bu logları yapılandırılmış (JSON gibi) formatta tutarsanız, merkezi bir log sistemi ile (ELK, Loki vb.) sorgular ve paneller kurabilirsiniz. Grafana Loki + Promtail ile merkezi loglama rehberimiz eski Promtail kurulumlarını anlamak için değerlendirilebilir. Grafana’nın resmi Promtail belgesine göre Promtail, 2 Mart 2026’da kullanım ömrünü tamamladı; desteği sona erdi ve yeni güncelleme almayacak. Yeni Loki kurulumlarında Grafana Alloy veya desteklenen başka bir istemci seçin; mevcut Promtail kurulumları için de geçiş planlayın.

4. Ödeme sağlayıcı ve banka logları

Ödeme sürecinde genellikle şu adımlar vardır:

• Ödeme isteği: Sitenizden banka/ödeme kuruluşuna istek gönderilir.
• 3D Secure doğrulaması gerekiyorsa kullanıcıdan ek doğrulama istenebilir; akış entegrasyona göre değişir.
• Callback/Webhook: Entegrasyon destekliyorsa banka veya ödeme kuruluşu durum bildirimi gönderir. Tarayıcı dönüşü ile sunucudan sunucuya bildirim aynı şey değildir; ödeme durumu sağlayıcının doğrulama akışına göre teyit edilir.

Burada iki tür log kritik:

• Sizin uygulamanızdaki ödeme logları: ödeme isteğinin zamanı, işlem referansı, dönen hata kodları ve sipariş ID’leri. Ham istek gövdeleri yerine gerekli alanları seçin; kart numarası, CVV, erişim anahtarları ve oturum belirteçlerini kaydetmeyin. URL/query string ve hata ayrıntılarında da bu verilerin sızmasını önleyin.
• Ödeme sağlayıcının logları: sağlayıcının erişime açtığı işlem kayıtları; bunlar panele veya dışa aktarılan raporlara dahil olabilir.

Sunucu loglarını bu ödeme raporları ile birleştirdiğinizde, hangi teknik sorunların reddedilen veya yarım kalan ödemelere neden olduğunu daha net görürsünüz.

5. Veritabanı ve kuyruk logları

Örnek bir e‑ticaret mimarisinde sipariş oluşturma ve e‑posta/entegrasyon işleri kuyruk (queue) sistemleriyle asenkron yürütülebilir. Bu durumda:

• Veritabanı hata logları ve slow query logları
• Queue worker logları (örneğin Laravel Queue, Horizon vb.)

özellikle kampanya dönemlerinde kritik hale gelir. Veritabanı yavaşladığında ya da queue tüketemez hale geldiğinde, ödeme almanız mümkün olsa bile siparişiniz “beklemede” kalabilir. Bu da kullanıcı tarafında güven kaybı ve destek yükü demektir.

6. Log saklama süreleri ve disk yönetimi

Log analizi planlanırken disk dolması riski de hesaba katılmalıdır. Uzun süre saklanan loglar disk alanını tüketip sitenin hata vermesine yol açabilir. Bu dengeyi doğru kurabilmek için:

• logrotate ile günlük/haftalık döndürme ve sıkıştırma
• Log türüne göre inceleme amacı, veri minimizasyonu ve uygulanabilir yükümlülükleri değerlendirerek saklama süresi belirleme; 90 gün veya 6 ay gibi süreleri zorunlu ya da asgari süre değil, planlama örneği olarak ele alma
• Gerekirse eski logları daha ucuz bir depolama alanına taşıma; arşivler dahil süre sonunda silmeyi planlama

gibi önlemleri mutlaka planlamalısınız. Bu konuda pratik adımları görmek için logrotate ile disk dolma hatasını önleme rehberimize bakabilirsiniz. Ayrıca hosting ve e‑posta altyapısında log saklama süreleri yazımız, hangi logu ne kadar tutmanız gerektiği konusunda iyi bir çerçeve sunuyor.

4xx ve 5xx Hataları Dönüşüm Kaybı Riskini Nasıl Gösterir?

HTTP durum kodları, log analizinde iyi bir başlangıç noktasıdır. Kullanıcıya açık bir hata mesajı gösterilmese bile başarısız istekler loglarda görülebilir. Ancak bir hata kaydını kayıp satışla ilişkilendirmek için kullanıcı akışı ve ödeme sonucu da incelenmelidir.

4xx hataları: Kullanıcı veya istemci kaynaklı görünen sorunlar

En sık göreceğiniz 4xx kodları:

• 404 Not Found: Kaynak bulunamadı. Sık rastlanıyorsa yanlış linkler, bozuk butonlar veya eksik yönlendirmeler olabilir.
• 403 Forbidden: Yetkisiz erişim. Doğru kullanıcılar yanlışlıkla engelleniyorsa güvenlik kuralları (WAF, firewall) agresif olabilir.
• 429 Too Many Requests: Rate limiting devrede. Kampanya dönemlerinde ödeme veya sepet adımlarında 429 artışı görüyorsanız, limitleri gözden geçirmek gerekir.

Özellikle sepet ve ödeme URL’lerinde 4xx oranının artması, dönüşüm kaybı riski için bir sinyaldir; bot istekleri, engellenmesi gereken erişimler ve başarılı yeniden denemeler ayrıştırılmadan doğrudan kayıp satış sayılmaz. Örneğin /sepet, /checkout, /odeme gibi URL’ler için 404 ve 403’leri günlük olarak takip etmenizi öneririz.

5xx hataları: Sunucu taraflı sorunlar

5xx kodları sunucu tarafında isteğin tamamlanamadığını gösterir; kaynak kendi altyapınız, bir ara katman veya bağımlı bir servis olabilir:

• 500 Internal Server Error: Genelde uygulama hataları (PHP exception, kod bug’ı).
• 502 Bad Gateway: PHP-FPM, Node.js veya upstream servis yanıt veremedi/yanlış yanıtladı.
• 503 Service Unavailable: Servis geçici olarak kullanılamıyor; bakım, limit aşımı veya aşırı yük altında.
• 504 Gateway Timeout: Arkadaki servis belirlenen sürede yanıt veremedi (genelde yavaş DB veya API).

Bu kodları zaman, URL ve kullanıcı akışı ile birlikte analiz ettiğinizde, dönüşüm kaybına yol açabilecek teknik sorunları daraltabilirsiniz.

Basit komutlarla 4xx/5xx istatistikleri çıkarmak

Küçük ve orta ölçekli sitelerde, SSH erişiminiz varsa basit komutlarla bile hızla içgörü elde edebilirsiniz. Örneğin aşağıdaki komutlar, boşlukla ayrıldığında istek hedefinin 7., durum kodunun 9. alan olduğu standart combined düzenindeki bir Nginx access.log dosyasını varsayar. Önce kendi log formatınızda bu alanları doğrulayın. Komutlar yalnızca verilen dosyayı tarar; zaman filtresi uygulamaz ve döndürülmüş logları kapsamaz:

• En çok görülen 5xx hataları:
  awk '$9 ~ /^5[0-9][0-9]$/ {print $9}' access.log | sort | uniq -c | sort -nr | head
• En çok 404 dönen ilk 10 URL:
  awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -nr | head
• Dosyadaki /sepet yoluna ait 5xx yanıt sayısı (query string dahil):
  awk '$9 ~ /^5[0-9][0-9]$/ {if ($7 ~ /^\/sepet(\?|$)/) n++} END {print n+0}' access.log

Bu komutlar, verilen dosyada en çok görülen 5xx kodlarını, en çok 404 dönen URL’leri ve /sepet yolunun 5xx yanıt sayısını göstererek incelemeye nereden başlayacağınızı belirlemenize yardımcı olur. Ani hata artışlarını görmek için kayıtları zaman aralıklarına göre gruplayıp toplam istek sayılarıyla oranlayın. Yanlış yönlendirmeleri araştırmak için ise 3xx yanıtlarını, yönlendirme hedeflerini ve zincirlerini ayrıca inceleyin; bu komutlar bunları göstermez.

Kritik funnel sayfalarına ayrı gözle bakmak

Tüm sitenin hata oranına değil, satış hunisinin kritik adımlarına odaklanmalısınız. Örneğin:

• Ürün detay sayfaları: /urun/, /product/ vb.
• Sepet: /sepet, /cart
• Checkout: /odeme, /checkout, /payment
• Sonuç sayfası: /siparis-tamam, /order-success vb.

Her bir adım için ayrı ayrı:

• Toplam istek sayısı
• 4xx oranı
• 5xx oranı

çıkardığınızda, örneğin aynı zaman aralığında checkout sayfasındaki 500 hata oranının site genelindeki oranın 5 katı olduğunu görürseniz doğrudan oraya odaklanabilirsiniz.

Sepet ve Ödeme Adımlarında Log Tabanlı Funnel Analizi

Log analizi sadece hataları saymak değildir; aynı zamanda kullanıcı yolculuğunu aşama aşama takip etmektir. Bunu e‑ticaret özelinde basit bir funnel kurgusuyla yapabilirsiniz.

URL desenleriyle adımları tanımlamak

İlk adım, access.log içinde sepet ve ödeme sürecine ait URL’leri netleştirmektir. Örneğin:

• Adım 1 – Sepet görüntüleme: /sepet
• Adım 2 – Adres/fatura bilgileri: /odeme/adres
• Adım 3 – Ödeme yöntemi seçimi: /odeme/yontem
• Adım 4 – Ödeme sonucu: /odeme/sonuc

Ardından loglarda bu URL’leri filtreleyerek, belirli bir zaman aralığında:

• Bu adımlara kaç farklı izleme oturumu girdi? IP ve user agent birleşimi benzersiz kullanıcıyı güvenilir biçimde tanımlamaz; oturum sayısı da kişi sayısıyla aynı değildir.
• Aynı oturum grubunda, adımların zaman sırası ve tanımlı tamamlanma süresi dikkate alındığında kaç oturum bir sonraki adıma geçmedi?
• Hangi adımda 4xx/5xx oranı anormal yüksek?

sorularına yanıt ararsınız. Ödeme sonuç URL’sinin ziyaret edilmesi tek başına başarılı ödeme kanıtı değildir; dönüşümü doğrulanmış ödeme ve sipariş durumuyla eşleştirin. Daha detaylı örnek funnel kurguları ve alarm senaryoları için e‑ticaret sepet ve ödeme adımlarını izleme rehberimizi inceleyebilirsiniz.

Uygulama loglarına olay bazlı kayıt eklemek

Sadece URL ile çalışmak bir yere kadar götürür. Daha derin analiz için, uygulama seviyesinde şu tip olay logları üretmenizi tavsiye ediyoruz:

• cart_viewed, cart_updated, checkout_started
• payment_initiated, payment_redirected, payment_callback_received
• payment_success, payment_failed

Bu olayları tek satırlık JSON logları olarak yazabilirsiniz. Örneğin:

{"event":"payment_failed","order_id":12345,"reason":"3d_auth_failed","user_id":678}

Bu kısa örneğe ek olarak zaman damgası ve benzersiz ödeme girişimi kimliği kaydedilmelidir. Banka veya kart türü karşılaştırması gerekiyorsa yalnızca analiz için gerekli sınıflandırma alanlarını ekleyin; kart numarası ya da diğer ödeme sırlarını kaydetmeyin. Kullanıcı ve sipariş kimlikleriyle ilişkilendirilen kayıtların erişimini sınırlandırın. Başarı ve başarısızlık olayları girişim bazında tekilleştirildiğinde, merkezi log sisteminizde şu tip sorgular yapabilirsiniz:

• Son 24 saatte başlatılan benzersiz ödeme girişimlerinin ne kadarı payment_failed ile sonuçlandı? Henüz sonucu bilinmeyen girişimleri ayrıca gösterin.
• Hangi bankalarda veya kart türlerinde hata oranı daha yüksek?
• Hangi saat aralığında teknik nedenli ödeme hataları artmış?

Oturum bazlı funnel ve korelasyon

Oturum veya sepet için kimlik doğrulamada kullanılamayan ayrı bir korelasyon ID’si oluşturun; bunu cart_id ve oluştuğunda order_id ile ilişkilendirin. Gerçek oturum erişim belirtecini loglamayın. Bu izleme ID’sini:

• access.log’ta ilgili isteklere, log formatında bu alanı ayrıca tanımlayarak ve ham Cookie başlığını kaydetmeden,
• uygulama loglarına,
• ödeme loglarına

eklediğinizde, eşleştirilebilen bir oturumun sepetten ödemeye kadar ilerleyişini takip edebilirsiniz. Hatalardan etkilenen oturumları ve sipariş tutarlarını hesaplayabilirsiniz; ancak bu tutarlar kesin ciro kaybı değildir. Sonraki başarılı denemeleri ve siparişlerin nihai durumunu da hesaba katmalısınız.

Ödeme Hatalarını Sunucu Loglarından Yakalamak

Ödeme adımı, dönüşüm kaybının en can acıtan noktasıdır. Buradaki hatalar siparişin tamamlanmasını engelleyebilir; ancak yeniden denemeyle tamamlanan ödemeler doğrudan ciro kaybı sayılmamalıdır. Ödeme hataları kabaca ikiye ayrılır:

• Kullanıcı/banka kaynaklı hatalar: yetersiz bakiye, kartın reddedilmesi, 3D şifre hatası vb.
• Teknik hatalar: timeout, 5xx, yanlış imza, callback’in işlenememesi vb.

Doğru log stratejisi, kaydı oluşan teknik hataları ilişkilendirmeyi kolaylaştırır. Sitenize ulaşmayan istekler veya log üretimini kesintiye uğratan arızalar için sağlayıcı kayıtları ve bağımsız izleme de gerekir.

Ödeme sağlayıcı hata kodlarını normalleştirmek

Farklı bankalar ve ödeme sağlayıcılar farklı hata kodları ve mesajlar kullanır. Bunları uygulama tarafında birkaç kategoriye indirgemek, log analizi için hayat kurtarıcıdır. Örneğin:

• technical_error (timeout, 5xx, network, imza doğrulama hatası)
• bank_decline (banka reddi, limit yetersiz vb.)
• user_canceled (kullanıcı iptalini doğrulayan sonuç; yalnızca 3D sayfasından geri dönmek kesin iptal kanıtı değildir)

Her ödeme girişiminin sonucuna sağlayıcının belgelenmiş kod eşlemesine göre normalleştirilmiş bir alan ekleyin; sonucu bilinmeyen girişimleri ayrı tutun. Oranlar için toplam girişimleri de kaydedin. Kampanya veya trafik kaynağı karşılaştırması yapacaksanız bu bilgileri girişimle ilişkilendirin. Böylece şu tip sorgular yapabilirsiniz:

• Son 1 saatte technical_error oranında ani artış var mı?
• Hangi kampanya veya trafik kaynağında bank_decline oranı daha yüksek?

Timeout ve performans kaynaklı ödeme problemleri

Ödeme sürecinde timeout’lar teknik sorunlara yol açabilir. Örneğin şu senaryo yaşanabilir:

• Kampanya döneminde trafik artar.
• Veritabanı yavaşlar veya kilitlenir.
• Ödeme isteğinin işlendiği PHP/uygulama kodu zamanında yanıt veremez.
• Kullanıcı ya hata görür ya da banka sayfasında takılı kalır.

Bu tip problemleri loglardan yakalamak için:

• access.log’da istek süresi alanı kaydediliyorsa, bu alanın birimini dikkate alarak uzun süren istekleri (örneğin > 2 sn) işaretlemek,
• error.log’da gateway timeout veya connection timeout mesajlarını filtrelemek,
• uygulama loglarında ödeme fonksiyonlarının çalışma sürelerini ölçmek

çok işe yarar. Altyapı tarafında performans optimizasyonu gerekiyorsa, WooCommerce ve büyük katalog siteleri için MySQL indeksleme rehberi veya PHP tarafında doğru memory_limit ve max_execution_time ayarları gibi yazılarımızdan da faydalanabilirsiniz.

Callback ve webhook sorunlarını loglardan yakalamak

Entegrasyonunuz kullanıyorsa, banka/ödeme kuruluşunun sitenize gönderdiği callback/webhook istekleri ödeme durumunun işlenmesinde kritik rol oynayabilir. Bu isteklerde yaşanan problemler:

• Kullanıcı kartından para çekilmiş olsa bile siparişin sisteminizde oluşmamasına,
• Siparişin “beklemede” kalmasına,
• Stok ve muhasebe kayıtlarının tutmamasına

neden olabilir. Callback sorunlarını loglardan yakalamak için:

• Callback URL’sine gelen isteklerin zaman, korelasyon ID’si ve işleme sonucu gibi gerekli metaverilerini ayrı bir log dosyasında toplamak; ham ödeme gövdesini, imza sırlarını veya erişim belirteçlerini kaydetmemek,
• Bu istekler için HTTP durum kodlarını (200, 400, 500) düzenli izlemek,
• Başarısız callback’ler için otomatik alarm üretmek

yararlıdır. Artan 4xx/5xx kodları tek başına nedeni göstermez; uygulama hata kayıtlarını, doğrulama sonuçlarını ve varsa WAF kayıtlarını aynı istek üzerinden ilişkilendirin. HTTP 200 yanıtı da siparişin doğru güncellendiğini tek başına kanıtlamaz; uygulamadaki işleme sonucunu ve nihai ödeme durumunu izleyin.

Alarm, Rapor ve Otomasyon: Log Analizini Günlük Rutine Çevirmek

Log analizi bir kerelik bir çalışma değil, yaşayan bir süreç olmalıdır. Bunu gerçekten faydalı hale getirmek için üç katmanlı bir yapı öneriyoruz: alarm, gösterge paneli ve düzenli raporlar.

Anlık alarm kuralları

Anlık alarmın hedefi, müdahale gerektiren hata artışlarını ekibe bildirmektir. Aşağıdaki eşikler başlangıç örnekleridir; trafik hacmine ve olağan hata düzeyine göre ayarlayın. Oran alarmlarında asgari örnek sayısı belirleyin, log tekrarlarını tekilleştirin ve sayısal artışları toplam ödeme girişimi sayısıyla birlikte değerlendirin:

• Son 5 dakikada checkout URL’lerinde 5xx oranı %3’ü geçtiyse alarm.
• Son 10 dakikada payment_failed sonucu kaydedilen benzersiz ödeme girişimi sayısı, karşılaştırılabilir geçmiş 10 dakikalık dönemlerdeki olağan düzeyin 2 katına çıktıysa alarm; toplam girişim hacmini de birlikte değerlendirin.
• Callback URL’sinde üst üste 10 adet 500 hatası oluştuysa alarm.

Merkezi loglama (Loki, ELK vb.) ve metrik sistemleri (Prometheus, Netdata) bu izleme yapısında kullanılabilir. Daha önce bahsettiğimiz Grafana Loki + Promtail ile log yönetimi yazısını eski kurulum bağlamında okuyun; Promtail yeni kurulumlar için güncel bir seçenek değildir. Loki’ye log göndermek için Grafana Alloy veya desteklenen başka bir istemci seçin. Alarm sorgularını kendi alan adlarınıza ve tekilleştirme kurallarınıza uyarlayın; bildirim hedeflerini ve veri gelmemesi durumunda izlenecek yolu da belirleyin.

Gösterge panelleri (dashboard) ile büyük resmi görmek

Günlük işlerin içinde kaybolmamak için, loglardan beslenen birkaç temel gösterge paneli kurmanızı öneriyoruz:

• Genel hata oranı (4xx/5xx) – zaman serisi
• Sepet ve ödeme funnel’ı – adım adım dönüşüm oranı
• Ödeme hata kategorileri (technical_error, bank_decline, user_canceled) dağılımı
• En çok hata üreten ilk 10 URL

Bu paneller, ekip toplantılarında “hissiyat” yerine veriye dayalı konuşmanızı sağlar. Örneğin, yeni bir tema güncellemesinden sonra checkout sayfasında 500 hata oranının arttığını net biçimde görebilirsiniz.

Crontab ile düzenli raporlar üretmek

Her ekibin merkezi log sistemi veya gelişmiş dashboard altyapısı olmayabilir. Böyle durumlarda bile, basit bash script’leri ve cron job’lar ile günlük özet raporlar üretmek mümkündür. Örneğin:

• Gün sonunda son 24 saate ait 4xx/5xx istatistiklerini çıkaran bir script
• Sepet ve ödeme URL’leri için hata oranlarını hesaplayan küçük bir araç
• Bu çıktıları e‑posta ile teknik ekibe gönderen bir yapı

Bu tarz otomasyonlar için cron tarafında dikkat etmeniz gereken noktalar hakkında, Linux crontab en iyi uygulamalar rehberimizde bolca pratik öneri bulursunuz.

Log Analizi Altyapısı İçin Pratik Öneriler

Paylaşımlı hosting, VPS, dedicated veya colocation seçeneklerini değerlendirirken loglara erişim yetkilerini ve log yönetiminden kimin sorumlu olduğunu netleştirin. Aşağıdaki önerileri bu yetki ve sorumluluklara göre uygulayın:

• Ayrı log dizini ve yeterli disk alanı: Özellikle yüksek trafikli mağazalar için logların büyüme hızı izlenmeli; depolama yönetimi yetkiniz varsa logları ayrı bir disk bölümünde tutmak değerlendirilmelidir.
• Standart alanlar ve zaman bilgisi: Web sunucularınızın (Nginx/Apache) kayıtlarını ortak bir analiz şemasına uyarlayın. Zaman damgalarının saat dilimini ve süre alanlarının birimini açıkça tanımlayın; sunucu saatlerini senkronize edin. Korelasyon alanlarını merkezi sistemde tutarlı biçimde eşleyin.
• Merkezi loglama: Birden fazla web, uygulama ve veritabanı sunucunuz varsa, logları merkezi bir sisteme (Loki/ELK tarzı) akıtmak birlikte incelemeyi kolaylaştırabilir. Bu mimari için birden fazla sunucuda log yönetimi rehberimiz iyi bir başlangıç noktasıdır.
• Güvenli erişim ve aktarım: Loglara erişimi görev gereği ihtiyaç duyanlarla sınırlayın; merkezi sisteme aktarımı ve arşivleri koruyun. IP adresleri ve kullanıcıyla ilişkilendirilebilen kimlikler için de veri minimizasyonu uygulayın.
• Test/staging ortamında da loglamak: Canlıya çıkmadan önce staging ortamında sepet ve ödeme akışını aynı log yapısıyla test etmek, hataların prod’a yansımadan yakalanmasına yardımcı olur.
• Destek ekibi ile ortak dil: Destek talebinde zaman aralığını ve saat dilimini, ilgili erişim/hata logu kesitlerini ve örnek URL’leri belirtmek incelemeyi kolaylaştırabilir. Paylaşmadan önce kişisel verileri, oturum belirteçlerini ve ödeme bilgilerini maskeleyin.

Sonuç ve Yol Haritası: Loglarla Dönüşüm Sorunlarını Araştırmak

Dönüşüm kaybını araştırırken kullanıcı davranışları ve pazarlama performansının yanında teknik aksaklıkları da değerlendirin. Sunucu logları bu incelemeye katkı sağlayabilir. Örneğin, checkout sayfasının 5 dakika boyunca 500 hatası döndüğü, ürün sayfalarının 404 verdiği, timeout nedeniyle ödeme sonucunun belirsiz kaldığı veya callback işlenemediği için sipariş durumunun güncellenmediği bir senaryo düşünün. Bu belirtiler altyapı ve uygulama kalitesi açısından incelenmelidir; dönüşüme etkilerini değerlendirmek için logları sipariş ve ödeme kayıtlarıyla ilişkilendirmek gerekir.

Bu yazıda DCHost ekibi olarak, e‑ticaret siteniz için:

• Hangi logların kritik olduğunu,
• 4xx/5xx hatalarından dönüşüm kaybı riskine işaret eden belirtileri nasıl yakalayabileceğinizi,
• Ödeme hatalarını loglardan nasıl ayrıştırabileceğinizi,
• Alarm, dashboard ve cron raporlarıyla düzenli izlemeyi nasıl planlayabileceğinizi

özetledik. Bundan sonraki adım, siteniz için küçük ama somut bir plan yapmak olabilir: bugün access.log ve error.log’unuzu kontrol edip sepet/ödeme URL’lerinizin hata oranlarını çıkarın; sonraki hafta uygulama loglarına event bazlı kayıt ekleyin; ardından da basit bir alarm kuralı kurun.

Yeni bir e‑ticaret altyapısı planlarken log stratejisini de tasarıma dahil edin: hangi kayıtların tutulacağını, bunlara kimlerin erişeceğini ve alarmlara kimin müdahale edeceğini belirleyin. Sepet ve ödeme akışındaki aksaklıkları loglarla izlemek, sipariş ve ödeme kayıtlarıyla birlikte değerlendirildiğinde sorunları araştırmayı ve olası ciro kaybına karşı müdahaleyi destekler.