E-Ticaret Sepet ve Ödeme Logları: İzleme ve Alarmlar

E‑ticaret sepet ve ödeme adımlarını neden loglarla izlemeliyiz?

E‑ticaret tarafında en çok konuşulan metrikler genelde trafik, dönüşüm oranı ve ciro olur. Ancak sepet ve ödeme adımlarında neler yaşandığını detaylı şekilde görmüyorsanız, bu metrikler aslında buzdağının sadece görünen kısmıdır. Bir kullanıcının ürünü sepete ekledikten sonra nerede takıldığını, hangi hata mesajını gördüğünü, ödeme sağlayıcısından nasıl bir yanıt döndüğünü ve tüm bunların sunucu tarafında hangi loglara yansıdığını netleştirmeden kalıcı iyileştirme yapmak zordur.

“Ödeme adımında hata var” bildirimi tek başına teşhis için yeterli değildir. Hangi adımda, hangi hata türünde ve ne zaman sorun oluştuğunu belirlemek gerekir. Bu rehber web sunucusu ve uygulama olaylarını ilişkilendirmeyi, gerekli alanları sınırlamayı ve sinyalleri alarmlara dönüştürmeyi anlatır. Log yalnız etkin ve çalışan toplama noktasına ulaşan isteği görür; tarayıcıda başlayıp hiç gönderilmeyen işlemi veya CDN’de karşılanan isteği origin logundan çıkaramazsınız.

İzlenebilirlik, olay incelemesini ve müdahaleyi kolaylaştırabilir; gelir artışı veya belirli çözüm süresi garantisi değildir. Teknik istek sayıları, kullanıcı dönüşüm hunisi ve ödeme sonucu farklı ölçümlerdir. Bunları doğru kimlik, zaman penceresi ve doğrulanmış uygulama olayıyla bağlayın; log toplama arızasının da görünür olmasını sağlayın.

Sepet ve ödeme akışında hangi loglar tutulmalı?

Önce neyi izlemeniz gerektiğini netleştirelim. E‑ticaret sepet ve ödeme adımları, kabaca şu log türlerinden oluşan bir orkestrasyon gibi düşünülebilir:

• Web sunucusunun gerekli access/error kayıtları
• Uygulamanın yapılandırılmış, hassas alanlardan arındırılmış iş olayları
• Gerekliyse kontrollü yavaş sorgu ve veri tabanı hata kayıtları
• Ödeme entegrasyonunun doğrulama ve sonuç özetleri; ham request/response gövdeleri değil
• Gerekliyse tarayıcı hataları ve olayları; ayrı kapsam ve toplama politikasıyla

Access kayıtları gözlenen istek adımı, zaman, durum ve süreyi gösterir. Uygulama kayıtları stok, kupon, sipariş ve ödeme kararlarını açıklayabilir. Ödeme sağlayıcısının ret, beklemede, yetkilendirme ve tahsilat durumlarını kendi belgelerine göre ayırın; HTTP 200 veya teşekkür sayfası görüntülenmesi ödeme başarısı değildir.

1. Web sunucusu logları: Giriş kapısındaki gerçekler

Sepet ve ödeme akışında, genelde şu URL kalıpları üzerinden ilerlenir:

• /cart veya /sepet
• /checkout veya /odeme
• /checkout/shipping, /checkout/payment, /checkout/review gibi adımlara bölünmüş URL’ler
• /payment/callback veya /odeme/notify gibi ödeme sağlayıcısı geri dönüş uçları
• /order/success veya /tesekkurler gibi sipariş başarı sayfaları

Access log’larınızda bu URL’leri ayırt ederek adımların istek hacmini karşılaştırabilirsiniz. Örneğin, aynı zaman diliminde /cart için 10.000, /checkout/payment için 3.000, /order/success için 1.200 hit olduğunu varsayalım. Bunların oranı kullanıcı dönüşüm oranı değildir: tekrar ziyaretler, botlar ve farklı oturumlar sayıları etkiler; başarı sayfasının açılması da tek başına ödemenin tamamlandığını kanıtlamaz. Dönüşüm hunisi için aynı sepet veya siparişe ait adımları ilişkilendirin, tekrarları ayıklayın ve ödeme başarısını doğrulanmış uygulama kayıtlarıyla ölçün.

2. Uygulama logları: İş kurallarının izleri

Uygulama katmanı, neyin neden hata verdiğini asıl gösteren yer. Örneğin:

