Очень простой пример использования Logstash. В реальной жизни настройки системы будут намного сложнее.

Logstash - это инструмент, который принимает на вход логи в различных форматах, обрабатывает их и отправляет на индексацию Elasticsearch.

Чтобы после установки Logstash провести эксперимент по заливке данных в Elasticsearch, необходимы данные в больших объемах. К счастью, у каждого пользователя Linux есть логи в больших количествах - в директории /var/log/ . Вот их и будем индексировать.

Обработка данных в Logstash организована по принципу конвейера и осуществляется с помощью плагинов. Любая информация проходит последовательно через цепочку плагинов. Конвееры Logstash создаются на основе одного или нескольких файлов конфигурации.

Плагины группируются по своему предназначению:

• input - входные плагины, отвечают за прием данных и отправку их в очередь на обработку;
• filter - фильтры, преобразуют данные, разбивают их на части;
• output - выходные плагины, отвечают за форматирование и доставку данных адресату (не обязательно Elasticsearch).

Logstash поставляется с большим набором плагинов.

Изображение взято отсюда: www.elastic.co/blog/a-practical-introduction-to-logstash

Для обработки нового лога требуется создать новый конфигурационный файл и определить - какие плагины на каком этапе необходимо использовать.

Заготовка конфигурационного файла:

Любая конфигурация Logstash должна определять как минимум один входной плагин и один выходной. Фильтры не являются обязательными.

Конфигурация Logstash для вывода данных в файл

Для обработки я выбрала файл /var/log/vsftpd.log. Неприятной особенностью данного лога является разное содержимое и формат каждой строки:

В директории /etc/logstash/conf.d/ создаем файл test.conf:

Благодаря приведенному конфигу, Logstash прочитает данные из файла /var/log/vsftpd.log, разобьет каждую строку на пары "ключ"/"значение", и запишет получившиеся структуры данных в json-формате, в файл /home/apache/output_logstash.log .

Почему запись сделана не в Elasticsearch, а в простой текстовый файл? Потому, что так удобнее на этапе отладки блока filter. Составить удовлетворяющие шаблоны для парсинга строк лога может получится далеко не сразу. Удалить данные из текстового файла и запустить парсинг заново намного проще, чем почистить Elasticsearch.

Запускаем Logstash:

После этого есть время на то, чтоб приготовить чашечку кофе - Logstash требуется время на запуск.

Открываем файл /home/apache/output_logstash.log:

Останавливаем Logstash:

Конфигурация Logstash для отправки данных в Elasticsearch

Допустим, получившаяся структура данных нас устраивает и ошибок парсинга не случилось. Теперь изменим в конфиге /etc/logstash/conf.d/test.conf блок output:

Запускаем все необходимые сервисы:

Позволяем этим сервисам загрузиться, ждем некоторое время. Запускаем Logstash. После того, как Logstash загрузится, он распарсит данные по уже отлаженному нами шаблону, но запишет результат не в файл, а передаст на индексацию Elasticsearch.

В браузере вводим адрес http://localhost:9999/app/kibana . Переходим на страницу "Management". Далее пункты меню "Kibana" -> "Index Patterns" и нажимаем кнопку "Refresh field list".

Теперь можно попробовать просмотреть результаты работы Logstash. Переходим на страницу "Discover":

Если Kibana пишет, что никаких данных не найдено ("No results match your search criteria"), попробуйте изменить временной интервал, указанный в правом верхнем углу страницы. По умолчанию, Kibana показывает данные, которые были добавлены за последние 15 минут.

Разворачиваем данные для просмотра:

Дополнительные комментарии к конфигурационному файлу Logstash

Конфигурирование блока input

Input-плагин позволяет Logstash прочитать данные из определенного источника. В указанном примере, данные запрашиваются из файла /var/log/vsftpd.log и используется плагин "file".

Деректива start_position, возможные значения: beginning, end (по умолчанию). Определяет, с какой позиции читать данные при обнаружении нового файла, с начала или с конца. Если мы работаем со старыми данными, устанавливаем "beginning". Если в режиме реального времени отслеживаем добавление новых данных в файл - то "end". Директива имеет значение только при самом первом обнаружении файла. При каждом прохождении Logstash начнет сохранять текущую позицию в файле sincedb, и в дальнейшем начинать просмотр именно с нее.

Директива sincedb_path - путь к файлу базы данных sincedb. Logstash использует sincedb для записи информации о текущей позиции читаемого файла. Т.к. при отладке конфига нам требуется многократное прохождение одного и того же файла, предлагаем Logstash писать данные о текущей позиции в /dev/null.

Для пользователя доступен достаточно большой список input-плагинов, вот самые полезные и часто используемые:

