Splunk. Fields extraction

Приветствую, уважаемый читатель!

Рассматривая возможности Splunk, мы совсем не коснулись темы парсинга событий, а конкретно - получения нужных нам полей из события. Данный механизм, на мой взгляд, реализован в Splunk очень круто и позволяет не только извлекать поля из событий, но и группировать их по приложениям. Об этом и поговорим J

В своем первом посте я упоминал, что в Splunk уже запрограммированы типы данных (sourcetype) для наиболее популярных источников событий, но как быть, если мы подключаем не типовой источник событий. Тут нам на помощь приходят возможности Splunk по парсингу событий с использованием регулярных выражений или разделителей (Delimiters).

Для начала подключим к Splunk новый источник событий, я буду экспериментировать с Apache Error log - /var/log/apache2/error.log. Процесс подключения текстового журнала событий я упущу (описан тут - http://unitybas.blogspot.ru/2015/08/splunk.html), тип данных назову  apache_error.

Итак, если подключение прошло успешно, то после запроса ниже вы увидите события из журнала:

sourcetype=apache_error

В колонке «Interesting Fields» вы видите поля, которые Splunk смог распарсить автоматически. Чуть ниже вы увидите ссылку «Extract New Fields», на которую необходимо нажать для извлечения дополнительных полей.

После нажатия на ссылку появится список событий, из которого необходимо выбрать любое понравившееся для парсинга. Выбор события показан на скрине ниже. 

Далее Splunk предлагает нам определиться, как мы будем парсить события в данном sourcetype. Есть 2 варианта, использовать регулярные выражения или различные разделители. Мы рассмотрим и тот и другой, но начнем с регулярных выражений.

После нажатия на Regular Expression выбранное событие отобразится в новом окне. Теперь необходимо указать, какие поля вы хотите достать из события. Для этого выделите мышью часть события и задайте для него новое имя.

Рекомендация: Так как событие разбивается на поля регулярным выражением, то от качества этого самого выражения будет зависеть качество разбора для всех событий. Поэтому, старайтесь выделять в поля те части события, которые легко парсятся регуляркой (например, есть какой-либо символ перед новым полем - пробел и т.д.).

Перейдем от слов к делу, в нашем событии достанем следующие поля (последовательно выделяя части события):

action, pidNum, clientip, port, message.

На скрине ниже вы видите, что Splunk автоматически подсветил в каждом событии поля, которые вы достали. Также вы видите несколько событий, у которых не подсвечено ни одно поле, это означает, что регулярка не сработала для данных событий.

На последней вкладке вы увидите статистическую информацию о новых полях, в т.ч. само регулярное выражение. В терминологии Splunk мы только что создали новое EXTRACTION.

Нажмите на «Finish». Для проверки корректности извлечения новых полей, вбейте в строке поиска:

sourcetype=apache_error | fieldsummary

Все поля, которые вы достали из события, теперь можно использовать в запросах.

Хотел бы немного вернуться назад, и рассказать про второй вариант парсинга события, а именно – использование разделителей. Для этого необходимо выбрать на соответствующей вкладке пункт «Delimiters», и указать какой конкретно разделитель вы хотите использовать.

Splunk предлагает использовать следующие типы разделителей: Space, Comma, Tab, Pipe, Other.

Данный вариант парсинга событий идеально подходит для логов приложений с относительно простой структурой события. Также, например, если вы разрабатываете ПО и можете сами определить формат будущих событий.

Собственно, теперь вы знаете как доставать из событий поля, если по какой-либо причине Splunk не сделал это сам J

Лирические отступления:

Что делать с событиями, для которых поля не определились (т.е. регулярка не сработала)? 

Очень не простой вопрос, и однозначно ответить на него нельзя, т.к. всё зависит от конкретной ситуации. Но могу дать 2 общие рекомендации:

• не использовать эти события в своих запросах, если они не несут ценности (например, отладочная информация приложения);
• после подключения источника событий, индивидуально распарсить поля средствами поисковой строки Splunk (операторы - regex, rex).

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

Сколько полей можно достать из события?

Я на практике не извлекал больше 15 полей, но по идее, можно извлечь и 30 полей.

Влияние сложности регулярного выражения на индексацию событий? 

Я пока не встречал случаев, когда Splunk не индексировал события по причине сложного регулярного выражения, но исключать такую ситуацию нельзя. Часто возникает ситуация, что от сенсора приходит событие с измененной структурой (значение какого-то поля длиннее, добавлен спецсимвол и т.д.), вот тогда начинается проблема, т.к. регулярка не сработала и поля не распарсились. Естественно, на дашбордах, оперирующих именованными полями, вы такие события не увидите, но Splunk всё равно сохранит событие, и его можно будет найти по raw_ тексту. И далее, найдя такое событие, сравните его с любым эталонным и оцените степень критичности новых изменений.