Logrotate ve S3cmd ile Logları Ubuntu 16.04 Üzerinde Nesne Depolamaya Arşivleme

Logrotate ve S3cmd ile Logları Ubuntu 16.04 Üzerinde Nesne Depolamaya Arşivleme

Sunucu yönetimi, özellikle de uzun süre çalışan sistemler için, log dosyalarının yönetimi kritik bir öneme sahiptir. Log dosyaları, sistemde olup biten her şeyi kaydederek sorun giderme, güvenlik denetimi ve performans analizi için paha biçilmez veriler sunar. Ancak zamanla bu dosyalar disk alanını tüketebilir ve sistem performansını etkileyebilir. İşte bu noktada log dosyalarını düzenli olarak döndürmek (rotate), sıkıştırmak ve güvenli bir şekilde arşivlemek devreye girer.

Bu rehberde, Ubuntu 16.04 işletim sistemi üzerinde logrotate aracını kullanarak log dosyalarını düzenli olarak döndürmeyi, sıkıştırmayı ve ardından s3cmd komut satırı aracını kullanarak bu logları Amazon S3 gibi nesne depolama hizmetlerine güvenli bir şekilde nasıl arşivleyeceğinizi adım adım açıklayacağız. Bu yöntem, hem disk alanından tasarruf etmenizi hem de log verilerinizi uzun vadeli, maliyet etkin ve erişilebilir bir şekilde saklamanızı sağlayacaktır.

Logrotate Nedir ve Nasıl Yapılandırılır?

Logrotate, Linux sistemlerinde log dosyalarını otomatik olarak yönetmek için tasarlanmış bir yardımcı programdır. Log dosyalarını belirli boyutlara veya zaman aralıklarına göre döndürebilir, sıkıştırabilir, yeni log dosyaları oluşturabilir ve eski log dosyalarını silebilir.

Logrotate Temelleri

Logrotate, sisteminizde genellikle /etc/logrotate.conf ana yapılandırma dosyası ve /etc/logrotate.d/ dizinindeki uygulama özelindeki yapılandırma dosyaları aracılığıyla çalışır. /etc/logrotate.d/ dizinindeki her dosya, belirli bir uygulamanın (örneğin, Nginx, Apache, syslog) loglarını yönetmek için özel kurallar içerir.

Logrotate, varsayılan olarak günlük olarak bir cron işi aracılığıyla çalıştırılır. Bu cron işi genellikle /etc/cron.daily/logrotate içinde tanımlıdır.

Logrotate Yapılandırması Örneği

Örnek olarak, bir web uygulamasının özel erişim loglarını (örneğin /var/log/mywebapp/access.log) yönetmek istediğimizi varsayalım. Öncelikle /etc/logrotate.d/mywebapp adında yeni bir dosya oluşturalım:

sudo nano /etc/logrotate.d/mywebapp

İçine aşağıdaki yapılandırmayı ekleyin:

/var/log/mywebapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    sharedscripts
    postrotate
        /usr/sbin/invoke-rc.d nginx rotate > /dev/null 2>&1 || true
    endscript
}

Bu yapılandırma dosyasındaki yönergeler şunları ifade eder:

/var/log/mywebapp/.log: Bu kuralın uygulanacağı log dosyalarının yolu ve deseni.
* daily: Logları günlük olarak döndür. Diğer seçenekler weekly, monthly, yearly olabilir.
* rotate 7: En fazla 7 eski log dosyasını sakla. Sekizinci döndürmede en eski dosya silinir.
* compress: Döndürülen log dosyalarını sıkıştır (gzip kullanarak).
* delaycompress: Log dosyasının bir sonraki döndürme döngüsüne kadar sıkıştırmayı ertele. Bu, bazı uygulamaların hala açık olan log dosyasına yazmaya devam etmesi durumunda faydalıdır.
* missingok: Log dosyası bulunamazsa hata verme.
* notifempty: Log dosyası boşsa döndürme.
* create 0640 www-data www-data: Yeni bir log dosyası oluştur ve belirtilen izinleri ve sahipliği ata.
* sharedscripts: Birden fazla log dosyası eşleşiyorsa, postrotate komutunu yalnızca bir kez çalıştır.
* postrotate/endscript: Log dosyaları döndürüldükten sonra çalıştırılacak komutları içerir. Bu örnekte, Nginx’e log dosyalarını yeniden açması için sinyal gönderilir. Biz bu bölümü daha sonra S3cmd ile arşivleme için kullanacağız.

