logrotate ile rsyslog: rsyslog ve copytruncate'i yeniden yükle

Ubuntu 14 üzerinde varsayılan rsyslog ve logrotate yardımcı programı ile çalışıyorum.

Varsayılan rsyslog logrotate config'te /etc/logrotate.d/rsyslogaşağıdakileri görüyorum:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

Anladığım kadarıyla, geçerli günlük hareket etmediği için, ancak açık bir dosya işleyicisine sahip herhangi bir işlemin yazmaya devam edebilmesi için günlüğü kısaltan tüm logrotate senaryolarında copytruncate kullanılması önerilir.

Peki yerine rsyslog yeniden yükleme özelliğini kullanarak varsayılan yapılandırma nasıl geliyor?

Sorunuzu cevaplamak için, önce yeniden yükleme ve taklit kesme işleminin farklı dengesini anlamanız gerekir:

• yeniden yükle : eski günlük dosyası yeniden adlandırılır ve bu günlüğe yazma işlemi günlük dosyasını yeniden oluşturmak üzere bildirilir (Unix sinyali aracılığıyla). Bu en hızlı / düşük havai yöntemdir: yeniden adlandırma / taşıma işlemleri çok hızlıdır ve sabit bir yürütme süresine sahiptir. Dahası, neredeyse atomik bir işlemdir: bu, taşıma / yeniden yükleme sırasında (neredeyse) hiçbir günlük girişinin kaybolmayacağı anlamına gelir. Öte yandan, günlük dosyasını yeniden yükleyebilen ve yeniden açabilen bir işleme ihtiyacınız vardır . Rsyslog böyle bir işlemdir, bu nedenle varsayılan logrotate config yeniden yükleme yöntemini kullanır. Bu modun rsyslog ile kullanılması rsyslog yukarı akış tarafından şiddetle tavsiye edilir.
• copytruncate : eski günlük dosyası bir arşiv dosyasına kopyalanır ve daha sonra eski günlük satırlarını "silmek" için kesilir. Kesme işlemi çok hızlı olsa da, kopya oldukça uzun olabilir (günlük dosyanızın büyüklüğüne bağlı olarak). Ayrıca, kopyalama işlemi (hatırlayın, yavaş olabilir) ve kesik arasındaki süre boyunca bazı günlük girişleri kaybolabilir. Bu nedenlerden dolayı, copytruncate, günlük dosyalarını yeniden yükleyebilen ve yeniden oluşturabilen hizmetler için varsayılan olarak kullanılmaz. Bir sunucu ise Öte yandan, değil yeniden / Tekrar Oluştur günlük dosyaları yeteneğine, copytruncate sizin en güvenli bahistir. Başka bir deyişle, herhangi bir hizmet düzeyinde destek gerektirmez. Rsyslog upstream projesi bu modu kullanmamanızı şiddetle tavsiye eder.

Rsyslog yazarı olarak konuşan copytruncate aslında çok, çok, çok kötü bir seçimdir. Doğası gereği açık saçıktır ve bunu kullanmak günlük verilerini kaybedeceğinizin neredeyse bir garantisidir. Dosya ne kadar sık ​​yazılırsa o kadar çok kaybedersiniz. Ve bu sadece son satırın bir parçası değil, aynı zamanda dönme gerçekleştiği zaman sistemin tam zamanlamasına ve durumuna bağlı olarak birkaç yüz olabilir.

Dosya taşındığında ve yeni bir inode (dosya) oluşturulduğunda, rsyslog önceki dosyayı ve tüm işlemleri izler. Yani bu durumda hiçbir kaybınız yok. Garantili (dosya sistemini çıkarmanız dışında ...).

"ReopenOnTruncate" hakkında: Ben şahsen reopenOnTruncate diğer konularda da, özellikle NFS ve benzeri ile açık saçık gördüm. Bir süre önce bu işlevselliği tamamen kaldırdım, ancak daha sonra benzer işlevselliği tekrar birleştirmeye ikna oldum. İnsanların çok yüklü sistemlerde sorun yaşadığını bildiğim için muhtemelen "deneysel" kalacak. "copytruncate" günlük dosyalarıyla çalışmak için iyi bir mod değildir.

Şu anda imfile (ETA 8.34 veya 8.35) yeniden düzenleme üzerinde çalışıyorum. Yeniden düzenlenmiş sürüm, muhtemelen API yarışından dolayı yanlışlıkla yeniden göndermeyi önleyebilecek, ancak aynı zamanda veri kaybına karşı koruma sağlayamayacaktır - çünkü bu kavramsal olarak imkansızdır.

Bu tamamen sürecin günlük yazma şekline bağlıdır.
copytruncateyalnızca günlük iletileri dosyaya eklenirse çalışır (örn whatever >> logfile.
Çıktıyı yeniden yönlendirirken değil (ör . whatever > logfile).

8.16 sürümünden beri rsyslog reopenOnTruncatecopytruncte sorununu işleyen imfile seçeneğine sahiptir.

Özellikle rsyslog için, şeyleri oldukları gibi bırakmak muhtemelen daha mantıklıdır.

Temel nedeni, rsyslog'un çıkış tanıtıcısının kullanılamadığı durumlarda kullanabileceği dahili kuyruklara sahip olmasıdır.

Yeniden yükleme, a) rsyslog'un kendi günlük dosyasını yeniden oluşturmasına neden olur ve b) sıraya alınan olayların oluşturma sırasında dosyayla temizlenmesine neden olur.

Bu copytruncate herhangi bir zarar vermez (kısmen yazılmış satırların kısaltılmasından endişe etmeme rağmen), ancak kopyalama / silme / yeniden yükleme işleminin bir bütünlük açısından 'daha güvenli' olduğunu düşünmeye eğilimliyim.

@ Tarafından belirtildiği gibi Faker dosya kullanılamaz hale nereye rsyslog durumu idare edebilir, çünkü, kullanım copytruncate için zorlayıcı bir neden yoktur.

Ve @ SelivanovPavel tarafından belirtildiği gibi , rsyslog aslında kopya kesme ile düzgün şekilde başa çıkmak için belirli bir yapılandırma gerektirir.

Bu yüzden, yalnızca reloadyaklaşımı kullanmak varsayılan yapılandırmadan daha az sapma gerektirdiğinden, onu tutardım.