асинхронний журнал через rsyslogd (8) та збільшення буфера запису

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

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

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

Мої запитання:

• Чи може клієнт коли-небудь блокувати, коли пише в rsyslogd за допомогою syslog (3) ?
• Чи є спосіб переглянути статистику rsyslogd , наприклад, наскільки великим / повним є буфер?
• Чи є спосіб збільшити розмір вхідного буфера rsyslogd ?

Наскільки я пам'ятаю режим за замовчуванням для основної черги повідомлень у rsyslog - це масив фіксованого розміру. Він має обмеження на 10 к елементів або близько того. Спробуйте змінити це на черзі зв'язаного списку, воно повинно набагато краще обробляти випадкові спалахи повідомлень.

Так, є FixedArrayі LinkedListчерги.

Відповідь на ваше перше запитання:

Так, будь-який виклик до syslog () блокується. Можливо, дуже короткий час, але все одно це синхронний дзвінок із дескриптором файлів. Перегляньте man 3 syslogбільше детіал.

Якщо ваші сервери не використовують асинхронну архітектуру та примітиви, завжди буде якесь блокування. Це можна пом'якшити, але не усунути, наприклад, використовуючи окрему нитку для ведення журналу. Для двох інших питань я насправді не знаю, але перевірка вихідного коду 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

Також ця опція зазвичай відключена за замовчуванням (чому на Землі?).