Yapılandırmanızı test etmek için aşağıdaki komutu kullanabilirsiniz:

sudo logrotate -d /etc/logrotate.d/mywebapp

Bu komut, logrotate’un ne yapacağını gösterir ancak değişiklikleri uygulamaz. Gerçek bir çalıştırma için:

sudo logrotate -f /etc/logrotate.conf

Not: -f (force) parametresi, logrotate’un normalde döndürme koşulları karşılanmasa bile döndürmeyi zorlamasını sağlar. Üretim ortamında dikkatli kullanılmalıdır.

S3cmd Kurulumu ve AWS S3 ile Entegrasyonu

S3cmd, Amazon S3 ve uyumlu diğer nesne depolama hizmetleriyle komut satırından etkileşim kurmanızı sağlayan ücretsiz, açık kaynaklı bir araçtır. Log dosyalarını S3’e yüklemek için bunu kullanacağız.

S3cmd Kurulumu

Ubuntu 16.04 üzerinde s3cmd kurulumu oldukça basittir:

sudo apt-get update
sudo apt-get install s3cmd

AWS S3 Bucket Oluşturma ve IAM Kullanıcısı Yapılandırma

Loglarınızı depolamak için bir S3 bucket’ına ihtiyacınız olacak. AWS Yönetim Konsolu’na giriş yaparak yeni bir S3 bucket oluşturabilirsiniz. Bucket isminin global olarak benzersiz olması gerektiğini unutmayın (örn: my-server-logs-12345).

Güvenlik açısından, S3’e erişim için tam yetkili bir AWS kök kullanıcısı yerine, sadece gerekli izinlere sahip bir IAM kullanıcısı oluşturmanız şiddetle tavsiye edilir.

1. IAM Kullanıcısı Oluşturma: AWS IAM Konsolu’na gidin, “Kullanıcılar” bölümünden “Yeni kullanıcı ekle” seçeneğini seçin. Kullanıcıya bir isim verin (örn: logrotate-s3-user) ve “Programatik erişim” seçeneğini işaretleyin.
2. İzinleri Ayarlama: Bir sonraki adımda, kullanıcıya S3 bucket’ınıza log dosyaları yüklemesi için gerekli izinleri vermeniz gerekir. “Mevcut ilkeleri doğrudan ekle” seçeneğini seçip aşağıdaki gibi özel bir politika oluşturabilirsiniz:

{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:PutObject",
                    "s3:GetObject",
                    "s3:DeleteObject",
                    "s3:ListBucket"
                ],
                "Resource": [
                    "arn:aws:s3:::your-log-bucket-name",
                    "arn:aws:s3:::your-log-bucket-name/*"
                ]
            }
        ]
    }

your-log-bucket-name yerine kendi bucket isminizi yazmayı unutmayın. Bu politika, kullanıcının belirtilen bucket’a nesne koymasına, almasına, silmesine ve bucket içeriğini listelemesine izin verir.
3. Erişim Anahtarları: Kullanıcı oluşturulduktan sonra size bir “Erişim Anahtarı Kimliği” (Access Key ID) ve bir “Gizli Erişim Anahtarı” (Secret Access Key) verilecektir. Bu anahtarları güvenli bir yere kaydedin, çünkü bir daha gösterilmeyeceklerdir.

S3cmd Yapılandırması

S3cmd’yi ilk kez çalıştırdığınızda, yapılandırma sihirbazı otomatik olarak başlar:

s3cmd --configure

Sihirbaz sizden aşağıdaki bilgileri isteyecektir:

* Access Key: IAM kullanıcınızın Erişim Anahtarı Kimliği.
* Secret Key: IAM kullanıcınızın Gizli Erişim Anahtarı.
* Default Region: S3 bucket’ınızın bulunduğu AWS bölgesi (örn: eu-central-1 veya us-east-1).
* Encryption password: İsteğe bağlı, logları yerel olarak şifrelemek isterseniz kullanabilirsiniz. Boş bırakılabilir.
* Path to GPG program: İsteğe bağlı, boş bırakılabilir.
* Use HTTPS protocol: Yes olarak bırakın.
* HTTP Proxy server name: Proxy kullanıyorsanız girin, aksi takdirde boş bırakın.

