Комментарии 13
Скажите, а какие протоколы используются при передаче логов в logstash (которые не из beats), и как происходит балансировка и гарантированная доставка?
Да, ElastAlert мы очень рекомендуем, его легко развернуть и у него есть все необходимые виды правил: простое соответствие фильтру, изменение количества событий или значения в определенном поле и т. д. И способов оповещения тоже умеет много, можно обойтись только им самим, если алерты нужно слать в почту или что-нибудь вроде Slack/Gitter/PagerDuty.
Протоколы у нас используются кроме beats такие:
- NXLog с машин под управлением AIX отправляет данные с помощью модуля om_tcp: читает из файлов лог, немного обрабатывает (multiline, пара фильтров), оборачивает в JSON и просто по TCP отправляет на серверы Logstash в TCP инпут. Балансируется это всё с помощью HAProxy. Не Nginx, потому что изначально в роли балансера был HAProxy, сейчас в основном используется Nginx, но перенести остатки с HAProxy не доходят руки, ведь всё работает. Здесь никаких дополнительных гарантий доставки, кроме предлагаемых TCP, нет.
- У нас есть сервис, который свои логи пишет исключительно в БД. Для того, чтобы собирать этот лог в Elasticsearch мы на отдельной машине запустили еще один экземпляр Logstash, который занимается исключительно тем, что с помощью jdbc input с определенной периодичностью забирает из базы все записи с момента предыдущего опроса и отправляет их "большим" Logstash по HTTP. Балансировка делается с помощью Nginx, с повторными попытками отправки данных в случае ошибок.
- Есть некоторый набор сервисов, с которых метрики собираются агентами сollectd — они отправляют данные Logstash'ам по UDP (UDP input + кодек collectd в Logstash). Никаких гарантий доставки нет, да и не требуется в этом случае.
В целом, мы стремимся к тому, чтобы заменить весь этот зоопарк агентами Beats, процесс идет, но не очень быстро. Основной фактор, который удерживает от перехода на Beats полностью — наличие AIX. Компилятор gccgo под AIX с определенной версии собирает агенты Beats и они даже запускаются, но в реализации netpoll есть недостаток, который приводит к высокой утилизации CPU при определенных условиях.
Сколько у Вас мастер нод, дата нод?
Используете ли Вы координатор?
Какой объем индексации с учетом реплик?
Использовали ли Вы Kibana Canvas?
Ну и с какими проблемами сталкиваетесь :)
В кластере Elasticsearch у нас всего 8 нод: 4 горячих, 4 тёплых.
Горячие ноды одновременно выполняют роль мастеров и координирующих нод, для защиты от split-brain параметр discovery.zen.minimum_master_nodes: равен трём. Тёплые ноды имеют только роль data и не могут становиться мастерами или координировать запросы.
Каждой виртуальной машине с горячей нодой выделено 20 vCPU и 64GB RAM, для тёплых — 8 vCPU, 32GB RAM.
Размер heap у всех горячих нод 31GB, у тёплых — 16GB. Основная часть оставшейся памяти используется под page cache, это хорошо помогает быстрее обслуживать пачки запросов к одним и тем же данным.
Машины c Logstash имеют следующую конфигурацию: 8 vCPU, 24GB RAM.
Тредпулы Elasticsearch настроены так: размер пулов write (bulk в более старых версиях) и management по количеству CPU, размер search по количеству CPU x 8. Ну а размеры очередей для пулов были подобраны таким образом: понемногу увеличивали их, пока очереди не перестали переполняться во время пиковой нагрузки и умножили этот размер на два.
Никаких проблем из-за того, что у нас нет выделенных мастер-нод или координаторов, мы не замечали. Вероятно, у нас недостаточный объем данных, чтобы их ощутить.
Кстати об объеме: с учетом репликации (1 реплика на шард) у нас в самые нагруженные периоды рабочего дня (09:00 — 12:00, 14:00 — 16:00) скорость индексации в среднем держится на уровне 25000 событий/сек., с редкими пиками до 60000 событий/сек. Кластер может пропустить через себя в среднем 100000 событий/сек. со 100% нагрузкой.
Прямо сейчас в кластере 751 индекс, 13 463 335 957 документов (без учета реплик) и 11.42TB данных (с учетом реплик).
В шаблонах для индексов у нас ничего особенного нет: маппинги для полей делаем, когда точно знаем, какие в них будут данные, в остальных случаях используем дефолтный маппинг из шаблона, который поставляется с Logstash — строки в поля типа text, плюс поле.raw с типом keyword. Данные храним с кодеком best_compression, структурированный текст из логов хорошо жмётся. Используем токенизатор типа pattern, который разбивает строки на токены по всем символам, кроме [A-Za-z0-9А-Яа-я_\.-]: по понятным причинам дефолтный токенизатор для обычного текста плохо подходит для логов.
Canvas не пробовали, но хотим. Ждем выхода версии, в которой он будет встроен в поставку по умолчанию.
Серьезные проблемы за всё время эксплуатации были связаны в основном с багами в компонентах стека. После перехода на 5.0 обнаружился серьезный баг в Elasticsearch, который приводил к кратковременному выпадению случайных нод из кластера в случайное время. Мы его зарепортили и Elastic очень быстро его починили. После перехода на 6.0 у нас воспроизвелся баг, который приводил к быстрому переполнению management тредпула в определенных условиях. Все точно так же быстро решилось после отправки баг-репорта.
Мы начали с версии 2.2 и я могу сказать, что с тех пор стек очень сильно изменился в лучшую сторону: как с точки зрения стабильности работы, так и с точки зрения функциональности. То есть, ELK времен Elasticsearch 2.2 и Elastic Stack 6.4 это почти два разных продукта.
Чтобы прямо не мила — нет, мы жили без него долгое время и начали им пользоваться только когда он вошел в комплект по умолчанию и для его установки перестал требоваться полный рестарт кластера.
То есть мы его не устанавливали, а просто не стали удалять.
Из всех компонентов X-Pack нам наиболее интересны Security и Graph, если бы их можно было приобрести отдельно, мы были бы весьма рады. Сейчас мы периодически используем kbn_network, но он довольно ограничен по сравнению с Graph. В качестве замены Security используем правила на Nginx (список разрешенных HTTP-методов, запрет доступа к определенным API, индексам и т. д.).
Компоненты Monitoring и Reporting в Kibana (выгрузки в CSV) — приятное дополнение, но их отсутствие не приведет к отказу от стека в целом.
Появляются ли множество событий в jira при жёсткой перезагрузке сервера? Были таки случаи?
NXLog мы используем только из-за наличия AIXовых машин сейчас.
Продукт неплохой, он производительный и позволяет делать с логами многое на стороне агента, разгружая таким образом препроцессоры.
Но у нас с ним есть одна проблема, которую победить до сих пор не удалось.
У NXLog есть внутренний лимит на длину обрабатываемой строки. Пока он не достигнут — все работает замечательно. Но у нас специфика сервисов, логи которых мы собираем, такая, что в логе внезапно может оказаться строка, скажем, на 50МБ. Или даже 100. Если такая строка встречается, нам нужно ее либо обрезать до вменяемой длины, либо дропнуть. Проблема в том, что для того, чтобы что-то сделать с событием, NXLog всё равно нужно обработать строку и, если она не влезает в его лимит, иногда происходят странные вещи:
- Перестает работать xm_multiline модуль — событие "рассыпается" на отдельные строки.
- В некоторых случаях после получения такой строки NXLog просто перестает обрабатывать записи из лога, но при этом, как правило, не падает (а иногда и падает).
- Иногда получение такой строки приводит к утечке NXLog в память.
С Filebeat, к примеру, такой проблемы никогда не было, там тоже есть (настраиваемый) лимит на максимальный размер события, но большие строки он обрабатывает корректно.
Пока что мы это обходим мониторингом запущенности процессов NXLog и "контролем качества" для логов приложений, чтобы в принципе не допускать попадание таких больших строк туда.
Если кто-то знает, как решить эту проблему с NXLog, мы были бы очень благодарны за наводку, в каком направлении копать.
А мы так и делаем: if size ($raw_event) > N {$message = substr(...);}. Это работает почти во всех случаях, но на очень длинных строках nxlog все равно иногда впадает в кому и приходится перезапускать его сервис. К счастью, сейчас это происходит гораздо реже, чем раньше.
Вот здесь у Filebeat неоспоримое преимущество — с ним об этих вещах не нужно думать вообще: лимит на размер события "просто работает".
К тому же есть у нас еще один механизм, который позволяет сократить количество тасков: для каждой заводимой задачи считается «отпечаток», который представляет собой SHA256 от строки «ячейка-кластер-исключение-класс-метод». Этот хеш записывается в таск и при следующем запуске скрипта при обнаружении ошибок сначала делается поиск по открытым таскам, чтобы определить, нет ли у нас уже задач про них. Если есть — туда просто добавляется комментарий с актуальной диагностической информацией из лога. Таким образом, «автозадачи» в JIRA у нас всегда автоматически актуализируются.
Но интересны и альтернативы (не столь жрущие как системы на Java), для менее жирных систем. Бо странно иметь систему сбора логов в разы более ресурсоемкую, чем основной софт.
Внимание, вопрос:
Есть ли какие-нибудь альтернативы ELK, более скромные по затратам ресурсов? Пусть и с меньшим количеством возможностей.
Ну, в нашем случае выделенные под стек ресурсы даже не приближаются к общему объему, выделенному под проект, поэтому для нас такой вопрос был неактуален. Для нас была важна функциональность, отсутствие необходимости платить за объем обрабатываемых данных и наличие большого сообщества у продукта.
Тут еще есть такой момент: если вам в основном нужно собирать метрики или большой объем сильно структурированных данных, то лучше, наверное, посмотреть в сторону чего-то вроде TICK stack от Influxdata или ClickHouse от Yandex. Elasticsearch поддерживает довольно эффективное хранение метрик (колоночное хранилище, поддержка rollup), но это скорее на случай, если вы уже собираете в него логи и рядом с ними есть еще немного метрик, которые тоже хотелось бы снимать и собирать.
Альтернативы для Beats/Logstash есть (fluentd, тот же nxlog, Heka (Hindsight), ...) Но если нужно собирать логи в разном формате из разных источников и с разной структурой, то, как правило, нужен и полнотекстовый поиск по ним, а значит понадобится какой-нибудь поисковый движок. Из популярных это Elasticsearch, Apache Solr (тот же Lucene внутри), Sphinx. Elasticsearch обладает преимуществом: так как Elastic активно продвигает весь стек как универсальное средство для сбора и аналитики событий/метрик, в Elasticsearch активно пилятся фичи, которые его превращают из поискового движка общего назначения в поисково-аналитическую платформу.
Наш путь к централизованному хранению логов