• beats - позволяет получать данные, отправленные агентами Elastic Beats;
• file - читает данные из файла;
• rabbitmq - получает данные от RabbitMQ exchange;
• redis - читает данные из Redis;
• sqlite - получает данные из базы данных SQLite;
• syslog - прослушивает порт 514 на предмет появления новых сообщений syslog и анализирует их в соответствии со стандартом RFC3164;
• twitter - читает данные из Twitter Streaming API.

elastic.co: Полный список Input-плагинов для текущей версии Logstash. Там же ссылки на параметры настройки каждого плагина.

Конфигурирование блока fliter

Фильтры выполняют промежуточную обработку данных. Можно использовать условное применение фильтров,
в зависимости от характеристик входящих данных.

Использование фильтра dissect

Фильтр Dissect - это своеобразная операция "split". Отличается тем, что в обычных "split"-функциях - указывается один разделитель, который применяется ко всей строке, а Dissect - задает шаблон строки с разделителями и набором полей. Dissect не использует регулярные выражения, работает быстро. Если текст от строки к строке слишком отличается, возможно, стоит использовать другой фильтр - Grok. Возможно так же комбинированое использование: сначала к строке применяется Dissect, затем Grok.

Директива mapping - содержит список полей "ключ"/"значение", где ключ - это название поля, содержимое которого предлагается разбить на части, а значение - это шаблон, по которому это будет выполняться.

Разбиение строки выполняется слева направо. Выполняется с помощью специальных %{} блоков. Внутри блока указывается имя будущего поля. Все, что находится между блоками %{} - будет являться разделителями.

При разборе строки текст захватывается до первого разделителя - этот захваченный текст сохраняется в первом поле. Операция повторяется для каждой пары "блок %{}"-"разделитель" до тех пор, пока не будет достигнут последний разделитель. Оставшийся текст будет сохранен в последнем поле, заданном с помощью %{}.

Для разбора строки из лога:

использовался следующий шаблон:

Первый разделитель - одиночный пробел, все символы, которые встретятся до первого попавшегося одиночного пробела будут выделены в поле с именем day_name. Следующий разделитель - тройной пробел, все символы, которые будут найдены в промежутке между одиночным пробелом и тройным - будут выделены в отдельное поле под названием "month_name", и так далее. Последним разделителем в данном шаблоне является сочетание символов ": ", весь найденный текст после этого разделителя будет помещен в поле с именем %{msg}. Кстати, после того, как поля выделены и содержат значения, их можно снова пропустить через какой-нибудь фильтр для дополнительной обработки - я так и сделала для поля "type".

Блоки %{} могут содержать специальные префиксы перед именем поля: "?", "+", "&" или суффикс "/num".

• %{} - пустое поле, пропускаем, сохранять не требуется. Формат шаблона требует, чтоб был указан каждый разделитель, но что если в строке встречается переменное значение, которое нельзя указать заранее?
• %{?foo} - именованное поле.
• %{field_name1} %{+field_name1} - "+field_name1" значение этого поля добавляется к значению уже существующего поля "field_name1"
• Модификатор /digits позволяет изменить порядок добавления значения к полю. Например, для текста "1 2 3 go", применим шаблон "%{+a/2} %{+a/1} %{+a/4} %{+a/3}" и получим ключ с именем "a" и значением "2 1 go 3". Если модификатор порядка не использовался, значения будут добавляться в порядке нахождения.
• %{&some_field} - позволяет использовать в качестве имени ключа значение другого поля. Например, для текста "error: some_error, some_description" применим шаблон "error: %{?err}, %{&err}" и получим пару "ключ"/"значение": "some_error" => "some_description".

Самые интересные фильтры Logstash:

• dissect - разбирает текст и превращает его в структуру данных, работает по принципу "split";
• drop - позволяет полностью удалить событие, структуру данных. Может быть полезно для удаления отладочных сообщений;
• grok - разбирает текст и превращает его в структуру данных, работает по принципу регулярных выражений;
• mutate - выполняет преобразования в полях структур данных, позволяет переименовывать поля, удалять, заменять и изменять их.

elastic.co: Полный список Filter-плагинов для текущей версии Logstash

github.com: Список доступных паттернов для grok

Конфигурирование блока output

Output-плагин отправляет обработанные данные в конкретный пункт назначения. Это завершающий этап в конвеере Logstash.

В приведенном примере используется плагин для вывода данных в файл. Директива codec - определяет, в каком формате сохранить данные.

elastic.co: Полный список кодеков для определения формата вывода данных

Список самых полезных доступных Output-плагинов:

• csv - сохраняет данные на диск в формате csv;
• elasticsearch - отправляет данные Elasticsearch;
• email - отправляет письмо на указанный адрес электронной почты;
• file - пишет информацию в файл;
• nagios - отправляет результаты пассивной проверки в Nagios;
• redmine - создает новый тикет с помощью Redmine API.

elastic.co: Полный список Output-плагинов для текущей версии Logstash