Docker üzerinde çalışan servislerde log yönetimi çoğu zaman ilk kurulum aşamasında göz ardı edilen fakat sistem büyüdükçe kritik hale gelen konulardan biridir.

Özellikle Nginx gibi reverse proxy, load balancer veya web server olarak kullanılan servisler yoğun trafik altında sürekli log üretir.

Bu loglar doğru şekilde yönetilmezse zaman içinde disk alanını tüketebilir, sistem performansını olumsuz etkileyebilir ve servislerin beklenmedik şekilde durmasına neden olabilir.

Geleneksel sunucu mimarisinde Nginx logları genellikle /var/log/nginx/ dizini altında tutulur ve sistem üzerindeki logrotate servisiyle düzenli olarak döndürülür.

Ancak Docker mimarisinde durum biraz farklıdır. Çünkü konteyner içindeki dosya sistemi izole çalışır ve konteyner silindiğinde içeride tutulan log dosyaları da kaybolabilir.

Bu nedenle Docker üzerinde çalışan Nginx için log rotation planlanırken hem Nginx’in log yazma davranışı hem de Docker’ın logging yapısı birlikte düşünülmelidir.

Bu makalede Docker üzerinde çalışan Nginx servislerinde log rotation işleminin neden gerekli olduğunu, hangi yöntemlerle yapılabileceğini, logrotate kullanımını, Docker logging driver yapılandırmasını ve sık karşılaşılan hataları detaylı şekilde inceleyeceğiz.

Log Rotation Nedir?

Log rotation büyüyen log dosyalarının belirli aralıklarla yeniden adlandırılması, sıkıştırılması, arşivlenmesi ve eski kayıtların temizlenmesi işlemidir.

Örneğin Nginx’in access.log dosyası sürekli büyüyorsa log rotation işlemi sonrasında mevcut dosya şu şekilde arşivlenebilir:

access.log
access.log.1
access.log.2.gz
access.log.3.gz

Bu işlem sayesinde aktif log dosyası sıfırlanır veya yeniden oluşturulur.

Eski loglar ise belirlenen süre boyunca saklanır. Böylece hem disk alanı kontrol altında tutulur hem de geçmiş loglara ihtiyaç duyulduğunda erişim sağlanabilir.

Log rotation yalnızca disk alanı yönetimi için değil operasyonel takip açısından da önemlidir. Çok büyük boyutlara ulaşmış tek bir log dosyasını analiz etmek zor olabilir. Günlük veya haftalık bölünmüş log dosyaları, hata ayıklama ve güvenlik incelemelerinde çok daha kullanışlıdır.

Docker Ortamında Log Yönetimi Neden Daha Dikkat İster?

Docker konteynerleri klasik sunuculardan farklı bir çalışma mantığına sahiptir. Bir konteyner geçici olabilir, yeniden oluşturulabilir veya tamamen silinebilir. Bu nedenle konteyner içinde tutulan veriler kalıcı kabul edilmemelidir.

Nginx loglarını doğrudan konteyner içindeki /var/log/nginx/ dizinine yazdırırsanız bu loglar sadece konteyner yaşam döngüsü boyunca var olur. Konteyner silindiğinde loglar da kaybolabilir. Ayrıca host işletim sistemi bu dosyalara doğrudan erişemez.

Bu noktada iki temel yaklaşım ortaya çıkar:

• Birinci yaklaşımda Nginx logları dosya olarak tutulur ve bu log dizini host sistemine volume olarak bağlanır. Ardından host üzerinde logrotate ile yönetilir.

• İkinci yaklaşımda ise Nginx logları dosyaya değil, stdout ve stderr üzerine yazdırılır. Bu durumda log yönetimi Docker Engine tarafından yapılır.

Her iki yöntem de doğru senaryoda kullanılabilir. Önemli olan sistemin ihtiyaçlarına göre doğru yöntemi seçmek ve logların kontrolsüz büyümesini engellemektir.

Docker Üzerinde Nginx Loglama Yöntemleri

Docker üzerinde çalışan Nginx servislerinde log yönetimi için genellikle iki temel yöntem tercih edilir:

1. Dosya bazlı loglama ve host üzerinde logrotate kullanımı
2. stdout / stderr yönlendirmesi ve Docker logging driver kullanımı

