У меня есть среда, которая генерирует откровенно смехотворный объем трафика Syslog - это в основном из-за культуры, когда в производственных приложениях не выполняется вход на уровне отладки (и изменение этой тенденции, к сожалению, не актуально и намного выше моей зарплаты).
Мне уже пришлось отойти от UDP из-за огромного объема, вызывающего потерю пакетов. Централизованная среда системного журнала меньшего размера (много отправителей, горстка получателей) быстро переполняется: либо отдельные серверы системного журнала, либо их резервное хранилище несколько раз выходят из строя под нагрузкой.
Теперь я могу изменить его архитектуру.
Я думаю, что это что-то вроде syslog-ng на моих клиентах (уже стандартное для принудительного управления конфигурацией), отправка сообщений, отформатированных как JSON, через кластер HAProxy, при этом сообщения остаются в кластере Elasticsearch. В качестве бонуса и HAProxy, и Elasticsearch независимо друг от друга, горизонтально масштабируются с учетом будущих потребностей.
Я не сразу предвижу никаких проблем с этим, но хотелось бы и другого мнения. Это жизнеспособный план? Есть варианты получше? Есть какие-нибудь ножные ружья, которые мне следует искать?
Примечание. На всякий случай я хочу прояснить, что этот вопрос касается отправки трафика системного журнала TCP на HAProxy для балансировки нагрузки, а не собственной регистрации трафика или статуса HAProxy.
Graylog и ELK - это проекты управления журналами, которые также могут масштабироваться по горизонтали и могут использовать хранилище Elasticsearch. Входы могут быть сбалансированы по нагрузке, как вам нравится, естественно, как существуют статьи для HAProxy.
Однако вы не поделились многими деталями, которые позволили бы прокомментировать вашу архитектуру. Почему выходит из строя ваше хранилище (вы, вероятно, должны сначала это исправить)? Какая частота сообщений в секунду вызывает у вас проблемы? Сколько узлов вы рассматривали? Неужели у каждого из этих может быть свой вопрос.