İade/iptal süreçlerini sunucu loglarıyla kanıtlama rehberi

Bir hosting/VDS/VPS hizmetinde iade (refund) veya iptal talebine ilerlerken, sağlayıcının değerlendireceği şey çoğunlukla "iddia" değil "kanıt"tır. İşin kritik kısmı; sorun başladığı andan bitişe kadar olayları zaman damgası (timestamp) ile birlikte toplayıp, sunucu logları üzerinden okunur bir rapora dönüştürmektir. Bu rehberde, iade/iptal süreçlerinde kullanabileceğiniz log türlerini, hangi komutlarla toplayacağınızı ve nasıl bir zaman çizelgesi (timeline) oluşturacağınızı net biçimde göreceksiniz.

Hangi iade/iptal senaryolarında log zorunlu?

İade/iptal talebinizin kabul olasılığını belirleyen ana etken, sorunu kanıtlayabildiğiniz ölçüde “objektif” görünmenizdir. Aşağıdaki durumlarda loglar doğrudan kritik rol oynar.

Tipik senaryolar

• Sunucunun reklam/taahhüt edilen performansı sağlamaması (CPU throttling, yüksek yük, gecikme artışı)
• Sürekli erişim kaybı (downtime) veya servis çökmesi
• Aşırı paket kaybı / yüksek gecikme (latency) iddiaları
• Güvenlik ihlali iddiası veya anormal saldırı trafiği
• Yanlış yapılandırma değil, “altyapı” veya “platform” kaynaklı olduğu öne sürülen problemler

Logların sağlayıcıya etkisi

Sağlayıcıların çoğu, talebi incelemek için şu sorulara cevap arar: - Sorun ne zaman başladı, ne zaman bitti? - Sorunun kaynağı sistem mi uygulama mı? - Aynı zaman aralığında başka kullanıcı/VM etkilenmiş mi? - Otomatik sistem logları “neden”i destekliyor mu?

Bu nedenle amaç; sadece “sunucu kötüydü” demek değil; zaman aralığı + olay + kanıt üçlüsünü üretmektir.

1. Aşama: Zaman çizelgesi oluşturun (timeline disiplinli yaklaşım)

İade/iptal süreçlerinde en sık yapılan hata, logları toplasa bile onları “ne zaman ne oldu” şeklinde birleştirmemektir. İlk adım olarak sorunun zamanını sabitleyin.

Timeline şablonu (kopyala-doldur)

Aşağıdaki formatla not alın. İsterseniz bir not uygulaması veya e-posta içine doğrudan yapıştırın.

• Talep konusu: (örn. “Sürekli downtime: 11:20–12:35 arası HTTP erişimi yok”)
• Etkilenen servis: (örn. Nginx/Apache, WordPress, API endpoint)
• Keşif zamanı: (ilk fark ediş)
• Başlangıç zamanı: (kesin gözlem/ölçüm)
• Bitiş zamanı: (düzeldiği an)
• Beklenen: (taahhüt/konfigürasyon)
• Gözlem: (hata mesajı/ekran görüntüsü)
• İlgili log dosyaları: (aşağıdaki listeden)

Zaman uyumu: saat dilimi problemi

Sunucu logları çoğunlukla sunucunun saat dilimiyle kaydedilir. Raporunuzda iki kritik bilgi olmalı: - Sunucu saat dilimi (ör. UTC) - Loglarda gördüğünüz zamanın saat dilimi

Sisteminizin saatini ve saat dilimini kontrol edin:

• date
• timedatectl

Raporunuza şu tek cümleyi ekleyin: "Loglar UTC saat dilimi ile kaydedilmiştir" (ya da kendi durumunuz neyse).

2. Aşama: Temel log paketini toplayın

Logları “tek tek dosya gönderme” yerine tek bir paket halinde düzenlemek daha etkilidir. Toplama yaklaşımı; erişim logları, sistem logları ve uygulama loglarını aynı zaman aralığıyla eşleştirmektir.

Önerilen klasör yapısı

• support_bundle/
• 01_timeline/
• 02_system/
• 03_network/
• 04_service/
• 05_app/
• 06_resource/
• 07_config/

Hangi log türleri gerekli?

Aşağıdaki tablo, iade/iptal senaryonuza göre en anlamlı logları özetler.

3. Hızlı toplama komutları (Linux için net yöntem)

Aşağıdaki komutlar, sunucu erişiminiz olduğu varsayımıyla hazırlanmıştır. İhtiyacınıza göre yalnızca ilgili aralığı yakalayın.

3.1 Sistem olayları: journalctl (en değerli kaynak)

