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 ?
Odpowiedzi:
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ą
FixedArrayiLinkedListkolejki.źródło
/etc/rsyslog.conf: nie widzę nic związanego z wymienionymi typami kolejek. Czy to wymaga zmiany kodu? Gdzie i jak można je skonfigurować? Dzięki!Odpowiedź na twoje pierwsze pytanie brzmi:
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ć:
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ć:
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:
Po czwarte , opcjonalne, ale wysoce zalecane, włączę także znaczniki czasu wysokiej rozdzielczości:
Również ta opcja jest zwykle domyślnie wyłączona (dlaczego na Ziemi?).
źródło