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

В компании заказчика появилась необходимость в неком хранилище логов с возможностью горизонтального масштабирования. Исходя из начала задачи первая мысль — Splunk. К сожалению, стоимость данного решения уходила далеко за пределы бюджета заказчика.

В итоге выбор пал на связку Logstash + Elasticsearch + Kibana.

Вдохновившись статьей на Хабре «Собираем и анализируем логи с помощью Lumberjack+Logstash+Elasticsearch+RabbitMQ» и вооружившись небольшим «облаком» на DevStack, начались эксперименты.

Первое, что понравилось — RabbitMQ как промежуточное звено, дабы не растерять логи. Но, к сожалению, logstash-forwarder оказался не очень удобным в сборе логов из Windows, а так как большинство клиентов будет как раз на WinServer, то это оказалось критичным. Поиски привели к nxlog community edition. Связку с logstash оказалось найти не трудно (использовался банально tcp + json).

И начались тесты. Все эксперименты проводились на конфигурации:

Name/Cores/RAM/HDD
HAProxy: 1Core/512MB/4Gb
LIstener: 2Core/512MB/4G
RABBIT: 2Core/2Gb/10G
Filter:2Core/2G/4G
ES_MASTER: 2Core/2G/4G
ES_DATA: 2Core/2G/40G
ES_BALANSER: 2Core/2G/4G
KIBANA: 2Core/2G/4G


Система: Ubuntu Server 14.04 LTS (образ здесь).

Первый подход


Связка: nxlog => haproxy => logstash(listener) => rabbimq => logstash(filter) => elasticsearch
listener`ов и filter`ов по 2 инстанса
elasticsearch – кластер из 2 «равноправных» инстанса

Преимущества:
  • Прост в установке на стороне заказчика.