• Stok yetersizliği (örnek mesaj: OutOfStockException)
• Adres doğrulama hataları
• Kupon/indirim kurallarıyla ilgili validasyon hataları
• Sepet eşzamanlama (anonim kullanıcıdan oturum açmış kullanıcıya devretme) problemleri
• Ödeme sağlayıcısına giderken oluşan timeout veya bağlantı hataları

Her HTTP isteğinde bir request/correlation kimliği kullanmak aynı isteğin access ve uygulama kayıtlarını eşleştirmeyi sağlar. Bu rehberin Nginx örneğinde kimliği Nginx üretir; uygulamaya güvenilen sınırdan iletilip uygulama loguna yazılmalıdır. Tek sipariş birden fazla HTTP isteğine ve ödeme denemesine yayılır; bunları ayrıca erişim yetkisi taşımayan, korunan sipariş/deneme referansıyla bağlayın. Ham oturum çerezini bu amaçla kullanmayın.

3. Veritabanı logları ve yavaş sorgu analizi

Ödeme adımındaki performans problemleri, veritabanı tarafındaki yavaş sorgulardan da kaynaklanabilir. Özellikle stok kontrolü, kupon validasyonu, kargo ücreti hesaplama ve müşteri adres sorguları yoğun trafik altında yavaşlayabilir. Bu yüzden MySQL/MariaDB veya PostgreSQL için uygun yavaş sorgu kayıtlarını toplamak ve düzenli analiz etmek yararlıdır. Sorgu metinleri kişisel veya hassas değerler içerebileceğinden, kaydedilen içeriği ve bu kayıtlara erişimi sınırlandırın.

WooCommerce MySQL/InnoDB tuning rehberi ölçümle doğrulanan veri tabanı darboğazlarını ele almak için kullanılabilir. Her ayarı topluca uygulamak yerine sorgu planını, kaynak ve kilit beklemelerini inceleyin; değişikliği temsilî yükle doğrulayın. Log toplamak veya sunucu büyütmek tek başına uygulama sorununu çözmez.

4. Ödeme sağlayıcısı logları ve callback kayıtları

Ödeme sağlayıcısıyla entegrasyon tarafında iki tür log önemlidir:

• Sunucudan ödeme sağlayıcısına giden isteklerin gerekli özet alanları (amount, currency, order_id gibi alanlar; client_ip yalnızca tanımlı bir ihtiyaç varsa ve uygun korumayla)
• Ödeme sağlayıcısından size gelen callback/notify çağrılarının gerekli özet alanları (status, error_code, 3D sonucu vb.; ham gövde yerine hassas verilerden arındırılmış kayıtlar)

Callback uçlarının access log’larda ayırt edilmesi, bu çağrıların web sunucusuna ulaşıp ulaşmadığını araştırmayı kolaylaştırır; kaydın bulunmaması tek başına çağrının gönderilmediğini kanıtlamaz. Örneğin, 100 başarısız ödeme denemesinin 90’ıyla callback kayıtlarını eşleştirdiğinizi varsayalım. Bu sayı tek başına sorunun tarafını göstermez: callback bir ret sonucunu da taşıyabilir veya aynı deneme için yeniden gönderilmiş olabilir. Sağlayıcının hangi durumlarda callback gönderdiğini, doğrulama sonucunu, ödeme durumunu ve uygulamanın sonucu işleyip işlemediğini birlikte inceleyin.

Sunucu logları ile sepet ve ödeme adımlarını görünür hale getirmek

Aşağıdaki Nginx örneği ham URL yerine sabit adım etiketi üretir. Gövde, Cookie, Authorization, Referer, ham User-Agent ve IP kaydetmez. Bu sınırlı erişim logu istek hacmi ve gecikme içindir; kullanıcı oturumu veya ödeme dönüşümü hesaplamak için yeterli değildir. Apache’de aynı Nginx değişkenleri kullanılmaz; kendi formatı ve zaman birimleri ayrıca yapılandırılmalıdır.

Nginx access log’larında doğru alanları toplamak

Map ve log_format tanımlarını http bağlamına yerleştirin. access_log satırı burada http düzeyindedir; kapsamı tek mağazayla sınırlamak için ilgili mevcut server bloğuna taşıyabilirsiniz. İç location bloklarında ayrı access_log veya off tanımı varsa etkin kapsamı kontrol edin. Dosya yolu, dizin izinleri ve rotasyonu hazırlayın; yeni yapılandırmayı sözdizimi kontrolünden ve staging testinden sonra devreye alın.