Yapılandırma tamamlandığında, bilgiler /home/kullanıcı_adınız/.s3cfg dosyasına kaydedilir. Bu dosyanın izinlerini 600 olarak ayarlamak önemlidir:

chmod 660 ~/.s3cfg

Bu, diğer kullanıcıların hassas anahtarlarınızı görmesini engeller.

S3cmd Test Etme

S3cmd’nin S3 bucket’ınıza erişebildiğini doğrulamak için aşağıdaki komutu kullanın:

s3cmd ls s3://your-log-bucket-name/

Eğer bucket içeriği listelenirse veya boş bir çıktı alırsanız, yapılandırma başarılı demektir. Bir dosya yükleyerek de test edebilirsiniz:

echo "Test dosyası" > test.txt
s3cmd put test.txt s3://your-log-bucket-name/test.txt
s3cmd ls s3://your-log-bucket-name/

Ardından test dosyasını silebilirsiniz:

s3cmd del s3://your-log-bucket-name/test.txt
rm test.txt

Logrotate ve S3cmd’yi Birleştirme: Logları S3’e Arşivleme

Şimdi sıra geldi logrotate’un logları döndürdükten sonra S3cmd kullanarak bu logları S3’e yüklemesine. Bunun için logrotate yapılandırma dosyamızdaki postrotate bölümünü değiştireceğiz.

Logrotate Yapılandırmasını Güncelleme

/etc/logrotate.d/mywebapp dosyasını tekrar açın:

sudo nano /etc/logrotate.d/mywebapp

postrotate bölümünü aşağıdaki gibi güncelleyin:

