Disclaimer: Этот пост ни как не связан ни с компанией Splunk, ни c моим работодателем. Все это мое личное мнение о продукте на основе свободной информации с сайта Splunk и посещения открытой бесплатной конференции SplunkLive 2012.

Грамотные логи – это практически все, ну или почти все. Если логирование сделано по уму, то и разработчикам будет легче, а службе поддержки еще легче.

“Ну а теперь – два слова о себе!”. Мы делаем банковский софт, серверная часть которого – это долгоиграющие неинтерактивные процессы. Логи (и иногда coredump’ы) – это единственный способ их мониторить. С некоторого времени мы используем Google Log в качестве механизма ведения логов с некоторой небольшой самодельной прослойкой сверху для интерфейса к C и прикладному уровню (у нас собственный язык для написания бизнес логики, типа как у 1C).

Итак, логи ведутся. Прикладной уровень тоже все больше и больше служебной информации пишет в них, что отлично. Более того, логи в виде текстовых файлов – это удобно (даже на Windows, и не говорите мне про недоразумение, называемое Windows Events).

Но вот удобства заканчиваются, и начинаются проблемы. Для начала, при многосерверной распределенной системе, чтобы централизировано анализировать логи, их надо выуживать с разных машин. Кроме того, разные подсистемы в силу разных, часто исторических причин, пишут информацию в совершенно разных форматах. И как прикажете их анализировать? хардкодить? Изобретать всякие rule engine’ы? А клиенты (читай, банки), хотят красивые, удобные и наглядные dashboard’ы, конфигурируемые системы оповещения, триггеры, интеграцию с другими продуктами, возможность горизонтально расширятся (не знаю, как по-русски сказать “to scale horizontally”) и т.д. Как я уже говорил, мы делаем банковский софт, делаем его хорошо, и совершенно не хотим тратить силы на побочные продукты, связанные с инфраструктурой. Было несколько попыток создать собственную систему мониторинга, но, увы, для банков уровня Tier 1 – это не та задача, которая может быть решена одним пальцем левой ноги. Вывод: нужно хорошее third-party решение, причем которое будет работать одинаково на UNIX’ах и Windows.

Надеюсь я достаточно нагнал страху. К делу.

Был обнаружен продукт, называемый Splunk. Удивительно, но суть этого продукта можно описать одним абзацем. А если вообще одним предложением, то это развитая система анализа неформатных текстовых данных, чем логи и являются. Входными данными являются произвольные текстовые данные, разбитые на строки. Способы их доставки в Splunk весьма гибкие. Самое простое – установить на сервера агент Splunk, указать ему каталоги или конкретные файлы, которые надо мониторить, и он будет автоматически отсылать обновления на центральный сервер. Можно самостоятельно доставлять логи на сервер Splunk, например, посылая их туда через по HTTP, TCP, UDP. Еще Splunk умеет брать данные из Windows (Logs, Events, Performance Counters). В общем, путей много. Мы остановились на агентах.

Итак, сервер Splunk постоянно получает актуальные обновления. Он как-то их сам хранит и индексирует. Есть возможность развернуть кластер Splunk-машин, и они будут распределено использоваться для хранения данных и поиска.

Но самое интересное начинается дальше. У Splunk есть специальный язык запросов, предназначенный для анализа неструктурированной текстовой информации. Основной принцип – это разнообразные фильтры, применяемые построчно к указанному куску данных, и результаты данных можно через pipe (|) как в unix’е “нанизывать” один на другой.

Например:

sourcetype=access_* | redup by user_id | transaction by tran_id | sort by duration desc | head 10

Берем файлы, начинающиеся с access_, затем “сжимаем” повторяющиеся записи по критерию повторяющегося значения поля user_id, затем группирует записи по полю tran_id (фактически логически “сжимаем” строки с одинаковыми значениям поля tran_id в транзакции), затем сортируем по длительности (поле duration автоматически добавляется фильтром transaction) и отбираем первые десять сверху. Итак, в итоге мне имеем десять самых длинных транзакций от уникальных пользователей. А всего то, написали один запрос.

Откуда берутся так называемые поля? Поля вычленяются из строк данных. По умолчанию разделителем полей является пробел, для разделения имени поля и значения является “равно”. Но все это, конечно, конфигурируемо. Фактически, любой формат, который можно разобрать программно, можно настроить. Специальными фильтрами можно создавать вычисляемые поля, причем ссылать можно не только на данных из текущей строки, но и на другие строки, отобранные по какому-то критерию. Все очень похоже на SQL, только источником данных являются не таблицы в базе данных, а тестовые строки. На выходе – табличные данные, которые можно трансформировать в новые таблицы (точнее, представления, view) и т.д. Результат можно оформить в виде красивой таблички или графической диаграммы. Да, чуть не забыл. Можно делать подстановки полей на основе запросов во внешние источники, например, RDBMS или RESTful-сервис. Все налету.

После того, как запрос отлажен, его можно запомнить и добавить в dashboard. Настроенный dashboard можно оформить в виде так называемого приложения (фактически, это набор xml-файлов) и, например, передать клиенту. На сайте Splunk’а есть даже магазин приложений (хотя большинство из них бесплатны). Можно, например, взять готовое приложение для анализа логов Microsoft Exchange’а, воткнуть и начать сразу получать удовольствие.

Путей для визуализации результатов поиска много: таблицы, графики, выгрузка во внешние источники, даже интеграция с Google Maps. Я видел живое демо, где человек из логов веб сервера вытащил информацию о положении пользователей, отсортировал и отфильтровал по вкусу, и в конце представил в виде Google Maps виджета, где было видно, откуда были запросы. И все это через несложные Splunk-запросы. Тот пример, что привел я – это микрочастичка того, что можно сделать запросами. Вкратце можно ознакомится со списком команд, так, чтобы понимать примерно возможности.

По-хорошему, имея Splunk и логи веб сервера, такие вещи как Google Analytics могут больше не понадобится. Splunk говорит, что многие их большие клиенты, кто работает c веб, так и делает, так как можно автоматически привязывать аналитику к любым внутренними данным, идущих от разных источников.

Если так задуматься, то если использовать Splunk, то логирование само по себе упрощается. Например, не надо придумывать, как именовать логи. Системе логирования достаточно использовать время в имени и порядковый номер, если лог был обрезан по длине. Но все это только ради уникальности файла в файловой системе. После “скормления” файла в Splunk имя будет уже не важно. Далее, можно не париться в вычислении длительности событий (это бывает удобно для профилирования). Это можно сделать через вычисляемые поля в запросе.

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

Идем далее. Как можно продукт попробовать? Бесплатно скачать с официального сайта (требуется свободная регистрация). У Splunk следующая ценовая политика: цена продукта определяется только объемом данных, прогоняемых через систему в день. Если ниже какого-то минимального порога, то можно использовать бесплатно.

У меня время от скачивания дистрибутива под Windows, установкой, подсосом локальных логов с той же машины (пока без агентов) и началом игры с запросами по ним было около получаса.