İade/iptal süreçlerinde sunucu loglarıyla net kanıt sunma

Sunucu hizmeti alırken en kritik konulardan biri, problem yaşandığında iade/iptal sürecini uzatmadan, somut delillerle ilerletmektir. “Sunucu yavaş çalışıyordu” gibi ifadeler yerine, altyapının gerçekten ne yaptığını gösteren kayıtlar gerekir: hata logları, performans metrikleri, oturum ve işlem kayıtları gibi. Bu rehberde, iade/iptal talebinde sağlayıcıyı ikna eden kanıtların hangi loglardan toplanacağını, zaman damgalarının nasıl eşleneceğini ve dosyaların hangi biçimde iletileceğini adım adım anlatıyorum.

1) İade/iptal için kanıt mantığı: “Ne oldu, ne zaman oldu?”

İade/iptal başvurusu çoğu senaryoda şu üç soruya cevap ister:

Sorun neydi? (ör. bağlantı kopması, 5xx hataları, disk dolması, OOM, login denemeleri)
Ne zaman başladı / ne kadar sürdü?
Sorun sizde mi başkalarında mı oluştu? (ör. bakım penceresi, sağlayıcı tarafı olayları, sizin tarafınızda yanlış konfigürasyon)

Bu yüzden kanıt paketinizin çekirdeğinde iki şey olmalı: - Zaman damgası (timestamp) tutarlılığı: olaylar saat/dakika seviyesinde eşleşmeli. - Doğrulanabilir log: düz metin loglar, hata kodları, olay raporları ve metrik ekran görüntüsü (tercihen ham değerle).

1.1. Zaman senkronu (clock drift) iade sürecini etkiler

Logların çoğunda zaman damgası vardır ancak sunucunuzun saati ile sağlayıcının izlediği saat farklı olabilir. Bu nedenle başvuru öncesi sunucuda şu kontrolleri yapın: - Linux’ta timedatectl ile saat dilimi ve NTP durumu - Uygulamanızda (ör. Nginx/Apache) zaman damgasının yerel saat mi UTC mi olduğunu bilin

Hedefiniz şu: Log dosyaları arasında “olay öncesi/olayı” net görünsün.

2) Hangi loglar “en hızlı sonuç” verir? (servis türüne göre)

Aşağıdaki liste, iade/iptal taleplerinde en çok işe yarayan kayıtları verir. Sizdeki servis stack’ine göre seçin.

2.1. Uygulama web ise (Nginx/Apache + uygulama)

Nginx error log: 502/504, upstream timeouts, permission hataları
Örnek yol: /var/log/nginx/error.log
Nginx access log: belirli endpoint’te artan 5xx/timeout oranı
Örnek yol: /var/log/nginx/access.log
Uygulama logları:
Node.js: pm2 logları veya uygulama stdout/stderr
PHP: PHP-FPM error log
Java: tomcat/journal veya application log
Sistem Olayları: kernel oops, OOM killer, disk I/O hataları
Örnek: dmesg çıktısı (olay saat aralığıyla)

2.2. Veritabanı tarafıysa (MySQL/MariaDB/PostgreSQL)

MySQL/MariaDB error log
Örnek: /var/log/mysql/error.log veya /var/log/mariadb/mariadb.log
PostgreSQL log (CSV/Plain)
Örnek: postgresql-*.log
Performans metrikleri:
CPU yükselmesiyle bağlantı kesilmesi
Too many connections benzeri durumlar (hata kaydı + zaman aralığı)

2.3. SSH/VPS tarafında erişim sorunuysa

Auth log: başarısız giriş denemeleri değil, gerçek erişim kesilmesi/hataları
Örnek: /var/log/auth.log (Debian/Ubuntu) veya /var/log/secure (CentOS/RHEL)
SSH daemon logları
Uygulamanın “bağlantı kuramama” hataları: sizin hostunuzdan mı, sağlayıcı ağından mı?

2.4. Disk ve kaynak (CPU/RAM) problemlerinde

aşağıdaki kayıtlar “tahmini” yerine “kanıt” sunar: - dmesg / journalctl: - OOM killer - I/O error - kernel watchdog - Disk doluluk: - df -h (olay sonrasında alınırsa yine işe yarar) - log içinde No space left on device - Kaynak anlıkları: - top, htop ekran görüntüsü tek başına zayıf olabilir; mümkünse olay saat aralığı için metrik çıkartın.

3) Zaman aralığı seçimi: doğru pencereyi kurun

İade/iptal başvurularında en sık hata: çok geniş log yollamak ya da olay saatini yanlış vermektir. Sağlayıcı ekibi genellikle şu şekilde çalışır: - Önce olay saat aralığını daraltır. - Sonra o aralığa denk gelen error logları ve sistem olaylarını tarar.

3.1. Olay penceresini 2 adımda daraltın

İlk belirtiyi yazın: “20:15 civarında uygulama 502 vermeye başladı”
Sonra logdan teyit edin: - access log’da 5xx artışı - error log’da upstream timeout / connect() failed

Sonuç: “20:12–20:38” gibi net aralık.

3.2. UTC/local karışmasını engelleyin

Başvuru formunda saat dilimini belirtin. Örnek ifade: - “Loglar sunucuda Europe/Istanbul saat dilimi ile alındı.” - “Olay saati 2026-07-10 20:12–20:38 (TR, UTC+3).”

Bu basit açıklama, karşı tarafın logları kaydırmasını engeller.

4) Kanıt paketini tek dosyada toplayın: “log bundling” standardı

Sunucu loglarını düzensiz göndermek yerine, sağlayıcının hızlı inceleyeceği bir paket hazırlayın.

4.1. Paket içeriği (önerilen minimum set)

