İade/iptal sürecini loglarla kanıtlayın: net kontrol rehberi

İade ya da iptal talebi geldiğinde tarafların en hızlı tartıştığı konu “sorun ne zaman başladı ve gerçekten yaşandı mı?” sorusudur. Hosting/VDS/VPS tarafında bunu en somut şekilde sunucu logları (server logs), kontrol paneli kayıtları ve zaman damgalı olay dökümleriyle gösterebilirsiniz. Bu rehberde, NetKıyas üzerinden baktığınız sağlayıcıya göre değişmeyen genel bir “kanıt paketi” mantığı kuracaksınız: hangi loglar toplanır, nasıl doğrulanır ve nasıl sunulur.

Aşağıdaki adımlar; disk dolulukları, 5xx hataları, kaynak aşımı, panel/otomasyon olayları ve ağ kesintileri gibi iddiaları tek bir zaman çizelgesinde toplamanızı sağlar. Böylece talebiniz “görüş” değil, doğrulanabilir veri üzerinden ilerler.

İade/iptalde logların rolü: “ne oldu”yu zamanla bağlayın

İptal ve iade süreçlerinde kanıtın kalitesi; logların hangi tarihte, hangi IP/host üzerinde üretildiği ve hangi hata ile sonuçlandığı bilgisine dayanır. Sağlayıcılar genellikle şu iki soruya logla yanıt ister:

İddia ettiğiniz sorun, sözleşme/deneme süresi içinde gerçekten oldu mu?
Sorun; sizin tarafınızdaki konfigürasyon mu, yoksa sağlayıcının altyapı/ops hatası mıydı?

Logları “ham dosya” gibi göndermek yerine, bir olay zaman çizelgesi (timeline) halinde paketleyin. Bu yaklaşım, inceleme süresini kısaltır.

Kanıt paketi için minimum hedef

Net bir hedef belirleyin. Örnek hedef:

Sorunun başlangıç-bitiş aralığı (YYYY-MM-DD HH:MM:SS)
Etkilenen domain/servis (ör. api.domain.com, web sitesi, SSH)
Kaynak göstergeleri (CPU/RAM/IO, disk doluluğu)
Hata logları (HTTP 4xx/5xx, uygulama exception, systemd journal)
Ağ/erişim olayları (SSH login denemeleri, bağlantı kesilmesi)
Kontrol paneli/otomasyon kayıtları (otomatik reboot, snapshot, yedekleme)

Hangi logları toplayın? Senaryoya göre net liste

Her sorun türü aynı logları gerektirmez. Aşağıdaki listeler, talebinize konu olan iddiaya göre “tam karşılık gelen” logları seçmenizi sağlar.

Web/site performansı veya erişim sorunu

Erişim kesintisi, yavaşlık veya 5xx hatası iddiasında şu kaynaklar değerlidir:

Nginx/Apache erişim ve hata logları
/var/log/nginx/access.log
/var/log/nginx/error.log
Apache için benzer yollar (ör. /var/log/apache2/...)
Uygulama logları
PHP-FPM logları (ör. /var/log/php*-fpm*.log)
Laravel/Symfony için storage/logs dizini
OS ve servis olayları
systemd journal kayıtları: journalctl -u nginx --since "..." --until "..."
Zaman damgası ile eşleştirme için:
date çıktısı ve NTP durumu (timedatectl)

İpucu: Logları almadan önce sunucunuzun saatinin doğru olduğundan emin olun. İptal dosyasında “saat farkı” yüzünden yorumlanan birçok çelişki bu yolla azalır.

Disk doluluğu, yedekleme taşmaları veya 500 hataları

Disk kaynaklı sorunlarda şu kanıtlar öne çıkar:

Disk kullanım geçmişi (o anı gösteren):
df -h
ilgili mount noktası (ör. /, /var, /home)
Uygulama 500 hataları ile birlikte oluşturulan exception logları
Sistem olayları
journal: servis çökmesi, yeniden başlatma
Dosya/backup işlemleri
otomatik job logları (cron/systemd timers)

Örnek senaryo: “Deneme süresi boyunca site sürekli 500’e düşüyordu.” Bu iddiayı; Nginx hata logundaki 500 nedenleri + disk doluluk yüzdesi + ilgili zaman aralığıyla bağlayın.

Kaynak aşımı (CPU/RAM/I/O) ve throttle iddiaları

