SPL для начинающих: поиск и исследование в Splunk

Первоначальный поиск

Простой поиск в Splunk может начинаться так:

index=lab sourcetype=auth earliest=-24h

Выбор диапазона времени (Time Range Picker) может определять время, но явное указание earliest и latest полезно для воспроизведения и документирования. index ограничивает определенное хранилище, а sourcetype описывает структуру источника. Условие поля можно добавить уже в первоначальный поиск:

index=lab sourcetype=auth action=failure earliest=-24h

Когда поле существует во время поиска, указание `field=value` более точно, чем полнотекстовый поиск. Кавычки требуются для значений с пробелами. Wildcards могут быть полезны, но ведущий Wildcard или широкий поиск ухудшают производительность и могут привести к неожиданным результатам.

Pipe и команды отображения

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

index=lab sourcetype=auth earliest=-24h
| fields _time user src_ip action host
| table _time user src_ip action host

`rename` изменяет имена для отображения. `sort` сортирует, а `head` ограничивает результаты. События обычно отображаются от новых к старым, но при построении временной шкалы рекомендуется явно сортировать:

index=lab sourcetype=auth user="student" earliest=-4h
| table _time user src_ip action host
| sort 0 _time

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

eval — создание полей

`eval` вычисляет или создает поле. Можно использовать if, case, lower, coalesce, tonumber и другие функции. Например, создание унифицированного Outcome:

index=lab sourcetype=auth earliest=-24h
| eval outcome=case(action="success", "Success", action="failure", "Failure", true(), "Other")
| table _time user src_ip action outcome

`where` фильтрует с помощью выражения после того, как события были собраны или после создания полей. Первоначальный поиск `action=failure` обычно предпочтительнее для базовой фильтрации. `where` полезен для сравнения полей, числовых условий или полей, созданных в eval.

index=lab sourcetype=auth earliest=-24h
| stats count as attempts by user src_ip
| where attempts >= 5
| sort - attempts

stats — превращаем события в вопрос

`stats` вычисляет агрегации по результатам. Без BY получается одна строка; с BY получается строка для каждой комбинации значений. Распространенные команды включают count, sum, avg, min, max, values и dc — distinct count.

index=lab sourcetype=auth action=failure earliest=-24h
| stats count as failures,
        earliest(_time) as first_seen,
        latest(_time) as last_seen,
        values(src_ip) as src_ips
  by user
| convert ctime(first_seen) ctime(last_seen)
| sort - failures

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

stats против eventstats и streamstats

Начинающие должны освоить stats, прежде чем использовать transaction. `transaction` может быть удобна для группировки, но при больших объемах она дорога и иногда скрывает логику. Часто stats, streamstats или eventstats дают более эффективное и прозрачное решение.

Временные окна и timechart

`timechart` создает временной ряд и группирует по `_time`. Она хорошо подходит для выявления всплесков, тенденций и изменений объема. Например:

index=lab sourcetype=auth action=failure earliest=-24h
| timechart span=30m count by src_ip limit=10

Выберите span в соответствии с вопросом. Слишком маленькое окно создаст шум, а слишком большое скроет всплеск. timechart — это преобразующая команда: результатом является сводная таблица, а не исходные события. Для получения доказательств выполните детализацию до соответствующего диапазона и IP.

Упражнение: отказы и успехи в одном окне

Цель — найти окна, в которых один и тот же пользователь и IP сгенерировали несколько отказов и хотя бы один успех. Следующий запрос использует eval, bin и stats:

index=lab sourcetype=auth earliest=-24h
| eval failed=if(action="failure", 1, 0), success=if(action="success", 1, 0)
| bin _time span=30m
| stats sum(failed) as failures,
        sum(success) as successes,
        earliest(_time) as window_start,
        latest(_time) as window_end
  by _time user src_ip
| where failures >= 5 AND successes >= 1
| sort - failures

Запрос указывает на окно, требующее исследования. Поскольку данные были агрегированы, он не доказывает, что успех произошел после отказов. Используйте результат для детализации по user, src_ip и времени:

index=lab sourcetype=auth user="student" src_ip="203.0.113.25" earliest="08/01/2026:09:00:00" latest="08/01/2026:09:30:00"
| table _time user src_ip action host reason
| sort 0 _time

Проверьте: относится ли успех к тому же хосту или приложению? Является ли исходный адрес VPN? Были ли отказы вызваны старым паролем в сервисе? Есть ли дальнейшая активность? SPL предоставляет данные; классификация требует контекста.

Поля, извлечение и CIM

Splunk извлекает поля во время индексации или поиска. Отсутствующее поле может потребовать `rex`, `spath` для JSON или определения Field extraction. Временное извлечение может помочь в лаборатории, но обнаружение в production должно иметь поддерживаемый Parser и Data model.

CIM нормализует концепции между источниками, например Authentication.user или Network_Traffic.src. Когда организация использует CIM, можно создавать обнаружения и панели мониторинга, которые можно использовать с несколькими продуктами. Необходимо убедиться, что данные действительно соответствуют модели, а не просто установлено приложение.

Повышение производительности и читабельности

• Установите максимально узкий временной диапазон.
• Начинайте с index, sourcetype и сопоставленных полей.
• Фильтруйте рано, до stats или sort.
• Избегайте ведущего Wildcard и широкого текстового поиска, когда существует поле.
• Используйте fields для уменьшения полезной нагрузки, но не до команды, которой требуется поле.
• Ограничьте values/list и операции с большим объемом памяти.
• Давайте полям четкие имена с помощью `as`.
• Сохраняйте запрос с описанием, владельцем, временем и версией.
• Проверяйте на небольшой выборке, прежде чем использовать длинный диапазон.

Распространенные ошибки

• Искать по всем индексам без необходимости.
• Предполагать, что поле action или user существует для каждого sourcetype.
• Использовать table рано и удалять поле, которое потребуется позже.
• Интерпретировать stats как точную временную шкалу.
• Использовать transaction по умолчанию.
• Включать оповещение на запрос, не проверенный по базовой линии.
• Копировать SPL из другой версии или модели данных без адаптации.
• Игнорировать часовой пояс и задержку при приеме.

Чек-лист для практики

1. Найдите index и sourcetype лабораторных данных.
2. Отобразите пять событий и проверьте поля.
3. Отфильтруйте одного пользователя или IP.
4. Отобразите временную шкалу с помощью table и sort.
5. Суммируйте отказы с помощью stats.
6. Создайте поле с помощью eval и отфильтруйте его в where.
7. Отобразите объем за определенный период времени с помощью timechart.
8. Напишите, что доказывает и что не доказывает каждый запрос.

Заключение и призыв к действию

Создайте небольшой лабораторный индекс или используйте авторизованные данные и запустите тот же сценарий в трех представлениях: Raw events, stats и timechart. Напишите рядом с каждым представлением, на какой вопрос оно отвечает и какой контекст отсутствует. Следующий шаг — превратить стабильный поиск в обнаружение с владельцем, порогом и Playbook — не просто сохранять впечатляющий запрос.

Вопросы и ответы