Geçen hafta Çarşamba sabahı 04:00 civarı, kendi VPS’imde koşan monitör sistemimden gelen “Disk Usage Critical” mailiyle uyandım. İlk başta “yine ne oldu acaba” diye düşünsem de, daha önce yaşadığım VPS overload ve OOM senaryolarından edindiğim tecrübeyle sakin kalmaya çalıştım. SSH ile bağlanmaya çalıştığımda bile sistemin zorlandığını gördüm, hatta bir süre sshd bağlantılarını bile kabul edemedi.
Bu seferki suçlu, tahmin ettiğim gibi bir veritabanı şişmesi ya da yanlış yapılandırılmış bir cache değildi. Sistemdeki 13’ten fazla Docker container’ın ürettiği log dosyaları, disk alanımı sessizce ve sinsi bir şekilde tüketmişti. df -h komutu %100 disk doluluğunu gösterdiğinde, sorunun kaynağını bulmak için derinlemesine bir incelemeye giriştim.
Disk Neden Doluyor? Docker Loglarının Sinsiliği
Docker’ın varsayılan json-file logging driver’ı, logları basitçe her konteyner için ayrı bir JSON dosyasına ekler. Bu, küçük ve kısa ömürlü konteynerler için sorun yaratmazken, benim gibi uzun süreli çalışan ve bolca çıktı üreten servislerde zamanla ciddi bir problem haline geliyor. Özellikle benim Astro sitelerim, AI generation pipeline’ım ve diğer yan ürünlerim (hesapciyiz.com, islistesi.com) sürekli log üretiyor.
Bir konteyner ne kadar çok log üretirse, o log dosyası o kadar büyür. Docker, varsayılan olarak bu log dosyalarını otomatik olarak döndürmez veya temizlemez. Bu da demek oluyor ki, eğer siz müdahale etmezseniz, log dosyaları sonsuza kadar büyüyebilir ve diskinizi tamamen doldurabilir. Bu durum bana GitHub Actions runner’ımda yaşadığım _work/_temp dizini doluluğunu hatırlattı; orada da geçici dosyalar diskimi şişirmişti.
Semptomlar ve İlk Müdahale
Disk doluluğunun ilk semptomu tabii ki monitörden gelen uyarıydı. Daha sonra SSH ile bağlanmaya çalıştığımda gecikmeler ve hatta bağlantı reddi yaşadım. Sistemin genel performansı düşmüş, web sitelerim yavaşlamış veya hiç açılmaz hale gelmişti.
İlk yaptığım şey, df -h ile genel disk durumunu kontrol etmek oldu. Ardından du -sh /* ile büyük dizinleri tespit etmeye çalıştım. Kısa sürede /var/lib/docker/containers dizininin anormal derecede büyük olduğunu gördüm. Bu dizinin içine girdiğimde, her bir konteyner ID’sinin altında bulunan *-json.log dosyalarının gigabaytlarca yer kapladığını fark ettim. Örneğin, bir Next.js uygulamamın log dosyası tek başına 15 GB’a ulaşmıştı!
Acil durum için, en büyük log dosyalarını cat /dev/null > /var/lib/docker/containers/<container-id>/<container-id>-json.log komutuyla boşalttım. Bu, dosyaları silmek yerine içeriklerini sıfırlayarak diski boşaltır ve çalışan konteynerlerin dosya handle’larını kaybetmesini engeller. Bu işlemden sonra sistem biraz rahatladı ve normal çalışmasına döndü. Ama biliyordum ki bu sadece bir “yama”ydı ve kalıcı bir çözüm bulmam gerekiyordu.
Kalıcı Çözüm: Docker Log Rotation Stratejileri
Bu tür disk yangınlarını önlemenin en etkili yolu, Docker’ın kendi log rotation mekanizmasını kullanmaktır. Docker, json-file driver’ı için log-opts adı verilen seçeneklerle log dosyalarının boyutunu ve sayısını sınırlamanıza olanak tanır.
daemon.json ile Global Ayarlar
Eğer tüm konteynerleriniz için aynı log rotation kurallarını uygulamak istiyorsanız, Docker daemon konfigürasyonunu daemon.json dosyası üzerinden güncelleyebilirsiniz. Bu dosya genellikle /etc/docker/daemon.json konumunda bulunur.
Burada log-driver olarak json-file’ı belirtip, log-opts altında max-size ve max-file değerlerini ayarlayabiliriz. max-size, bir log dosyasının ulaşabileceği maksimum boyutu (örneğin “10m” 10 megabayt), max-file ise tutulacak maksimum log dosyası sayısını belirtir.
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}Bu konfigürasyon, her bir log dosyasının 10 MB’ı geçmesini engelleyecek ve en fazla 3 tane log dosyası tutulmasını sağlayacaktır. Eski log dosyaları, yenisi oluşturulduğunda otomatik olarak silinecektir. Bu değişiklikleri uyguladıktan sonra Docker servisini yeniden başlatmanız gerekir: sudo systemctl restart docker.
Bu yaklaşımın trade-off’u, tüm konteynerleri etkilemesi ve Docker daemon’ı yeniden başlatmayı gerektirmesidir. Eğer üretim ortamında bu işlemi yapıyorsanız, servis kesintisi yaşanmaması için dikkatli olmalısınız. Ben kendi VPS’imde bunu gece saatlerinde, trafiğin en az olduğu zamanda yapmayı tercih ediyorum.
docker-compose.yml ile Konteyner Bazında Ayarlar
Eğer her konteyner için farklı log rotation kuralları uygulamak istiyorsanız veya daemon.json’a global bir değişiklik yapmak istemiyorsanız, docker-compose.yml dosyanızda servis bazında logging ayarlarını kullanabilirsiniz. Bu, bana daha esnek bir kontrol sağlıyor, çünkü bazı servislerim daha az log üretirken, AI pipeline’ımdaki gibi bazıları çok daha fazla log üretebiliyor.
Aşağıdaki örnekte, my-app servisi için log rotation ayarları tanımlanmıştır:
version: '3.8'
services:
my-app:
image: my-image:latest
ports:
- "80:80"
logging:
driver: "json-file"
options:
max-size: "5m"
max-file: "5"
another-app:
image: another-image:latest
ports:
- "81:81"
logging:
driver: "json-file"
options:
max-size: "20m"
max-file: "2"Bu örnekte, my-app için her log dosyası maksimum 5 MB olacak ve en fazla 5 dosya tutulacakken, another-app için bu limitler 20 MB ve 2 dosya olarak belirlenmiştir. Bu yöntemde, ilgili servisi docker-compose up -d ile yeniden oluşturduğunuzda ayarlar devreye girecektir. Bu, global Docker daemon restart’ına kıyasla daha kontrollü bir yaklaşımdır.
Log Rotation Sonrası Bakım ve İzleme
Log rotation ayarlarını yaptıktan sonra iş bitmiyor. Mevcut log dosyaları, bu ayarlardan etkilenmeyecektir. Yani, yukarıdaki ayarları yapsanız bile, zaten var olan devasa log dosyaları küçülmeyecektir. Bu yüzden, ilk kurulumdan sonra eski, büyük log dosyalarını manuel olarak silmeniz veya boşaltmanız gerekebilir.
Ayarların doğru bir şekilde uygulandığını doğrulamak için docker inspect <container-id> komutunu kullanabilirsiniz. Çıktıda LogOpts bölümünü kontrol ederek max-size ve max-file değerlerinin doğru ayarlandığını görebilirsiniz.
Benim kendi pipeline’ımda, df -h çıktısını düzenli olarak kontrol eden basit bir shell script’im var. Bu script, disk kullanımının belirli bir eşiği (örneğin %80) aşması durumunda bana bir uyarı maili gönderiyor. Böylece olası bir disk doluluğu sorununu erkenden tespit edebiliyorum. Bu, preflight resource guard pattern’imin bir parçası. Ayrıca, docker ps -s komutuyla konteynerlerin boyutlarını da takip etmek faydalı olabilir.
max-size ve max-file değerlerini belirlerken dikkatli olmak gerekiyor. Çok küçük değerler, logların çok sık dönmesine neden olabilir ve disk I/O’sunu artırabilir. Çok düşük max-file değerleri ise, bir problem anında geriye dönük inceleyebileceğiniz log miktarını sınırlayabilir. Bu, disk alanı tasarrufu ile debug edilebilirlik arasında bir trade-off’tur. Benim için 10MB ve 3-5 dosya çoğu zaman yeterli oluyor.
Alternatif Log Driverları ve Ne Zaman İhtiyaç Duyulur?
json-file driver’ı, çoğu küçük ve orta ölçekli self-hosted proje için yeterli olsa da, bazen daha gelişmiş çözümlere ihtiyaç duyulabilir. Özellikle büyük ölçekli ve dağıtık sistemlerde, logları merkezi bir sistemde toplamak ve analiz etmek çok daha verimli olabilir.
Docker, syslog, journald, gelf, fluentd, awslogs gibi farklı log driver’larını destekler. Bu driver’lar logları doğrudan bir syslog sunucusuna, systemd journal’a, Graylog’a, Fluentd’ye veya AWS CloudWatch’a gönderebilir. Kendi VPS’imde şu an için json-file ve doğru rotation ayarları bana yetiyor. Ancak geçmişte büyük bir TR e-ticaret sitesinde veya bir bankanın iç platformunda çalışırken, logları fluentd ile Elasticsearch’e basıp Kibana üzerinden analiz ettiğimizi hatırlıyorum. Bu tür çözümler, binlerce konteynerin çalıştığı ortamlarda vazgeçilmezdir.
Ancak benim gibi kendi sunucusunda 13+ container yöneten biri için, ek bir log toplama altyapısı kurmak hem ek maliyet hem de yönetim yükü anlamına gelir. Bu yüzden, json-file driver’ının sunduğu log-opts seçenekleri, pragmatik ve yeterli bir çözüm sunuyor.
Sonuç
Docker loglarının sessizce diski doldurması, benim de defalarca karşılaştığım ve tecrübeyle sabit bir problem. Özellikle kendi VPS’imde bu tür “disk yangınları” yaşadığımda, otomatik log rotation’ın ne kadar kritik olduğunu bir kez daha anladım. Doğru max-size ve max-file ayarlarını yapmak, bu tür sorunların önüne geçmenin en basit ve etkili yollarından biri.
Bu sorun sadece disk doluluğuna yol açmakla kalmıyor, aynı zamanda sistemin genel performansını düşürüp, kritik servislerin çalışamaz hale gelmesine de neden olabiliyor. Bu yüzden, Docker konteynerlerinizi kurarken log rotation ayarlarını baştan yapmak, ileride yaşanabilecek birçok baş ağrısını engelleyecektir.
Sizin de benzer bir disk doluluğu maceranız oldu mu? Hangi log rotation stratejilerini kullanıyorsunuz? Yorumlarda duymak isterim. Belki bir sonraki yazıda, bu log dosyalarındaki verileri basit shell script’lerle nasıl daha anlamlı hale getirdiğimi veya AI destekli içerik pipeline’ımın loglarını nasıl izlediğimi anlatırım.