VPS/VDS tarafında kaynak aşımı iddiası genellikle ölçüm ister. Log türleri şunlar olabilir:

Uygulama/servis loglarındaki performans uyarıları
OS metrik logları (varsa):
sar/sysstat çıktıları
dmesg (donanım/IO hataları için)
İsterseniz kontrol paneli/sağlayıcı olayları:
otomatik yeniden başlatma
kapasite yükseltme (rescue/resize)

NetKıyas’ta gördüğünüz “garanti edilen kaynak” veya “burst” ifadesi hangi mekanizmaya dayanıyor olursa olsun, elinizde zaman damgalı kaynak göstergeleri olmalı.

Log toplama yöntemleri: zaman aralığıyla çalışın

Logları gelişi güzel toplamak yerine, sorunla ilgili tarih aralığını esas alın. Bu bölüm size “tek seferde” doğru sonuç üretme mantığını verir.

1) Saat ve zaman dilimini sabitleyin

Önce sunucunun saatini doğrulayın:

timedatectl
Sistem zamanını gösteren date

İptal sürecinde logların okunması sırasında zaman dilimi uyuşmazlığı sorun çıkarır. Dosyaya şu bilgileri ekleyin:

Sunucunun saat dilimi (örn. Europe/Istanbul)
UTC mi yerel mi loglandığı

2) Journal loglarını daraltın

systemd tabanlı dağıtımlarda (Ubuntu/Debian/Alma/Rocky) journalctl ile olayları daraltın.

Örnek komut mantığı (gerçek tarih/saat ile):
journalctl -u nginx --since "2026-05-10 09:00:00" --until "2026-05-10 12:00:00"
journalctl --since "..." --until "..." --priority=err..alert

3) Nginx/Apache loglarında ilgili aralığı filtreleyin

Log boyutu büyüyebilir. Bu nedenle aralığı filtreleyin.

Nginx için örnek yaklaşım:
erişim ve hata logunu aynı tarih aralığına göre ayırın

Sadece “tüm access.log” göndermek inceleme süresini uzatır; sağlayıcılar genellikle ilgili satırlara hızlı erişmek ister.

4) Log snapshot’ı alın (kanıt seti)

Kanıt seti; bir klasör içinde şu bileşenlerden oluşmalıdır:

timeline.txt (olay özetiniz)
nginx_access.log (filtreli)
nginx_error.log (filtreli)
journal_errors.log (filtreli)
system_time.txt (timedatectl/date çıktısı)
disk_usage.txt (df çıktısı veya ilgili durum)
varsa panel_events.txt (kontrol panelinden alınmış olaylar)

Ardından tek bir arşiv oluşturun:

tar -czvf kanit-paketi-2026-05-16.tar.gz <klasor_adi>

Logların doğruluğu: aynı şeyi iki kez söyleyin (ve çelişki yaratmayın)

Sağlayıcıların incelemesinde en sık görülen problem; farklı kaynaklarda çelişkili zamanların olmasıdır. Bu yüzden logları şu şekilde “çift kontrol” edin.

Çelişki kontrolü: Nginx zamanı vs journal zamanı

Nginx loglarında 5xx üretildiği an ile journalctl içinde ilgili servis restart/crash anı örtüşüyor mu?
Tarihler uyuşmuyor ise saat farkı veya farklı timezone etkisi vardır.

Bu noktada, timeline.txt içinde tek cümlelik not ekleyin:

“Sunucu timezone: Europe/Istanbul. Loglar bu timezonla alındı.”

İstemci tarafı kanıtı: HTTP status ve hata mesajı

Sağlayıcıya “sitenin açılmadığını” yazmak tek başına yeterli değildir. Şu somut çıktıları ekleyin:

Tarayıcıdan alınan hata kodları (ör. 502/503/504)
curl -I çıktıları (ilgili zamanlarda mümkünse)
Uygulama hata mesajları (stack trace parçaları)

Bu çıktılar, loglardaki HTTP 5xx satırlarını doğrular.

“O an bende miydi?” ayrımı: 4 teknik işaret

İptal/iadede kritik ayrım; sorunun sunucu tarafında mı, yoksa uygulamanın/config/internet tarafında mı olduğudur. Loglar bu ayrımı destekleyebilir.

1) Servis düşmesi mi var, yoksa sadece kaynak yetersizliği mi?

