rejestrowanie asynchroniczne przez rsyslogd (8) i zwiększenie bufora zapisu

Na stronie o dużym ruchu, uruchomionej w wirtualnych kontenerach (VMware) i pozbawionej lokalnej pamięci, udało nam się znacznie zwiększyć przepustowość (liczbę żądań na sekundę), przechodząc z logowania bezpośrednio do plików dziennika (które znajdują się na zdalnej pamięci sieciowej) na rsyslogd .

Zasadniczo zmieniliśmy rejestrowanie synchroniczne na asynchroniczne. Pracownicy serwera WWW piszą za pomocą syslog (3) do jakiegoś bufora pamięci, a rsyslogd (8) wysyła dane do rzeczywistego pliku równolegle i we własnym tempie, aby procesy nie blokowały IO podczas logowania.

Na razie w porządku. Problem polega na tym, że okazjonalnie rsyslogd nie może pisać (np. Chwilowe / przedłużające się przerwy w sieci), a przychodzący bufor szybko się zapełnia.

Moje pytania to:

• Czy klient może kiedykolwiek zablokować pisząc do rsyslogd przy użyciu syslog (3) ?
• Czy istnieje sposób, aby spojrzeć na statystyki rsyslogd , np. Jak duży / pełny jest bufor?
• Czy istnieje sposób na zwiększenie rozmiaru bufora wejściowego rsyslogd ?

O ile pamiętam domyślnym trybem dla głównej kolejki komunikatów w rsyslog jest tablica o stałym rozmiarze. Ma limit około 10 000 elementów. Spróbuj zmienić to na kolejkę z listami połączonymi, co powinno znacznie lepiej obsłużyć sporadyczne wysyłanie wiadomości.

Tak, są FixedArrayi LinkedListkolejki.

Odpowiedź na twoje pierwsze pytanie brzmi:

Tak, każde wywołanie syslog () blokuje. Może przez bardzo krótki czas, ale wciąż jest to synchroniczne wywołanie obejmujące deskryptor pliku. Zobacz man 3 syslogwięcej detali.

O ile serwery nie używają architektur asynchronicznych i operacji podstawowych, zawsze będzie pewne blokowanie. Można to złagodzić, ale nie można go wyeliminować, na przykład używając oddzielnego klucza do logowania. W przypadku pozostałych dwóch pytań tak naprawdę nie wiem, ale jedynym sposobem na sprawdzenie jest sprawdzenie kodu źródłowego rsyslogd (oraz jednego z rodziny funkcji syslog ()).

Mówiąc bardziej ogólnie, jeśli przeniesiesz rejestrowanie na serwer zewnętrzny za pomocą UDP: 514 „sieciowego protokołu syslog”, wówczas zwiększysz możliwości tworzenia blokad prawie do zera. Z zwrotu ewentualnej utraty niektórych rejestrowania podczas dużych obciążeń.

Po pierwsze , na serwerach „inicjujących” należy upewnić się, że wszystkie rejestrowanie odbywa się za pośrednictwem syslog. Na przykład w Apache2 musisz określić:

ErrorLog "syslog:daemon"

W przypadku innych serwerów zapoznaj się z odpowiednią stroną podręcznika. Jeśli nie możesz tego zapewnić, pamiętaj, że można utworzyć logowanie do systemów plików

Po drugie , w początkowej konfiguracji rsyslogd należy skierować cały ruch syslog dla wybranego obiektu (w tym przykładzie „demona”) na jeden lub więcej zewnętrznych serwerów syslog. W pliku konfiguracyjnym rsyslog możesz określić:

daemon.* @192.168.128.1
daemon.* @192.168.254.1

mieć dwie kopie dzienników, które będą wysyłane jednocześnie na dwa różne serwery.

Po trzecie , na serwerach docelowych włączasz odbiór wiadomości syslog przez UDP: 514. Jest w (konfiguracyjnym) pliku konfiguracyjnym rsyslogd i zwykle jest wyłączany przez defualt (wystarczyłoby usunąć wiodące #s:

$ModLoad imudp
$UDPServerRun 514

Po czwarte , opcjonalne, ale wysoce zalecane, włączę także znaczniki czasu wysokiej rozdzielczości:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

Również ta opcja jest zwykle domyślnie wyłączona (dlaczego na Ziemi?).