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.

Якщо цікаво і актуально, то можу написати докладний мануал, що і як встановлювати.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.