# http context. Adapt these route patterns to the actual store.
map $request_uri $commerce_step {
    default other;
    ~^/(order/success|checkout/thank-you|tesekkurler)(/|\?|$) confirmation;
    ~^/(payment/callback|odeme/notify|webhook/payment-provider)(/|\?|$) callback;
    ~^/(cart|sepet)(/|\?|$) cart;
    ~^/(checkout|odeme)(/|\?|$) checkout;
}
map $commerce_step $log_commerce {
    default 1;
    other 0;
}
log_format cart_checkout escape=json
    '{"time":"$time_iso8601","site":"$server_name",'
    '"step":"$commerce_step","method":"$request_method",'
    '"status":"$status","bytes":"$body_bytes_sent",'
    '"request_seconds":"$request_time",'
    '"upstream_seconds":"$upstream_response_time",'
    '"upstream_status":"$upstream_status","request_id":"$request_id"}';

# May instead be placed in the selected existing server block.
access_log /var/log/nginx/cart-checkout.jsonl cart_checkout if=$log_commerce;

Bu örnek yalnız eşleşen yolları kaydeder; gerçek yerelleştirilmiş, API, callback ve özel ödeme yollarını envantere göre ekleyin. Kodlanmış yolları, yönlendirmeleri ve iç rewrite’ları da test edin. İki sayfanın aynı etiketi taşıması aynı kullanıcı veya sipariş olduğu anlamına gelmez. JSON kaçışı veriyi anonimleştirmez; ham hassas alanları formata eklememek gerekir.

• step: Ham URL yerine cart, checkout, callback veya confirmation gibi sabit etiket; sorgu değerleri kaydedilmez.
• status: İstemciye dönen HTTP durumu; uygulama/ödeme kararı değildir.
• request_seconds: Nginx’in ilk istemci baytını okumasından son yanıt baytını gönderdikten sonraki log yazımına kadar geçen süre; saniye ve milisaniye çözünürlüğündedir. Tarayıcı TTFB’si veya yalnız uygulama süresi değildir.
• upstream_seconds / upstream_status: Upstream yanıtını alma süresi ve durumları; süre saniyedir. Birden fazla denemede virgül/iki noktayla ayrılmış değerler, upstream yoksa eksik değer bulunabilir.
• request_id: Nginx’in 16 rastgele bayttan ürettiği 32 haneli hex kimlik. İstemcinin gönderdiği X-Request-ID kendiliğinden bu değişkene dönüşmez.

Tüm alanlar JSON dizgesi olarak yazılır; eksik upstream değeri “-” olabilir. Ayrıştırıcı bunu sıfır gecikme saymamalı, çoklu denemeleri tek sayı gibi çevirmemelidir. Milisaniye paneli gerekiyorsa tekil saniye değerini açıkça 1000 ile çarpın ve alan adını/birimi belirtin. Örneğin şu sorgular teknik sinyal sağlar:

• Son 15 dakikada checkout adımındaki uygun isteklerin sayısı ve 5xx oranı nedir?
• Callback için request_seconds ve ayrı upstream_seconds dağılımları nasıl değişti; örnek sayısı yeterli mi?
• Confirmation istek hacmi düşerken uygulamanın aynı ödeme-denemesi grubuna ait doğrulanmış sonuçları nasıl değişti?

Uygulama loglarında korrelasyon kimliği kullanmak

Nginx HTTP reverse proxy kullanıyorsa mevcut proxy location içinde proxy_set_header X-Request-ID $request_id; ile üretilen kimliği iletin. PHP-FPM/FastCGI için mevcut parametre kümesine HTTP_X_REQUEST_ID değerini $request_id olarak ekleyen fastcgi_param kullanılır. Bu ekleme mevcut parametre/başlık mirasını değiştirebileceğinden bütün etkin kümeyi koruyun. Uygulama bu alanı yalnız güvenilen proxy’den kabul edip loglarına eklemelidir; doğrudan erişim veya istemci başlığına kör güven korelasyonu bozabilir.

• Her istek için güvenilen sınırdan gelen request_id
• İş için gerekliyse erişim yetkisi taşımayan takma kullanıcı/sipariş/ödeme-denemesi referansı
• Olay zamanı, şema sürümü, sabit event adı ve deduplikasyon için olay kimliği
• Gerekli ve kapsamı belirlenmiş tutar/para birimi ve sağlayıcı sonuç sınıfı
• cart_view, checkout_start, payment_init ve doğrulanmış payment_success/payment_failed gibi uygulama olayları