Belirli bir zaman aralığı için örnek:

journalctl --since "2026-08-11 11:00:00" --until "2026-08-11 13:00:00" --no-pager > support_bundle/02_system/journal_subset.txt

Sunucuda servis çökmesi veya yeniden başlatma varsa “neden”yi genelde burada görürsünüz. Ek olarak kernel seviyesinde çekirdek mesajlarını inceleyin:

dmesg --ctime --level=err,warn > support_bundle/02_system/dmesg_err_warn.txt

3.2 Servis logları: web sunucusu (Nginx/Apache)

Nginx için:

sudo grep -R "\[error\]" /var/log/nginx/ -n | head -n 200 > support_bundle/04_service/nginx_error_sample.txt

Zaman aralığına göre filtrelemek için “server hata logu formatına” göre grep/awk kullanın. Daha net yaklaşım için log formatını standartlaştırın (sağlayıcıyla paylaşacaksanız).

Apache için:

sudo grep -R "AH[0-9]" /var/log/apache2/ -n > support_bundle/04_service/apache_error_sample.txt

3.3 Kimlik doğrulama (auth) logları

Güvenlik iddiası veya izinsiz erişim varsa:

sudo journalctl -u ssh --since "2026-08-11 11:00:00" --until "2026-08-11 13:00:00" --no-pager > support_bundle/05_app/ssh_auth_subset.txt

Bazı dağıtımlarda ayrıca /var/log/auth.log veya /var/log/secure bulunur:

• Debian/Ubuntu: /var/log/auth.log
• RHEL/CentOS: /var/log/secure

3.4 Kaynak kullanımı: CPU/RAM/OOM tespiti

Performans düşüşü iddiasında, en ikna edici kanıtlar OOM ve anormal kaynak pikleridir.

Otomatik OOM yakalayan mesajları arayın:

journalctl --since "2026-08-11 11:00:00" --until "2026-08-11 13:00:00" -k --no-pager > support_bundle/06_resource/kernel_subset.txt

Linux’ta sysstat kuruluysa (bazı imajlarda gelir), sar çıktıları çok nettir. Yüksek yük zamanlarını gösterir. Örnek paket mantığı: - sar -u (CPU) - sar -r (RAM) - sar -n DEV (ağ)

sysstat yoksa o anda çalıştırıp “o anki durum”u da ekleyin:

top -b -n 1 | head -n 80 > support_bundle/06_resource/top_snapshot.txt
free -h > support_bundle/06_resource/free_snapshot.txt

3.5 Ağ bağlantısı: ss ve arayüz durumları

Ağla ilgili iptal/değerlendirme taleplerinde, “bağlantı kurulamadı” veya “paket kaybı” iddialarını destekleyin.

ss -s > support_bundle/03_network/ss_summary.txt
ip a > support_bundle/03_network/ip_addr.txt
ip route > support_bundle/03_network/ip_route.txt

Arayüz hata sayıları için (gerektiğinde):

cat /proc/net/dev > support_bundle/03_network/proc_net_dev.txt

4. Aynı olayı web erişim loglarıyla doğrulayın

Sunucu “hata vardı” demek yerine, istemcilerin erişim davranışını gösteren web logları genelde en güçlü destekleyicidir.

4.1 Erişim loglarını zaman aralığıyla çıkarın

Nginx erişim logu örnek:

grep "2026-08-11T11:" /var/log/nginx/access.log | head -n 200 > support_bundle/05_app/nginx_access_subset.txt

Apache erişim logu örnek:

grep "2026-08-11" /var/log/apache2/access.log | head -n 200 > support_bundle/05_app/apache_access_subset.txt

Burada hedef, şu göstergeleri rapora taşımaktır: - 5xx artışı - 4xx patlaması (bazı olaylar saldırı gösterebilir) - Aynı endpoint’te denemeler - “Uygulama çökmesi” ile “sunucu çökmesi”nin ayrımı

4.2 Kanıtı tek sayfalık özetleştirin

İnceleyen kişi 2 dakika içinde şunu görmeli: - Zaman aralığında 5xx/downtime var mı? - Bu aralığa denk gelen sistem olayları var mı?

Bu nedenle paketinizde ayrıca bir README.txt olmalı.

Örnek mini özet: - "11:20–12:35 arası nginx erişimlerinde 502/504 yoğunluğu var" - "Aynı aralıkta kernel tarafında OOM/yeniden başlatma olayları görünüyor" - "Sistem loglarında servis restartları bulunuyor"

5. Paketleme ve gönderim: destek ekibi hangi dosyaları ister?

İade/iptal değerlendirmesinde genelde iki şey önemlidir: hızlı erişim ve tutarlılık.

