rsyslogd (8) ve yazma arabelleği artışı aracılığıyla eşzamansız günlüğe kaydetme


10

Sanal kapsayıcılarda (VMware) çalışan ve yerel depolama alanı olmayan oldukça yüksek trafikli bir web sitesinde, doğrudan günlük dosyalarından (uzak ağ depolamasında bulunan) oturum açmaya geçerek verimi (saniye başına istek) önemli ölçüde artırmayı başardık rsyslogd .

Esasen senkronize olmayan asenkron günlüklemeye geçtik. Web sunucusu çalışanları , bazı bellek arabelleğine syslog (3) kullanarak yazar ve rsyslogd (8) , verileri gerçek bir dosyaya paralel ve kendi hızında gönderir, bu nedenle işlemler günlüğe kaydetme sırasında G / Ç'de engellenmez.

Çok uzak çok iyi. Sorun, zaman zaman rsyslogd'ın yazılmasının önlenmesi (örn. Anlık / uzun süreli ağ kesintisi) ve gelen arabellek hızla dolar .

Sorularım:

  • Bir istemci syslog (3) kullanarak rsyslogd'a yazarken engelleyebilir mi?
  • Rsyslogd istatistiklerine bakmanın bir yolu var mı , örneğin arabellek ne kadar büyük / dolu?
  • Boyutunu artırmak için bir yol var mı rsyslogd gelen tampon?

2
Bunu hiç çözdün mü? Eğer öyleyse, cevabınızı okumak isterim.
djeikyb

1
@djeikyb: üzgünüm hayır. İlgi görüyorum (soruya oy veriyor) ama henüz kimse cevap vermedi. Bu bir kaynak kodu dalış gerektirir gibi görünüyor.
arielf

1
Hangi web sunucusunu kullandığınızı söylemiyorsunuz. Belki de sistem günlüğü kullanmamalısınız. Örneğin Apache, günlüğe kaydetmek için syslog kullanıyor mu, yoksa yalnızca günlük dosyalarına mı yazıyor? Veritabanında oturum açmak başka bir olasılıktır.
blujay

Yanıtlar:


1

Bildiğim kadarıyla rsyslog ana ileti kuyruğu için varsayılan mod sabit boyutlu dizisidir. 10k element için bir sınırı vardır. Bunu ara sıra mesaj patlamaları çok daha iyi işlemeli bağlantılı liste kuyruğuna değiştirmeyi deneyin.

Evet, vardır FixedArrayve LinkedListkuyruklar.


"Değiştirmeye çalışın" ... Daha açık olabilir misiniz? Şuna bakıyorum /etc/rsyslog.conf: Bahsettiğiniz kuyruk türleriyle ilgili hiçbir şey görmüyorum. Bu bir kod değişikliği gerektiriyor mu? Bunlar nerede ve nasıl yapılandırılabilir? Teşekkürler!
arielf

1

İlk sorunuzun cevabı:

Evet, herhangi bir syslog () çağrısı engelleniyor. Belki çok kısa bir süre için, ama yine de bir dosya tanımlayıcı içeren eşzamanlı bir çağrı. Daha man 3 syslogfazla detial için bakın .

Sunucularınız eşzamansız mimarileri ve ilkel öğeleri kullanmadığı sürece, her zaman bir miktar kilitleme olacaktır. Bu, örneğin kayıt için ayrı bir iplik kullanılarak hafifletilebilir, ancak ortadan kaldırılamaz. Diğer iki soru için gerçekten bilmiyorum ama rsyslogd kaynak kodu (hem de syslog () fonksiyon ailesi için olanı) muayene bilmek tek yoldur.

Daha genel olarak, günlüğe kaydetmeyi UDP: 514 "ağ syslog protokolü" aracılığıyla harici bir sunucuya taşırsanız, kilit oluşturma olasılıklarını neredeyse sıfıra getirirsiniz. İle bazı günlük olası kaybı dezavantajı yüksek yükleri sırasında.

İlk olarak , "menşei" sunucularında, tüm günlüğe kaydetmenin syslog üzerinden gerçekleşmesini sağlamanız gerekir. Örneğin, Apache2'de şunları belirtmeniz gerekir:

ErrorLog "syslog:daemon"

Diğer sunucular için lütfen ilgili kılavuz sayfasına bakınız. Bunu sağlayamıyorsanız, lütfen dosya sistemlerinde oturum açmanın

İkinci olarak , kaynak rsyslogd yapılandırmasında, seçtiğiniz tesis için tüm bu sistem günlüğü trafiğini (bu örnekte "daemon") bir veya daha fazla harici syslog sunucusuna yönlendirmenizi istersiniz. Rsyslog yapılandırma dosyasında şunları belirleyebilirsiniz:

daemon.* @192.168.128.1
daemon.* @192.168.254.1

aynı anda iki farklı sunucuya gönderilecek günlüklerin iki kopyasına sahip olmak.

Üçüncü olarak , hedef sunucu (lar) da, sistem günlüğü iletisinin UDP: 514 üzerinden alınmasını etkinleştirirsiniz. (Hedef) rsyslogd yapılandırma dosyasındadır ve normal olarak defualt tarafından devre dışı bırakılır (önde gelen #'leri kaldırmak yeterli olacaktır:

$ModLoad imudp
$UDPServerRun 514

Dördüncüsü , isteğe bağlı ancak şiddetle tavsiye edilir, ayrıca yüksek çözünürlüklü zaman damgalarını da etkinleştiririm:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

Ayrıca bu seçenek normalde varsayılan olarak devre dışıdır (neden Dünya'da?).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.