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

10

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

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

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

Мои вопросы:

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

2 ответа

1

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

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

ответ дан hostmaster 18.02.2014 в 14:00
1

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

  

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

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

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

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

ErrorLog "syslog:daemon"

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

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

daemon.* @192.168.128.1
daemon.* @192.168.254.1

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

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

$ModLoad imudp
$UDPServerRun 514

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

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

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

    
ответ дан Uqbar 14.05.2014 в 14:02