Varsayımsal bir siparişte ilk ödeme denemesi reddedilip ikincisi başarılı olabilir. Her HTTP isteği ayrı request_id, her deneme ayrı attempt referansı taşımalı; tekrar gelen callback aynı olay/deneme için ikinci başarı sayılmamalıdır. Webhook imzasını ve beklenen sipariş/tutar/para birimini doğrulayın, uygulanan durum geçişini kaydedin. Gecikmeli veya sırasız olayları sağlayıcının sözleşmesine göre işleyin; access hit’lerini iş olayı yerine kullanmayın.

Merkezi loglama: Tek ekranda tüm sepet ve ödeme sinyalleri

Gerekli erişim ve kaynak sağlandığında merkezi toplama katmanı bir VPS veya dedicated sunucu üzerinde ya da uygun yönetilen hizmette çalışabilir. Promtail 2 Mart 2026’da kullanım ömrünü tamamladı; yeni kurulum için Grafana Alloy veya desteklenen başka istemci seçin. VPS merkezi loglama rehberi mimari bağlam sağlar; eski Promtail adımlarını güncel istemciye uyarlamadan kullanmayın.

Merkezi loglama sayesinde:

• Yetkili kaynaklardan gelen kayıtlar ortak şemayla sorgulanabilir.
• Access ve uygulama olayları, gerçekten aktarılan request_id ile ilişkilendirilebilir.
• Adım, hata, gecikme ve doğrulanmış ödeme sonuçlarına ayrı paneller kurulabilir.
• Toplama gecikmesi, kayıp kayıt, ayrıştırma hatası ve disk/kuyruk doluluğu da izlenmelidir; görünmeyen veri sıfır hata demek değildir.

Hata tespiti için metrikler ve alarm kuralları

Sadece log toplamak yeterli değil; bu loglardan anlamlı metrikler üretmek ve eşik değerlerine göre alarmlar kurmak gerekiyor. Sepet ve ödeme adımlarında düzenli olarak takip etmenizi önerdiğimiz bazı temel metrikler şöyle:

• Adım başına gözlenen istek sayısı; bot, tekrar ve yönlendirme etkisiyle
• Uygulamada deduplike edilmiş checkout başlangıcı ve ödeme denemesi sayısı
• Doğrulanmış ödeme durumuna ulaşan ayrı denemeler/siparişler
• Checkout/callback 4xx ve 5xx sayısı, uygun payda ve oranı
• Adım başına p50/p95 süre, örnek sayısı ve açık birim
• Log/olay toplama gecikmesi, kayıp ve no-data durumu

Dönüşüm hunisi (funnel) üzerinden alarm kurmak

Loglarınızdan ürettiğiniz metriklerle basit bir funnel tanımı yapabilirsiniz:

1. cart_view: tanımlanan takip kapsamındaki farklı sepetler
2. checkout_start: aynı sepet grubunda en az bir uygun checkout başlangıcı bulunan sepetler
3. payment_init: aynı grupta en az bir ödeme denemesi başlatılmış sepetler
4. payment_success: aynı grupta ilgili sipariş ve denemeye bağlanmış, doğrulanmış başarı sonucu bulunan sepetler

Aşağıdaki oranlar yalnız varsayımsal örnektir. Her aşamada aynı başlangıç grubundaki farklı sepetleri sayın; bir sepetin birden fazla ödeme denemesi olması o aşamada birden fazla sayılmasına yol açmamalıdır. Sonuçların olgunlaşması için sağlayıcı gecikmesine uygun süre tanıyın. Deneme bazlı başarı oranını ayrıca, doğrulanmış başarılı denemeleri aynı uygun deneme grubuna bölerek hesaplayın. Farklı pencerelerdeki ham sayaçları bölmek dönüşüm değildir:

• cart_view → checkout_start: %40
• checkout_start → payment_init: %70
• payment_init → payment_success: %85

Eşikleri kendi normal/kampanya veriniz, asgari örnek sayısı, iş etkisi ve kalıcılık süresiyle kalibre edin. Aşağıdaki değerler çalıştırılabilir hazır kurallar veya evrensel eşikler değildir:

