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

[miolini]

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

[onegreyonewhite]

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

[kay]

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

[olku]

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

[onegreyonewhite]

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

[olku]

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

[julia_morg]

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

[Eternalko]

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

[julia_morg]

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

[Eternalko]

«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]

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

[banzayats]

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

[julia_morg]

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

[onegreyonewhite]

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

[julia_morg]

спасибо!

[AlexWinner]

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

[onegreyonewhite]

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

[AlexWinner]

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

[onegreyonewhite]

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

[Eternalko]

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

[onegreyonewhite]

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

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

[Eternalko]

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

[onegreyonewhite]

У клиента вся архитектура на OpenStack, но боюсь они вместо контейнеров используют KVM или VMWare.

[Eternalko]

Ну тогда нет смысла менять технологии раз прижилось и опыт есть.

[erthad]

Kafka вместо RabbitMQ не пробовали смотреть?