Elk что это такое
1.Elastic stack: анализ security логов. Введение
В связи окончанием продаж в России системы логирования и аналитики Splunk, возник вопрос, чем это решение можно заменить? Потратив время на ознакомление с разными решениями, я остановился на решении для настоящего мужика — «ELK stack». Эта система требует времени на ее настройку, но в результате можно получить очень мощную систему по анализу состояния и оперативного реагирования на инциденты информационной безопасности в организации. В этом цикле статей мы рассмотрим базовые (а может и нет) возможности стека ELK, рассмотрим каким образом можно парсить логи, как строить графики и дашбоарды, и какие интересные функции можно сделать на примере логов с межсетевого экрана Check Point или сканера безопасности OpenVas. Для начала, рассмотрим, что же это такое — стек ELK, и из каких компонентов состоит.
«ELK stack» — это сокращение от трех проектов с открытым исходным кодом: Elasticsearch, Logstash и Kibana. Разрабатывается компанией Elastic вместе со всеми связанными проектами. Elasticsearch — это ядро всей системы, которая сочетает в себе функции базы данных, поисковой и аналитической системы. Logstash — это конвейер обработки данных на стороне сервера, который получает данные из нескольких источников одновременно, парсит лог, а затем отправляет в базу данных Elasticsearch. Kibana позволяет пользователям визуализировать данные с помощью диаграмм и графиков в Elasticsearch. Также через Kibana можно администрировать базу данных. Далее более детально рассмотрим каждую систему отдельно.
Logstash
Logstash – это утилита для обработки лог событий из различных источников, с помощью которой можно выделить поля и их значения в сообщении, также можно настроить фильтрацию и редактирование данных. После всех манипуляций Logstash перенаправляет события в конечное хранилище данных. Утилита настраивается только через конфигурационные файлы.
Типичная конфигурация logstash представляет из себя файл(ы) состоящий из нескольких входящих потоков информации (input), несколько фильтров для этой информации (filter) и несколько исходящих потоков (output). Выглядит это как один или несколько конфигурационных файлов, которые в простейшем варианте (который не делает вообще ничего) выглядит вот так:
В INPUT мы настраиваем на какой порт будут приходить логи и по какому протоколу, либо из какой папки читать новые или постоянно дозаписывающиеся файлы. В FILTER мы настраиваем парсер логов: разбор полей, редактирование значений, добавление новых параметров или удаление. FILTER это поле для управления сообщением которое приходит на Logstash с массой вариантов редактирования. В output мы настраиваем куда отправляем уже разобранный лог, в случае если это elasticsearch отправляется JSON запрос, в котором отправляются поля со значениями, либо же в рамках дебага можно выводить в stdout или записывать в файл.
ElasticSearch
Изначально, Elasticsearch – это решение для полнотекстового поиска, но с дополнительными удобствами, типа легкого масштабирования, репликации и прочего, что сделало продукт очень удобным и хорошим решением для высоконагруженных проектов с большими объемами данных. Elasticsearch является нереляционным хранилищем(NoSQL) документов в формате JSON, и поисковой системой на базе полнотекстового поиска Lucene. Аппаратная платформа — Java Virtual Machine, поэтому системе требуется большое количество ресурсов процессора и оперативки для работы.
Каждое приходящее сообщение, как с Logstash или с помощью API запроса, индексируется как “документ” – аналог таблицы в реляционных SQL. Все документы хранятся в индексе – аналог базы данных в SQL.
Пример документа в базе:
Вся работа с базой данных строится на JSON запросах с помощью REST API, которые либо выдают документы по индексу, либо некую статистику в формате: вопрос — ответ. Для того чтобы все ответы на запросы визуализировать была написана Kibana, которая представляет из себя веб сервис.
Kibana
Kibana позволяет искать\брать данные и запрашивать статистику из базы данных elasticsearch, но основе ответов строятся множество красивых графиков и дашбоардов. Также система имеет функционал администрирования базы данных elasticsearch, в последующих статьях мы рассмотрим более подробно данный сервис. А сейчас покажем пример дашбоардов по межсетевому экрану Check Point и сканеру уязвимостей OpenVas, которые можно будет построить.
Пример дашбоарда для Check Point, картинка кликабельна:
Пример дашбоарда по OpenVas, картинка кликабельна:
Заключение
Мы рассмотрели из чего состоит ELK stack, немного познакомились с основными продуктами, далее в курсе отдельно будем рассматривать написание конфигурационного файла Logstash, настройку дашбоардов на Kibana, познакомимся с API запросами, автоматизацией и много чего еще!
Пациент приходит к врачу и жалуется на боль в животе. «Срочно на операцию! — отвечает врач. — Сейчас мы вас разрежем, покопаемся и постараемся зашить как было».
Когда пользователи ругались на работу системы, называя программистов негодяями, мы поднимали журнал событий и смотрели, что пошло не так. А потом перешли на ELK. Теперь мы мониторим ошибки в моменте, не тормозя работу сервисов.
О каких проектах речь?
Тяжело и тщательно: реалии Java
Наш продукт на Java — это федеральная система розничной продажи билетов. Она должна работать бесперебойно, зависания и приостановка работы недопустимы. А в случае сбоя нужно быстро и точно понять причину, ведь это потери живых денег клиента.
Тут ELK работает как онлайн-мониторинг и инструмент работы нашей службы поддержки. Мы логируем «сырые» данные, чтобы при обращении заказчика в техподдержку мы знали, какие данные обсуждаем, какой был ключ шифрования и т.д.
.Net-проекты в основном представляют собой сервисы поддержки продаж и клиентов. Им пользуются более 20 тысяч человек. Тоже немало, но нагрузки не такие большие, как в Java.
Логируем ошибки и информацию, которая показывает динамику бизнес-операций. Например, сколько юзеров зарегистрировалось на сайте. И когда видим, что два дня не было регистраций, то сразу ясно, что там что-то случилось. Или наоборот — продали миллион билетов и отправили об этом письмо директору, порадовали человека.
Как работаем с ELK
Логирование: Serilog + ELK
Durable mode
Мы используем режим Serilog под названием Durable mode — он гарантирует доставку сообщений, даже если Elastic какое-то время лежит. Он действует примерно так же, как Filebeat плюс Logstash — сперва складывает всё в файл, потом пытается экстренно доставить до Elastic, если это не удается, то Serilog периодически пытается, пока Elastic не поднимется. Можно настроить, как часто он будет обращаться в Elastic.
Здесь можно прочитать инструкцию по настройке.
Контейнеры для логов
на Java-проектах пишем много логов, — до 5 Гб в день. Эти файлы бьем на куски по 5 Мб, чтобы они занимали меньше места и их стало легче хранить. ELK храним и поднимаем в Docker-контейнерах на наших компьютерах — получается виртуальная машина, просто более легкая, которую кто-то уже настроил до тебя.
Мониторинг Zabbix
У каждой записи есть Trace ID, а браузер меряет время старта и конца операции — мы логируем эти данные на сервере, а потом мониторим через Zabbix.
Kibana/ Grafana
Kibana используем для ежедневного мониторинга ошибок. В Kibana можно сделать поиск по логам. Мы используем эту функцию на проде и на тестовых серверах. У нас также есть Grafana — визуализация у неё лучше, на одном дашборде показаны все наши проекты. Здесь мы можем посмотреть все данные. Красным помечаются все ошибки — это повод залезть в Kibana и посмотреть детали. Мы видим, где ошибка, её место в коде, когда она возникла, условия окружения. У нас есть один ID, который связывает все системы воедино и может проследить полный путь ошибки.
Если ошибка неизвестная, начинаем разбираться более пристально. Например, недавно мы выложили на прод один бизнес-процесс. Тестирование со стороны заказчика прошло хорошо, но мы заглянули в логи и увидели, что там ошибка. Мы сразу поправили её, и никто ничего не заметил.
Например, на этом скриншоте видно количество регистраций на одном проекте:
Анализ ошибок
Ежедневно мы получаем из ELK все ошибки, определяем среди них новые, классифицируем их, и заодно даём человеко-понятное название.
Наблюдаем за динамикой уже классифицированных ошибок, отлавливаем всплески и разбираемся в причинах. Инженер техподдержки заводит задачи на устранение причин. За сутки в логах нужно проанализировать тысячи и десятки тысяч строк, а на Java-проектах и того больше. Многие ошибки повторяются ежеминутно.
Начинали, как и многие с визуального просматривания всех логов. Но быстро поняли, что при наших объемах так жить нельзя. И настроили Excel-таблицу с макросами, которые умеют забирать из Kibana данные за сутки, выбирать из них ошибки и распределить их по существующим категориям.
В итоге Excel выдаёт отчет, где для каждой ошибки есть информация, сколько раз за сутки эта ошибка произошла. Отдельным списком мы получаем новые ошибки, и можем быстро проанализировать сначала их — есть там критичное, или нет.
В Kibana ходим смотреть детальную информацию по каждой новой ошибке.
Что позволяет делать файл:
Разберем на примере одного из проектов свежие ошибки за последние пару дней:
Что мы видим:
1) ошибки в верхней части, которым присвоены номера задач – не критичны, ждут решения разработчиками, им присвоены номера задач из TFS.
2) ошибка «Сервис ADMS недоступен» возникла 388 раз за сутки – несколько часов сервис был недоступен, что мы увидели, обратившись в Kibana за уточнением.
3) появился новый тип ошибки «Could not connect to…» – она связана с предыдущей, просто логировалась еще в одном месте.
Мы собираемся «расследовать» эти два вида ошибок, чтобы выяснить причины, вероятность повторения и способы предотвращения их в будущем. Им будет присвоено общее обозначение, чтобы эти ошибки «свернулись» в одну строку.
Что планируем улучшить
Сейчас мы работаем над отдельной системой, которая сама по расписанию будет выбирать все ошибки из Elasticsearch, уведомлять оператора о новых и уведомлять о всплесках ошибок. Она будет работать быстрее, чем файл Excel, который постоянно растет. Эта система позволит строить график с различной дискретностью, а не только сутки. Оператор все так же будет анализировать новые ошибки, давать им имена и реагировать на непредвиденные ситуации.
Практическое применение ELK. Настраиваем logstash
Разворачивая очередную систему, столкнулись с необходимостью обрабатывать большое количество разнообразных логов. В качестве инструмента выбрали ELK. В данной статье пойдёт речь о нашем опыте настройки этого стека.
Не ставим цели описать все его возможности, но хотим сконцентрироваться именно на решении практических задач. Вызвано это тем, что при наличии достаточно большого количества документации и уже готовых образов, подводных камней достаточно много, по крайней мере у нас они обнаружились.
Мы разворачивали стек через docker-compose. Более того, у нас был хорошо написанный docker-compose.yml, который позволил нам практически без проблем поднять стек. И нам казалось, что победа уже близка, сейчас немного докрутим под свои нужды и всё.
К сожалению, попытка донастроить систему на получение и обработку логов от нашего приложения, с ходу не увенчалась успехом. Поэтому, мы решили, что стоит изучить каждый компонент отдельно, а потом уже вернуться к их связям.
Итак, начали с logstash.
Окружение, развёртывание, запуск Logstash в контейнере
Для развёртывания используем docker-compose, описанные здесь эксперименты проводились на MacOS и Ubuntu 18.0.4.
Образ logstash, который был прописан у нас в исходном docker-compose.yml, это docker.elastic.co/logstash/logstash:6.3.2
Его мы будем использовать для экспериментов.
Для запуска logstash мы написали отдельный docker-compose.yml. Можно конечно было из командной строки образ запускать, но мы ведь конкретную задачу решали, где у нас всё из docker-compose запускается.
Кратко про конфигурационные файлы
Внутри контейнера есть ещё один конфигурационный файл — logstash.yml. Мы его не трогаем, используем как есть.
Итак, структура наших каталогов:
Для получения входных данных пока считаем, что это tcp по порту 5046, а для вывода будем использовать stdout.
Вот такая простая конфигурация для первого запуска. Поскольку ведь начальная задача — запустить.
Итак, у нас есть вот такой docker-compose.yml
Что мы здесь видим?
Здесь описан один канал с идентификатором HABR и путь к его конфигурационному файлу.
И наконец файл «./config/pipelines/habr_pipeline.conf»
Не будем пока вдаваться в его описание, пробуем запустить:
Контейнер запустился. Можем проверить его работу:
И видим в консоли контейнера ответ:
Но при этом, видим также:
logstash_one_channel | [2019-04-29T11:28:59,790] [ERROR][logstash.licensechecker.licensereader] Unable to retrieve license information from license server <:message=>«Elasticsearch Unreachable: [http://elasticsearch:9200/] [Manticore::ResolutionFailure] elasticsearch», …
logstash_one_channel | [2019-04-29T11:28:59,894][INFO ][logstash.pipeline ] Pipeline started successfully <:pipeline_id=>«.monitoring-logstash», :thread=>»#
logstash_one_channel | [2019-04-29T11:28:59,988][INFO ][logstash.agent ] Pipelines running <:count=>2, :running_pipelines=>[:HABR, :».monitoring-logstash»], :non_running_pipelines=>[]>
logstash_one_channel | [2019-04-29T11:29:00,015] [ERROR][logstash.inputs.metrics ] X-Pack is installed on Logstash but not on Elasticsearch. Please install X-Pack on Elasticsearch to use the monitoring feature. Other features may be available.
logstash_one_channel | [2019-04-29T11:29:00,526][INFO ][logstash.agent ] Successfully started Logstash API endpoint <:port=>9600>
logstash_one_channel | [2019-04-29T11:29:04,478][INFO ][logstash.outputs.elasticsearch] Running health check to see if an Elasticsearch connection is working <:healthcheck_url=>http://elasticsearch:9200/, :path=>»/»>
l ogstash_one_channel | [2019-04-29T11:29:04,487] [WARN ][logstash.outputs.elasticsearch] Attempted to resurrect connection to dead ES instance, but got an error. <:url=>«elasticsearch:9200/», :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>«Elasticsearch Unreachable: [http://elasticsearch:9200/][Manticore::ResolutionFailure] elasticsearch»>
logstash_one_channel | [2019-04-29T11:29:04,704][INFO ][logstash.licensechecker.licensereader] Running health check to see if an Elasticsearch connection is working <:healthcheck_url=>http://elasticsearch:9200/, :path=>»/»>
logstash_one_channel | [2019-04-29T11:29:04,710] [WARN ][logstash.licensechecker.licensereader] Attempted to resurrect connection to dead ES instance, but got an error. <:url=>«elasticsearch:9200/», :error_type=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :error=>«Elasticsearch Unreachable: [http://elasticsearch:9200/][Manticore::ResolutionFailure] elasticsearch»>
И наш лог всё время ползёт вверх.
Здесь я выделил зелёным цветом сообщение о том, что pipeline успешно запустилась, красным — сообщение об ошибке и жёлтым — сообщение о попытке связаться с elasticsearch:9200.
Происходит это из за того, что в logstash.conf, включенном в состав образа, стоит проверка на доступность elasticsearch. Ведь logstash предполагает, что работает в составе Elk стека, а мы его отделили.
Работать можно, но не удобно.
Решением является отключить эту проверку через переменную окружения XPACK_MONITORING_ENABLED.
Внесём изменение в docker-compose.yml и снова запускаем:
Вот теперь, всё нормально. Контейнер готов к экспериментам.
Можем снова набрать в соседней консоли:
Работа в рамках одного канала
Итак, мы запустились. Теперь собственно можно уделить время настройке непосредственно logstash. Не будем пока трогать файл pipelines.yml, посмотрим, что можно получить, работая с одним каналом.
Надо сказать, что общий принцип работы с файлом конфигурации канала хорошо описан в официальном руководстве, вот здесь
Если хочется почитать по-русски, то мы пользовались вот этой статьёй(но синтаксис запросов там старый, надо это учитывать).
Пойдем последовательно от секции Input. Работу по tcp мы уже видели. Что ещё здесь может быть интересного?
Тестовые сообщения, используя heartbeat
Есть такая интересная возможность генерировать автоматические тестовые сообщения.
Для этого в input секцию нужно включить плагин heartbean.
Включаем, начинаем раз в минуту получать
Хотим получать почаще, надо добавить параметр interval.
Вот так будем получать раз в 10 секунд сообщение.
Получение данных из файла
Ещё решили посмотреть режим file. Если нормально с файлом работает, то возможно, и агента никакого не потребуется, ну хотя бы для локального использования.
Итак, что мы хотим получить:
И изменим секцию input в habr_pipeline.conf
Для создания и записывания лог файлов будем пользоваться командой:
При этом, мы видим, что у нас автоматически добавилось поле path. Значит в дальнейшем, мы сможем по нему фильтровать записи.
А теперь в другой файл:
Отлично! Файл подхватился, path указался верно, всё хорошо.
Остановим logstash и запусти заново. Подождём. Тишина. Т.е. Повторно мы эти записи не получаем.
А теперь самый смелый эксперимент.
Кладём logstash и выполняем:
Снова запускаем logstash и видим:
Ура! Всё подхватилось.
Но, надо предупредить о следующем. Если контейнер с logstash удаляется (docker stop logstash_one_channel && docker rm logstash_one_channel), то ничего не подхватится. Внутри контейнера была сохранена позиция файла, до которой он был считан. Если запускать «с нуля», то он будет принимать только новые строки.
Считывание уже существующих файлов
Допустим мы первый раз запускаем logstash, но у нас уже есть логи и мы хотели бы их обработать.
Если мы запустим logstash с той секцией input, которую использовали выше, то мы ничего не получим. Только новые строки будут обрабатываться logstash.
Для того, чтобы подтянулись строки из существующих файлов, следует добавить в input секцию дополнительную строчку:
Причём, есть нюанс, это действует только на новые файлы, которые logstash ещё не видел. Для тех же файлов, что уже попадали в поле зрения logstash, он уже запомнил их размер и теперь будет брать только новые записи в них.
Остановимся на этом на изучении секции input. Там ещё множество вариантов, но нам, для дальнейших экспериментов пока хватит.
Маршрутизация и преобразование данных
Попробуем решить следующую задачу, допустим у нас идут сообщения из одного канала, часть из них информационные, а часть сообщение об ошибках. Отличаются тегом. Одни INFO, другие ERROR.
Нам нужно на выходе их разделить. Т.е. Информационные сообщения пишем в один канал, а сообщения об ошибках в другой.
Для этого, от секции input переходим к filter и output.
С помощью секции filter мы разберём входящее сообщение, получив из него hash(пары ключ-значение), с которым уже можно работать, т.е. разбирать по условиям. А в секции output, отберём сообщения и отправим каждое в свой канал.
Разбор сообщения с помощью grok
Для того, чтобы разбирать текстовые строки и получать из них набор полей, в секции filter есть специальный плагин — grok.
Не ставя себе целью дать здесь его детальное описание (за этим отсылаю к официальной документации), приведу свой простой пример.
Для этого, надо определиться с форматом входных строк. У меня они такие:
1 INFO message1
2 ERROR message2
Т.е. Идентификатор на первом месте, затем INFO/ERROR, затем какое-то слово без пробелов.
Не сложно, но для понимания принципа работы хватит.
Итак, в секции filter, в плагине grok мы должны определить паттерн для разбора наших строк.
Выглядеть он будет так:
По сути, это регулярное выражение. Используются уже готовые паттерны, такие как INT, LOGLEVEL, WORD. Их описание, а также другие паттерны, можно посмотреть вот здесь
Теперь, проходя через этот фильтр, наша строка превратится в hash из трёх полей: message_id, message_type, message_text.
Именно они будут выводиться в секции output.
Маршрутизация сообщений в секции output с помощью команды if
В секции output, как мы помним, мы собирались разделить сообщения на два потока. Одни — которые iNFO, будем выводить на консоль, а с ошибками, будем выводить в файл.
Как нам разделить эти сообщения? Условие задачи уже подсказывает решение — у нас ведь есть уже выделенное поле message_type, которое может принимать только два значения INFO и ERROR. Именно по нему и сделаем выбор с помощью оператора if.
Описание работы с полями и операторами, можно посмотреть вот в этой секции официального мануала.
Теперь, про собственно сам вывод.
Вывод в консоль, здесь всё понятно — stdout <>
А вот вывод в файл — вспоминаем, что мы это всё запускаем из контейнера и чтобы файл, в который мы пишем результат, был доступен снаружи, нам необходимо открыть эту директорию в docker-compose.yml.
Секция output нашего файла выглядит вот так:
В docker-compose.yml добавляем ещё один том, для вывода:
Запускаем, пробуем, видим разделение на два потока.
На что обратить внимание при выборе системы логирования, и почему мы остановились на ELK
На рынке представлено огромное количество систем логирования — как открытых, так и проприетарных. У каждой из них своя функциональность, свои достоинства и недостатки.
Сегодня мы решили поделиться опытом выбора системы логирования и рассказать, почему мы в 1cloud остановились на ELK.
Минутка теории
При переходе в продакшн, приложения превращаются в своеобразные «черные ящики». Их работу нужно постоянно мониторить, чтобы предотвращать и реагировать на потенциальные ЧП, отлавливать «узкие места».
Системы логирования — обязательный инструмент, без которого не обойтись в этом процессе. Проводя подробный анализ собираемых данных, можно идентифицировать «вторжения» в сеть, выявить неправильно настроенное оборудование и оперативно принять меры. Также логирование является обязательным требованием при прохождении разного рода сертификаций, например PCI DSS.
Для автоматизации процессов логирования есть специальные фреймворки: log4j, log4net, Retrace, Logback, Logstash и другие — их множество. Свои инструменты для логирования имеют отдельные средства разработки, например JDK — там есть java.util.logging. Разумеется, функциональность различных инструментов логирования отличается, и необходимый набор функций нужно выбирать исходя из требований бизнеса. Однако есть ряд общих моментов, которые стоит отметить при выборе системы анализа логов.
Простота использования и размеры сообщества
Простота — один из ключевых компонентов при выборе системы логирования. С лог-фреймворками работают все разработчики в команде, потому опыт использования этого инструмента должен быть положительным и не превращать анализ логов в кошмар. API фреймворка должен быть интуитивно понятным, чтобы все, кто раньше не работал с системой, могли быстро разобраться, как она устроена и настроена.
Если рассматривать опенсорсную систему логирования, то имеет смысл оценить сообщество, которое сформировалось вокруг неё. Для этого можно изучить, насколько часто её упоминают на профильных площадках (Stack Overflow), а также в профильных тредах, например на Reddit. Как вариант — посмотреть популярность проекта на GitHub (количество звезд) и посмотреть, как часто его вписывают в различные подборки инструментов в сети (наподобие таких). Очевидно, чем больше сообщество, тем выше вероятность, что вам помогут в случае возникновения непредвиденных трудностей.
Что касается выбора проприетарных систем логирования, то здесь в первую очередь стоит смотреть на скорость ответов и адекватность службы поддержки выбираемого решения, а также его цену.
Возможность сбора «разнокалиберных» логов
Не все платформы для логирования способны обрабатывать большое количество данных и предоставлять полную информацию об используемых системах.
Перед выбором решения стоит определиться, какие именно логи вы планируете собирать: HTTP-логи (помогут понять поведение пользователей на сайте), API-логи (дадут возможность оценить, какие сервисы чаще всего запрашиваются по API), логи об ошибках и просто записи изменений в системе (укажут на «узкие места», если таковые есть).
Масштабируемость
Инструмент логирования должен собирать логи с каждого системного компонента и предоставлять к ним доступ в одном месте. Если система не приспособлена для масштабирования, качество лог-анализа упадет.
Мы в 1cloud изначально использовали для логирования MS SQL. Однако с ростом числа клиентов и сервисов (например, совсем недавно мы разместили оборудование в минском ЦОД и добавили поддержку IPv6), у нас появились территориально разнесенные компоненты инфраструктуры, у которых не было доступа к БД. А одной из главных наших задач было сохранение возможности анализа логов из единого места.
Система логирования 1cloud
Как мы уже отметили, для хранения логов в 1cloud раньше использовался MS SQL, а для их записи — log4net. И это начало создавать для нас определенные трудности. Из-за территориально разнесенных компонентов, стало невозможно держать сетевую связанность с БД и обеспечивать единую точку для анализа.
При этом большой объем логов и невозможность построить индексы по всем необходимым нам для поиска полям привели к излишнему упрощению лог-анализа — нам приходилось отказываться от функциональности в угоду производительности.
Чтобы решить эту проблему и обеспечить масштабируемость, мы внедрили новую систему логирования. Всего мы изучили больше пятидесяти различных решений и выделили четыре, которые полностью удовлетворяли нашим требованиям:
Logstash
Решение имеет 9,2 тыс. звезд на GitHub. Logstash распространяется по лицензии Apache 2.0 и является частью стека ELK. Имеет большое количество плагинов (на GitHub их насчитывается порядка 250 штук). Работает под Windows и Linux и имеет высокую производительность, практически не зависящую от объемов данных.
Система дает быстро проводить обзор и анализ событий с рабочих станций, файрволов, маршрутизаторов и коммутаторов. Это связано с тем, что нет необходимости в «нормализации» событий.
Однако стоит понимать, что это «голый» движок, потому он не предоставляет готовых визуализаций. Из других недостатков отметим необходимость ставить Java на все серверы, так как Logstash написан на Ruby (JRuby).
У решения довольно обширное сообщество: имеется IRC-канал и отдельный форум. В сети есть примеры по конфигурации всей системы и API. Используют Logstash следующие организации: CERN Control Center, GitHub, SoundCloud.
Fluentd
6,6 тыс. звезд на GitHub. Распространяется по лицензии Apache 2.0 фондом CNCF (Cloud Native Computing Foundation) — он основан компанией Google и The Linux Foundation для продвижения технологий контейнеров.
Fluentd работает под Linux, Windows и Mac и написан на Ruby (CRuby). Fluentd имеет гибкую систему плагинов, которая расширяет его функциональные возможности.
Решение имеет унифицированный формат логирования: полученные данные Fluentd старается привести к формату JSON. Для обеспечения надежности работы не требуются сторонние решения, однако для этого приходится проводить дополнительную настройку. Также не рекомендуется устанавливать его на серверы, генерирующие логи.
Сообщество большое: имеется канал в Slack, а также тред в Google Groups. На официальном сайте проекта есть примеры конфигураций и API. Fluentd используют такие компании, как Microsoft, Amazon, change.org и Nintendo.
Graylog
4,3 тысячи звезд на GitHub. Распространяется по лицензии GNU GPL v3. Работает только под Linux. Централизованная экосистема плагинов и настраиваемая система буферизации. Для удобства позволяет по ключевому слову объединять поступающие сообщения в потоки и группировать эти потоки с разных хостов.
Система использует функции Elasticsearch, но несмотря на частые обновления Graylog и развитое сообщество (есть форум, IRC-канал, на официальном сайте проекта есть примеры конфигураций и API.), интеграция актуальных версий Elasticsearch в проект занимает длительное время. Например, в прошлом году возникла ситуация, когда Graylog 2.2.1 (на то время последний) работал только с Elasticsearch версии 2.4.4, которая считалась устаревшей.
В своей работе Graylog использует Европейское агентство по окружающей среде, компании Dial Once, Stockopedia и др.
LOGalyze
Работает под Linux и Windows. Cистема обладает высокой производительностью и умеет составлять подробные отчеты по ключевым словам. Есть серьезный недостаток — LOGalyze собирает логи в свою файловую БД, где затем их индексирует, занимая значительный объем дискового пространства.
Разработчики LOGalyze ведут свой блог, также обсуждение решения проходит в группах Google. Есть руководство по настройке системы и миграции данных, а также CLI.
Оценив эти четыре варианта, мы остановили свой выбор на Logstash и решили организовать стек ELK (ElasticSearch, Logstash, Kibana). Из них Elasticsearch — это поисковый движок, Logstash представляет собой механизм сбора и анализа логов, а Kibana «занимается» аналитикой и визуализацией данных.
Мы выбрали ELK, так как все три компонента разрабатывает один «производитель», потому они хорошо интегрируются друг с другом. При необходимости мы сможем использовать каждый из этих инструментов в отдельности для решения других задач.
Такой подход делает продукт гибким и универсальным. Все это позволит эффективнее обрабатывать уже существующие объемы данных и быстрее внедрять новые сервисы — их будет легче подключать.
Сейчас готова тестовая среда. Она «покрывает» все сервисы, логи которых мы будем анализировать. Мы заканчиваем последние отладочные процессы и планируем полноценный запуск решения уже в ближайшее время.
Кстати, несмотря на то, что мы подробно анализировали различные варианты и выбрали наилучший для наших нужд, в итоге не обошлось и без ложки дегтя. При тестировании решения мы столкнулись с ситуацией, когда Kibana запросом уронила Elasticsearch — что считается крайне редким и вырожденным случаем. Также при «сборке» системы возник ряд вопросов, связанных в основном с безопасностью. В базовом варианте Elasticsearch ничем не защищен — пришлось приспосабливать для этих целей стороннее ПО.
После запуска мы займемся настройкой систем мониторинга, чтобы максимально оперативно реагировать на сбои в работе лог-сервиса. Мы рассчитываем, что новый стек технологий позволит улучшить пользовательский опыт наших клиентов и в дальнейшем быстрее развивать наши сервисы.