bdmde 25 янв 2016 в 10:33

Как мы Elasticsearch готовили, или О том, как обработать 36 тысяч логов в секунду

5 мин

32K

Высокая производительность*

Из песочницы

+25

Комментарии 24

alexkuzko 25 янв 2016 в 13:42

если есть свободная память, может туда писать? все равно работать будет как временная папка.

bdmde 25 янв 2016 в 15:39

Не понял комментария, писать на каком этапе?

alexkuzko 25 янв 2016 в 16:23

Вот что вы писали:
… мы принимаем их Rsyslog и складываем в файл…
...Из файла эти логи затем читаются logstash, который их обрабатывает и отправляет в ES…
Я предположил что можно было бы попробовать их в tmpfs / shm писать и читать оттуда. Вопрос только в их размерах.

kay 25 янв 2016 в 15:32

А не пробовали логи писать прямиком в JSON? Их тогда и не придётся обрабатывать GROK'ом.

bdmde 25 янв 2016 в 15:34

К сожалению, такой возможности нет, логи пишутся не нами.

felix0id 25 янв 2016 в 16:32

Из того, отчего пришлось отказаться от логшеттера:

Надо было слать логи дальше в http POST батчами — перепилили стандартный плагин, не было критичным
jruby медленный и не обрабатывал нормально системные сигналы: кажется, кто-то их перехватывал, точно не вспомню, но стандартный убунтовый (14.04) init-script не отрабатывал должным образом.
Внешне удобные grok иногда скрывают под собой жуткие конструкции, которые катастрофически сказываются на производительности
Если логшеттер спотыкается об строчку в файле (тоже не вспомню, на input или уже на обработке), он падает и больше не поднимается (невозможно заставить его даже сказать, на какой строчке он упал)
У нас возникла проблема в месте сохранения состояния. ЕМНИП, LS считает «успешным» момент обработки строки по её прочтению. Если после этого не удаётся её отправить — who cares?
Было что-то ещё, но за последний год, к сожалению, забылось

Прошу не воспринимать коммент как «технология говно», просто у нас не полетело даже на тестах. Для прода пришлось писать самим.

igor_suhorukov 25 янв 2016 в 17:10

Тогда возможно вам подойдет другой подход к решению проблемы.

felix0id 25 янв 2016 в 17:12

Спасибо, но уже год как крутится самописная конструкция без всего этого на внутренних инструментах, которая шлёт метрики в графит

igor_suhorukov 25 янв 2016 в 17:21

Так это же замечательно! Раз работает уже год — не трогайте)

Про jruby я сталкивался с пренеприятным явлением, что файловые локи не поддерживались на Solaris — приходилось писать обертку для локов в java и вызывать из logstash jruby плагина.

kt97679 26 янв 2016 в 07:12

Я посмотрел презентацию, но не нашел цифр по производительности, вы не знаете сколько логов в секунду им удается обработать?

rudenkovk 26 янв 2016 в 13:35

Кстати, немного на грани оффтопа.
Недавно пошла мода все переписывать, типа как puppet на clojure. Про logstash/fluentd такого не слышно?

igor_suhorukov 25 янв 2016 в 17:19

У вас индексы партиционируются по дням? Попробуйте сделать их по часам-десяткам минут. В зависимости от объема логов.
А вообще тут как и в любой оптимизации надо сначала собрать метрики с серверов и посмотреть в чем проблемы, и только потом оптимизировать.

У нас система справлялась с гораздо большим количеством событий в кластере из 6 ES серверов.

Для мониторинга Elasticsearch много решений, для dev целей с ограничениями marvel был бесплатным

vip_delete 25 янв 2016 в 17:20

Если данные не особо важны, то можно не делать fsync или делать его еще реже. см. index translog. Т.е. в период 1 нужно перестраивать индекс, а в период 2 делать fsync, при этом принимать данные в только память.

chinacoolhacker 25 янв 2016 в 17:36

Rsyslog умеет писать в elasticsearch

tgz 25 янв 2016 в 22:31

А умеет ли он при этом сохранять данные в буферы, если elasticsearch недоступен? Как, например, fluentd?

chinacoolhacker 26 янв 2016 в 10:55

В теории да
На практике я не проверял, у меня объём логов был с ~5 серверов.
Если интересно попробовать именно Rsyslog — доклад по разгону пропускной способности от Райнера.

bdmde 26 янв 2016 в 05:45

В этом случае будет проблема с пиками нагрузок, такая же, что с LS была. Буфер все равно нужен.

aml 25 янв 2016 в 21:03

А что вы логгируете в таких количествах, если не секрет?

kt97679 26 янв 2016 в 07:23

Буквально только что ставил эксперименты по производительности elasticsearch кластера. Сгенерировал логсташем файл с миллионом json логами и заливал их в кластер программой на си, которая читала данные со стандартного ввода и загружала в кластер через http bulk api (размер запроса ограничен 1мб). Экспериментировал на 2-х кластерах из 4-х и 10-ти машин (48гб, 24-х ядерный ксеон 2ггц). На 4-х машинном кластере удалось выжать 200к логов в секунду, на 10-ти машинном 170к. Я допускаю, что что-то делал не так и из конфигураций выше можно выжать больше, но предварительный вывод, что у elasticsearch кластера не все хорошо с масштабированием. С учетом того, что мне надо обрабатывать порядка 2м логов в секунду похоже придется искать нечто отличное от elasticsearch. Буду крайне признателен за наводки на работающие решения.