Недостатки:
  • Узкое место — rabbitmq. После перезагрузки rabbitmq приходилось перезапускать listener`ы, т. к. они по неведомой мне причине не хотели переподключаться самостоятельно. Да и падение «кролика» никто не отменял;
  • Elasticsearch с очень большой потугой переваривал запросы, после наполнения индекса > 100mb;
  • Неудобно добавлять новые инстансы в ES кластер: приходилось руками дописывать в filter список доступных серверов.


Ошибки были учтены + появилось новое требование: система должна быть на CentOS.

Второй подход


Связка: nxlog => haproxy => logstash(listener) => haproxy(2) => rabbimq => haproxy(3) => logstash(filter) => elasticsearch-http => elasticsearch-data+master
haproxy(2) и haproxy(3) — это одна и та же машина.
Под ES 5 машин — ES-http, 2xES-data и 2xES-master.

Преимущества:
  • Горизонтальный рост до бесконечности;
  • Отказоустойчивость;
  • Можно реализовать обмен между listener и filter на rabbitmq ram нодах (+10 к производительности).

Недостатки:
  • Массивность решения;
  • Трудности в установке у клиента;


В итоге получили примерно такую систему:

Схема


Система спокойно «переваривает» 17 488 154 сообщений логов в день. Размер сообщений — до 2кб.

Одним из преимуществ ES является тот факт, что размер базы сообщений очень сильно сокращается при однотипности полей: при потоке в 17 млн сообщений и среднем размере сообщения 1кб, размер базы был чуть больше 2Гб. Почти в 10 раз меньше, чем должен быть.

При такой конфигурации оборудования свободно проходит до 800 сообщений/сек без задержек. При большем количестве сообщений растёт очередь, но для пиковых нагрузок не так критично.

TODO:
  • После перезапуска по очереди всех инстансов RabbitMQ, logstash-listener начинал истерически и неуспешно пытаться переподключиться к Rabbit`у. Необходим перезапуск listener`ов. Поиск причин продолжается;
  • «Выжать» из Elasticsearch больше производительности.


Проблема с установкой решена средствами Chef-server.
Всё уместилось (и ещё место осталось) на тестовом стенде i5-4570 4x3.2GHz + 24Gb RAM + 2x500Gb HDD.

Если интересно и актуально, то могу написать подробный мануал, что и как устанавливать.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 25

    0
    Замените RabbitMQ на NSQ от Bitly. На каждую ноду с logstash можно поставить nsqd (или же просто отдельным кластером). Nsqd еще можно спрятать за http прокси. Слушатели будут равномерно разбирать сообщения из одной очереди с разных nsqd хостов при запуске двух-трех nsqlookupd процессов — это реализовано в драйвере. В итоге у вас не будет бутылочного горлышка для MQ.
      0
      Интересное предложение. Протестим.
      0
      Я бы объединил listener+queue+filter. Вместо rabbitmmq, использовать redis. redis чуть подтюнить с помощью twitter/twemproxy и получим отказоустойчивое решение.
        0
        Вы уверены, что вам было нужно не потерять ни одно из тысяч сообщений? Логи обычно агрегируют весьма широко, а убрав это требование, вы открываете дорогу для UDP и syslog, попутно отказываетесь от кролика и балансера. Рост пропускной должен быть выше раза в 3.
          0
          К сожалению, «клиент всегда прав». К тому же это логи с 1000 хостов (у клиента), поэтому одно из сообщений потерять может быть весьма критично. Хотя решение на Syslog могло бы быть симпатичным.
            0
            Бесспорно. Бывает, в практике встречается, что заказчик сам не может сформулировать, какую бизнес-проблему он хочет решить жесткими граничными условиями. Проект — это всегда взаимное обучение заказчика и исполнителя в технологиях и предметной области.
          +2
          Не отказалась бы от мануала по установке: )
            0
            Лучше всего как-то так для начала (:
              0
              ого! спасибо! На досуге попробую воспроизвести
                0
                «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
                


              0
              Сделаем!
              Только вышел с больничного, ближайшие пару дней напишу man. А там уже можно будет и Chef-рецепты описать.
                0
                Устанавливал используя серию статей (есть вариант для Ubuntu)
                Без каких либо ухищрений настроил приём логов с фаерволов Cisco. Поток логов в р-не 1500-1800 логов в секунду. Пока полёт нормальный.
                  0
                  спасибо, буду разбираться с мануалом
                  0
                  Тут продолжение об установке.
                0
                Кстати, наткнулся на интересную фичу у ElasticSearch. Нода отказывается добавляться в кластер, если на других нодах кластера установлены плагины, которых нет на этой ноде.
                  0
                  Хм… Или у Вас несколько http-нод? Может такой плагин? Какая версия es`а?
                    0
                    Всего 4 ноды было, добавлял пятую.
                    Версия ES — 1.4.5, плагин был license.
                    Случайно нашёл похожий баг про плагин jdbc: github.com/jprante/elasticsearch-jdbc/issues/439, по нему и догадался, из-за чего такой косяк. Полдня дебаг-логи читал, ничего понять не мог.
                      0
                      Всё же дело в плагине. Я кроме mobz/elasticsearch-head плагины не включал (даже shield ибо $$$), но новые master и data машины легко входят в кластер. Licence — сложно даже плагином назвать. Насколько я понял, это «билет в платную поддержку». Не стал углубляться в этом вопросе.
                  0
                  ELK хороший stack. Не совсем понимаю зачем тут нужен RabbitMQ. Может стоит подумать о альтернативах?
                  Что до массивности, то по опыту, ее можно «понизить» с помощью Docker. Раз настроить систему и сколько угодно можно клонировать.
                    0
                    Обработчик filter в logstash имеет свойство жутко «выжирать» CPU, поэтому пришлось его расположить отдельно. Так падение даже всех фильтров не сказывается на заборе логов, только на их отображении.
                    RabbitMQ как балансировщик нагрузки между фильтрами + очереди. Как-то так. Альтернативу предложили в первом комментарии, будем смотреть.

                    Заказчик хочет, чтоб система смогла расти от 100мб логов в день, до 1Тб в час (вот ума не приложу где они всё это собираются хранить), так что вариант с Docker не совсем подходит.
                      0
                      Конечно.С другой стороны, Гугл специально все держит в контейнерах, чтобы можно было этим всем хозяйством вменяемо управлять и горизонтально масштабировать
                        0
                        У клиента вся архитектура на OpenStack, но боюсь они вместо контейнеров используют KVM или VMWare.
                          0
                          Ну тогда нет смысла менять технологии раз прижилось и опыт есть.
                    0
                    Kafka вместо RabbitMQ не пробовали смотреть?

                    Only users with full accounts can post comments. Log in, please.