Ubuntu Sunucuda Sistem Loglarını Akıllıca Yönetmek: Logrotate ile Temizlik ve Performans 
Selam sistemciler!
Bugün, genellikle "sonra hallederim" deyip kenara attığımız ama aslında sunucu sağlığı ve performansı için kritik bir konuya değiniyoruz: log dosyaları.
Bir süre sonra `/var/log` dizinine girip de gigabaytları bulan `syslog`, `auth.log` veya kendi uygulama loglarınızı gördüğünüzde içiniz cız etti mi? O devasa dosyalar sadece disk alanınızı tüketmekle kalmaz, bir log dosyasını açıp incelemeye çalıştığınızda sisteminizi de yavaşlatabilir. Neyse ki Linux dünyasında bu işi bizim için otomatik ve zarif bir şekilde halleden, ismi kadar işlevsel bir araç var: Logrotate. Bugün terminalin tozunu alıp, logrotate'ı nasıl özelleştireceğimizi öğreniyoruz.
Logrotate Nedir ve Neden Önemli?
Logrotate, adından da anlaşılacağı gibi, log dosyalarını döndüren (rotate), sıkıştıran ve gerektiğinde eski logları silen bir sistem hizmetidir. Temel amacı:
Logrotate Nasıl Çalışır? Temel Kavramlar
Logrotate'ın yapılandırma dosyaları `/etc/logrotate.d/` dizinindedir. Ana yapılandırma `/etc/logrotate.conf` dosyasıdır ve `d` dizinindeki tüm dosyaları içe aktarır. Her bir yapılandırma dosyası, hangi log dosyasına ne yapılacağını tanımlar.
İşte sık kullanılan direktifler:
Pratik Örnek: Özel Bir Uygulama Logunu Yönetmek
Diyelim ki `/var/log/myapp/application.log` yolunda bir Node.js veya Python uygulamanızın log dosyası var. Bu dosyayı günlük olarak döndürmek, 30 günlük geçmişi saklamak ve eski logları sıkıştırmak istiyoruz.
İlk adım, `/etc/logrotate.d/` dizininde yeni bir yapılandırma dosyası oluşturmak:
Ardından, aşağıdaki gibi bir konfigürasyon yapıştıralım:
Önemli Not: `myapp-user` ve `myapp-group` yerine, log dosyasını oluşturan uygulamanızın çalıştığı kullanıcı ve grubu yazmalısınız. `create` direktifi olmazsa, döndürme sonrası oluşan yeni log dosyasının sahipliği `root` olur ve uygulamanız ona yazamayabilir.
Konfigürasyonunuzu Test Etmek (ÇOK ÖNEMLİ!)
Kuralları yazdıktan sonra hemen canlı sisteme bırakmayın! Önce test edin. Logrotate'ın `-d` (debug) bayrağı kurallarınızı çalıştırmadan ne yapacağını gösterir:
Eğer her şey yolunda görünüyorsa ve bir kerelik döndürme işlemi yapmak isterseniz, `-f` (force) bayrağını kullanabilirsiniz:
`-v` bize neler yaptığını detaylıca anlatır.
Sistem Geneli Logrotate Ayarlarını Anlamak
Ana yapılandırma dosyasına (`/etc/logrotate.conf`) bir göz atmanızda fayda var. Buradaki ayarlar, özel bir kural tanımlamadığınız tüm loglar için geçerli olan varsayılanlardır.
Genelde `weekly`, `rotate 4`, `create` ve `compress` gibi temel ayarları burada görürsünüz.
Logrotate Cron'da Ne Zaman Çalışır?
Logrotate bir servis değil, bir cron işidir. Günlük cron görevleri kontrol edilir:
Burada `logrotate` isimli bir dosya göreceksiniz. Bu, sistemin her gün (genelde sabah 06:25 gibi bir saatte) logrotate'ı çalıştırmasını sağlar. Eğer `size` direktifi kullandıysanız, log dosyası o boyuta anında ulaşsa bile, bir sonraki günlük cron çalışana kadar döndürülmez. Bu nedenle çok kritik ve hızlı büyüyen loglar için `size` ile `daily`yi birlikte kullanmak iyi bir stratejidir.
Dikkat Edilmesi Gereken Noktalar (Püf Noktaları)
Log yönetimi, proaktif sistem yönetiminin sessiz kahramanlarından biridir. Küçük bir zaman yatırımıyla, gelecekteki disk krizi, performans düşüşü veya "o hatayı hangi logda arayacaktım?" karmaşasından kurtulabilirsiniz.
Peki ya siz? Sunucularınızda logrotate dışında log yönetimi için hangi araçları veya yöntemleri kullanıyorsunuz? (Örn: Centralized logging with ELK/Loki, log shippers). Yorumlarda deneyimlerinizi paylaşın, tartışalım!
Selam sistemciler!
Bugün, genellikle "sonra hallederim" deyip kenara attığımız ama aslında sunucu sağlığı ve performansı için kritik bir konuya değiniyoruz: log dosyaları.Bir süre sonra `/var/log` dizinine girip de gigabaytları bulan `syslog`, `auth.log` veya kendi uygulama loglarınızı gördüğünüzde içiniz cız etti mi? O devasa dosyalar sadece disk alanınızı tüketmekle kalmaz, bir log dosyasını açıp incelemeye çalıştığınızda sisteminizi de yavaşlatabilir. Neyse ki Linux dünyasında bu işi bizim için otomatik ve zarif bir şekilde halleden, ismi kadar işlevsel bir araç var: Logrotate. Bugün terminalin tozunu alıp, logrotate'ı nasıl özelleştireceğimizi öğreniyoruz.
Logrotate Nedir ve Neden Önemli?
Logrotate, adından da anlaşılacağı gibi, log dosyalarını döndüren (rotate), sıkıştıran ve gerektiğinde eski logları silen bir sistem hizmetidir. Temel amacı:
- Disk alanını verimli kullanmak.
- Çok büyük tek bir log dosyası yerine, tarihli ve boyutlu parçalara ayırarok loglara erişimi ve analizi kolaylaştırmak.
- Belirli bir süreden eski logları otomatik temizleyerek düzeni sağlamak.
Logrotate Nasıl Çalışır? Temel Kavramlar
Logrotate'ın yapılandırma dosyaları `/etc/logrotate.d/` dizinindedir. Ana yapılandırma `/etc/logrotate.conf` dosyasıdır ve `d` dizinindeki tüm dosyaları içe aktarır. Her bir yapılandırma dosyası, hangi log dosyasına ne yapılacağını tanımlar.
İşte sık kullanılan direktifler:
- daily/weekly/monthly: Log döndürme sıklığı.
- rotate X: Kaç adet eski log dosyası (rotate edilmiş) saklanacak. `rotate 4` demek, en güncel + 4 eski dosya tutulur.
- compress: Eski log dosyalarını gzip ile sıkıştırır (`.gz` uzantılı olur).
- delaycompress: En son döndürülen logu bir sonraki döndürme döngüsüne kadar sıkıştırmayı geciktirir. Hata ayıklama için faydalıdır.
- missingok: Log dosyası yoksa hata verme, sessizce devam et.
- notifempty: Log dosyası boşsa döndürme işlemi yapma.
- create 644 root adm: Döndürme sonrası yeni boş log dosyasını belirtilen izinler (644) ve sahiplikle (kullanıcı: root, grup: adm) oluşturur.
- postrotate/endscript: Döndürme işleminden hemen sonra çalıştırılacak komutları (örneğin, servisi yeniden başlatmak) bu bloklar arasına yazarsınız.
- size 100M: Log dosyası belirtilen boyuta (örn. 100 MegaByte) ulaştığında, sıklık (daily/weekly) beklemeden döndürür.
Pratik Örnek: Özel Bir Uygulama Logunu Yönetmek
Diyelim ki `/var/log/myapp/application.log` yolunda bir Node.js veya Python uygulamanızın log dosyası var. Bu dosyayı günlük olarak döndürmek, 30 günlük geçmişi saklamak ve eski logları sıkıştırmak istiyoruz.
İlk adım, `/etc/logrotate.d/` dizininde yeni bir yapılandırma dosyası oluşturmak:
Bash:
sudo nano /etc/logrotate.d/myappArdından, aşağıdaki gibi bir konfigürasyon yapıştıralım:
NGINX:
/var/log/myapp/application.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
create 644 myapp-user myapp-group
postrotate
# Uygulamanız log dosyasını açık tutuyorsa, sinyal göndermeniz gerekebilir.
# Örneğin, systemd servisi için:
# systemctl reload myapp.service > /dev/null 2>&1 || true
# Veya basitçe log dosyasını yeniden oluşturmak için:
# touch /var/log/myapp/application.log
endscript
}Önemli Not: `myapp-user` ve `myapp-group` yerine, log dosyasını oluşturan uygulamanızın çalıştığı kullanıcı ve grubu yazmalısınız. `create` direktifi olmazsa, döndürme sonrası oluşan yeni log dosyasının sahipliği `root` olur ve uygulamanız ona yazamayabilir.
Konfigürasyonunuzu Test Etmek (ÇOK ÖNEMLİ!)
Kuralları yazdıktan sonra hemen canlı sisteme bırakmayın! Önce test edin. Logrotate'ın `-d` (debug) bayrağı kurallarınızı çalıştırmadan ne yapacağını gösterir:
Bash:
sudo logrotate -d /etc/logrotate.d/myappEğer her şey yolunda görünüyorsa ve bir kerelik döndürme işlemi yapmak isterseniz, `-f` (force) bayrağını kullanabilirsiniz:
Bash:
sudo logrotate -vf /etc/logrotate.d/myappSistem Geneli Logrotate Ayarlarını Anlamak
Ana yapılandırma dosyasına (`/etc/logrotate.conf`) bir göz atmanızda fayda var. Buradaki ayarlar, özel bir kural tanımlamadığınız tüm loglar için geçerli olan varsayılanlardır.
Bash:
cat /etc/logrotate.confLogrotate Cron'da Ne Zaman Çalışır?
Logrotate bir servis değil, bir cron işidir. Günlük cron görevleri kontrol edilir:
Bash:
ls /etc/cron.daily/Dikkat Edilmesi Gereken Noktalar (Püf Noktaları)
- Postrotate Senaryosu: Bazı uygulamalar (ör. Nginx, Apache, MySQL) log dosyasını bir işlem kimliği (PID) ile açık tutar. Sadece dosyayı taşırsanız (`mv`), uygulama eski dosya tanımlayıcısına yazmaya devam eder. Bu yüzden `postrotate` içinde uygulamaya bir sinyal (`reload`, `reopen`) göndererek yeni log dosyasına yazmaya başlamasını söylemek şarttır. Örneğin Nginx için: `invoke-rc.d nginx rotate-logs > /dev/null 2>&1`
- Disk Doluluğu: `rotate` değerini makul tutun. 365 günlük log sıkıştırılmış olsa bile ciddi yer kaplayabilir.
- Sıkıştırma Maliyeti: `compress` CPU kullanımına neden olur. Çok yüksek trafikli sistemlerde bu işlemin gece saatlerinde yapılması için `su` direktifi kullanılabilir veya sıkıştırma tamamen kaldırılabilir.
Log yönetimi, proaktif sistem yönetiminin sessiz kahramanlarından biridir. Küçük bir zaman yatırımıyla, gelecekteki disk krizi, performans düşüşü veya "o hatayı hangi logda arayacaktım?" karmaşasından kurtulabilirsiniz.
Peki ya siz? Sunucularınızda logrotate dışında log yönetimi için hangi araçları veya yöntemleri kullanıyorsunuz? (Örn: Centralized logging with ELK/Loki, log shippers). Yorumlarda deneyimlerinizi paylaşın, tartışalım!