Bu iki yöntemi detaylı şekilde inceleyelim.

Yöntem 1: Dosya Bazlı Nginx Logları ve Logrotate Kullanımı

Bu yöntemde Nginx klasik sunucu yapısında olduğu gibi loglarını dosya sistemine yazar.

Nginx yapılandırmasında genellikle şu satırlar bulunur;

access_log /var/log/nginx/access.log;
error_log  /var/log/nginx/error.log;

Burada access.log Nginx üzerinden geçen HTTP isteklerini kaydeder. error.log ise Nginx hatalarını upstream bağlantı problemlerini, timeout durumlarını ve servis seviyesindeki sorunları içerir.

Docker ortamında bu dosyaların host tarafından yönetilebilmesi için /var/log/nginx dizininin host tarafına mount edilmesi gerekir.

Docker Compose ile Nginx Loglarını Host’a Taşımak

Aşağıdaki örnekte Nginx’in log dizini host üzerindeki ./logs klasörüne bağlanmıştır;

services:
  nginx:
    image: nginx:stable
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./logs:/var/log/nginx
      - ./conf.d:/etc/nginx/conf.d

Bu yapılandırmadan sonra konteyner içindeki;

/var/log/nginx

dizini host üzerindeki;

./logs

klasörüyle eşleşir.

Yani Nginx konteyner içinde /var/log/nginx/access.log dosyasına yazdığında bu log host üzerindeki ./logs/access.log dosyasında da görülebilir.

Bu yaklaşımın en büyük avantajı, logların konteynerden bağımsız şekilde host üzerinde kalıcı olarak tutulmasıdır. Konteyner silinse veya yeniden oluşturulsa bile log dosyaları host üzerinde korunur.

Host Üzerinde Logrotate Yapılandırması

Log dosyaları host üzerinde erişilebilir hale geldikten sonra logrotate ile yönetilebilir.

Öncelikle Nginx Docker logları için özel bir logrotate dosyası oluşturulur:

sudo nano /etc/logrotate.d/nginx-docker

Ardından aşağıdaki örnek yapılandırma eklenebilir:

/home/user/nginx/logs/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        docker exec nginx-proxy nginx -s reopen
    endscript
}

Bu yapılandırmada /home/user/nginx/logs/ dizini altında bulunan .log uzantılı dosyalar günlük olarak rotate edilir.

Buradaki değerler ihtiyaca göre değiştirilebilir.

Örneğin yoğun trafik alan bir production ortamında günlük rotation yeterli olmayabilir.

Log dosyaları çok hızlı büyüyorsa size parametresiyle boyut bazlı rotation da yapılabilir.

Örneğin:

/home/user/nginx/logs/*.log {
    size 100M
    missingok
    rotate 10
    compress
    delaycompress
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        docker exec nginx-proxy nginx -s reopen
    endscript
}

Bu örnekte log dosyası 100 MB boyutuna ulaştığında rotation işlemi uygulanır.

Logrotate Parametreleri Ne Anlama Gelir?

Logrotate yapılandırmasında kullanılan parametrelerin ne işe yaradığını bilmek production ortamlarında daha sağlıklı ayar yapmayı sağlar.

daily

Log dosyalarının her gün rotate edilmesini sağlar.

size 100M

Log dosyası belirlenen boyuta ulaştığında rotation yapılmasını sağlar. Trafiği değişken olan sistemlerde oldukça kullanışlıdır.

missingok

Log dosyası bulunamazsa hata vermeden işlemin devam etmesini sağlar.

rotate 14

Eski log dosyalarından 14 adet saklanır. Günlük rotation kullanılıyorsa yaklaşık 14 günlük log geçmişi tutulur.

compress

Eski log dosyalarını gzip formatında sıkıştırır. Bu sayede disk kullanımı ciddi şekilde azalır.

delaycompress

En son rotate edilen dosyanın hemen sıkıştırılmasını engeller.

Bir sonraki rotation işleminde sıkıştırma yapılır. Bazı servisler kısa süreli olarak eski dosyaya yazmaya devam edebileceği için güvenli bir seçenektir.

notifempty

Boş log dosyaları rotate edilmez.

create 0640 root adm

Rotation sonrasında yeni oluşturulacak log dosyasının izinlerini, kullanıcı ve grup bilgisini belirler.

sharedscripts

Birden fazla log dosyası eşleşse bile postrotate bloğundaki komutların yalnızca bir kez çalışmasını sağlar.

Nginx İçin nginx -s reopen Neden Gereklidir?

Logrotate yapılandırmalarında en kritik noktalardan biri postrotate bölümüdür.

Logrotate bir log dosyasını rotate ettiğinde mevcut dosyanın adını değiştirir. Örneğin:

access.log

dosyası şu hale gelebilir:

access.log.1

Ardından yeni bir access.log dosyası oluşturulur. Ancak burada dikkat edilmesi gereken önemli bir detay vardır.

Nginx log dosyasına yalnızca dosya adı üzerinden yazmaz. Çalışırken dosyayı açar ve açık dosya tanıtıcısı üzerinden yazmaya devam eder. Bu nedenle logrotate eski dosyayı yeniden adlandırsa bile Nginx hâlâ eski dosyaya yazmaya devam edebilir.

Bu durumu engellemek için Nginx’e log dosyalarını yeniden açması söylenmelidir:

docker exec nginx-proxy nginx -s reopen

Bu komut konteyner içindeki Nginx master process’e log dosyalarını yeniden açmasını bildirir. Böylece Nginx yeni oluşturulan access.log ve error.log dosyalarına yazmaya devam eder.

Bu adım atlanırsa logrotate çalışıyor gibi görünse bile aktif log yazımı beklenen dosyaya yapılmayabilir.

Alternatif: USR1 Parametresi ile;

Nginx log dosyalarını yeniden açmak için alternatif olarak USR1 sinyali de kullanılabilir:

kill -USR1 $(cat /var/run/nginx.pid)

Docker konteyneri içinde bu komut şu şekilde çalıştırılabilir:

docker exec nginx-proxy sh -c 'kill -USR1 $(cat /var/run/nginx.pid)'

Ancak pratikte daha okunabilir ve yönetilebilir yöntem genellikle şudur:

docker exec nginx-proxy nginx -s reopen

Bu nedenle logrotate yapılandırmalarında çoğunlukla nginx -s reopen tercih edilir.

Logrotate Yapılandırmasını Test Etmek

Yapılandırmayı production ortamına bırakmadan önce mutlaka test etmek gerekir.

Öncelikle logrotate konfigürasyonu debug modda kontrol edilebilir:

sudo logrotate -d /etc/logrotate.d/nginx-docker

Bu komut gerçek rotation işlemi yapmaz. Sadece logrotate’ın ne yapacağını gösterir.

Rotation işlemini manuel olarak zorlamak için şu komut kullanılabilir:

sudo logrotate -f /etc/logrotate.d/nginx-docker

Ardından log dizini kontrol edilir:

ls -lh /home/kullanici/nginx/logs/

Beklenen çıktı şu yapıya benzer olabilir:

access.log
access.log.1
error.log
error.log.1

Sıkıştırma aktifse daha eski dosyalar şu şekilde görünebilir:

access.log.2.gz
error.log.2.gz

Son olarak Nginx’in yeni log dosyasına yazıp yazmadığı kontrol edilmelidir:

tail -f /home/kullanici/nginx/logs/access.log

Yeni istekler geldiğinde aktif access.log dosyasına yazılıyorsa yapılandırma doğru çalışıyor demektir.

Yöntem 2: Nginx Loglarını stdout ve stderr Üzerine Yazdırmak

Docker mimarisine daha uygun olan yaklaşım uygulama loglarının dosya yerine stdout ve stderr üzerinden yayınlanmasıdır.

Bu yöntemde Nginx logları şu şekilde yapılandırılır:

access_log /dev/stdout;
error_log  /dev/stderr;

Burada access_log kayıtları standart çıktıya, error_log kayıtları ise standart hata çıktısına yönlendirilir.

Bu yapı kullanıldığında loglar Docker Engine tarafından yakalanır.

Kullanıcı logları şu komutla görüntüleyebilir:

docker logs nginx-proxy

Canlı takip için:

docker logs -f nginx-proxy

Bu yöntem özellikle container tabanlı sistemlerde daha sade bir yönetim sağlar. Log dosyasını konteyner içinde veya host üzerinde ayrıca takip etmek gerekmez. Docker, container çıktısını kendi logging driver yapısıyla işler.

Docker Compose ile Logging Driver Ayarı

Docker’ın varsayılan logging driver’ı çoğu kurulumda json-file olarak gelir. Eğer bu driver için herhangi bir sınır koymazsanız container logları zamanla çok büyüyebilir.

Bu nedenle Docker Compose dosyasında log rotation ayarı yapılmalıdır;

services:
  nginx:
    image: nginx:stable
    container_name: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

Bu yapılandırmada her bir log dosyası en fazla 10 MB boyutuna ulaşabilir. Docker en fazla 5 adet log dosyası saklar. Böylece ilgili container için toplam log kullanımı yaklaşık 50 MB ile sınırlandırılmış olur.

Bu değerler sistemin trafiğine göre artırılıp azaltılabilir. Örneğin daha yoğun bir production ortamında şu şekilde bir yapılandırma tercih edilebilir:

logging:
  driver: "json-file"
  options:
    max-size: "100m"
    max-file: "10"

Bu yapılandırmada container başına yaklaşık 1 GB log saklama alanı ayrılmış olur.

Docker Log Dosyaları Nerede Tutulur?

Docker json-file driver kullanıldığında loglar host üzerinde genellikle şu dizin altında tutulur:

/var/lib/docker/containers/<container-id>/<container-id>-json.log

Container ID bilgisini öğrenmek için:

docker ps

Belirli bir container’ın log dosyasını bulmak için:

docker inspect nginx-proxy --format='{{.LogPath}}'

Bu komut size ilgili container’ın aktif log dosyasının tam yolunu verir.

Ancak bu dosyalar doğrudan elle düzenlenmemelidir. Docker tarafından yönetilen log dosyalarına müdahale etmek, beklenmeyen sonuçlara yol açabilir. Logları okumak için tercih edilmesi gereken yöntem şudur:

docker logs nginx-proxy

Docker Logging Driver Ayarlarını Kontrol Etmek

Bir container’ın hangi logging driver ile çalıştığını görmek için:

docker inspect nginx-proxy --format='{{.HostConfig.LogConfig.Type}}'

Log driver seçeneklerini görmek için:

docker inspect nginx-proxy --format='{{json .HostConfig.LogConfig.Config}}'

Beklenen çıktı şu şekilde olabilir:

{"max-file":"5","max-size":"10m"}

Bu kontrol özellikle compose dosyası değiştirildikten sonra önemlidir. Çünkü bazı logging ayarları mevcut container üzerinde otomatik olarak güncellenmez. Ayarların uygulanması için container’ın yeniden oluşturulması gerekebilir.

Örneğin:

docker compose down
docker compose up -d

veya:

docker compose up -d --force-recreate

komutlarıyla container yeniden oluşturulabilir.

Dosya Bazlı Loglama mı, Docker Logging Driver mı?

Bu iki yöntem arasında seçim yaparken altyapının ihtiyaçları dikkate alınmalıdır.

Dosya bazlı loglama, klasik Linux yönetim alışkanlıklarına daha yakındır. Log dosyaları host üzerinde belirli bir dizinde tutulur, logrotate ile yönetilir ve gerektiğinde farklı araçlarla işlenebilir. Özellikle mevcut log analiz araçları dosya bazlı çalışıyorsa bu yöntem avantajlı olabilir.

Docker logging driver yöntemi ise container mantığına daha uygundur. Uygulama loglarını standart çıktıya verir, Docker bu logları toplar ve sınırlandırır. Bu yöntem daha sade, taşınabilir ve container odaklıdır.

Genel bir değerlendirme yapmak gerekirse:

Küçük ve orta ölçekli Docker kurulumlarında stdout / stderr yöntemi daha pratik olabilir.

Klasik sunucu yönetimi, özel arşivleme politikaları veya dosya bazlı log analiz süreçleri varsa logrotate yöntemi tercih edilebilir.

Kubernetes, Docker Swarm veya merkezi logging altyapısı kullanılan ortamlarda ise logların standart çıktıya verilmesi çoğu zaman daha doğru yaklaşımdır.

Production Ortamları İçin Önerilen Yaklaşım

Production ortamlarında log yönetimi yalnızca “disk dolmasın” diye yapılmaz. Loglar aynı zamanda sistemin davranışını anlamak, saldırı denemelerini incelemek, performans problemlerini tespit etmek ve hata analizi yapmak için kullanılır.

Bu nedenle production ortamlarında şu noktalara dikkat edilmelidir:

Nginx access log ve error log ayrı değerlendirilmelidir.

Log rotation mutlaka aktif olmalıdır.

Container logları için max-size ve max-file değerleri tanımlanmalıdır.

Disk kullanımı monitoring sistemiyle takip edilmelidir.

Eski logların ne kadar süre saklanacağı kurum politikasına göre belirlenmelidir.

Loglar mümkünse merkezi bir log yönetim sistemine aktarılmalıdır.

Log dosyaları içinde hassas veri tutulmamasına dikkat edilmelidir.

Yoğun trafikli sistemlerde sadece dosya boyutu değil, log yazma yoğunluğu da izlenmelidir.

Merkezi log yönetimi için şu araçlar tercih edilebilir:

Loki
Elasticsearch
OpenSearch
Graylog
Fluent Bit
Filebeat
Logstash
Promtail

Özellikle birden fazla Docker host bulunan yapılarda logları her sunucuda ayrı ayrı incelemek sürdürülebilir değildir. Bu nedenle merkezi logging mimarisi uzun vadede daha sağlıklı bir çözümdür.

Örnek Senaryo: Docker Compose ile Nginx ve Log Driver Kullanımı

Aşağıdaki örnek, Docker üzerinde çalışan Nginx için sade ve kullanışlı bir logging yapılandırması sunar:

services:
  nginx:
    image: nginx:stable
    container_name: nginx-proxy
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./conf.d:/etc/nginx/conf.d:ro
      - ./html:/usr/share/nginx/html:ro
    logging:
      driver: "json-file"
      options:
        max-size: "50m"
        max-file: "5"

Bu yapılandırmada Nginx logları Docker tarafından yönetilir. Her log dosyası 50 MB ile sınırlandırılır ve en fazla 5 dosya saklanır. Böylece ilgili container için log kullanımı yaklaşık 250 MB seviyesinde tutulur.

Bu yöntem, basit ve yönetilebilir bir yapı isteyen birçok Docker ortamı için yeterlidir.

Örnek Senaryo: Dosya Bazlı Loglama ve Logrotate Kullanımı

Bazı sistemlerde logların doğrudan host üzerinde tutulması istenebilir. Bu durumda aşağıdaki gibi bir Compose dosyası kullanılabilir:

services:
  nginx:
    image: nginx:stable
    container_name: nginx-proxy
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./conf.d:/etc/nginx/conf.d:ro
      - ./logs:/var/log/nginx

Ardından host üzerinde logrotate dosyası oluşturulur:

sudo nano /etc/logrotate.d/nginx-docker

İçerik:

/home/kullanici/nginx/logs/*.log {
    daily
    rotate 14
    missingok
    compress
    delaycompress
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        docker exec nginx-proxy nginx -s reopen
    endscript
}

Bu yöntem özellikle log dosyalarını sunucu üzerinde saklamak, arşivlemek veya farklı araçlarla işlemek isteyen yapılar için uygundur.

Logrotate Çalışıyor Ama Log Dosyası Yenilenmiyor

Bu durum genellikle Nginx’in eski dosya tanıtıcısına yazmaya devam etmesinden kaynaklanır. postrotate bölümünde şu komutun olduğundan emin olun:

docker exec nginx-proxy nginx -s reopen

Container adı yanlışsa komut çalışmaz. Bu nedenle container adını kontrol edin:

docker ps

Log Dosyaları Host Üzerinde Görünmüyor

Bu durumda volume mount yapılandırması hatalı olabilir. Docker Compose dosyasında şu satırın bulunduğundan emin olun:

volumes:
  - ./logs:/var/log/nginx

Ayrıca Nginx konfigürasyonunda logların gerçekten /var/log/nginx/ altına yazıldığını kontrol edin.

Docker Logs Çok Fazla Büyüyor

Container logları için max-size ve max-file tanımlanmamış olabilir. Compose dosyasına şu bölüm eklenmelidir:

logging:
  driver: "json-file"
  options:
    max-size: "10m"
    max-file: "5"

Ardından container yeniden oluşturulmalıdır:

docker compose up -d --force-recreate

Disk Alanı Dolmaya Devam Ediyor

Logrotate veya Docker logging driver ayarları doğru çalışmıyor olabilir. Öncelikle büyük dosyalar tespit edilmelidir:

du -sh /var/lib/docker/containers/*

Docker log dosyalarını görmek için:

find /var/lib/docker/containers/ -name "*-json.log" -exec ls -lh {} \;

Dosya bazlı Nginx logları için:

du -sh /home/kullanici/nginx/logs/*

Eğer eski .gz dosyaları çok fazla yer kaplıyorsa rotate değeri düşürülebilir veya daha kısa saklama politikası uygulanabilir.

Logrotate Manuel Çalışıyor Ama Otomatik Çalışmıyor

Bu durumda sistemde cron veya systemd timer yapısı kontrol edilmelidir.

Logrotate çoğu Linux dağıtımında günlük olarak otomatik çalışır. Kontrol için:

systemctl status logrotate.timer

veya:

ls -l /etc/cron.daily/logrotate

Ayrıca logrotate durum dosyası da incelenebilir:

cat /var/lib/logrotate/status

Güvenlik ve Yetki Konuları

Log dosyaları çoğu zaman IP adresleri, URL bilgileri, user-agent kayıtları ve hata detayları içerir. Bu nedenle log dizinlerinin yetkileri dikkatli ayarlanmalıdır.

Host üzerinde log dosyalarının herkes tarafından okunabilir olması önerilmez. Örneğin:

chmod 750 ./logs

ve log dosyaları için:

chmod 640 ./logs/*.log

uygulanabilir.

Ayrıca loglar merkezi sistemlere gönderiliyorsa, hassas verilerin loglara yazılmadığından emin olunmalıdır. Özellikle query string içinde token, session ID veya kişisel veri taşınan uygulamalarda access log formatı dikkatli tasarlanmalıdır.

Log Formatı da Önemlidir

Log rotation kadar log formatı da önemlidir. Varsayılan Nginx access log formatı çoğu zaman yeterli olsa da reverse proxy kullanılan ortamlarda gerçek istemci IP adresini görmek için özel log formatı gerekebilir.

Örneğin:

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

Eğer Nginx bir load balancer veya CDN arkasında çalışıyorsa, gerçek IP bilgisini alabilmek için X-Forwarded-For başlığı önemlidir.

Docker ortamında merkezi log analizi yapılacaksa JSON formatlı log üretmek de tercih edilebilir. Böylece loglar Elasticsearch, OpenSearch veya Loki gibi sistemlerde daha kolay ayrıştırılabilir.

Docker üzerinde çalışan Nginx servislerinde log rotation yapılandırması, sistemin kararlı çalışması için mutlaka planlanması gereken bir konudur. Log dosyaları kontrolsüz şekilde büyüdüğünde disk alanı tükenebilir, servisler hata verebilir ve sistem yönetimi zorlaşabilir.

Bu problemi çözmek için iki temel yöntem kullanılabilir. İlk yöntemde Nginx logları dosya olarak tutulur, host üzerine volume ile taşınır ve logrotate ile yönetilir. Bu yöntemde rotation sonrası Nginx’e nginx -s reopen komutunun gönderilmesi kritik öneme sahiptir.

İkinci yöntemde ise Nginx logları stdout ve stderr üzerine yönlendirilir. Böylece Docker’ın logging driver mekanizması devreye girer. max-size ve max-file ayarlarıyla container loglarının büyümesi sınırlandırılır. Bu yaklaşım Docker mimarisine daha doğal ve yönetilebilir bir çözümdür.

Küçük ve orta ölçekli yapılarda Docker logging driver çoğu zaman yeterlidir. Daha özel arşivleme, dosya bazlı analiz veya legacy entegrasyon gerektiren sistemlerde ise host üzerinde logrotate kullanımı tercih edilebilir.

Sağlıklı bir production ortamı için önemli olan nokta, hangi yöntemin kullanıldığından bağımsız olarak logların mutlaka sınırlandırılması, düzenli olarak rotate edilmesi ve mümkünse merkezi bir log yönetim sistemine aktarılmasıdır. Bu sayede hem disk alanı korunur hem de hata analizi, güvenlik incelemesi ve operasyonel takip çok daha düzenli hale gelir.