• Yeterince eski ve yeterli sayıda ödeme denemesinin doğrulanmış başarı oranı, karşılaştırılabilir başlangıcın belirgin altına birkaç değerlendirme boyunca düşerse uyar.
• Checkout 5xx oranı için hem yeterli istek paydası hem asgari hata sayısı ara; 10 dakikada %2 yalnız başlangıçta tartışılabilecek örnektir.
• Callback p95 request_seconds değerinin örnek sayısı yeterliyken kendi karşılaştırılabilir başlangıcını aşması için kalıcılık koşulu tanımla; upstream dağılımını ayrıca incele.

HTTP durum kodlarına göre alarm örnekleri

Access log’larınızdan basit ama etkili alarm kuralları çıkarabilirsiniz:

• Checkout 5xx: Hata sayısını uygun istek paydasına ve normal yükteki dağılıma göre değerlendirin; 20 hata her trafik düzeyinde aynı anlamı taşımaz.
• Callback 4xx: İmza, şema, yetkilendirme veya tekrar işleme reddi olabilir. Sağlayıcı/ağ arızası diye otomatik sınıflamayın.
• Confirmation 404: Yol/yönlendirme sorununu araştırın; başarısız ödeme sonucu olduğu varsayımını yapmayın.

Prometheus dosyaları doğrudan tarayan bir log aracı değildir; sayaç/histogramları exporter veya uygulama ölçümleriyle alabilir. Loki/LogQL ya da başka log sorgu motoru kayıtları metriklere çevirebilir. Kural motoru koşulu değerlendirir; Alertmanager bildirimleri yönlendirir, gruplar ve sessize alma uygular. No-data, değerlendirme hatası, tekrar bildirimi ve iyileşme bildirimini de tanımlayın; her alarmın sorumlusu ve ilk kontrol adımları olmalıdır.

Eşik değerleri nasıl belirlenmeli?

Eşik değerleri belirlerken iki uç tehlike var: Çok sık alarm üretip ekibi alarmlara kör etmek veya o kadar gevşek değerler koymak ki ciddi sorunlarda bile alarm gelmemesi. İyi başlangıç stratejisi şu olabilir:

1. Temsilî geçmiş dönemi saat/gün, trafik, cihaz sınıfı ve sağlayıcıya göre karşılaştırın; 30–60 gün yalnız örnek toplama aralığıdır.
2. Kampanya ve normal günleri, veri kaybını ve olay gecikmesini ayırın.
3. Asgari payda/hata sayısı, p95 için örnek yeterliliği ve kalıcılık süresi belirleyin. %0,2’nin 3–5 katı %0,6–1’dir; %1–2 değildir.
4. Geçmiş olaylar ve staging senaryolarıyla yanlış/kaçan alarmları ölçüp eşikleri ayarlayın.

Özellikle yüksek trafikli WooCommerce veya özel geliştirme e‑ticaret sitelerinde, VPS izleme ve uyarı altyapısını doğru kurmak, log tabanlı bu metrikleri sağlıklı üretmenin temel şartlarından biridir.

Varsayımsal Alarm ve İnceleme Senaryoları

Aşağıdaki senaryolar ölçülmüş müşteri olayları değildir. Her biri ek uygulama kanıtı gerektiren bir inceleme başlangıcıdır; erişim logu tek başına kök nedeni veya gelir kaybını kanıtlamaz.

Senaryo 1: Yalnızca mobilde checkout 500 hataları

Örneğin checkout hataları mobil istemcilerde daha fazla görünebilir. Yukarıdaki asgari log biçimi User-Agent kaydetmez; bu ayrım gerekliyse toplama öncesi sınırlandırılmış cihaz sınıfını uygulama telemetrisine ekleyin. Bu sınıf istemciden türetildiği için kesin cihaz kanıtı sayılmaz. Aynı sürüm/yol ve yeterli örnekle oranları karşılaştırıp uygulama doğrulama hatalarını request_id ile inceleyin.

Bu durumda kurulabilecek alarm:

• Mobil sınıftaki checkout 5xx oranı, yeterli mobil/diğer örnek ve asgari hata sayısıyla karşılaştırılabilir başlangıcı belirli süre aşarsa uyarı üretin. İki kat oran tek başına evrensel alarm kuralı değildir.

Alarm, ilgili form ve backend doğrulamasını araştırmayı sağlar. Eksik alan, JavaScript arızası veya sürüm uyuşmazlığı gibi nedenleri olay kanıtıyla ayırın; cihaz etiketi nedeniyle peşinen karar vermeyin.

Senaryo 2: Ödeme sağlayıcısı timeout ve callback düşüşü