Gönderim önerisi (dosya listesi)

Aşağıdaki dosyalar “minimum güçlü paket”tir.

• support_bundle/01_timeline/timeline.txt
• support_bundle/02_system/journal_subset.txt
• support_bundle/02_system/dmesg_err_warn.txt
• support_bundle/04_service/nginx_error_sample.txt (veya Apache muadili)
• support_bundle/05_app/<servise özel log subset>
• support_bundle/06_resource/kernel_subset.txt
• support_bundle/03_network/ss_summary.txt

Dosya bütünlüğü ve düzen

• Arşivi tar ile oluşturun.
• Dosya adlarında tarih-saat kullanın.
• Okunabilirlik için ham çıktılardan sonra “kısa özet” ekleyin.

Örnek arşiv:

tar -czf support_bundle_2026-08-11.tgz support_bundle/

6. Raporun dilini teknik yapın (iddia değil bulgu)

Loglarla birlikte yazacağınız metin, iade/iptali hızlandıran veya geciktiren belirleyicidir. Sağlayıcının teknik ekibi “ne istiyorsunuz ve neden?” sorusuna saniyeler içinde cevap bulmalıdır.

İyi rapor örneği (format)

• Konu: "Downtime ve 5xx artışı"
• Zaman aralığı: "UTC 11:20–12:35"
• Kanıt:
• "journalctl: servicename restart/restart reason" (dosya adı)
• "nginx access: 502/504 yoğunluğu" (dosya adı)
• "kernel subset: OOM/segfault/timeout mesajları" (dosya adı)
• Sonuç:
• "Bu aralıkta uygulama kesintiye uğradı"
• "Taahhüt edilen SLA/performans sağlanmadı" (yalnızca sizde ölçüm varsa)
• Talep:
• "İade/iptal değerlendirmesi için log paketinin incelenmesini rica ederim"

Kötü rapor örneği (kaçının)

• "Sunucu çok kötü, iade istiyorum"
• "Her şeyden şüpheleniyorum"
• “Zaman aralığı” olmadan sadece ekran görüntüsü paylaşmak

7. Ölçüm de ekleyin: log + ölçüm birlikte daha güçlüdür

Log tek başına her şeyi ispatlamayabilir. Özellikle gecikme (latency) ve bant genişliği iddialarında, loglar kadar ölçüm de gereklidir.

En pratik ölçümler (içeride/şeffaf şekilde)

• ping (latency/zaman)
• mtr (packet loss + route)
• Uygulama seviyesinde hata oranı (ör. Nginx 5xx oranı)

Ölçümü yapabildiğiniz anda komut kaydını da support_bundle/ içine koyun:

• mtr çıktısı
• Paket kaybı/ortalama gecikme değerleri

8. İade/iptal talebinde “sorumluluk” ayrımı: platform mu uygulama mı?

Kanıtınız, sorunun kaynağını ayırmaya yardım etmeli.

Platform kaynaklı olasılıklar

• Aynı zaman aralığında çekirdek/kayıtlarında yeniden başlatma veya OOM
• Ağ hataları ve arayüz problemleri
• Sağlayıcı alt yapısıyla tetiklenen “node” olayları

Uygulama kaynaklı olasılıklar

• Yalnızca belirli endpoint’lerde 5xx
• Uygulama loglarında exception patlaması, sistem loglarında OOM yok
• Cron/job kaynaklı aşırı yük (ör. tek seferlik peak)

Burada yapılacak doğru şey; “sorunun uygulama değil platform olduğuna” dair kesin iddia atmak yerine, loglarınızın işaret ettiği bölgeyi açık söylemektir.

Örnek ifade: - "journalctl -k çıktısında OOM olayları bulunduğu için kaynak yetersizliği tetikleyicisi var. Bu olaylar 11:20–12:35 aralığıyla örtüşüyor."

Sonuç: Aksiyon planı

İade/iptal sürecini sunucu loglarıyla desteklemek için tek hedefiniz “kanıt + zaman uyumu + özet” üretmek olsun. İlk adım olarak sorunun başladığı/bittiği zamanı UTC (veya sunucu saat dilimi) ile sabitleyin; ardından journalctl (sistem), web server error/access logları (uygulama) ve kaynak/ağ çıktıları (OOM/CPU/latency) paketini oluşturun. En sonda da sağlayıcının teknik ekibinin 2 dakika içinde anlayacağı şekilde README.txt ile bulguları zaman çizelgenize bağlayın. Bu yaklaşımı uyguladığınızda talebiniz varsayıma değil, doğrulanabilir kayıtlara dayanır.