Aşağıdaki dosyaları tek bir klasörde toparlayın: - README.txt (kısa özet) - time_window.txt (olay başlangıç/bitiş + saat dilimi) - nginx_error.log (olay aralığına kırpılmış) - nginx_access.log (olay aralığına kırpılmış veya 5xx istatistiği) - Uygulama/servis logu - Sistem logu parçası: - journalctl çıktısı (olay aralığı) - Disk/CPU kanıtı: - olay aralığı öncesi-sonrası df -h çıktısı (varsa)

4.2. Linux’ta olay aralığına göre log filtreleme

Aşağıdaki komutlar örnek niteliğindedir. Kendi sunucunuzdaki log konumlarına göre uyarlayın.

Nginx error log içinde belirli zaman aralığı için grep/awk ile filtreleme:
Örnek akış: log zaman damgasını aynı formatta yakalayın ve sadece olay penceresini çıkarın.
journalctl ile olay penceresi:
journalctl --since "2026-07-28 20:12:00" --until "2026-07-28 20:38:00" > journal_window.txt

Not: Amaç, sağlayıcının “binlerce satırı tek tek taramasını” önlemek.

4.3. Mahremiyet: kişisel veri ve gizli bilgiyi temizleyin

Loglar bazen API anahtarları, kullanıcı IP’leri veya session token içerebilir. - E-posta adresi, API key, JWT, parola gibi verileri maskeleyin. - Sağlayıcı teknik ekibi genelde ham log ister; fakat gizli bilgi sizde kalmalı. Maskeleme sonrası log yapısı bozulmuyorsa gönderin.

5) Loglarla birlikte sayısal doğrulama ekleyin (kanıtı güçlendiren metrikler)

Sadece log göndermek çoğu zaman yeterli değildir; ancak doğru metrik eklendiğinde iade/iptal değerlendirmesi hızlanır.

5.1. Şu metrikler “log’u anlamlandırır”

Ortalama ve tepe CPU kullanımı (olay penceresinde)
RAM kullanımı + OOM var mı?
Disk doluluğu ve I/O wait
Network packet loss veya latency (varsa)
Uygulama tarafı:
5xx oranı artışı
Ortalama yanıt süresi (p95/p99)

Bu metrikleri sağlayıcıdan isteyebilirsiniz; sizde de varsa olay penceresine kırpılmış şekilde ekleyin.

5.2. Nginx 5xx kanıtını basit şekilde raporlayın

Örnek yaklaşım: - access log’dan 5xx sayısını çıkarın - Olay penceresinde 5xx oranını önce/sonra ile kıyaslayın

Özellikle şu format iyi çalışır: - “20:12–20:38 aralığında 502+504 toplamı: X; aynı gün 2 saat önce toplam: Y.”

6) Sağlayıcıya iletme biçimi: iade/iptal biletini net yazın

Log dosyaları kadar, bilet mesajının yapısı da önemlidir. Sağlayıcı ekibi sizden şu standartta bir özet bekler.

6.1. Bilet mesajı şablonu (kopyala-doldur)

Aşağıdaki formatı doğrudan kullanın:

Ürün: (VPS/VDS/web hosting/dedicated)
Etki: (ör. site 502 vermeye başladı)
Tarih/saat: 2026-07-28 20:12–20:38 (Europe/Istanbul)
Kanıt: nginx_error.log ve journal_window.txt ektedir
Denediğim düzeltmeler: (örn. cache temizleme, servisi restart, config doğrulama)
Sonuç: Sorun devam ediyor, iade/iptal talep ediyorum

6.2. “Bizde mi sağlayıcıda mı?” ayrımı

İfade dilini net tutun. Örneğin: - “Olay penceresinde kernel OOM killer kayıtları ve Nginx upstream timeout hataları eş zamanlıdır.” - “Aynı saat aralığında bağlantı kopması SSH auth loglarında değil, web upstream timeout şeklindedir.”

Bu tür bağlantılar, sağlayıcının logları daha hızlı bağlamlandırmasını sağlar.

7) Sık hatalar: log var ama iade/iptal reddediliyor

Aşağıdaki durumlar iade/iptal sürecini gereksiz uzatır:

Yanlış saat dilimi: Loglar UTC, siz TR belirtiyorsunuz.
Olay penceresini daraltmama: 1 aylık log gönderip beklemek.
Sadece ekran görüntüsü: Sağlayıcı görür ama doğrulama zorlaşır.
Kanıt olmadan beklenti: “Performans kötü” yerine “20:12–20:38 aralığında 502/504 artışı + upstream timeout” demek gerekir.
Gizli veri içeren log: Gönderim durdurulur, yeniden talep açılır.

7.1. “Daha hızlı sonuç” için pratik kontrol listesi

Başvuru öncesi şu maddeleri tamamlayın: - [ ] Olay penceresi net (başlangıç-bitiş) - [ ] Saat dilimi belirtildi (TR/UTC) - [ ] En az 1 uygulama hatası logu + 1 sistem olayı logu var - [ ] 5xx/timeout gibi sayısal işaretler eklendi - [ ] Loglarda gizli veri maskelemesi yapıldı - [ ] README.txt ile olay kısa özetlendi

Sonuç: İade/iptal sürecini uzatmayacak aksiyon

NetKıyas’ta hedefiniz ürün seçimini doğru yapmak olsa bile, her zaman senaryo değişebilir. Bu yüzden iade/iptal sürecinde en etkili adım, logları “kanıt paketine” dönüştürmektir: zaman penceresi, ilgili error log, olayla eşleşen sistem kayıtları ve kısa bir README ile ilerleyin. Bugün başlayın: Olayların saat aralığını belirleyin, seçtiğiniz logları kırpın ve biletinizi şablona uygun şekilde düzenleyin. Bu düzen, değerlendirme süresini belirgin biçimde kısaltır.