У себя тоже используем Graylog для сбора логов от Nginx (около 40-50 разных параметров) и немножко ещё от другого ПО. В день у нас приходит чуть побольше данных, около 3-4ТБ со средним рейтом днём около 60-80к/сек. Но хранимый объём меньше, 4 дата ноды эластика с 4 SATA дисками по 2 ТБ + 2 рабочие ноды Graylog с 250ГБ журнала + 1 нода с мастерами и монгой. А из-за малого количества IOPs'ов приходится идти на разные ухищрения.
Сильно поверхностно описали системы, хочу сказать пару слов за Graylog. Описанная проблема (со старыми версиями эластика), уже давно не такая острая так как они перешли на http-клиент, вместо нативного, с 2.3 (который вышел год назад) они поддерживают ES 5.х (но пока не 6.х, не знаю есть ли там что-то сильно улучшающего процессинг логов).
На предыдущей работе использовали Graylog для хранения логов с разных мест (в основном это были логи Nginx с 40+ разными полями). В день переваривалось порядка 2ТБ данных, которые обрабатывали 2 сервера Graylog и 4 дата сервера ES. На мой взгляд, Graylog был понятней и проще Kibana (сравнивалось давно, сейчас Kibana выглядит более юзер-френдли), настройка его почти минимальна, всё настраивается через веб-интерфейс. Также удобная штука была, это дисковый журнал, в момент когда ES плохо или нужно провести обслуживание, очень помогал (можно было поставить обработку на паузу).
Если вам так действительно сильно нужна поддержка по Erlang, то её всегда можно получить на оутсорсе или фрилансе.
Нам поддержка не нужна, мы же как раз и не агитируем писать всё на Erlang с нуля.
но по моему статья не о том, как вы построили систему, а как собирали слабые стороны RMQ и что-то пытались фиксить
Естественно никто не будет фиксить сильные стороны. Мы рассказали о применени конкретного инструмента в нашей практие и как его можно расширить под свои нужны (пользуясь существующим механизмом плагинов) по мере роста потребностей.
Попробуйте написать своё решение, я думаю разница производительности будет в 2-3 раза в пользу своего. А объем кода в десятки раз меньше RMQ.
Безусловно уже смотрели, и выигрышь будет больше, но затраты на разработку пока будут выше, чем профит. Потому-что это не просто нафигачить 500 строк кода, как у человека на видео выше, а делать надо адекватно, с поддержкой многих клиентов, кейсов использования, возможности расширения, всевозможных видов тестирования и интеграцией в CI. Какие-то тестовые испытательные образцы у нас на «4 ядрах» отправляли и по 500-600к/сек.
То есть, если Вам требуется использовать стороннее открытое решение, то первым делом Вы становитесь профессионалом (а лучше экспертом) в языке, на котором написано данное ПО, а затем его анализируете на идеальность. Причём заранее имеете чёткую задачу, которая никогда не изменятся в будущем. И весь этот труд оплачивается вашей компанией. Так?
Я конечно может отстал от жизни, но обычно если нужно использовать стороннее решение, то проводится его тестирование на пригодность с точки зрения функционала и других требований.
И, следуя Вашей логике, если когда-то в будущем потребуется, скажем, написать какой-то порт на С++ для Erlang, то получается надо было всё сразу писать на С++ согласно вашей фразе: «Почему все стараются использовать какие-то стандартные решения, а потом адаптируют их костылями под свои нужды?».
Здесь всегда два мнения: «зачем изучать и настраивать что-то готовое, ведь проще запилисть своё?» и «зачем изобретать велосипед, если есть готовое?», и выбор зависит от ситуации. На момент старта у нас не было специалистов по Erlang, а RabbitMQ имел всё на борту. За 4 года жизни проекта на фикс проблем ушло наверное не более 2 человекомесяцев.
У нас есть тест, работающий из браузера (браузер->БЛ->RabbitMQ->браузер), и с хорошим каналом полный цикл получается 10-20 мс при средней дневной нагрузке.
10-ку пока не доводилось ставить, но на предыдущих версиях, чтобы винда не создавала доп. раздел, я делал раздел в 1 гиг, а потом ресайзил его до нужного объёма
Спасибо за статью!
А планируются ли ещё статьи по этой системе? Интересно узнать ещё чем проводите нагрузочное тестирование, насколько сложная маршрутизация внутри и какое количество сообщений в среднем проходит через систему?
На предыдущей работе использовали Graylog для хранения логов с разных мест (в основном это были логи Nginx с 40+ разными полями). В день переваривалось порядка 2ТБ данных, которые обрабатывали 2 сервера Graylog и 4 дата сервера ES. На мой взгляд, Graylog был понятней и проще Kibana (сравнивалось давно, сейчас Kibana выглядит более юзер-френдли), настройка его почти минимальна, всё настраивается через веб-интерфейс. Также удобная штука была, это дисковый журнал, в момент когда ES плохо или нужно провести обслуживание, очень помогал (можно было поставить обработку на паузу).
Нам поддержка не нужна, мы же как раз и не агитируем писать всё на Erlang с нуля.
Естественно никто не будет фиксить сильные стороны. Мы рассказали о применени конкретного инструмента в нашей практие и как его можно расширить под свои нужны (пользуясь существующим механизмом плагинов) по мере роста потребностей.
Безусловно уже смотрели, и выигрышь будет больше, но затраты на разработку пока будут выше, чем профит. Потому-что это не просто нафигачить 500 строк кода, как у человека на видео выше, а делать надо адекватно, с поддержкой многих клиентов, кейсов использования, возможности расширения, всевозможных видов тестирования и интеграцией в CI. Какие-то тестовые испытательные образцы у нас на «4 ядрах» отправляли и по 500-600к/сек.
Я конечно может отстал от жизни, но обычно если нужно использовать стороннее решение, то проводится его тестирование на пригодность с точки зрения функционала и других требований.
И, следуя Вашей логике, если когда-то в будущем потребуется, скажем, написать какой-то порт на С++ для Erlang, то получается надо было всё сразу писать на С++ согласно вашей фразе: «Почему все стараются использовать какие-то стандартные решения, а потом адаптируют их костылями под свои нужды?».
А планируются ли ещё статьи по этой системе? Интересно узнать ещё чем проводите нагрузочное тестирование, насколько сложная маршрутизация внутри и какое количество сообщений в среднем проходит через систему?