Hastanelerde ve cerrahi merkezlerde en kritik hijyen protokollerinden biri tıbbi atık yönetimidir. Ameliyathanelerden çıkan biyolojik atıklar, kanlı gazlı bezler, drenaj sıvıları ve tek kullanımlık enjektörler özel sızdırmaz konteynerlerde toplanır ve her mesai bitiminde imha edilmek üzere merkezi tıbbi atık ünitesine tahliye edilir. Şimdi hastane yönetiminin "Nasılsa bodrum katındaki atık odamız çok geniş, taşarsa bakarız" diyerek bu tahliyeyi unuttuğunu düşünün. Aylar boyunca binlerce cerrahi operasyonun atığı o odaya yığılır. Sonunda atık torbaları tavana kadar ulaşır; kapıyı patlatır, havalandırma kanallarını tıkar, ameliyathane koridorlarına taşar ve oksijen santralinin elektrik panolarını kısa devre yaptırır. Hastanede steril ameliyathane kalmaz, elektrikler kesilir ve hastalar tahliye edilmek zorunda kalınır. Felaketin sebebi mikroplar veya cerrahi bir hata değil; basit bir çöp tahliye disiplinsizliğidir.
Linux sunucu altyapılarında logrotate yapılandırmasını unutmak ya da yeni kurulan bir servisin loglarını serbest bırakmak, tam olarak bu ameliyathane çöpünün kontrolsüzce taşmasıdır.
Sessiz Büyüyen Tümör: /var/log/ Depremi
Bir sunucu ayağa kaldırıldığında her servis (Nginx, Apache, PHP-FPM, Docker, PostgreSQL, Redis ve özel Node.js/Python betikleri) yaptığı her hareketi günlüğe kaydeder.
- Web sunucusuna gelen her HTTP isteği
access.logdosyasına bir satır ekler. - Her hata, uyarı veya stack trace
error.logdosyasına işlenir.
Geliştirme aşamasında bu dosyalar birkaç yüz kilobayttır; kimse dönüp bakmaz. Ancak sistem canlıya (production) alındığında ve saniyede yüzlerce istek işlemeye başladığında bu dosyalar sessiz birer veri emicisine dönüşür:
[Canlıya Çıkış - Gün 1] : access.log -> 5 MB (Her şey harika)
[Hafta 4] : access.log -> 4.2 GB
[Ay 3] : access.log -> 38.5 GB
[Gece 03:42 - Ay 6] : access.log -> 98.9 GB (Disk Alanı: %100 DOLU!)
Ve o gece saat 03:42'de diskte kalan son 1 megabayt da tükendiğinde, sunucuda domino etkisiyle çalışan bir acil durum siren sesi başlar.
Diskin %100 Dolması Anında Ne Olur? İlk Kurban Kimdir?
Birçok acemi yönetici diskin dolmasının sadece yeni logların yazılamamasıyla sonuçlanacağını zanneder. Oysa modern bir işletim sisteminde diskin tamamen dolması (No space left on device), sistemin hayati organlarının anında iflas etmesi demektir.
┌─────────────────────────┐
│ DİSK %100 DOLDU! │
└───────────┬─────────────┘
│
┌───────────────────────────┼───────────────────────────┐
▼ ▼ ▼
[İLK KURBAN: MySQL] [İKİNCİ KURBAN: SSH] [ÜÇÜNCÜ KURBAN: Cron]
- InnoDB Redo Log yazamaz - /tmp/ veya /run doldu - State dosyası yazamaz
- Transaction açılamaz - SSH oturumu açılamaz! - Görevler donar
- MySQL PANİK ATARAK - "Session closed by - Yedekler alınamaz
SERVİSİ DURDURUR! ❌ remote host" ❌
1. İlk İnfaz: Veritabanı Sunucusu (MySQL / PostgreSQL)
İlişkisel veritabanları ACID güvencesini sağlamak için her işlemden önce WAL (Write-Ahead Logging) veya InnoDB Redo Log yazar. Disk dolduğu an veritabanı motoru güvenli bir şekilde veri yazamayacağını anlar. Veri bütünlüğünün bozulmasını (corruption) engellemek için motor derhal kendini acil kapatmaya (emergency shutdown / panic) alır!
mysqld.service: Main process exited, code=killed, status=6/ABRT
E-ticaret siteniz, API servisiniz ve mobil uygulamanız anında çöker.
2. İkinci Kurban: SSH Girişleri Kilitlenir!
Sunucu çöktüğünde mühendis terminale koşar: ssh root@sunucu.
Ancak giriş yapılamaz! Neden? Çünkü Linux oturum açarken /var/log/wtmp veya /run/utmp dosyasına kayıt yazmak zorundadır, PAM modülü geçici dosya oluşturamaz. Sunucu "No space left on device" diyerek SSH oturumunuzu açıldığı milisaniyede yüzünüze kapatır! Mühendis sunucunun içine bile giremez.
Logrotate Mimarisi: Dijital Çöp Tahliyesi Nasıl Çalışır?
Linux dağıtımlarında bu felaketi engellemek için yerleşik bir bekçi vardır: logrotate.
Her gece cron.daily veya systemd.timer tarafından tetiklenen logrotate, belirlenen kurallara göre devasa logları parçalar, sıkıştırır (gzip) ve eskiyenleri imha eder.
Örnek bir Nginx logrotate dosyası (/etc/logrotate.d/nginx):
/var/log/nginx/*.log {
daily # Günlük olarak döndür
missingok # Dosya yoksa hata verme
rotate 14 # En fazla 14 günlük arşiv tut, eskileri sil
compress # Arşivleri gzip ile sıkıştır (%90 yer kazancı)
delaycompress # En son günün yedeğini hemen sıkıştırma (açık tut)
notifempty # Dosya boşsa döndürme
create 0640 www-data adm# Yeni boş log dosyasını bu izinlerle oluştur
sharedscripts
postrotate
# Nginx'e dosya tanıtıcısını (file descriptor) yeniden açması için sinyal ver!
if [ -f /var/run/nginx.pid ]; then
kill -USR1 `cat /var/run/nginx.pid`
fi
endscript
}En Ölümcül Hata: Dosyayı rm -f access.log İle Silmek!
Gece 04:00'te diski dolmuş sunucuya kurtarma konsolundan bir şekilde giren acemi sistem yöneticisi df -h yazar:
/dev/sda1 100G 100G 0 100% /
Hemen /var/log/nginx/ dizinine gider, 80 GB'lık devasa access.log dosyasını görür ve zafer kazanmış bir komutan edasıyla komutu fırlatır:
rm -f access.log
Ardından tekrar df -h yazar. Bir de bakar ki disk HÂLÂ %100 DOLUDUR!
Mühendis cinnet noktasına gelir: "Dosyayı sildim ama boş yer açılmadı! Bu sunucu bozuldu!"
Neden Boş Yer Açılmadı? (Unlinked File Descriptors)
Linux dosya sisteminde (ext4 / XFS) bir dosya iki parçadan oluşur: Dizin tablosundaki isim (dentry) ve diskin bloklarını tutan inode.
Nginx çalışmaya devam ettiği sürece access.log dosyasını açık bir dosya tanıtıcısıyla (file descriptor) tutmaktadır. Siz rm komutu verdiğinizde sadece dizindeki ismi silersiniz. Ancak dosya bir süreç (Nginx worker) tarafından hala açık tutulduğu için Linux çekirdeği o 80 GB'lık fiziksel blokları diske iade etmez! Dosya "hayalet" (deleted but held open) olarak bellekte ve diskte yaşamayı sürdürür.
# Hayalet dosyayı yakalama komutu:
lsof | grep deleted | grep log
# Çıktı:
# nginx 1420 www-data 4w REG 8,1 85899345920 12458 /var/log/nginx/access.log (deleted)Doğru Acil Müdahale: Dosyayı Silmeyin, İçini Boşaltın (Truncate)!
Canlıda açık olan bir log dosyasını anında sıfırlayıp disk alanını geri kazanmanın tek cerrahi yolu dosyayı silmek değil, içini kesmektir (truncate):
# Dosya tanıtıcısını bozmadan fiziksel blokları anında sıfırlar:
> /var/log/nginx/access.log
# Veya:
truncate -s 0 /var/log/nginx/access.logBu komut çalıştığı anda df -h çıktısında 80 GB boş alanın anında açıldığını görürsünüz! Ardından Nginx'e sinyal verilir (kill -USR1) veya servis yeniden başlatılır.
Önleyici Tıbbi Reçete: Sistemik Güvenceler
Bir sunucunun loglar yüzünden komaya girmesini engellemek için üç katmanlı bir savunma hattı kurulmalıdır:
- Özel Servisler İçin Mutlaka Logrotate Kuralı Ekleyin:
Node.js (PM2), Python (Gunicorn/Uvicorn), Go binary'leri gibi özel uygulamalarınızın loglarını/etc/logrotate.d/uygulamaaltına tanımlayın. Tanımsız bırakılan her log dosyası bir gün diski patlatacaktır. - Kritik Dizinleri Bağımsız Bölümlere (Partition) Ayırın:
Üretim sunucularında/varve/var/logdizinleri ana kök dizinden (/) ayrı disk bölümlerine bağlanmalıdır. Bu sayede loglar tamamen dolsa bile, işletim sisteminin kök dizini (/) ve/tmpdolmaz; SSH bağlantınız kesilmez, sistem yöneticisi dışarıda kalmaz. - Diski İzleyen Nöbetçi Problar (Monitoring & Alerting):
Prometheus Node Exporter, Datadog veya basit bir Monit betiği ile disk doluluğu %80'e ulaştığında acil durum e-postası veya Slack/Telegram bildirimi gönderin. Kriz yaşanmadan 3 hafta önce haberiniz olsun.
Sonuç
Tıbbi atıklarını düzenli tahliye etmeyen bir hastane steril kalamaz; log rotasyonunu yapılandırmayan bir Linux sunucusu da ayakta kalamaz.
Geliştiriciler log yazmayı çok sever; ancak sistem mühendisleri o logların nasıl ve ne zaman imha edileceğini planlamakla yükümlüdür. Sunucunuzun kendi hafızası altında boğulmasını istemiyorsanız; logrotate'i bir detay değil, sunucunuzun temel solunum filtresi olarak yapılandırın.