Ödeme denemeleri artarken callback gözlemi azalabilir. Önce sağlayıcının hangi ödeme türünde, ne kadar gecikmeyle ve hangi tekrar politikasıyla webhook gönderdiğini kontrol edin. Log hattı, DNS/ağ, yönlendirme ve imza doğrulaması sorunlarını sağlayıcı arızasından ayırın:

• Sonucun gelmesi için tanımlı süreyi aşmış denemeleri, aynı denemeye bağlı doğrulanmış sonuçlarla eşleştirin.
• Beklenen webhook’ların gecikmesini ve doğrulama/işleme hatasını izleyin; ham callback hit/payment_init oranını ödeme başarı oranı saymayın.
• No-data veya log iletim arızasını ayrı bildirin; tekrar callback’leri deduplike edin.

Bulguyu sağlayıcı durum bilgisi ve uygulama kayıtlarıyla doğrulayın. Alternatif ödeme yoluna geçiş gerekiyorsa mevcut denemelerin durumunu uzlaştırın; timeout sonucu bilinmeyen bir işlemi körlemesine yeniden tahsil etmeyin. İzleme alarmı para iadesi, tahsilat veya sağlayıcı değişimini otomatik olarak yetkilendirmez.

Senaryo 3: Stok eşitsizliği ve sepet boşalması

Stok hatalarının artması; talep, ayrılmış stok, eşzamanlı sipariş veya iş kuralı değişiminden kaynaklanabilir. OutOfStockException gibi uygulamaya özgü hata sınıfını sipariş/deneme referansıyla izleyin. Access logundaki checkout/confirmation hit oranı yerine aynı başlangıç grubunun doğrulanmış sonuçlarını kullanın; beklenen stok tükenmesini yazılım hatasından ayırın.

• Yeterli örnekte stok kaynaklı hata oranı karşılaştırılabilir başlangıcı aşıyor ve aynı sepet/sipariş grubunun başarı oranı düşüyorsa inceleme alarmı üretin; sabit üç kat kuralını test etmeden uygulamayın.

Bu tür alarmlar, yalnızca altyapı değil, iş kuralı değişikliklerinde de size erken uyarı mekanizması sağlar.

Senaryo 4: Fraud şüphesine yönelik log tabanlı sinyaller

Log’lar sadece teknik hata değil, fraud tespiti için de ipucu verir. Örneğin:

• Aynı korunmuş izleme referansından beklenenden fazla başarısız ödeme denemesi
• Ödeme sağlayıcısının mevcut, hassas veriden arındırılmış risk sinyalleri
• Normal trafik ve deneme hacminden açıklanamayan sapmalar; tek başına ülke veya IP’ye dayanarak sonuç çıkarmadan

Bu amaçla ham kart verisi, ödeme yetkisi taşıyan token veya oturum çerezi eklemeyin. IP veya takma kimlik gerekiyorsa amaç, erişim, süre ve kaynak doğruluğunu tanımlayın; proxy başlığı istemci tarafından taklit edilebilir. Paylaşılan NAT veya ağ, bir IP’nin tek kullanıcı olduğu varsayımını bozar. Risk sinyali doğrulanması gereken şüphedir.

• Belirlenmiş izleme referansında başarısız deneme oranı ve sayısı kalıcı biçimde yükselirse inceleme uyarısı oluşturun. 10 dakikada 20 olay yalnız örnek eşiği olabilir; beklenen hacim ve yanlış pozitiflerle kalibre edilmelidir.

Bu asgari access logu IP veya ödeme tokenı içermez. Ek risk telemetrisi gerekiyorsa ayrı, amaçla sınırlı ve erişimi kontrollü tasarlayın; kişisel veriyi hash’lemek tek başına anonimleştirme veya hukuki uyum sağlamaz.

Güvenlik, KVKK, PCI‑DSS ve log saklama politikaları

Loglar sipariş ve kullanıcıyla ilişkilendirildiğinde kişisel veri içerebilir. KVKK/GDPR veri koruma çerçeveleri ile PCI DSS ödeme kartı standardını aynı şey saymayın; uygulanacak kapsamı belirleyin. Bu rehberin sınırlı alan seçimi tek başına uyum kanıtı değildir. Yetkilendirme, silme, bütünlük, amaç ve saklama politikasını sistemin bütünüyle değerlendirin.

Loglarda hangi veriler maskeleme gerektirir?

Genel prensip: Hata analizi için gerçekten ihtiyaç duymadığınız hiçbir kişisel veriyi loglara yazmayın. Özellikle:

• Tam isim, TC kimlik numarası, adres detayları
• Tam kart numarası, CVV, kart son kullanma tarihi
• E‑posta ve telefon numaraları

Sepet/checkout izleme için kart numarası, CVV ve kart son kullanma tarihini kaydetmeyin; bunları maskelemek bu kullanımda gereksiz toplamayı haklı çıkarmaz. Parola, token, bağlantı dizgesi ve ham oturum değerlerini de kayıttan önce çıkarın. Gerekli takma kimlikler hâlâ ilişkilendirilebilir veri olabilir. KVKK/GDPR hosting ve log politikaları rehberi daha geniş saklama ve silme değerlendirmesine yardımcı olabilir.

PCI‑DSS açısından loglama

Ödeme kartı verisi ortamıyla ilgili güvenlik audit kayıtlarının kapsamı ve saklama kuralları, bu yazıdaki isteğe bağlı checkout tanı loglarıyla aynı olmak zorunda değildir. Uygulanabilir PCI DSS gereksinimlerini ayrıca belirleyin. Veri toplamayı artırmadan erişim, bütünlük ve olay araştırması ihtiyacını karşılayacak kayıt türlerini ayırın:

• Bu tanı akışına kart ve kimlik doğrulama sırlarını hiç yazmamak
• Log erişimini görev bazlı sınırlamak ve erişimleri izlemek
• Güvenlik audit, uygulama tanı ve toplu metrik saklama sınıflarını ayrı tanımlamak
• Yetkisiz değişikliği tespit etmek, aktarımı/depolamayı korumak ve saklama süresi sonunda ilgili kopyaları yönetmek

Bu çerçeveyi pratikte nasıl uygulayacağınızı merak ediyorsanız, e‑ticarette PCI‑DSS uyumu ve hosting tarafında yapılması gerekenler yazımızdan yola çıkabilirsiniz.

Log saklama süreleri ve yedekleme

Sepet ve ödeme loglarını sonsuza kadar tutmak da doğru değil, çok kısa sürelerle silmek de. Burada iki şeye bakmak gerekir:

• Her kayıt sınıfı için amaç, gerekli inceleme aralığı, uygulanabilir yükümlülük ve silme koşulunu belgeleyin; herkese uygun 3–6 ay kuralı yoktur.
• Güvenlik audit kayıtlarına uygulanan asgari süreyi daha kısa tanı-log politikasına indirgemeyin.
• Arşiv, yedek, dışa aktarım ve yeniden işlenen kopyaları da politikaya dahil edin; toplulaştırma veriyi otomatik anonim yapmaz.

Logların yedeğinin alınması, saklama politikalarının dokümante edilmesi ve düzenli olarak test edilmesi için, veri yedekleme ve saklama politikaları rehberimizdeki prensipleri e‑ticaret loglarınıza uyarlamanız iyi bir başlangıç olacaktır.

DCHost altyapısında sepet ve ödeme log/alert mimarisini kurgulamak

DCHost üzerinde plan seçerken log erişimi, yönetim yetkisi, depolama/IO sınırları, ağ ve işletim sorumluluğunu somut ihtiyaçla karşılaştırın. Aşağıdakiler genel mimari seçeneklerdir; belirli bir planın tüm özellikleri veya danışmanlık kapsamı olarak okunmamalıdır.

1. paylaşımlı hosting + hafif e‑ticaret

Yeni başlayan, trafiği nispeten düşük e‑ticaret sitelerinde paylaşımlı hosting ortamı tercih edilebiliyor. Bu durumda:

• Planın gerçekten sunduğu panel/log erişimini, dışa aktarım sıklığını ve saklama süresini doğrulayın.
• Uygulama kayıtlarını webden erişilemeyen yerde, sınırlandırılmış içerik ve izinlerle saklayın.
• Merkezi toplama gerekiyorsa mevcut plandan güvenli aktarım veya ayrı hizmet seçeneklerini inceleyin; sırf log ihtiyacı var diye mağazayı taşımak zorunlu değildir.

Bu aşamada, öncelik basit ama tutarlı bir log formatı ve temel alarm kurallarıdır. Loglarınız olgunlaştıkça altyapınızı da büyütmek daha sağlıklı bir strateji olur.

2. VPS üzerinde orta ölçekli e‑ticaret

Gerekli yönetim erişimi ve kaynak varsa VPS üzerinde uygulama ve izleme bileşenleri çalıştırılabilir. Kapasiteyi sipariş sayısına bakarak tahmin etmek yerine byte/gün, sorgu yükü, saklama süresi ve pik kuyruk hacmiyle planlayın:

• Grafana Alloy veya desteklenen başka istemciyle gerekli logları güvenli kanala aktarın; rsyslog gibi seçeneklerde hedef uyumunu doğrulayın.
• Loki log saklama/sorgulama, Grafana panel ve kural değerlendirmesi, bildirim bileşenleri ise yönlendirme için yapılandırılır.
• Prometheus/Node Exporter sistem kaynaklarını izleyebilir; checkout iş olayları için ayrıca uygulama metriği veya log sorgusu gerekir.
• Toplayıcı kuyrukları, ayrıştırma/kayıp kayıtlar, kaynak rekabeti ve log hizmetinin kendi erişilebilirliği için alarm kurun.

Bu mimarinin nasıl adım adım kurulacağını merak ediyorsanız, hem VPS log yönetimi rehberimizi hem de VPS izleme ve alarm kurulumu yazımızı gözden geçirmenizi öneririm.

3. Dedicated sunucu veya colocation ile yüksek hacimli e‑ticaret

Dedicated sunucu veya müşteri donanımını barındırma modeli, kapasite/izolasyon ihtiyacına göre değerlendirilebilir. Colocation dahil istenen hizmetin gerçekten sunulup sunulmadığını ve yönetim kapsamını ayrıca teyit edin. Sipariş hacmi tek başına fiziksel sunucu veya küme zorunluluğu yaratmaz:

• Uygulama, veri tabanı ve log hizmetini gerekirse kaynak/arıza alanı açısından ayırın.
• Yedeklilik gerekiyorsa arıza senaryosu, veri aktarımı, erişim ve geri kazanımı tasarlayıp test edin.
• CDN, Anycast DNS veya çok bölge tek başına yüksek erişilebilirlik sağlamaz; gözlenen istek kapsamı, saatler ve kimlik aktarımı katmanlar boyunca tutarlı olmalıdır.

E-ticaret hosting seçimi rehberindeki kriterleri loglama, saklama ve alarm ihtiyaçlarıyla birlikte değerlendirin. DCHost’tan kapasite planlama veya log mimarisi desteği isteniyorsa sunulup sunulmadığını ve hangi işlerin müşteri sorumluluğunda olduğunu önceden doğrulayın.

Özet ve uygulanabilir yol haritası

İyi log tasarımı, seçilmiş isteklerin teknik sonucunu uygulamadaki doğrulanmış olaylarla birleştirir. Ham istek sayısını kullanıcı veya ödeme başarısı sanmadan; doğru kimlik, zaman penceresi, deduplikasyon ve veri kalitesiyle çalışın. Cihaz/ülke gibi ek kırılımlar ancak tanımlı ihtiyaca ve uygun veri politikasına dayanmalıdır.

Uygulanabilir bir yol haritasını şöyle özetleyebiliriz:

1. Gerçek endpoint ve iş olaylarını envanterleyin; sabit, hassas veri içermeyen route etiketleri tanımlayın.
2. Nginx/uygulama kimlik aktarımını, süre birimlerini ve kayıt ayrıştırmasını test edin.
3. Gerekli kayıtları kontrollü biçimde toplayın; log hattı arızasını da izleyin.
4. Aynı başlangıç grubuna ait deduplike olaylar, yeterli örnek ve gecikme toleransıyla alarm koşullarını kurun.
5. Erişim, bütünlük, saklama ve silme gereksinimlerini kayıt sınıfına göre belgeleyip staging olaylarıyla doğrulayın.

Plan değerlendirmesine günlük log hacmini, sorgu ve saklama gereksinimini, ağ erişimini ve işletim sorumluluğunu dahil edin. Yeni kaynak veya merkezi log aracı satın almak tek başına görünürlük sağlamaz. Kullanıcıya yansıyan sorunları yakalayan bir test alarmı, doğru alıcıya ulaşan bildirim ve uygulanabilir müdahale adımlarıyla sonucu doğrulayın.

Uygulama, ödeme sağlayıcısı veya URL düzeni değiştiğinde haritayı ve alarmları güncelleyin. Ödeme sandbox’ı ve izole staging’de sentetik olaylar kullanın; gerçek tahsilat, e-posta ve stok yan etkilerini engelleyin. İzleme sisteminin doğruluğunu düzenli kontrol etmek, yalnız bir kez kurmaktan daha önemlidir.