/var/log/mywebapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    sharedscripts
    postrotate
        # Döndürülen ve sıkıştırılan log dosyasını bul
        # Logrotate'un çalıştırdığı kullanıcının (genellikle root) s3cmd'yi bulabilmesi için tam yolu belirtin
        # S3cmd yapılandırma dosyasının yolunu belirtin, aksi takdirde varsayılanı (~/.s3cfg) arar.
        # Root kullanıcısı için /root/.s3cfg veya /etc/.s3cfg gibi bir yer olabilir.
        # Bu örnekte, s3cmd'nin global olarak kurulu olduğunu ve root'un PATH'inde olduğunu varsayıyoruz.
        # Eğer s3cmd yapılandırmasını root kullanıcısı için yapmadıysanız, --config=/path/to/.s3cfg kullanın.
        
        LOG_FILE=$(ls -t /var/log/mywebapp/*.log.gz | head -1) # En son sıkıştırılan log dosyasını bulur
        BUCKET_NAME="your-log-bucket-name"
        S3_PATH="mywebapp/$(date +\%Y/\%m/\%d)/$(basename ${LOG_FILE})" # S3'te yıl/ay/gün/logadı.gz yapısı

        if [ -f "${LOG_FILE}" ]; then
            echo "Uploading ${LOG_FILE} to s3://${BUCKET_NAME}/${S3_PATH}"
            /usr/bin/s3cmd put "${LOG_FILE}" "s3://${BUCKET_NAME}/${S3_PATH}" --config=/root/.s3cfg

            if [ $? -eq 0 ]; then
                echo "Upload successful, deleting local file ${LOG_FILE}"
                rm "${LOG_FILE}"
            else
                echo "Upload failed for ${LOG_FILE}"
            fi
        else
            echo "No compressed log file found to upload."
        fi

        /usr/sbin/invoke-rc.d nginx rotate > /dev/null 2>&1 || true # Uygulamaya sinyal gönderme
    endscript
}

Önemli Notlar:

* S3cmd Yapılandırma Dosyası Konumu: logrotate genellikle root kullanıcısı altında çalışır. Bu nedenle, s3cmd --configure komutunu sudo s3cmd --configure olarak veya root kullanıcısı olarak çalıştırarak /root/.s3cfg dosyasına yapılandırmayı kaydetmeniz gerekecektir. Aksi takdirde, s3cmd put komutunda --config=/path/to/your/user/.s3cfg parametresini kullanarak doğru yapılandırma dosyasını belirtmelisiniz. Genellikle /root/.s3cfg kullanmak en kolay yoldur.
Log Dosyası Tespiti: LOG_FILE=$(ls -t /var/log/mywebapp/.log.gz | head -1) komutu, /var/log/mywebapp/ dizinindeki en son değiştirilmiş .log.gz dosyasını bulur. Bu, delaycompress kullandığımızda doğru dosyayı bulmak için önemlidir.
* S3 Yolu: S3_PATH değişkeni, S3 bucket’ınız içinde logları düzenli bir şekilde depolamanızı sağlar (örn: mywebapp/2023/10/26/access.log-20231025.gz).
* Hata Kontrolü ve Silme: if [ $? -eq 0 ]; then rm "${LOG_FILE}"; fi satırı, S3’e yükleme başarılı olursa yerel log dosyasını siler. Bu, gereksiz disk kullanımını önler. Yükleme başarısız olursa, dosya yerelde kalır, bu da manuel inceleme veya yeniden deneme için bir fırsat sunar.
* Uygulama Sinyali: postrotate içinde hala uygulamanızın log dosyalarını yeniden açmasını sağlayacak komutları tutmanız önemlidir (örn: invoke-rc.d nginx rotate).

Bu yapılandırma ile, logrotate günlük olarak çalışacak, eski log dosyasını sıkıştıracak, yeni bir boş log dosyası oluşturacak ve sıkıştırılmış eski log dosyasını S3 bucket’ınıza yükleyecektir. Yükleme başarılı olursa, yerel sıkıştırılmış dosya silinecektir.

Gelişmiş Kullanım ve En İyi Uygulamalar

Logları nesne depolamaya arşivlerken dikkate almanız gereken bazı gelişmiş konular ve en iyi uygulamalar şunlardır:

Güvenlik

* IAM Politikaları: Daima en az ayrıcalık (least privilege) prensibini uygulayın. IAM kullanıcınıza sadece logları yüklemek ve yönetmek için gerekli olan minimum S3 izinlerini verin.
* S3 Nesne Şifrelemesi: Hassas log verileri içeriyorsa, S3’e yüklenen nesneleri şifrelemeyi düşünün. Bunu S3 bucket politikaları aracılığıyla sunucu tarafı şifrelemeyi zorlayarak veya s3cmd put komutuna --encrypt parametresini ekleyerek yapabilirsiniz.
* .s3cfg Dosya İzinleri: .s3cfg dosyasının yalnızca root kullanıcısı tarafından okunabilir olduğundan emin olun (chmod 600 /root/.s3cfg).

Maliyet Yönetimi

* S3 Yaşam Döngüsü Kuralları (Lifecycle Rules): AWS S3, belirli bir süre sonra nesneleri daha ucuz depolama sınıflarına (örneğin, S3 Standard-IA, S3 Glacier) otomatik olarak taşımak veya tamamen silmek için yaşam döngüsü kuralları tanımlamanıza olanak tanır. Bu, uzun vadede depolama maliyetlerinizi önemli ölçüde azaltabilir.
* S3 Depolama Sınıfları: Log verilerinizin erişim sıklığına göre uygun depolama sınıfını seçin. Nadiren erişilen loglar için S3 Standard-IA veya S3 Glacier daha uygun maliyetli olabilir.

İzleme ve Hata Ayıklama

* Logrotate Durum Dosyası: Logrotate’un en son ne zaman çalıştığını ve hangi dosyaları döndürdüğünü /var/lib/logrotate/status dosyasından kontrol edebilirsiniz.
* Cron Job Çıktısı: logrotate bir cron işi olarak çalıştığı için, postrotate betiğinizdeki echo komutlarının çıktısı cron’un varsayılan e-posta adresine gönderilebilir (eğer yapılandırılmışsa) veya /var/log/syslog gibi sistem loglarında görünebilir. Hata ayıklama için bu çıktıları kontrol etmek önemlidir.
* Manuel Çalıştırma: Hata ayıklama yaparken, sudo logrotate -f /etc/logrotate.conf komutunu çalıştırarak logrotate’u ve dolayısıyla postrotate betiğini manuel olarak tetikleyebilirsiniz.

Alternatifler ve Diğer Nesne Depolama Hizmetleri

* AWS CLI: S3cmd’ye bir alternatif olarak AWS’nin resmi komut satırı arayüzü (AWS CLI) kullanılabilir. Daha kapsamlı özellikler sunar ancak kurulumu ve yapılandırması biraz daha karmaşık olabilir.
* Diğer Nesne Depolama Sağlayıcıları: Bu rehber AWS S3’e odaklanmış olsa da, s3cmd MinIO gibi S3 API uyumlu diğer nesne depolama çözümleriyle de çalışabilir. Google Cloud Storage veya Azure Blob Storage gibi diğer bulut sağlayıcıları için kendi komut satırı araçlarını kullanmanız gerekir.

Sonuç ve SSS

Bu rehberde, Ubuntu 16.04 üzerinde logrotate ve s3cmd kullanarak log dosyalarınızı otomatik olarak döndürme, sıkıştırma ve Amazon S3 gibi nesne depolama hizmetlerine güvenli bir şekilde arşivleme sürecini detaylıca ele aldık. Bu entegrasyon, sunucunuzun disk alanını verimli kullanırken, değerli log verilerinizi uzun vadeli, güvenli ve maliyet etkin bir şekilde saklamanızı sağlar. Otomatik arşivleme, manuel müdahaleyi azaltır ve operasyonel verimliliği artırır.

Sıkça Sorulan Sorular (SSS)

S: Logrotate neden çalışmıyor veya logları S3’e yüklemiyor?
C: Birkaç olası neden olabilir:
* Logrotate’un cron işi çalışmıyor olabilir. /etc/cron.daily/logrotate dosyasının çalıştırılabilir olduğundan ve cron’un doğru şekilde yapılandırıldığından emin olun.
* Logrotate yapılandırma dosyasında (örn. /etc/logrotate.d/mywebapp) sözdizimi hatası olabilir. sudo logrotate -d /etc/logrotate.d/mywebapp ile test edin.
* postrotate betiğindeki s3cmd komutu doğru yolu bulamıyor veya yetkilendirme sorunları yaşıyor olabilir. s3cmd‘nin root kullanıcısı için yapılandırıldığından (/root/.s3cfg) veya --config parametresinin doğru yolu gösterdiğinden emin olun.
* IAM kullanıcınızın S3 bucket’ına yükleme izinleri olmayabilir. IAM politikasını kontrol edin.
Log dosyası deseni (/var/log/mywebapp/.log) doğru değilse, logrotate dosyaları bulamaz.

S: S3cmd yetkilendirme hatası veriyor, ne yapmalıyım?
C: Bu genellikle yanlış veya eksik Access Key/Secret Key veya yanlış IAM izinlerinden kaynaklanır.
* /root/.s3cfg dosyasındaki anahtarların doğru olduğundan emin olun.
* IAM kullanıcınızın S3 bucket’ına PutObject ve ListBucket izinleri olduğundan emin olun.
* s3cmd --configure komutunu sudo ile çalıştırarak yapılandırmayı yeniden yapmayı deneyin.

S: Logları S3’ten geri nasıl alırım?
C: s3cmd get komutunu kullanabilirsiniz:

s3cmd get s3://your-log-bucket-name/mywebapp/2023/10/26/access.log-20231025.gz ./

Bu komut, belirtilen log dosyasını mevcut dizine indirir.

S: Logları yerelde silmek güvenli mi?
C: Evet, logları S3’e başarıyla yüklendikten sonra yerelde silmek genellikle güvenlidir, çünkü S3 yüksek dayanıklılık ve erişilebilirlik sunar. Ancak, işletmenizin veya uygulamanızın belirli gereksinimleri varsa (örneğin, yerel erişim için kısa bir süre tutma), rm komutunu postrotate betiğinden kaldırabilir veya belirli bir süre sonra silmek için ayrı bir cron işi kullanabilirsiniz.

S: Ubuntu 16.04 yerine başka bir versiyon kullanabilir miyim?
C: Evet, bu rehberdeki temel adımlar Ubuntu’nun diğer sürümleri (örn. 18.04, 20.04, 22.04) ve hatta diğer Debian tabanlı Linux dağıtımları için de geçerlidir. Paket isimleri ve bazı dosya yolları küçük farklılıklar gösterebilir, ancak genel mantık aynı kalacaktır.