асинхронное ведение журнала через rsyslogd (8) и увеличение буфера записи

На веб-сайте с довольно высоким трафиком, работающем в виртуальных контейнерах (VMware) и не имеющем локального хранилища, нам удалось значительно увеличить пропускную способность (количество запросов в секунду), переключившись с входа непосредственно в файлы журнала (которые находятся в удаленном сетевом хранилище) на rsyslogd .

По сути, мы перешли от синхронного к асинхронному ведению журнала. Работники веб-сервера пишут с использованием syslog (3) в некоторый буфер памяти, а rsyslogd (8) отправляет данные в реальный файл параллельно и в своем собственном темпе, поэтому процессы не блокируются при вводе-выводе при ведении журнала.

Все идет нормально. Проблема в том, что иногда rsyslogd не может записывать (например, кратковременное / длительное отключение сети) и входящий буфер быстро заполняется.

Мои вопросы:

• Может ли клиент когда-либо блокироваться при записи в rsyslogd с использованием syslog (3) ?
• Есть ли способ посмотреть статистику rsyslogd , например, насколько большой / полный буфер?
• Есть ли способ увеличить размер входящего буфера rsyslogd ?

Насколько я помню, режим по умолчанию для основной очереди сообщений в rsyslog - это массив фиксированного размера. У этого есть предел для 10k элементов или около того. Попытайтесь изменить это на очередь связанного списка, это должно обработать ваши случайные посылки сообщений намного лучше.

Да, есть FixedArrayи LinkedListочереди.

Ответ на ваш первый вопрос:

Да, любой вызов syslog () блокируется. Может быть, на очень короткое время, но это все равно синхронный вызов с использованием файлового дескриптора. Смотрите man 3 syslogбольше деталей.

Если ваши серверы не используют асинхронные архитектуры и примитивы, всегда будет некоторая блокировка. Это может быть смягчено, но не устранено, например, с помощью отдельной темы для ведения журнала. Что касается двух других вопросов, которые я на самом деле не знаю, но изучение исходного кода rsyslogd (также как и для семейства функций syslog ()) - единственный способ узнать.

В общем, если вы перемещаете протоколирование на внешний сервер по протоколу UDP: 514 «протокол сетевого системного журнала», то возможности создания блокировок практически сводятся к нулю. С недостатком возможны потери некоторых заготовок при высоких нагрузках.

Во-первых , на «исходных» серверах необходимо убедиться, что все журналы ведутся через системный журнал. Например, в Apache2 вам нужно указать:

ErrorLog "syslog:daemon"

Для других серверов, пожалуйста, обратитесь к соответствующей странице руководства. Если вы не можете этого гарантировать, имейте в виду, что вход в файловую систему может создать

Во-вторых , в исходной конфигурации rsyslogd вы просите направить весь трафик syslog для выбранного вами средства (в данном примере «daemon») на один или несколько внешних серверов syslog. В файле конфигурации rsyslog вы можете указать:

daemon.* @192.168.128.1
daemon.* @192.168.254.1

иметь две копии журналов для одновременной отправки на два разных сервера.

В-третьих , на конечном (ых) сервере (ах) вы включаете прием сообщения системного журнала по UDP: 514. Он находится в (целевом) конфигурационном файле rsyslogd и обычно отключается по умолчанию (этого достаточно, чтобы удалить первые #:

$ModLoad imudp
$UDPServerRun 514

В-четвертых , необязательно, но настоятельно рекомендуется также включить временные метки с высоким разрешением:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

Также эта опция обычно отключена по умолчанию (почему на Земле?).