journalctl içinde servis crash/restart olayları varsa: altyapı/servis kararlılığı iddiası güçlenir.
Sadece uygulama yavaşlığı ve yüksek CPU/RAM tüketimi varsa: kaynak planlaması iddiası güçlenir.

2) Disk doluluğu trace edilebilir mi?

Nginx/uygulama logunda “No space left on device” gibi satırlar varsa: sorunun nedeni nettir.

3) 4xx/5xx dağılımı ne söylüyor?

Ağırlıklı 502/503: reverse proxy/upstream/servis sağlığı.
Ağırlıklı 504: upstream zaman aşımı.

4) Ağ kesintisi veya DNS etkisi var mı?

Sunucuda servis ayakta ama erişim yoksa, erişim katmanına dair işaretler aranır.

Eğer DNS değişikliği yaptıysanız (Cloudflare/alan adı kayıtları), iptal talebinde loglara ek olarak “şu tarihte şu ayar değişti” notu ekleyin. Aksi halde sağlayıcı bunun etkisini dışarıda bırakmak isteyebilir.

Talep dosyasını nasıl iletmelisiniz? Net şablon

Logları hazırladıktan sonra mesajın yapısı da önemlidir. Tek bir mesajda hem zaman çizelgesi hem de dosyalar bulunmalı.

Mesaj şablonu (kopyalanabilir iskelet)

Konu: “Deneme süresi içinde erişim/performans sorunu - log kanıtı”
Zaman aralığı: “2026-05-10 09:00 - 2026-05-10 12:00 (Europe/Istanbul)”
Etkilenen: “domain.com, nginx, php-fpm”
Somut bulgular:
“Nginx hata logunda 503/502 oluştu. Örnek satırlar: ...”
“systemd journal içinde nginx restart/crash: ...”
“Disk kullanımı: ... / zaman aralığı öncesi ...”
Ekler:
“kanit-paketi-2026-05-16.tar.gz”
“curl çıktıları (varsa)”

Bu yapı, sağlayıcının inceleme ekibinin loglarda kaybolmasını engeller.

Dosya isimlendirme kuralı

Tarih + servis adı + kapsam
Örn: nginx_error_2026-05-10_0900-1200.log

Bu sayede inceleme sürecinde farklı dosyalar karışmaz.

Sık yapılan hatalar: iade/iptali zayıflatan durumlar

Aşağıdaki hatalar, teknik kanıtı olan kullanıcıların bile süreci uzatmasına neden olur:

Logları saat farkı olmadan göndermemek (timezone belirtilmemiş)
Sadece “hata oluştu” demek, hata kodunu ve örnek satırı eklememek
Çok büyük ham log göndermek (tüm access log)
Uygulama kaynaklı hatayı altyapı hatası gibi anlatmak (ör. uygulama exception ama siz sadece sunucu iddianızı yazıyorsunuz)
Kanıt seti olmadan ekran görüntüsü paylaşmak

Ekran görüntüsü tek başına iddiayı güçlendirmez; loglar iddianın omurgasıdır.

Kontrol listesi: taleple birlikte hazır hale getirin

Son aşamada, aşağıdaki kontrol listesini işaretleyin.

İade/iptal kanıt paketi kontrol listesi

[ ] timeline.txt hazır (tarih aralığı + etkilenen servis)
[ ] Nginx/Apache hata logu filtreli (ilgili aralık)
[ ] Journal hata/çökme logları filtreli (ilgili birimlerle)
[ ] timedatectl ve timezone bilgisi
[ ] Disk/CPU/RAM göstergeleri (varsa)
[ ] En az 3 somut olay örneği (ör. 5xx zamanları)
[ ] Tek arşiv halinde dosya: kanit-paketi-....tar.gz

Sonuç: İptal/iadede başarı, “kanıtın zamanla uyumu”dur

Net bir iade/iptal talebi için en güçlü yol; logları zaman aralığına göre toplamak, servis bazında filtrelemek ve tek bir timeline ile bağlamaktır. Aksiyon olarak bugün: sorun yaşadığınız tarih aralığını netleştirin, ilgili Nginx/Apache + journalctl kayıtlarını filtreleyip arşivleyin ve talebinizi log örnek satırlarıyla destekleyin. Bu yaklaşım, sağlayıcının inceleme ekibine “neye bakacağını” hemen gösterir ve süreci teknik zeminde ilerletir.