Комментарии 6
Мы только начали развивать систему, и далеко не все, что хотим в ней видеть, в ней сейчас есть. Сейчас мы собираем и фильтруем логи с файрволов и деплоя, предстоит добавить различные веб-проекты, сетевое оборудование, виртуализацию и прочее. То-есть речь идет только о части того что должно приходить в систему и обрабатываться ей, поэтому мы заранее закладываем вопросы производительности и масштабирования.
Деплой, файрволы и ресурсы, обеспечивающие деплой дают сейчас поток примерно в 9 миллионов сообщений в сутки, то-есть около 100 сообщений в секунду.
Да, мы сразу по-разворачивании и первым тестам заметили заметные проблемы производительности. Поэтому отбросили план сосредоточить все в логгере без фильтрации. Наша цель - до 1000-2000 тысяч сообщений при нормальном функционировании системы. На случай пиков, как защита от потерь и предлагается система в статье. С Реббитом в качестве кеша - система будет медленнее пережевывать сообщения, но их не потеряет.
Ничего не изменилось. Вам так и не удалось добиться от ELK нужной вам производительности.
я как-то экспериментировал с логстэшем пару лет назад - дул в него где-то 70k записей в секунду, умирал быстро и надолго. То же количество раскидывал раундробином в мастера и все было норм. И я склоняюсь к следующему: все что по середине между поставщиками логов и мастерами эластика - узкое место. Препарсинг должен быть сделан в виде агента, типа как у егеря, где это возможно, ну а там где нет, то подойдет ваша схема
Архитектура ELK-RabbitMQ — управление логами для большой IT-инфраструктуры