Core dump, üretimde “en faydalı ama en riskli” debug artefaktlarından biridir. Çünkü bir prosesin belleğini yakalarsınız: bu, root-cause için altın değerinde olabilir; ama aynı zamanda secret / token / PII gibi verileri de içerebilir.
Bu runbook’un hedefi şu dengeyi kurmak:
- Debug için yeterli veri (özellikle nadir crash’ler)
- Disk ve performans kontrolü
- Gizlilik ve erişim modeli
- Incident sırasında “güvenli analiz” akışı
1) Karar: Core dump açık mı, kapalı mı?
İlk soru teknik değil, operasyonel:
- Crash nadir mi, reprodüksiyon zor mu?
- İlgili servis PII/secret taşıyor mu?
- Log/metric/trace ile aynı teşhis yapılabiliyor mu?
2) Temel kontrol noktaları
Linux’ta core dump akışını belirleyen ana bileşenler:
ulimit -c(core dump boyut limiti)/proc/sys/kernel/core_pattern(nereye yazılacağı)- systemd’nin
systemd-coredumpdavranışı (coredump.conf)
Hızlı durum kontrolü
ulimit -c
sysctl kernel.core_pattern
systemctl status systemd-coredump3) systemd-coredump yapılandırması (örnek yaklaşım)
Dağıtıma göre path değişebilir; çoğu sistemde:
/etc/systemd/coredump.conf/etc/systemd/coredump.conf.d/*.conf
Örnek politika: boyutu ve saklamayı sınırla, disk dolmasını önle:
[Coredump]
# core dosyalarını diske yaz
Storage=external
# boyut limitleri (örnek)
ProcessSizeMax=2G
ExternalSizeMax=2G
# toplam disk kotası (örnek)
MaxUse=10G
KeepFree=5G
# eski core'ları temizleme
Compress=yesDeğişiklik sonrası:
sudo systemctl daemon-reload4) Gizlilik: Core dump bir “secret kaynağıdır”
Core dump’larınızı şu klasmanda düşünün:
- Erişim: sadece incident/debug rolü (en az ayrıcalık)
- Saklama: kısa süreli (ör. 7-14 gün)
- Aktarım: şifreli kanal + hedefte şifreleme
- Audit: kim okudu, ne zaman indirdi, hangi ticket ile
Pratik koruma seti:
- Core dump dizinine root-only izinler
- Merkezi log hattına “coredump created” event’i
- Eğer dışarı taşınıyorsa: şifreli artefact store (ve mümkünse WORM/immutability)
5) Incident runbook: Crash olduğunda ne yapacağız?
- Crash’i doğrula:
journalctl -u systemd-coredump --since "2 hours ago"
coredumpctl list --since "2 hours ago"- Hangi binary ve hangi versiyon?
- paket versiyonu / image digest
- deploy zamanı
- config/flag versiyonu (değer değil, sürüm)
- Analiz ortamı:
- Core dump’ı üretim sunucusunda analiz etme (risk + performans)
- Ayrı bir “debug VM” veya izole ortam kullan
- Erişim ve kayıt:
- “Kim aldı?” kaydı (ticket)
- Artefact lifecycle: analiz bitince temizle
6) Sık görülen hatalar
- Sınırsız core dump: disk dolar, incident büyür
- Secrets içeren proseslerde kontrolsüz saklama
- Debug erişimi “herkese açık” (kötü pratik)
- Core dump alındıktan sonra “temizlik” yapılmaması
Doğru tasarlanmış core dump politikası; crash’leri hızlı teşhis eder, aynı zamanda güvenlik ve operasyon maliyetini yönetilebilir kılar. Üretimde amaç “daha çok veri” değil, doğru veri + kontrollü süreç olmalı.