На веб-сайте с довольно высоким трафиком, работающем в виртуальных контейнерах (VMware) и не имеющем локального хранилища, нам удалось значительно увеличить пропускную способность (количество запросов в секунду), переключившись с входа непосредственно в файлы журнала (которые находятся в удаленном сетевом хранилище) на rsyslogd .
По сути, мы перешли от синхронного к асинхронному ведению журнала. Работники веб-сервера пишут с использованием syslog (3) в некоторый буфер памяти, а rsyslogd (8) отправляет данные в реальный файл параллельно и в своем собственном темпе, поэтому процессы не блокируются при вводе-выводе при ведении журнала.
Все идет нормально. Проблема в том, что иногда rsyslogd не может записывать (например, кратковременное / длительное отключение сети) и входящий буфер быстро заполняется.
Мои вопросы:
- Может ли клиент когда-либо блокироваться при записи в rsyslogd с использованием syslog (3) ?
- Есть ли способ посмотреть статистику rsyslogd , например, насколько большой / полный буфер?
- Есть ли способ увеличить размер входящего буфера rsyslogd ?
Ответы:
Насколько я помню, режим по умолчанию для основной очереди сообщений в rsyslog - это массив фиксированного размера. У этого есть предел для 10k элементов или около того. Попытайтесь изменить это на очередь связанного списка, это должно обработать ваши случайные посылки сообщений намного лучше.
Да, есть
FixedArrayиLinkedListочереди.источник
/etc/rsyslog.conf: я не вижу ничего, связанного с типами очередей, которые вы упоминаете. Требуется ли изменение кода? Где и как их можно настроить? Спасибо!Ответ на ваш первый вопрос:
Если ваши серверы не используют асинхронные архитектуры и примитивы, всегда будет некоторая блокировка. Это может быть смягчено, но не устранено, например, с помощью отдельной темы для ведения журнала. Что касается двух других вопросов, которые я на самом деле не знаю, но изучение исходного кода rsyslogd (также как и для семейства функций syslog ()) - единственный способ узнать.
В общем, если вы перемещаете протоколирование на внешний сервер по протоколу UDP: 514 «протокол сетевого системного журнала», то возможности создания блокировок практически сводятся к нулю. С недостатком возможны потери некоторых заготовок при высоких нагрузках.
Во-первых , на «исходных» серверах необходимо убедиться, что все журналы ведутся через системный журнал. Например, в Apache2 вам нужно указать:
Для других серверов, пожалуйста, обратитесь к соответствующей странице руководства. Если вы не можете этого гарантировать, имейте в виду, что вход в файловую систему может создать
Во-вторых , в исходной конфигурации rsyslogd вы просите направить весь трафик syslog для выбранного вами средства (в данном примере «daemon») на один или несколько внешних серверов syslog. В файле конфигурации rsyslog вы можете указать:
иметь две копии журналов для одновременной отправки на два разных сервера.
В-третьих , на конечном (ых) сервере (ах) вы включаете прием сообщения системного журнала по UDP: 514. Он находится в (целевом) конфигурационном файле rsyslogd и обычно отключается по умолчанию (этого достаточно, чтобы удалить первые #:
В-четвертых , необязательно, но настоятельно рекомендуется также включить временные метки с высоким разрешением:
Также эта опция обычно отключена по умолчанию (почему на Земле?).
источник