onegreyonewhite 22 июн 2015 в 15:00

ELK+R как хранилище логов

3 мин

33K

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

Из песочницы

+14

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

miolini 22 июн 2015 в 16:10

Замените RabbitMQ на NSQ от Bitly. На каждую ноду с logstash можно поставить nsqd (или же просто отдельным кластером). Nsqd еще можно спрятать за http прокси. Слушатели будут равномерно разбирать сообщения из одной очереди с разных nsqd хостов при запуске двух-трех nsqlookupd процессов — это реализовано в драйвере. В итоге у вас не будет бутылочного горлышка для MQ.

onegreyonewhite 25 июн 2015 в 03:54

Интересное предложение. Протестим.

kay 22 июн 2015 в 16:23

Я бы объединил listener+queue+filter. Вместо rabbitmmq, использовать redis. redis чуть подтюнить с помощью twitter/twemproxy и получим отказоустойчивое решение.

olku 22 июн 2015 в 18:10

Вы уверены, что вам было нужно не потерять ни одно из тысяч сообщений? Логи обычно агрегируют весьма широко, а убрав это требование, вы открываете дорогу для UDP и syslog, попутно отказываетесь от кролика и балансера. Рост пропускной должен быть выше раза в 3.

onegreyonewhite 25 июн 2015 в 04:01

К сожалению, «клиент всегда прав». К тому же это логи с 1000 хостов (у клиента), поэтому одно из сообщений потерять может быть весьма критично. Хотя решение на Syslog могло бы быть симпатичным.

olku 25 июн 2015 в 09:09

Бесспорно. Бывает, в практике встречается, что заказчик сам не может сформулировать, какую бизнес-проблему он хочет решить жесткими граничными условиями. Проект — это всегда взаимное обучение заказчика и исполнителя в технологиях и предметной области.

julia_morg 22 июн 2015 в 20:46

Не отказалась бы от мануала по установке: )

Eternalko 23 июн 2015 в 14:47

Лучше всего как-то так для начала (:

julia_morg 28 июн 2015 в 10:54

ого! спасибо! На досуге попробую воспроизвести

Eternalko 29 июн 2015 в 16:14

«docker run sebp/elk» и все готово

Или через через «docker-compose up». Примерный конфиг docker-compose.yml

elasticsearch:
  image: elasticsearch:1.6.0
  ports:
    - "9200:9200"
logstash:
  image: logstash:1.5.1
  volumes:
    - logstash-conf:/config-dir
  ports:
    - "5000:5000"
  links:
    - elasticsearch:elasticsearch
  command: logstash -f /config-dir/logstash.conf
kibana4:
  image: kibana:4.1.0
  ports:
    - "5601:5601"
  links:
    - elasticsearch:elasticsearch

onegreyonewhite 25 июн 2015 в 04:03

Сделаем!
Только вышел с больничного, ближайшие пару дней напишу man. А там уже можно будет и Chef-рецепты описать.

banzayats 25 июн 2015 в 17:21

Устанавливал используя серию статей (есть вариант для Ubuntu)
Без каких либо ухищрений настроил приём логов с фаерволов Cisco. Поток логов в р-не 1500-1800 логов в секунду. Пока полёт нормальный.

julia_morg 28 июн 2015 в 10:57

спасибо, буду разбираться с мануалом

onegreyonewhite 26 июн 2015 в 05:13

Тут продолжение об установке.

julia_morg 28 июн 2015 в 10:53

спасибо!

AlexWinner 22 июн 2015 в 22:46

Кстати, наткнулся на интересную фичу у ElasticSearch. Нода отказывается добавляться в кластер, если на других нодах кластера установлены плагины, которых нет на этой ноде.

onegreyonewhite 25 июн 2015 в 04:07

Хм… Или у Вас несколько http-нод? Может такой плагин? Какая версия es`а?

AlexWinner 25 июн 2015 в 18:25

Всего 4 ноды было, добавлял пятую.
Версия ES — 1.4.5, плагин был license.
Случайно нашёл похожий баг про плагин jdbc: github.com/jprante/elasticsearch-jdbc/issues/439, по нему и догадался, из-за чего такой косяк. Полдня дебаг-логи читал, ничего понять не мог.

onegreyonewhite 26 июн 2015 в 02:31

Всё же дело в плагине. Я кроме mobz/elasticsearch-head плагины не включал (даже shield ибо $$$), но новые master и data машины легко входят в кластер. Licence — сложно даже плагином назвать. Насколько я понял, это «билет в платную поддержку». Не стал углубляться в этом вопросе.

Eternalko 23 июн 2015 в 14:51

ELK хороший stack. Не совсем понимаю зачем тут нужен RabbitMQ. Может стоит подумать о альтернативах?
Что до массивности, то по опыту, ее можно «понизить» с помощью Docker. Раз настроить систему и сколько угодно можно клонировать.

onegreyonewhite 25 июн 2015 в 04:16

Обработчик filter в logstash имеет свойство жутко «выжирать» CPU, поэтому пришлось его расположить отдельно. Так падение даже всех фильтров не сказывается на заборе логов, только на их отображении.
RabbitMQ как балансировщик нагрузки между фильтрами + очереди. Как-то так. Альтернативу предложили в первом комментарии, будем смотреть.

Заказчик хочет, чтоб система смогла расти от 100мб логов в день, до 1Тб в час (вот ума не приложу где они всё это собираются хранить), так что вариант с Docker не совсем подходит.

Eternalko 25 июн 2015 в 12:19

Конечно.С другой стороны, Гугл специально все держит в контейнерах, чтобы можно было этим всем хозяйством вменяемо управлять и горизонтально масштабировать