асинхронное ведение журнала через rsyslogd (8) и увеличение буфера записи
На веб-сайте с довольно высоким трафиком, работающем в виртуальных контейнерах (VMware) и не имеющем локального хранилища, нам удалось значительно увеличить пропускную способность (количество запросов в секунду), переключившись с входа непосредственно в файлы журнала (которые находятся в удаленной сети). хранение) до rsyslogd .
По сути мы переключились с синхронного на асинхронное ведение журнала. Работники веб-сервера пишут, используя syslog (3) , в некоторый буфер памяти, а rsyslogd (8) отправляет данные в реальный файл параллельно и в своем собственном темпе, поэтому процессы не не блокировать ввод-вывод при регистрации.
1113 Пока все хорошо. Проблема в том, что иногда rsyslogd запрещается запись (например, кратковременное / длительное отключение сети) и входящий буфер быстро заполняется.
Мои вопросы:
- Может ли клиент когда-либо блокировать запись в rsyslogd с использованием syslog (3) ?
- есть способ посмотреть статистику rsyslogd , например насколько большой / полный буфер?
- Есть ли способ увеличить размер входящего буфера rsyslogd ?
2 ответа
Насколько я помню, режим по умолчанию для основной очереди сообщений в rsyslog - это массив фиксированного размера. У него есть предел для 10k элементов или около того. Попытайтесь изменить это на очередь связанного списка, это должно обработать ваши случайные посылки сообщений намного лучше.
Да, есть очереди FixedArray и LinkedList.
Ответ на ваш первый вопрос:
Да, любой вызов syslog () блокируется. Может быть, в течение очень короткого времени, но это все еще синхронный вызов с использованием файлового дескриптора. См.
man 3 syslogдля получения дополнительной информации.Если ваши серверы не используют асинхронные архитектуры и примитивы, всегда будет некоторая блокировка. Это может быть смягчено, но не устранено, например, с помощью отдельной темы для ведения журнала. Что касается двух других вопросов, которые я на самом деле не знаю, но изучение исходного кода rsyslogd (а также одного из функций семейства syslog ()) - единственный способ узнать это.
В целом, если вы перенесете протоколирование на внешний сервер по протоколу UDP: 514 «протокол сетевого системного журнала», то возможности создания блокировок практически сведены к нулю. С недостатком возможны потери некоторых заготовок при высоких нагрузках.
Во-первых , на «исходных» серверах вы должны убедиться, что все журналы ведутся через системный журнал. Например, в Apache2 вам необходимо указать:
ErrorLog "syslog:daemon"Для других серверов, пожалуйста, обратитесь к соответствующей странице руководства. Если вы не можете этого гарантировать, имейте в виду, что регистрация в файловых системах может создать
Second , в исходной конфигурации rsyslogd вы просите направить весь трафик syslog для выбранного вами средства («daemon»). «в этом примере) к одному или нескольким внешним серверам системного журнала. В файле конфигурации rsyslog вы можете указать:
daemon.* @192.168.128.1 daemon.* @192.168.254.1иметь две копии журналов для одновременной отправки на два разных сервера.
В-третьих , на сервере (ах) назначения вы разрешаете прием сообщения системного журнала по UDP: 514. Он находится в (целевом) конфигурационном файле rsyslogd и обычно отключается по умолчанию (достаточно удалить первые #:
$ModLoad imudp $UDPServerRun 514Четвертый , необязательно, но настоятельно рекомендуется, Я также включил бы метки времени с высоким разрешением:
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormatТакже эта опция обычно отключена по умолчанию (почему на Земле?).