syslog-ng: баланс производительности и контроль нагрузки на входе
Anarchist 8 декабря, 2017 - 12:36
В ванильном конфиге app-admin/rsyslog
Enterprise Linux прописаны… мягко говоря странные параметры контроля входной нагрузки.
Зачем это сделано — понятно (предотвращение DoS).
Но заставь… профессионала делать что-то нужное — такого нагородит.
Однако сама идея правильная.
Откуда просьба в первую очередь к тов. SysA поделиться опытом на тему:
1. Определения величины производительности (и способа задания сбалансированного режима работы) app-admin/syslog-ng
. В смысле как сказать серверу не принимать сообщений в единицу времени больше, чем он может записать.
2. Буферизация (когда сервер сглаживает пик нагрузки, превосходящий производительность записи) и поведение сервера при переполнении буфера (когда пик превышает ёмкость буфера).
»
- Для комментирования войдите или зарегистрируйтесь
Нет времени на подробное
Нет времени на подробное описание, но в двух словах:
1. На каждом ДЦ по 2 лог-сервера, все пишут на оба.
2. С них инфа идет на
GRAYLOG
(кластер) для доступа разработчиков и прочих, кому положено (лог-серверы для всех, кроме админов, закрыты).3. реальный
/etc/rsyslog.conf
:Ну так мы никуда не опаздываем…
Эта тема предполагает использование
app-admin/syslog-ng
.Выбор демона — отдельная история. И так как ты начал отвечать про
app-admin/rsyslog
, и потому что у нас давненько не былосрачейдискуссий, её должно рассмотреть.Как и вопрос о кластеризации.
Навскидку про реальный
rsyslog
(правда в не-гентушной реинкарнации сборки) процитирую фрагмент реального конфига::wq
--
Live free or die
У всех своя песочница...
Ты упомянул оба... фантазировать/теоретизировать не хочу - дал, что есть. Конфиг устоялся с годами и прекрасно работает (по-крайней мере для нашей инфраструктуры)...
И не будет! :)
У всех своя песочница...
/
Потому-что:
Во-первых, на линуксах ассортимент практически содится к выбору из этих двух вариантов.
Причём обычно (вне эволюционной линии гентушечки) выбор осуществляется разработчиками дистрибутива.
И во-вторых, только про rsyslog мне известен факт достаточно распространённого решения по ограничению нагрузки. А фантазировать/теоретизировать не хочу.
Практически два вопроса: о методике выбора демона (хотя бы из двух озвученных вариантов) и о методике поверки правильности сделанного выбора.
И что, никогда не сталкивался с сообщениями типа (мои да-а-авно сротировались, цитирую по интернетам):
Ты гонишь! ☺
…и только количество конструкторов, из которых можно собрать решение, долженствующее удовлетворять каждому конкретному частному случаю сугубо ограничено.
:wq
--
Live free or die