splunk 7

Джеймс Д. Миллер Внедрение Splunk 7 James D. Miller Implementing Splunk 7 Third Edition Effective operational intelligence to transform machine-generated data into valuable business insightr BIRMINGHAM – MUMBAI Джеймс Д. Миллер Внедрение Splunk 7 Третье издание Эффективный операционный анализ для преобразования машинных данных в ценную бизнес-информацию Москва, 2019 УДК 004.056.5 ББК 32.973 М60 Миллер Дж. Д. М60 Внедрение Splunk 7 / пер. с анг. А. Н. Киселева. – М.: ДМК Пресс, 2019. – 490 с.: ил. ISBN 978-5-97060-698-8 Среди систем, созданных для агрегации, систематизации и прочей автоматизации работы с логами, Splunk – один из самых мощных. Он позволит следить за тонкостями жизни всех ваших систем, особенно если их много и они достаточно распределенные. Splunk – ведущая платформа, реализующая эффективные методологии поиска, мониторинга и анализа больших данных с постоянно растущим объемом. Эта книга позволит вам реализовать новые услуги и использовать их для быстрой и эффективной обработки машинных данных. Вы познакомитесь со всеми возможностями и улучшениями в Splunk 7, включая новые модули Splunk Cloud и Machine Learning Toolkit, научитесь эффективно использовать поисковые запросы и метасимволы, а также работать с полями и расширениями диаграмм. Издание будет полезно всем, кто занимается информационной безопасностью в организации и выявлением инцидентов ИБ. УДК 004.056.5 ББК 32.973 Authorized Russian translation of the English edition of Implementing Splunk 7, Third Edition ISBN 9781788836289 © 2018 Packt Publishing. This translation is published and sold by permission of Packt Publishing, which owns or controls all rights to publish and sell the same. Все права защищены. Любая часть этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. ISBN 978-1-78883-628-9 (анг.) ISBN 978-5-97060-698-8 (рус.) © 2018 Packt Publishing © Оформление, издание, перевод, ДМК Пресс, 2019 Содержание Участники ...................................................................................................................... 13 Вступление ................................................................................................................... 14 Глава 1. Интерфейс Splunk ................................................................................ 18 Логирование в Splunk ......................................................................................................... 18 Домашнее приложение ...................................................................................................... 19 Верхняя полоса меню ......................................................................................................... 23 Приложение Search & Reporting ........................................................................................ 27 Генератор данных .......................................................................................................... 28 Представление Summary................................................................................................ 28 Поиск ............................................................................................................................... 30 Действия ......................................................................................................................... 31 Шкала времени ............................................................................................................... 32 Виджет выбора полей .................................................................................................... 33 Результаты поиска ......................................................................................................... 35 Использование виджета выбора времени ........................................................................ 38 Использование виджета выбора полей ............................................................................. 39 Раздел с настройками......................................................................................................... 40 Splunk Cloud ........................................................................................................................ 44 Опробование перед покупкой ........................................................................................... 45 Краткий тур по облаку........................................................................................................ 46 Полоса меню в Splunk Cloud .............................................................................................. 48 Splunk reference App – PAS ................................................................................................. 50 Universal forwarder .............................................................................................................. 50 eventgen ............................................................................................................................... 50 Что дальше .......................................................................................................................... 50 Итоги ................................................................................................................................... 51 Глава 2. Основы поиска ........................................................................................ 52 Эффективное использование критериев поиска ............................................................. 52 Логические операторы и операторы группировки .......................................................... 53 Щелчки мышью могут менять критерии поиска ............................................................. 55 Сегментирование событий ............................................................................................ 55 Виджеты полей ............................................................................................................... 55 Время .............................................................................................................................. 57 Использование полей в поиске.......................................................................................... 58 Использование виджета выбора полей ........................................................................ 58 Эффективное использование метасимволов ................................................................... 59 Метасимволы в полях .................................................................................................... 60 6  Содержание Все о времени ...................................................................................................................... 60 Как Splunk анализирует время ...................................................................................... 60 Как Splunk хранит время ............................................................................................... 61 Как Splunk отображает время ........................................................................................ 61 Как определяются часовые пояса, и почему это важно............................................... 61 Разные способы поиска по времени ............................................................................. 62 Определение времени в строке запроса ...................................................................... 66 Ускорение поиска ............................................................................................................... 67 Передача результатов другим ............................................................................................ 68 Адрес URL ....................................................................................................................... 68 Сохранение в виде отчета ............................................................................................. 69 Сохранение в виде дашборда ........................................................................................ 71 Сохранение в виде оповещения.................................................................................... 72 Сохранение в виде типа события .................................................................................. 73 Настройки задания поиска ................................................................................................ 73 Сохранение поиска для повторного использования ....................................................... 74 Создание оповещения на основе поиска .......................................................................... 77 Enable Actions ................................................................................................................. 79 Action Options ................................................................................................................. 79 Sharing ............................................................................................................................. 79 Аннотирование событий .................................................................................................... 81 Иллюстрация .................................................................................................................. 82 Итоги ................................................................................................................................... 83 Глава 3. Таблицы, диаграммы и поля........................................................... 84 О символе вертикальной черты......................................................................................... 84 Вывод типичных значений полей командой top ............................................................. 85 Управление выводом команды top ............................................................................... 87 Агрегирование значений с помощью команды stats ....................................................... 88 Представление данных с помощью команды chart ......................................................... 91 Отображение шкалы времени с помощью timechart ....................................................... 93 Параметры команды timechart ..................................................................................... 95 Работа с полями .................................................................................................................. 96 Пример регулярного выражения .................................................................................. 97 Команды создания полей .............................................................................................. 99 Извлечение уровня журналирования ......................................................................... 100 Расширение поддержки диаграмм в версии 7.0 ............................................................. 110 charting.lineWidth ......................................................................................................... 111 charting.data.fieldHideList ............................................................................................ 112 charting.legend.mode .................................................................................................... 113 charting.fieldDashStyles ................................................................................................ 113 charting.axisY.abbreviation ........................................................................................... 114 Итоги ................................................................................................................................. 114 Глава 4. Модели данных и сводные таблицы ...................................... 115 Что такое модель данных? ............................................................................................... 115 Роль моделей данных в поиске ........................................................................................ 116 Содержание  7 Объекты модели данных ............................................................................................. 116 Acceleration в версии 7.0 ................................................................................................... 117 Создание модели данных ................................................................................................. 118 Заполнение полей в диалоге создания новой модели данных ................................. 119 Добавление полей (атрибутов) ................................................................................... 122 Подстановочные атрибуты .............................................................................................. 125 Потомки ........................................................................................................................ 127 Что такое сводная таблица? ............................................................................................. 129 Редактор Pivot Editor .................................................................................................... 131 Работа с элементами сводных таблиц ........................................................................ 132 Разбиение (на строки или столбцы) ........................................................................... 133 Форматирование сводной таблицы ............................................................................ 134 Короткий пример.............................................................................................................. 134 Sparklines ........................................................................................................................... 138 Итоги ................................................................................................................................. 140 Глава 5. Простые дашборды на XML.......................................................... 141 Назначение дашбордов .................................................................................................... 141 Конструирование дашбордов с помощью мастеров ...................................................... 142 Добавление еще одной панели ................................................................................... 145 Преобразование панели в отчет ...................................................................................... 152 Дополнительные настройки ........................................................................................ 157 И снова о дашборде .......................................................................................................... 157 Добавление полей ввода .............................................................................................. 157 Редактирование исходного кода ................................................................................. 158 Редактирование пользовательского интерфейса ...................................................... 158 Непосредственное редактирование XML........................................................................ 158 Приложение с примерами пользовательского интерфейса .......................................... 159 Создание форм ................................................................................................................. 159 Создание формы из дашборда .................................................................................... 159 Управление несколькими панелями из одной формы .............................................. 163 Постобработка результатов поиска ............................................................................ 165 Ограничения постобработки....................................................................................... 165 Устаревшие функции ........................................................................................................ 166 Автоматический запуск дашборда .................................................................................. 168 Выполнение запросов по расписанию ............................................................................ 169 Итоги ................................................................................................................................. 170 Глава 6. Примеры продвинутого поиска ................................................. 171 Использование подзапросов для поиска дополнительных событий ............................ 171 Подзапрос ..................................................................................................................... 171 Ограничения подзапросов .......................................................................................... 173 Вложенные подзапросы ............................................................................................... 174 Использование транзакций ............................................................................................. 175 Определение продолжительности сеанса .................................................................. 175 Получение агрегированных статистических показателей........................................ 177 Подзапросы в транзакциях.......................................................................................... 178 8  Содержание Команда concurrency ........................................................................................................ 182 Использование команд transaction и concurrency ..................................................... 182 Использование команды concurrency для оценки нагрузки на сервер ................................................................................... 183 Определение уровня concurrency с использованием предложения by .................... 184 Подсчет событий в интервалах времени ........................................................................ 190 С помощью timechart ................................................................................................... 190 Вычисление среднего числа запросов в минуту ........................................................ 191 Вычисление среднего числа событий в минуту за каждый час ................................ 193 Имитация команды top .................................................................................................... 195 Ускорение .......................................................................................................................... 201 Большие данные – стратегия получения сводной информации .............................. 202 Ускорение отчетов ....................................................................................................... 202 Доступность ускорения отчетов.................................................................................. 205 Расширенная поддержка метрик в версии 7.0................................................................ 205 Определение метрик в Splunk ..................................................................................... 205 Использование метрик в Splunk ................................................................................. 206 Итоги ................................................................................................................................. 207 Глава 7. Расширенный поиск ........................................................................... 208 Использование тегов для упрощения поиска ................................................................. 208 Классификация результатов по типам событий (eventtypes) ........................................ 212 Использование lookups для обогащения данных ........................................................... 216 Определение файла с lookup-таблицей ..................................................................... 216 Настройка определений lookup .................................................................................. 218 Определение автоматического Lookup ...................................................................... 220 Проблемы с lookups...................................................................................................... 223 Применение макросов ..................................................................................................... 224 Создание простого макроса ........................................................................................ 224 Создание макроса с аргументами ............................................................................... 225 Создание сценариев реагирования ................................................................................. 226 Запуск нового поиска с использованием значения из события ............................... 226 Ссылки на внешние сайты........................................................................................... 229 Создание сценария реагирования для отображения контекста поля ................................................................................ 231 Использование внешних команд .................................................................................... 236 Извлечение значений из XML ..................................................................................... 236 Генерирование результатов с помощью Google ........................................................ 238 Итоги ................................................................................................................................. 239 Глава 8. Работа с приложениями ................................................................. 240 Определение приложения ............................................................................................... 240 Встроенные приложения ................................................................................................. 241 Установка приложений .................................................................................................... 242 Установка приложений из Splunkbase ........................................................................ 243 Установка приложений из файлов .............................................................................. 247 Наше первое приложение ................................................................................................ 247 Содержание  9 Настройка навигации ....................................................................................................... 251 Настройка внешнего вида приложения .......................................................................... 253 Настройка значка запуска ........................................................................................... 253 Использование своих стилей оформления CSS ......................................................... 254 Использование своей разметки HTML ....................................................................... 254 Разрешения доступа к объектам ..................................................................................... 258 Как разрешения влияют на навигацию ...................................................................... 259 Как разрешения влияют на другие объекты .............................................................. 259 Исправление проблем с разрешениями ..................................................................... 260 Структура каталога приложения ..................................................................................... 261 Добавление приложения в Splunkbase ....................................................................... 263 Упаковка приложения.................................................................................................. 265 Выгрузка приложения.................................................................................................. 265 Самостоятельное управление приложениями ............................................................... 266 Итоги ................................................................................................................................. 267 Глава 9. Создание продвинутых дашбордов ....................................... 268 Причины использования продвинутого XML ................................................................. 268 Причины отказаться от использования продвинутого XML ......................................... 269 Процесс разработки .......................................................................................................... 269 Структура продвинутого XML .......................................................................................... 270 Преобразование упрощенного XML в продвинутый ..................................................... 272 Логика модулей................................................................................................................. 277 Знакомство с layoutPanel ................................................................................................. 279 Размещение панелей ................................................................................................... 280 Повторное использование запроса ................................................................................. 281 Использование intentions ................................................................................................ 282 stringreplace .................................................................................................................. 282 addterm.......................................................................................................................... 283 Создание нестандартных детализаций .......................................................................... 284 Определение детализации в своем запросе............................................................... 284 Создание детализации в отдельной панели............................................................... 286 Применение HiddenPostProcess для создания детализаций с несколькими панелями ...................................................................................................................... 288 Сторонние расширения.................................................................................................... 291 Google Maps .................................................................................................................. 291 Sideview Utils ................................................................................................................. 293 Модуль search в Sideview .............................................................................................. 294 Итоги ................................................................................................................................. 302 Глава 10. Summary-индексы и файлы CSV ............................................ 303 Общие сведения о summary-индексах ............................................................................ 303 Создание summary-индекса ........................................................................................ 304 Когда следует использовать summary-индексы ............................................................. 305 Когда не следует использовать summary-индексы......................................................... 306 Заполнение summary-индексов через saved search ....................................................... 307 Использование summary-индексов в запросах .............................................................. 308 10  Содержание Использование sistats, sitop и sitimechart ....................................................................... 310 Как задержка влияет на запросы, использующие summary-индексы .......................... 313 Как и когда добавлять исторические данные в summary-индексы .............................. 315 Использование fill_summary_index.py для заполнения ............................................. 315 Создание нестандартных summary-индексов с помощью collect ............................ 316 Уменьшение размера summary-индекса......................................................................... 319 Определение полей для группировки с помощью eval и rex .................................... 320 Подстановка с метасимволами ................................................................................... 322 Группировка результатов по типам событий ................................................................. 325 Подсчет наиболее часто встречающихся данных в больших интервалах времени ..... 327 Поиск в summary-индексе ........................................................................................... 331 Использование файлов CSV для хранения промежуточных данных............................ 332 Предварительное заполнение раскрывающегося списка ......................................... 332 Создание вычислений, выполняющихся в течение дня ............................................ 333 Итоги ................................................................................................................................. 334 Глава 11. Настройка Splunk.............................................................................. 335 Местоположение конфигурационных файлов Splunk ................................................... 335 Структура конфигурационных файлов Splunk ............................................................... 336 Логика слияния конфигураций ....................................................................................... 337 Порядок слияния .......................................................................................................... 337 Логика слияния конфигураций ................................................................................... 339 Инструмент btool.......................................................................................................... 344 Обзор конфигурационных файлов Splunk ...................................................................... 345 props.conf ...................................................................................................................... 345 inputs.conf ..................................................................................................................... 352 transforms.conf .............................................................................................................. 361 fields.conf....................................................................................................................... 371 outputs.conf ................................................................................................................... 372 indexes.conf ................................................................................................................... 372 authorize.conf ................................................................................................................ 374 savedsearches.conf......................................................................................................... 375 times.conf ...................................................................................................................... 375 commands.conf .............................................................................................................. 375 web.conf ......................................................................................................................... 375 Ресурсы пользовательского интерфейса ........................................................................ 375 Представления и навигация ........................................................................................ 376 Ресурсы сервера приложений ..................................................................................... 376 Метаданные .................................................................................................................. 377 Итоги ................................................................................................................................. 379 Глава 12. Продвинутая настройка ............................................................... 380 Планирование архитектуры системы ............................................................................. 380 Типы серверов Splunk....................................................................................................... 381 Форвардеры Splunk ...................................................................................................... 381 Индексеры Splunk ........................................................................................................ 382 Поиск в Splunk .............................................................................................................. 383 Содержание  11 Типичные источники данных .......................................................................................... 383 Мониторинг файлов журналов на сервере ................................................................. 384 Мониторинг файлов журналов на общих дисках (file share)..................................... 385 Периодическая (Batch) обработка файлов журналов ................................................ 386 Прием событий от syslog ............................................................................................. 387 Извлечение событий из базы данных......................................................................... 391 Использование скриптов для сбора данных .............................................................. 392 Организация индексирования ........................................................................................ 393 Планирование отказоустойчивости ................................................................................ 395 Коэффициент репликации .......................................................................................... 396 Балансировка нагрузки на индексеры........................................................................ 397 Основные последствия остановки индексеров.......................................................... 398 Работа с несколькими индексами ................................................................................... 399 Структура каталогов индекса ...................................................................................... 400 Когда следует создавать дополнительные индексы .................................................. 400 Жизненный цикл корзины (bucket) ............................................................................ 402 Определение размера индекса.................................................................................... 404 Использование томов для управления индексами.................................................... 404 Развертывание серверов Splunk ...................................................................................... 406 Развертывание из файла tar ........................................................................................ 407 Развертывание из дистрибутива msiexec ................................................................... 407 Добавление базовой конфигурации ........................................................................... 408 Настройка запуска Splunk на этапе загрузки операционной системы .................... 408 Использование приложений для организации конфигурации ..................................... 409 Распределение конфигураций по целям .................................................................... 409 Установка конфигурации ................................................................................................. 413 Использование собственной системы развертывания ............................................. 413 Использование Splunk Deployment Server ................................................................. 414 Использование LDAP для аутентификации .................................................................... 420 Использование единой точки входа................................................................................ 420 Балансировщики нагрузки и Splunk ............................................................................... 421 Веб-серверы .................................................................................................................. 421 splunktcp ....................................................................................................................... 422 Сервер развертывания ................................................................................................. 422 Несколько Search Head ..................................................................................................... 422 Итоги ................................................................................................................................. 423 Глава 13. Расширение Splunk ......................................................................... 424 Разработка скриптов ввода для сбора данных ............................................................... 424 Прием данных без дат.................................................................................................. 424 Прием данных, представляющих единственное событие ........................................ 427 Прием данных от скриптов, выполняющихся продолжительное время ................. 429 Использование Splunk из командной строки ................................................................. 430 Отправка запросов в Splunk через REST-интерфейс...................................................... 431 Реализация своих команд поиска ................................................................................... 434 Когда не стоит писать свои команды.......................................................................... 434 Когда стоит писать свои команды .............................................................................. 435 12  Содержание Конфигурирование команд ......................................................................................... 436 Добавление полей ........................................................................................................ 437 Манипулирование данными ....................................................................................... 438 Преобразование данных .............................................................................................. 439 Генерирование данных ................................................................................................ 444 Реализация скриптов для обогащения данных .............................................................. 445 Реализация визуализаторов событий ............................................................................. 448 Визуализация определенных полей ........................................................................... 448 Таблица полей на основе их значений ....................................................................... 450 Форматированный вывод XML ................................................................................... 453 Реализация скриптов для обработки уведомлений (alert) ............................................ 454 Hunk ................................................................................................................................... 457 Итоги ................................................................................................................................. 458 Глава 14. Machine Learning Toolkit .............................................................. 459 Что такое машинное обучение?....................................................................................... 459 Механизмы рекомендаций по содержимому ............................................................ 460 Обработка естественного языка ................................................................................. 460 Оперативные исследования ........................................................................................ 461 Обзор инструментария .................................................................................................... 461 Время, потраченное не зря .......................................................................................... 462 Получение приложения ............................................................................................... 463 Рабочее пространство ...................................................................................................... 465 Ассистенты ........................................................................................................................ 467 Расширенный язык запросов SPL.................................................................................... 468 Приложение ML-SPL Performance ............................................................................... 468 Создание модели .............................................................................................................. 469 Прогнозирование временных рядов .......................................................................... 469 Использование Splunk ................................................................................................. 470 Запуск приложения ...................................................................................................... 470 Проверка ........................................................................................................................... 475 Эксплуатация................................................................................................................ 476 Сохранение в виде отчета ........................................................................................... 476 Исследование данных .................................................................................................. 477 Итоги ................................................................................................................................. 478 Участники Об автОре Джеймс Д. Миллер (James D. Miller) – эксперт, сертифицированный в IBM, творческий новатор, директор, руководитель проектов и архитектор систем и приложений с более чем 35-летним опытом применения, проектирования и разработки. Помогает клиентам внедрять новые и иногда революционные технологии и платформы, интеграцию с IBM Watson Analytics, Cognos BI, TM1, веб-архитектуры, системный анализ, проектирование и тестирование графических интерфейсов и моделирование баз данных. Занимался проектированием и разработкой OLAP, клиент-серверных и веб-приложений, а также приложений для больших вычислительных систем. Хочу поблагодарить Нанетт (Nanette), Шелби (Shelby) и Пейдж (Paige), которые не перестают удивлять меня своей поддержкой и любовью. О рецензентах Кайл Смит (Kyle Smith) – истинный энтузиаст из Пенсильвании, активно использующий Splunk с 2010 года. Много раз выступал на конференции Splunk User Conference, активный участник сообщества Splunk Answers Community, IRC-канала #splunk и каналов Splunk Slack. Опубликовал несколько приложений для Splunk и расширений для Splunkbase, главного приложения сообщества Splunk, а также дополнений к платформе публикации. В настоящее время работает консультантом/разработчиком в компании Aplura, LLC. Написал книгу «Splunk Developer’s Guide», также выпущенную издательством Packt. Хочу сказать спасибо моей супруге, которая терпеливо мирилась с моей занятостью, когда я работал над этой книгой. Без нее все это было бы бессмысленным. Йогеш Рахея (Yogesh Raheja) – сертифицированный эксперт в области DevOps и облачных технологий с десятилетним опытом. Имеет опыт в таких областях, как администрирование операционных систем, управление исходным кодом, сборка и выпуск инструментов, использование средств непрерывной интеграции/развертывания/доставки, настройка контейнеров, использование инструментов управления конфигурациями, мониторинг, применение инструментов журналирования и организация общедоступных и частных облачных окружений. С радостью делится своим опытом с другими на различных форумах, конференциях, вебинарах, блогах и в LinkedIn (https://in.linkedin.com/ in/yogesh-raheja-b7503714). Написал книги «Automation with Puppet 5» и «Automation with Ansible». Вступление Splunk – ведущая платформа, предлагающая эффективные методы поиска, мониторинга и анализа растущих объемов данных. Эта книга поможет вам внедрить новые службы и использовать их для быстрой и эффективной обработки машинных данных. Мы познакомим вас со всеми новыми особенностями, улучшениями и предложениями в Splunk 7. Рассмотрим новые модули Splunk – Splunk Cloud и Machine Learning Toolkit – упрощающие применение данных. Кроме того, вы узнаете, как эффективно использовать поиск с логическими операторами и операторами группировки. Вы не только узнаете об оптимизации скорости поиска, но и познакомитесь с приемами эффективного использования шаблонных символов. Далее вы увидите, как использовать статистические и агрегированные значения, строить диаграммы данных и временные диаграммы для отображения изменения значений с течением времени; вы также научитесь работать с полями и Chart Enhancements и узнаете, как создать модель данных с Faster Data Model Acceleration. После этого мы перейдем к знакомству с XMLпанелями, работе с приложениями, созданию продвинутых панелей, настройке и расширению Splunk и многим другим возможностям. Наконец, мы научим вас пользоваться инструментами машинного обучения Machine Learning Toolkit и дадим несколько советов и рекомендаций, которые помогут вам быстро и эффективно внедрить Splunk. К концу этой книги вы будете иметь полное представление о программном обеспечении Splunk и уметь интегрировать Splunk в свои задачи и проекты. КОму адресОвана эта Книга Эта книга предназначена для аналитиков данных, бизнес-аналитиков и ИТадминистраторов, желающих поднять на новый уровень умение работы с большими данными, операционный анализ, управление журналами и мониторинг систем в своей организации. Обладание некоторыми знаниями Splunk поможет вам получить максимум выгоды от этой книги. О чем рассКазывается в Книге Глава 1 «Интерфейс Splunk» познакомит вас с основными элементами интерфейса Splunk. Глава 2 «Основы поиска» знакомит с техническими деталями работы механизма поиска, чтобы вы могли эффективнее выполнять поиск и создавать отчеты. Что необходимо, чтобы извлечь максимум пользы из книги  15 Глава 3 «Таблицы, диаграммы и поля» расскажет, как использовать поля не только для поиска; здесь вы будете учиться строить таблицы и графики. А затем узнаете, как создавать свои поля. Глава 4 «Модели данных и сводные таблицы (Pivot)» охватывает модели данных и сводные таблицы, редактор сводных таблиц, элементы и фильтры сводных таблиц и встраиваемые графики. Глава 5 «Дашборды на упрощенном XML» демонстрирует дашборды на упрощенном XML; их назначение; создание с помощью мастера, планирование создания и редактирование разметки XML непосредственно; конструирование форм. Глава 6 «Примеры продвинутого поиска» демонстрирует интересные примеры улучшения поиска. Здесь мы раскроем некоторые по-настоящему мощные возможности языка поиска и рассмотрим несколько трюков, которые я накопил за годы работы. Глава 7 «Расширенный поиск» демонстрирует еще более мощные возможности Splunk для расширения языка поиска и пополнения данных во время поиска. Глава 8 «Работа с приложениями» описывает структуру приложений для Splunk, а также рассказывает о последней версии механизма Self-Service App Management (первоначально появившегося в Splunk 6.6), обновленной в версии 7.0. Глава 9 «Создание продвинутых дашбордов» охватывает методы вложения модулей, атрибут layoutPanel, intention и альтернативу intentions – SideView Utils. Глава 10 «Summary-индексы и файлы CSV» исследует использование summary-индексов и команд для работы с ними. Глава 11 «Настройка Splunk» знакомит с приемами настройки и описывает наиболее широко используемые аспекты конфигурации Splunk. Глава 12 «Продвинутая настройка» погружается в особенности развертывания в распределенной среде и показывает, как эффективно настроить такое развертывание. Глава 13 «Расширение Splunk» демонстрирует множество способов расширения Splunk новыми средствами ввода, управления и вывода событий. Глава 14 «Инструменты машинного обучения» знакомит с основами инструментов Machine Learning Toolkit в Splunk и показывает, как с их помощью создать модель машинного обучения. чтО неОбхОдимО, чтОбы извлечь маКсимум пОльзы из Книги Прежде чем начать читать эту книгу, вам нужно загрузить Splunk с сайта https:// www.splunk.com/ru_ru/download.html. Официальное руководство по установке можно найти по адресу: http://docs. splunk.com/Documentation/Splunk/latest/Installation/Systemrequirements 16  Вступление Код в этой книге использует генератор данных, который можно применять для проверки демонстрируемых здесь запросов. Однако, поскольку данные генерируются случайным образом, не все запросы будут работать, как ожидается, и вам может потребоваться внести в них соответствующие изменения. Соглашения В этой книге используется несколько разных стилей оформления текста с целью обеспечить визуальное отличие информации разных типов. Программный код в тексте, имена таблиц баз данных, имена папок, имена файлов, расширения файлов, пути в файловой системе, фиктивные адреса URL, ввод пользователя и ссылки в Twitter оформляются, как показано в следующем предложении: «События должны иметь поле _time». Блоки программного кода оформляются так: sourcetype="impl_splunk_gen" ip="*" | rex "ip=(?P<subnet>\d+\.\d+\.\d+)\.\d+" | table ip subnet Новые термины и важные определения, а также надписи на экране будут выделяться в обычном тексте жирным шрифтом. Например, пункты меню или надписи в диалоговых окнах будут оформляться так: «Определить поле можно несколькими способами. Сначала рассмотрим интерфейс Extract Fields». Так будут оформляться предупреждения и важные примечания. Так будут оформляться советы или рекомендации. Скачивание иСходного кода примеров Скачать файлы с дополнительной информацией для книг издательства «ДМК Пресс» можно на сайте www.dmkpress.com или www.дмк.рф на странице с описанием соответствующей книги. Пакет с исходным кодом примеров доступен также в репозитории GitHub по адресу: https://github.com/PacktPublishing/Implementing-Splunk-7-Third-Edition. Все обновления кода, по мере дальнейшей работы над ними, мы будем производить только в репозитории GitHub. отзывы и пожелания Мы всегда рады отзывам наших читателей. Расскажите нам, что вы думаете об этой книге – что понравилось или, может быть, не понравилось. Отзывы важны для нас, чтобы выпускать книги, которые будут для вас максимально полезны. Нарушение авторских прав  17 Вы можете написать отзыв прямо на нашем сайте www.dmkpress.com, зайдя на страницу книги и оставив комментарий в разделе «Отзывы и рецензии». Также можно послать письмо главному редактору по адресу dmkpress@gmail. com, при этом напишите название книги в теме письма. Если есть тема, в которой вы квалифицированы, и вы заинтересованы в написании новой книги, заполните форму на нашем сайте по адресу http://dmkpress.com/authors/publish_book/ или напишите в издательство по адресу dmkpress@gmail.com. Список опечаток Хотя мы приняли все возможные меры, для того чтобы удостовериться в качестве наших текстов, ошибки все равно случаются. Если вы найдете ошибку в одной из наших книг — возможно, ошибку в тексте или в коде, — мы будем очень благодарны, если вы сообщите нам о ней. Сделав это, вы избавите других читателей от расстройств и поможете нам улучшить последующие версии данной книги. Если вы найдете какие-либо ошибки в коде, пожалуйста, сообщите о них главному редактору по адресу dmkpress@gmail.com, и мы исправим это в следующих тиражах. Нарушение авторских прав Пиратство в интернете по-прежнему остается насущной проблемой. Издательства «ДМК Пресс» и Packt очень серьезно относятся к вопросам защиты авторских прав и лицензирования. Если вы столкнетесь в интернете с незаконно выполненной копией любой нашей книги, пожалуйста, сообщите нам адрес копии или веб-сайта, чтобы мы могли принять меры. Пожалуйста, свяжитесь с нами по адресу электронной почты dmkpress@ gmail.com со ссылкой на подозрительные материалы. Мы высоко ценим любую помощь по защите наших авторов, помогающую нам предоставлять вам качественные материалы. Глава 1 Интерфейс Splunk Это уже третье издание книги! Популярность Splunk продолжает расти, и появление каждой новой версии продукта с энтузиазмом встречается пользователями. Содержимое всех глав в этом издании было пересмотрено и приведено в соответствие с версией Splunk 7.0. Появились новые разделы, охватывающие новые особенности, добавленные в версии 7.0. Также появились две новые главы, одна из них охватывает набор инструментов машинного обучения (Machine Learning Toolkit, MLT), а другая предлагает рекомендации, эффективность которых подтверждена практикой. Поэтому даже если у вас уже есть более раннее издание этой книги (спасибо вам за его покупку!), вам определенно стоит приобрести данное издание. Приступим! Эта глава познакомит вас с наиболее часто используемыми элементами интерфейса Splunk и затронет некоторые понятия, которые более подробно будут рассматриваться в последующих главах. Возможно, у вас появится желание сразу перейти к их изучению, но имейте в виду, что общее знакомство с интерфейсом в этой главе может предохранить вас от неудач в будущем. В этой главе мы рассмотрим следующие темы: журналирование и выбор приложений; подробное описание элементов интерфейса поиска; краткий обзор интерфейса администратора. Логирование в Splunk Графический интерфейс Splunk (Splunk поддерживает также интерфейс командной строки (CLI) и REST API) доступен через веб-интерфейс, то есть вам не потребуется устанавливать никакого клиентского программного обеспечения. Новейшие браузеры с быстрыми движками JavaScript, такие как Chrome, Firefox и Safari, прекрасно отображают этот интерфейс. Начиная с версии Splunk 6.2.0 (и версия 7.0 не исключение) не требуется устанавливать в браузеры никаких расширений. По умолчанию Splunk использует порт 8000 (который можно изменить). Адрес будет выглядеть примерно так: http://mysplunkserver:8000 или http:// mysplunkserver.mycompany.com:8000: Домашнее приложение  19 Рис. 1.1  Интерфейс Splunk Если вы установили систему Splunk на локальный компьютер, она будет доступна по любому из следующих адресов: http://localhost:8000, http://127.0.0.1:8000, http://имя_компьютера:8000 или http://имя_компьютера.local:8000. После ввода адреса в окне браузера вы увидите самую первую страницу – страницу входа. По умолчанию создается учетная запись с именем пользователя admin и паролем changeme. Сразу после входа вам будет предложено изменить пароль пользователя admin. Обязательно измените его, чтобы предотвратить несанкционированный доступ к вашей системе. По умолчанию учетные записи создаются и хранятся внутри Splunk. Однако есть возможность настроить аутентификацию с использованием другой системы, например Lightweight Directory Access Protocol (LDAP). По умолчанию аутентификация выполняется локально. Если у вас есть настроенная система LDAP, тогда аутентификация будет выполняться в таком порядке: LDAP/Local. Домашнее приложение После входа автоматически запускается приложение Launcher (некоторые называют его домашним – Home). Это панель для запуска других приложений и руководств. Обратите внимание, что после первого входа в систему Splunk отобразит всплывающее окно Help us improve Splunk software (Помогите нам улучшить Splunk), в котором предлагается дать право системе Splunk собирать информацию об особенностях ее использования. Вам решать, как ответить на эту просьбу. 20  Интерфейс Splunk Рис. 1.2  Приложение Launcher В предыдущих версиях Splunk на вкладке Welcome (Добро пожаловать) присутствовали два важных ярлыка: Add data (Добавить данные) и Launch search (Запустить поиск). В версии 6.2.0 домашнее приложение было разделено на отдельные области, или панели: Explore Splunk Enterprise (Add Data (Добавить данные), Splunk Apps (Приложения Splunk), Splunk Docs (Документация Splunk) и Splunk Answers (Ответы Splunk)), Apps (страница управления приложениями), Search & Reporting (ссылка на приложение поиска) и область, куда вы сможете поместить свою панель по умолчанию. В версии 7.0 главная страница изменилась не очень сильно, хотя вы можете заметить некоторые изменения в графическом оформлении. Но в целом компоновка страницы осталась прежней, с теми же панелями и ссылками на те же функции. Подробнее о приложениях и панелях мы поговорим в последующих главах. Рис. 1.3  Панель Explore Splunk Enterprise Домашнее приложение  21 На панели Explore Splunk Enterprise присутствуют следующие ссылки (см. рис. 1.3): Рис. 1.4  Выбор обзора Product Tours (Обзор продуктов, новинка версии 7.0): после щелчка по этой ссылке вам будет предложено на выбор три обзора (рис. 1.4) – Add Data Tour (Обзор добавления данных), Search Tour (Обзор поиска) и Dashboards Tour (Обзор дашбордов1); Обратите внимание: когда вы впервые щелкнете на любой из ссылок, перечисленных далее, вам будет предложено сделать паузу и познакомиться с обзором соответствую щей функции. Конечно, вы всегда сможете вернуться назад к ссылке Product Tours (Обзор продуктов), чтобы познакомиться с тем или иным обзором. Add Data (Добавить данные): ссылка для добавления данных на страницу Splunk. Этот интерфейс послужит отличной начальной точкой для получения локальных данных, поступающих в Splunk (чтобы сделать их доступными для пользователей Splunk). Интерфейс Preview data (Предварительный просмотр данных) избавляет от необходимости выполнять сложные настройки. Мы не будем рассматривать эти интерфейсы здесь, но исследуем файлы конфигурации, которые эти мастера производят, в главе 11 «Настройка Splunk»; Splunk Apps (Приложения Splunk): поможет найти дополнительные приложения в онлайн-магазине Splunk Apps Marketplace (https://splunkbase.splunk.com/) и установить их. Это очень удобный ресурс, где пользователи и разработчики Splunk могут размещать свои приложения для Splunk, в основном бесплатные, но среди них есть платные премиумверсии. Обратите внимание, что для загрузки приложений необходимо иметь идентификатор пользователя splunk.com; 1 От англ. dashboard. В Splunk – это документ с лаконично представленными статистическими данными, отчетами и нередко с инфографикой. В Splunk используются два похожих термина «dashbord» и «panel», поэтому, чтобы избежать путаницы, я буду использовать транслитерацию «дашборд» для перевода термина «dashbord» и «панель» для перевода «panel». – Прим. перев. 22  Интерфейс Splunk Splunk Docs (Документация Splunk): по этой ссылке доступен огромный объем документации для Splunk, в частности, перейдя по ссылке https:// answers.splunk.com, вы сможете присоединиться к сообществу Splunk на Splunkbase (https://splunkbase.splunk.com/) и решить вопросы, возникающие у вас при работе с системой Splunk. Кроме того, здесь же вы увидите ссылку http://docs.splunk.com/Documentation/Splunk на самую свежую документацию для любых (почти) версий Splunk; в разделе Apps (Приложения, слева на рис. 1.2) отображаются приложения с элементами графического интерфейса в вашем экземпляре Splunk. Термин «приложение» в Splunk имеет свое значение. Приложение не обязательно должно иметь графический интерфейс; это просто коллекция конфигураций, заключенная в структуру каталогов, имеющая особый смысл для Splunk. Мы обсудим приложения более подробно в главе 8 «Работа с приложениями»; Search & Reporting (Поиск и отчеты, слева на рис. 1.2): ссылка на Splunkприложение Search & Reporting (Поиск и отчеты); Рис. 1.5  Ссылка для добавления дополнительных приложений под ссылкой Search & Reporting (Поиск и отчеты) вы увидите прямоугольную область, ограниченную пунктирной рамкой, при наведении указателя мыши на которую появляется всплывающая подсказка Find More Apps (Найти еще приложения), как показано на рис. 1.5. Щелчок на ссылке откроет страницу Browse more apps (Обзор дополнительных приложений), что и ссылка Splunk Apps (Приложения Splunk), описанная выше; Choose a home dashboard (Выбор домашнего дашборда, см. рис. 1.6) предлагает понятный способ выбора существующего дашборда (на упрощенном XML) для отображения на начальной (домашней) странице. Благодаря этому вы всегда будете видеть знакомый начальный экран после входа в Splunk. На рис. 1.7 показан диалог Choose Default Dashboard (Выбор дашборда по умолчанию). Верхняя полоса меню  23 Рис. 1.6  Ссылка для выбора домашнего дашборда Рис. 1.7  Диалог выбора дашборда по умолчанию После выбора дашборда в раскрывающемся списке он станет частью вашей домашней страницы и будет отображаться при каждом входе в Splunk, пока вы его не замените. Вместе с системой Splunk по умолчанию не устанавливается никаких дашбордов, кроме приложения Search & Reporting (Поиск и отчеты). Поэтому выбрать дашборд по умолчанию вы сможете только после его создания. Верхняя полоса меню Полоса меню, располагающаяся вдоль верхнего края окна, содержит информацию о вашем текущем местоположении в системе, а также ссылки на настройки, другие приложения и на раздел администрирования. В левом верхнем углу отображается текущее приложение, например на рис. 1.8 показана часть верхней полосы с текущим местоположением после перехода в приложение Search & Reporting (Поиск и отчеты). Рис. 1.8  Текущее местоположение в полосе меню 24  Интерфейс Splunk Щелчок на этой области перенесет вас на страницу по умолчанию указанного приложения. В большинстве приложений просто изменяется текст рядом с логотипом, но есть возможность полностью реорганизовать блок с использованием логотипов и альтернативного текста изменением стилей CSS-приложения. Подробнее об этом мы поговорим в главе 8 «Работа с приложениями». Рис. 1.9  Пункты меню Справа в верхней полосе находится меню (рис. 1.9) со ссылками на почти всегда доступные действия. Первым следует имя текущего пользователя. В данном случае (рис. 1.9) это пользователь Administrator. В предыдущих версиях Splunk щелчок на имени пользователя позволял выбрать пункт меню Edit Account (Изменить учетную запись) и перейти на страницу Your account (Ваша учетная запись), или пункт Logout (Выйти). В версии 7.0 произошли небольшие изменения. Первый пункт теперь доступен под именем Account Settings (Настройки учетной записи) и открывает страницу с настройками, напоминающую аналогичную страницу из предыдущих версий (предшествовавших версии 7.0). Пункт Logout (Выйти) остался прежним и завершает текущий сеанс, вынуждая пользователя вновь ввести учетные данные. На рис. 1.10 показано, как выглядит страница с настройками учетной записи. В этой форме перечислены глобальные настройки, которые пользователь может изменить. Другие настройки определяют разрешения на объекты и параметры в ролях. (Обратите внимание, что настройки можно также изменять с использованием интерфейса командной строки или путем редактирования конфигурационных файлов Splunk.) В число настроек, доступных для изменения, входят: – Full name (Полное имя) и Email address (Адрес электронной почты) – предусмотрены для удобства администратора; – поля в разделе Set password (Установка пароля) позволяют изменить пароль. Это актуально, только если система Splunk настроена на использование внутреннего механизма аутентификации. Например, если система настроена на использование Windows Active Directory через LDAP (что на практике встречается очень часто), пользователи должны менять свои пароли в Windows; – Global/Time zone (Глобальные/Часовой пояс) определяет часовой пояс для зарегистрированного пользователя; Верхняя полоса меню  25 Рис. 1.10  Страница с настройками учетной записи часового пояса используется только для отображения данных. Это очень важ Настройка но для правильного представления данных при индексировании событий. Подробнее об этом мы поговорим в главе 2 «Основы поиска». – Default application (Приложение по умолчанию) определяет приложение, которое будет запущено первым сразу после входа. На роль такого приложения большинство пользователей выбирает приложение поиска; – Restart backgrounded jobs (Перезапускать фоновые задания) определяет необходимость повторного запуска незавершенных запросов при 26  Интерфейс Splunk перезапуске Splunk; – Search assistant (Ассистент поиска), Syntax highlighting (Подсветка синтаксиса), Search auto-format (Автоматическое форматирование результатов поиска) и Show line numbers (Показывать номера строк): эти параметры используются для оказания помощи с синтаксисом команд, включая вывод примеров, автодополнение и включение/выключение ассистента поиска. Подсветка синтаксиса выделяет цветами разные компоненты строки поиска. Меню Messages (Сообщения) позволяет увидеть все системные сообщения об ошибках, ожидающие обработки. С появлением нового сообщения об ошибке, требующего вашего внимания, рядом с меню Messages (Сообщения) появится уведомление с числом ошибок. Вы можете щелк нуть на значке с крестиком, чтобы удалить сообщение. Ссылка Settings (Настройки) перенесет пользователя на страницу с разделами Knowledge (Объекты знаний), Distributed environment (Распределенное окружение), System and Licensing (Система и лицензирование), Data (Данные) и Users and Authentication (Пользователи и аутентификация), в которых перечислены ссылки на конкретные страницы с настройками (см. рис. 1.11). Здесь отображаются только ссылки на настройки, которые вы имеете право просматривать или изменять. Рис. 1.11  Страница с разделами настроек Меню Activity (Деятельность) содержит пункты Jobs (Задания), Triggered Alerts (Оповещения), как показано на рис. 1.12. В предыдущих Приложение Search & Reporting  27 версиях имелся также пункт System Activity (Системная деятельность). После выбора пункта Jobs (Задания) откроется окно диспетчера заданий поиска, где можно просматривать запущенные запросы поиска и управлять ими. Выбор пункта Triggered Alerts (Оповещения) позволяет просмотреть запланированные оповещения. System Activity (Системная деятельность), открывавший дашборды с информаци Пункт ей о деятельности пользователей и состоянии системы, в версии 7.0 был убран из меню Activity (Деятельность). Теперь вся эта информация доступна в приложении поиска! Рис. 1.12  Меню Activity (Деятельность) В меню Help (Справка) перечисляются ссылки на видеоруководства, Splunk Answers (Ответы Splunk), портал Contact Support (Контакты поддержки) и онлайн-документацию, как показано на рис. 1.13. Рис. 1.13  Меню Help (Справка) Поле Find (Найти) можно использовать для поиска объектов в вашем экземпляре Splunk Enterprise, в том числе отчеты, дашборды, оповещения и т. д. Поиск ошибок можно выполнить в приложении Search & Reporting (Поиск и отчеты), щелкнув на ссылке Open error (Открыть ошибки). Приложение Search & Reporting Приложение Search & Reporting (Поиск и отчеты), или просто приложение поиска, – это место, где запускается большинство действий, производимых системой Splunk. Это приложение отображается как дашборд, откуда вы будете начинать поиск. 28  Интерфейс Splunk Генератор данных Если у вас есть желание повторить у себя примеры, которые приводятся в следующих нескольких главах, установите демонстрационное приложение ImplementingSplunkDataGenerator, выполнив следующие шаги. 1.Загрузите архив ImplementingSplunkDataGenerator.tar.gz, входящий в состав пакета с примерами кода, доступного на сайте www.dmkpress.com или www.дмк.рф в разделе Читателям – Файлы к книгам. 2.Выберите пункт Manage apps... (Управление приложениями…) в меню Apps (Приложения). 3.Щелкните на кнопке Install app from the file (Установить приложение из файла). 4.Щелкните на ссылке Choose File (Выбрать файл), выберите файл и щелк ните на кнопке Upload (Выгрузить). Приложение-генератор производит порядка 16 мегабайт выходных данных в день. Его можно остановить, выбрав пункт Manage apps... (Управление приложениями…) в меню Apps (Приложения), и тем самым прекратить генерирование данных. Представление Summary Внутри приложения Search & Reporting (Поиск и отчеты) перед пользователем отображается представление Summary (Сводка) с информацией о данных, поиск в которых осуществляется по умолчанию. Это важное отличие; в системах Splunk, действующих достаточно продолжительное время, не все пользователи будут выполнять поиск во всех данных. Но если вы впервые используете Search & Reporting (Поиск и отчеты), то увидите картину, как на рис. 1.14. Рис. 1.14  Страница приложения Search & Reporting Как показано на скриншоте (рис. 1.14), у пользователя есть доступ к документации, имеющей отношение к разделам What to Search (Что искать) и How Приложение Search & Reporting  29 to Search (Как искать). После того как у вас появятся первые индексированные данные (эту тему мы обсудим позже), Splunk представит в разделе What to Search (Что искать) некоторую статистику о доступных данных. забывайте, что здесь отображаются только индексы, которые текущий пользова Не тель ищет по умолчанию; есть также другие события, которые индексируются системой Splunk, включая события, касающиеся самой системы Splunk. Мы обсудим индексы в главе 9 «Создание продвинутых дашбордов». На рис. 1.15 показано, как примерно будет выглядеть раздел What to Search (Что искать). Рис. 1.15  Содержимое раздела What to Search В предыдущих версиях Splunk панели, такие как All indexed data (Все индексированные данные), включали статистику по пользовательским индексированным данным. Другие панели разбивали данные на три основные группы по метаданным – Source (Источник), Sourcetype (Тип источника) и Hosts (Хосты). В текущей версии 7.0.0 эта информация становится доступна после щелчка на кнопке Data Summary (Сводные данные), в диалоге, изображенном на рис. 1.16. Рис. 1.16  Сводная информация о данных В этом окне информация разбита на три вкладки – Hosts (Хосты), Sources (Источники) и Sourcetypes (Типы источников). Хост определяется именем хоста, где возникло событие. В большинстве случаев в поле host (хост) записывается имя компьютера, откуда полу- 30  Интерфейс Splunk чены данные. Иногда имя хоста неизвестно, и тогда значение для этого поля можно настроить произвольно. Под источником в Splunk понимается уникальный путь или имя. В больших системах может иметься по нескольку тысяч компьютеров, посылающих данные, но все данные с одинаковыми путями будут считаться как принадлежащие одному источнику. Если источником данных является не файл, это поле может иметь произвольное значение. Например, имя скрипта или номер сетевого порта. Тип источника – это произвольное значение для классификации события. В системе может иметься большое количество разных источников среди множества хостов, имеющих один и тот же тип источника. Например, на источники /var/log/access.2012-03-01.log и /var/log/access.2012-03-02.log на хостах fred и wilma можно ссылаться по типу источника как на журналы или под любым другим названием типа источника. А теперь продолжим и рассмотрим виджеты, находящиеся непосредственно под названием приложения. Первый виджет – полоса навигации, изображенная на рис. 1.17. Рис. 1.17  Полоса навигации Как правило, элементы с треугольником, направленным вершиной вниз, в Splunk являются раскрывающимися списками, или меню, а элементы без такого треугольника – обычными ссылками. Подробнее о настройке полосы навигации мы поговорим в главе 8 «Работа с приложениями». Ниже находится поле Search (Поиск), как показано на рис. 1.18. Именно здесь начинает твориться волшебство. Подробнее об этом поле рассказывается ниже. Рис. 1.18  Поле поиска Поиск Вот мы и добрались до поиска. Именно здесь сосредоточена вся мощь Splunk. В качестве первого примера попробуем выполнить поиск (без учета регист ра символов) по слову error. Щелкните в поле поиска, введите слово error и затем нажмите клавишу Enter или щелкните на значке с изображением лупы справа от поля, как показано на рис. 1.19. Приложение Search & Reporting  31 Рис. 1.19  Поле поиска Search После запуска процедуры поиска откроется страница с результатами (которая мало изменилась в версии 7.0), как показано на рис. 1.20. Рис. 1.20  Страница с результатами поиска внимание, что мы запустили поиск по данным за все время (по умолчанию);  Обратите чтобы изменить интервал времени для поиска, можно использовать виджет выбора времени. Однако из-за того, что мы экспериментируем на случайно сгенерированных данных, не все запросы будут действовать, как ожидается, и вам может потребоваться изменить их. Описание этапов загрузки наборов данных вы найдете в предыдущем разделе «Генератор данных». Как изменить интервал времени для поиска, вы узнаете в разделе «Использование виджета выбора времени». Действия Рассмотрим элементы на этой странице. Под поисковой строкой Search (Поиск) выводятся счетчик событий, значки действий и меню (рис. 1.21). 32  Интерфейс Splunk Рис. 1.21  Информация под полем Search (Поиск) Вот какие сведения выводятся под поисковой строкой (слева направо). Количество событий, найденных в процессе поиска. Технически это число может не соответствовать количеству результатов, прочитанных с диска, в зависимости от параметров поиска. Кроме того, если в запросе используются команды, это число может отличаться от числа событий в списке ниже. Меню Job (Задание): открывает окно инспектора заданий поиска, в котором приводится очень подробная информация о запросе. Кнопка «Пауза»: приостанавливает текущий поиск событий, но не удаляет результаты. Это может пригодиться, когда нужно просмотреть уже полученные результаты, чтобы определить – стоит ли продолжать поиск, который может занять продолжительное время. Кнопка «Стоп»: останавливает выполнение запроса, но сохраняет на странице уже полученные результаты. Это может пригодиться, когда получен достаточный объем информации и можно переходить к их исследованию. Кнопка «Поделиться»: растягивает временной интервал поиска до семи суток и открывает доступ к результатам для чтения всем пользователям. Кнопка «Печать»: форматирует страницу для печати и запускает функцию печати в браузере. Кнопка «Экспорт»: экспортирует результаты, предлагая указать количество экспортируемых результатов и формат – CSV, простой текст, XML или JSON (JavaScript Object Notation – форма записи объектов JavaScript). Меню Smart mode (Интеллектуальный режим): управляет режимом поиска. Вы можете использовать это меню для ускорения поиска, ограничивая объем возвращаемых данных и количество полей, которые Splunk будет извлекать из данных (Fast mode (Быстрый режим)). Также можно выбрать Verbose mode (Подробный режим), чтобы получить максимальный объем информации о событиях. В режиме Smart mode (Интеллектуальный режим), который используется по умолчанию, поведение поиска определяется его типом. Шкала времени Теперь перейдем к шкале времени, отображаемой под полосой с кнопками действий (рис. 1.22). Приложение Search & Reporting  33 Рис. 1.22  Шкала времени Шкала времени не только позволяет быстро оценить распределение событий в заданном интервале, но и является ценным инструментом, помогающим выбрать подходящий интервал. Если навести указатель мыши на шкалу времени, появится всплывающая подсказка с количеством событий в данном промежутке. Щелчок на шкале выбирает события за конкретный отрезок времени. Если нажать левую кнопку мыши и потянуть указатель, выделится несколько отрезков времени, как показано на рис. 1.23. Рис. 1.23  Выделение нескольких отрезков времени Выделив интервал, можно щелкнуть на ссылке Zoom to selection (Увеличить масштаб выделения), чтобы изменить интервал и повторить поиск для данного интервала. Повторяя этот процесс, можно добраться до конкретных событий. Deselect (Убрать выделение) снова возвращает отображение всех событий в интервале времени, установленном в виджете выбора времени. Zoom out (Уменьшить масштаб) увеличивает интервал времени, отображаемый в окне. Виджет выбора полей Слева от результатов поиска находится виджет выбора полей (рис. 1.24). Это отличный инструмент для выявления закономерностей и фильтрации результатов поиска. 34  Интерфейс Splunk Рис. 1.24  Виджет выбора полей Поля Виджет выбора полей содержит два списка: Selected Fields (Выбранные поля) перечисляет поля, значения которых в данный момент отображаются в результатах поиска; Interesting Fields (Интересные поля) перечисляет поля, которые Splunk извлек для вас. Над списками полей имеются две ссылки: Hide Fields (Скрыть поля) и All Fields (Все поля): Hide Fields (Скрыть поля) скрывает область со списком полей; All Fields (Все поля): открывает окно Selected Fields (Выбранные поля) со списком полей для выбора (рис. 1.25). Приложение Search & Reporting  35 Рис. 1.25  Окно Selected Fields (Выбранные поля) со списком полей для выбора Результаты поиска Мы познакомились почти со всеми виджетами на странице, остался лишь сам список результатов поиска (рис. 1.26). 36  Интерфейс Splunk Рис. 1.26  Результаты поиска Как можно заметить на рис. 1.26, в этом разделе отображается множество найденных событий. При просмотре результатов в исходном формате их число совпадает с числом, отображаемым над шкалой времени. Это значение можно изменить, либо выбрав другой интервал времени, либо запустив иную команду поиска. Также на список с результатами влияют значки действий (были описаны выше). Под полосой со значками действий можно видеть четыре вкладки. Events (События) отображает список событий в исходной форме. Это представление используется по умолчанию, когда выполняется простой поиск, как в данном примере. Patterns (Закономерности) помогает выявить закономерности в потоке событий. Перечисляет закономерности, наиболее часто встречающиеся в наборе событий, возвращаемом поиском. Эти закономерности представлены событиями с похожей структурой. Statistics (Статистики) заполняется, когда поиск сопровождается командами преобразований, такими как stats, top, chart и т. д. Для поиска по ключевому слову error, как в данном примере, эта вкладка не заполняется, потому что в ходе поиска не выполняется никаких команд преобразований. Visualization (Визуализация) позволяет добавить преобразование поиска и заполнить вкладку визуальной информацией с диаграммами и таблицами статистик, использованных для создания диаграмм. Не все виды поиска можно визуализировать – подробнее об этом мы поговорим далее в книге. Приложение Search & Reporting  37 Под вкладками находится шкала времени, о которой пойдет разговор далее в этой главе. Параметры Под шкалой находится полоса с параметрами настройки (слева направо): Show Fields (Показать поля): показывает прежде скрытый виджет Selected Fields (Выбранные поля); List (Список): позволяет выбрать формат вывода результатов поиска (Raw (Исходный), List (Список) или Table (Таблица)); Format (Формат): позволяет установить дополнительные параметры отображения результатов, такие как Show row numbers (Показывать номера строк), Wrap results (Переносить строки), Max lines (Максимальное число строк, для одного события) и Drilldown (Детализация) как on (включено) и off (выключено); NN Per Page (NN на странице): позволяет выбрать количество результатов, отображаемых на странице (10, 20 или 50). Справа находятся элементы выбора конкретной страницы с результатами. старых версиях Splunk (до версии 4.3) эти параметры были доступны в диалоге Results  Вdisplay options (Параметры отображения результатов). Представление событий Наконец, перейдем к элементу отображения фактических событий. Допустим, у нас имеется единственное событие, как показано на рис. 1.27. Рис. 1.27  Элемент отображения одного события В этом элементе отображаются (слева направо): подробности о событии: если щелкнуть на этой стрелке вправо, выбранное событие откроется, и на экране появится дополнительная информация о типе события, полях и их значениях, и здесь же вы сможете выполнить некоторые действия с данным событием. Кроме того, Splunk предлагает кнопку Event Actions (Действия с событиями) для доступа к операциям, доступным всегда: – Build Event Type (Создать тип события): типы событий дают возможность задавать искомые события в запросах. Подробнее о типах событий мы поговорим в главе 7 «Расширенный поиск»; – Extract Fields (Извлекаемые поля): открывает страницу для создания нового правила извлечения полей. Подробнее об извлечении полей мы поговорим в главе 3 «Таблицы, диаграммы и поля»; – Show Source (Показать источник): открывает новую страницу, имитирующую отображение оригинального источника; 38  Интерфейс Splunk номер события: результаты простого поиска отображаются в обратном хронологическом порядке – от самых свежих к более старым; далее следуют любые настроенные сценарии реагирования (workflow actions). Сценарии реагирования позволяют запускать новые виды поиска или создавать ссылки на другие сайты на основе данных из события. По дробнее сценарии реагирования мы обсудим в главе 7 «Расширенный поиск»; затем следуют данные, извлеченные из события, отображаемые с привязкой к часовому поясу, выбранному пользователем. Это важная особенность, часто приводящая к путанице. В большинстве систем все – серверы, пользователи и события – находятся в одном часовом поясе. Когда что-то из перечисленного оказывается в другом часовом поясе, может возникать путаница. Подробнее о времени мы поговорим в главе 2 «Основы поиска»; далее следует само событие. Именно так Splunk видит события. Без посторонней помощи Splunk в состоянии находить даты и разрывы строк; но, как мы увидим позже, с дополнительной помощью парсинг событий может быть еще более надежным и эффективным; ниже события отображаются выбранные нами поля. Щелчок на значении в поле добавляет его в критерии поиска. Использование виджета выбора времени Теперь, когда мы перечислили все виджеты, попробуем с их помощью изменить настройки поиска. Сначала изменим интервал времени. По умолчанию поиск выполняется за все время, и такой подход вполне оправдан, когда событий немного. Но если события собирались системой Splunk в течение продолжительного времени (например, нескольких недель или даже месяцев), такой выбор оказывается далеким от оптимального. Давайте выберем интервал поиска, соответствующий последнему часу (см. рис. 1.28). Рис. 1.28  Выбор интервала поиска, соответствующего последнему часу Использование виджета выбора полей  39 После выбора интервала поиск будет выполнен снова, и теперь в списке результатов отобразятся только события, происшедшие в течение последнего часа. Попробуем задать нестандартный интервал. Выберите раздел Date Range (Диапазон дат), как показано на рис. 1.29. Рис. 1.29  Раздел Date Range (Диапазон дат) Если известно, когда случилось искомое событие, вы можете установить любой желаемый интервал дат для поиска. Другие настройки мы детально исследуем в главе 2 «Основы поиска». пояс в Custom Time Range (Свой диапазон времени) соответствует часовому  Часовой поясу, выбранному в предпочтениях пользователя, который по умолчанию совпадает с часовым поясом сервера Splunk. Использование виджета выбора полей Виджет выбора полей очень удобно использовать для исследования данных и навигации по ним. Щелчок на любом поле в виджете открывает всплывающую панель с дополнительной информацией об этом поле в результатах поиска, как показано на рис. 1.30. Здесь можно видеть следующие сведения: число значений и процент от общего числа результатов сообщают, сколько событий содержит значение в этом поле; переключатель Selected (Выбрано) показывает, выбрано ли данное поле; ссылки Top values (Топ значений) и Top values by time (Топ значений по времени) позволяют увидеть десятку наиболее часто встречающихся значений, найденных в результате поиска, в виде графиков. Это отличный способ приступить к исследованию механизмов поддержки отчетов и графиков. Когда подойдет время, мы используем эти ссылки как отправную точку для начала обсуждения; ссылка Rare values (Редкие значения) отображает самые редкие значения, встречающиеся в данном поле; 40  Интерфейс Splunk Рис. 1.30  Панель с дополнительной информацией о поле ссылка Events with this field (События с этим полем) изменяет запрос так, что в результатах остаются только события, для которых определено это поле; ссылки в списке Top 10 values (Топ-10 значений) фактически позволяют получить общее представление о наиболее часто встречающихся значениях. Щелчок на любой из них добавляет соответствующее значение в запрос. Например, щелкнем на c:\\Test Data\\tm1server.log (см. рис. 1.31). Рис. 1.31  Строка поиска после щелчка на ссылке в списке Top 10 values (Топ-10 значений) В результате поиск выполнится повторно, но теперь Splunk будет искать ошибки со значением c:\\Test Data\\tm1server.log в поле source. Раздел с настройками Раздел Settings (Настройки) фактически представляет интерфейс для управления конфигурационными файлами. Количество файлов и параметров в них Раздел с настройками  41 поистине огромно, поэтому в веб-интерфейсе представлены только наиболее часто используемые параметры в разных типах конфигураций. Настройки Splunk хранятся исключительно в текстовых конфигурационных файлах. Не бойтесь заглядывать в них после внесения изменений в интерфейсе администратора. Они находятся в следующих каталогах: $SPLUNK_HOME/etc/system/local/ $SPLUNK_HOME/etc/apps/ $SPLUNK_HOME/etc/users/<user>/<app>/local В разных местах вы можете обнаружить конфигурационные файлы с одинаковыми именами. Мы подробнее расскажем о разных конфигурационных файлах, их назначении, а также о правилах их объединения в главе 11 «Настройка Splunk». Не следует начинать изменять конфигурационные файлы, пока вы не узнаете, для чего они предназначены и как объединяются. Щелчок на ссылке Settings (Настройки) в верхней полосе меню откроет страницу Settings (Настройки), как показано на рис. 1.32. Рис. 1.32  Страница с настройками Распределение информации на странице с настройками немного изменилось в версии 7.0, но в целом она осталась прежней. Тем не менее отметим появившиеся отличия. Во-первых, изменились некоторые названия (Distributed Management Console (Консоль распределенного управления) теперь называется Monitoring Console (Консоль мониторинга)) и добавились дополнительные ссылки (в разделе SYSTEM (Система) появилась ссылка Instrumentation (Инструменты), а в разделе DATA (Данные) добавилась ссылка Source Types (Типы источников)). 42  Интерфейс Splunk Параметры организованы в логические группы. KNOWLEDGE (Объекты знаний): ссылки в группе KNOWLEDGE позволяют управлять типами объектов, которые используются на этапе поиска. На рис. 1.33 показан пример одного из типов объектов, сценариев реагирования (workflow actions): Searches, reports, and alerts (Поиск, отчеты и оповещения). Рис. 1.33  Тип объектов Searches, reports, and alerts (Поиск, отчеты и оповещения) System (Система): параметры в этой группе определяют общесистемные настройки: – Server settings (Настройки сервера) содержит сетевые настройки, путь к каталогу по умолчанию для хранения индексов, параметры сервера исходящей электронной почты и объем журналов с информацией о самой системе Splunk; – Server controls (Управление сервером) содержит единственную страницу, позволяющую перезапустить Splunk через веб-интерфейс; – Licensing (Лицензии) позволяет добавить файлы лицензий или настроить Splunk как клиента и указать сервер лицензий Splunk; – Instrumentation (Инструменты) – новая ссылка, появившаяся в версии 7.0, – позволяет определить параметры автоматического создания отчетов, просматривать собранные данные, экспортировать данные в файл и посылать их в Splunk. Data (Данные): в этом разделе находятся настройки управления потоками данных: – Data Inputs (Входные данные): Splunk может читать данные из файлов (единоразово или в режиме реального времени), принимать по сети на определенный порт или получать их, запуская скрипты; Раздел с настройками  43 – Forwarding and receiving (Отправка и прием): архитектура Splunk обычно использует несколько серверов. Большинство систем обычно включает, по крайней мере, один индексер Splunk и несколько форвардеров (forwarders). Этот интерфейс позволяет настроить все взаимодействующие стороны и реализовать более сложные конфигурации (подробнее об этом рассказывается в главе 12 «Продвинутое развертывание»); – Indexes (Индексы): индекс – это контейнер с данными. Фактически это просто набор каталогов, которые создаются и управляются системой Splunk. В небольшой системе достаточно одного индекса. В больших системах наличие нескольких индексов помогает гибко управлять безопасностью, сохранностью и производительностью, а также обеспечить оптимальное использование аппаратных средств. Мы продолжим обсуждение этой темы в главе 11 «Настройка Splunk»; – Report acceleration summaries (Сведения об ускорении отчетов): открывает доступ к информации об ускорении выполнения отчетов некоторых видов; – Source Types (Типы источников): открывает доступ к странице с настройками типов источников. Типы источников используются для назначения таких настроек, как распознавание меток времени, выделения событий и полей в данных, которые индексируются системой Splunk. Distributed environment (Распределенная архитектура): три параметра, доступных в этой группе, имеют отношение к развертыванию системы в распределенном виде (подробнее они будут описаны в главе 12 «Продвинутое развертывание»): – Indexer clustering (Кластер индексеров): открывает доступ к настройкам кластера индексеров в Splunk, о котором рассказывается далее в этой книге; – Forwarder management (Управление форвардерами): открывает доступ к пользовательскому интерфейсу для настройки управления форвардерами, а также распределения приложений между ними; – Distributed search (Распределенный поиск): любой сервер Splunk, выполняющий поиск, может использовать себя и другие серверы Splunk для получения результатов. Этот интерфейс дает возможность настроить соединения с другими серверами Splunk. Users and authentication (Пользователи и аутентификация): в этой группе сосредоточены настройки аутентификации и ссылки на учетные записи: – Access controls (Управление доступом): настройки в этом разделе определяют порядок аутентификации в Splunk и полномочия пользователей. Мы рассмотрим эти настройки в главе 11 «Настройка Splunk». 44  Интерфейс Splunk Помимо ссылок, на странице Settings (Настройки) слева имеется также панель с двумя значками: Add Data (Добавить данные) и (прежнее название) Distributed Management Console (Консоль распределенного управления), которая ныне называется Monitoring Console (Консоль мониторинга): ссылка Add Data (Добавление данных) ведет на страницу Add Data (Добавление данных). На ней отображаются три параметра, управляющих получением данных экземпляром Splunk Enterprise: Upload (Загрузка), Monitor (Мониторинг) и Forward (Отправка); Monitoring Console (Консоль мониторинга) представляет подробную информацию о работе Splunk Enterprise. Splunk Cloud В Splunk появилось новое интересное решение Splunk Cloud. Оно предоставляет все возможности Splunk Enterprise в формате настоящей облачной платформы. Простота доступа через интернет. Как отмечается в документации Splunk (http://docs.splunk.com/Documentation/SplunkCloud/6.6.3/User/WelcometoSplunkCloud): «Splunk Cloud предоставляет иной уровень безопасности и оперативного управления, чем Splunk Enterprise». По моему опыту, перенос в облако любого программного обеспечения или службы влечет за собой определенные последствия. В Splunk Cloud, например, имеются следующие отличия (от Splunk Enterprise). Отсутствует поддержка интерфейса командной строки (CLI). Это означает, что некоторые (административные) задачи можно решать с по мощью веб-браузера, но чаще придется обращаться в службу поддержки Splunk. Устанавливать и использовать в Splunk Cloud можно только приложения, проверенные (с точки зрения безопасности и надежности) и принятые службой поддержки Splunk. Если вы выберете управляемое облако Splunk Cloud, установить и настроить все приложения вы сможете, только обратившись в службу поддержки Splunk (в собственное облако Splunk Cloud вы сможете установить свои приложения самостоятельно). Невозможность прямого мониторинга TCP, UDP, файлов и системного журнала syslog. В отличие от Splunk Enterprise, эти типы данных нельзя напрямую передать в Splunk Cloud (требуется использовать локальный форвардер). Управляемые оповещения (Scripted Alerts) поддерживаются только для одобренных приложений. Опробование перед покупкой  45 Объединение лицензий недоступно в Splunk Cloud. Диспетчер лицензий недоступен клиентам Splunk Cloud через интернет. И снова, чтобы в управляемом облаке Splunk Cloud воспользоваться механизмом доставки событий через HTTP – HTTP Event Collector (HEC), – он должен быть включен службой поддержки Splunk. Доступ к Splunk API по умолчанию отключен (для Splunk Cluster), но может быть включен службой поддержки Splunk. Чтобы получить программный доступ к «песочницам» и пробным версиям Splunk Cloud, а также к отдельным экземплярам, вы должны подать заявку в службу поддержки (однако это не рекомендуется для пробных версий из-за короткого пробного периода). Опробование перед покупкой Вам определенно стоит опробовать Splunk Cloud (даже если вы не рассматриваете возможность использования этой версии в ближайшем будущем). Если у вас есть действительный идентификатор Splunk ID, воспользуйтесь возможностью провести бесплатный тест-драйв Splunk Cloud (в течение 15 дней). На рис. 1.34 перечислены возможности, которые вы получите на период опробования. Рис. 1.34  Возможности, поддерживаемые в течение пробного периода Чтобы воспользоваться своим Splunk ID для опробования Splunk Cloud, достаточно зарегистрироваться и согласиться с условиями обслуживания. На рис. 1.35 показана страница с текстом этого соглашения. 46  Интерфейс Splunk Рис. 1.35  Текст соглашения с условиями обслуживания Когда вы поставите галочку (и щелкнете на кнопке Ok), вам будет отправлено электронное письмо с дальнейшими инструкциями, выполнив которые, вы сможете приступить к опробованию! Рис. 1.36  Можно приступать к опробованию! Краткий тур по облаку Начнем с доступа к Splunk. После получения подтверждения, что ваш пробный сервер Splunk Cloud готов, введите в адресную строку браузера указанный URL. Обратите внимание, что веб-адрес Splunk Cloud начинается с уникального идентификатора (см. рис. 1.37), отличающего ваш сервер (это фактическое имя сервера, где находится ваш Splunk). Рис. 1.37  Веб-адрес экземпляра Splunk Cloud начинается с уникального идентификатора Краткий тур по облаку  47 Страница входа в Splunk Cloud имеет немного иной вид (отличный от Splunk Enterprise), как показано на рис. 1.38. Рис. 1.38  Страница входа в Splunk Cloud После аутентификации откроется главная страница Splunk Cloud, как показано на рис. 1.39. Рис. 1.39  Главная страница Splunk Cloud Сначала о главном. Посмотрите на полосу меню (в верхней части страницы), если выбрать пункт Support & Services (Поддержка и обслуживание) и затем 48  Интерфейс Splunk About (О программе), можно обнаружить, что используется версия Splunk Cloud 6.6.3.2 – далеко НЕ последняя, как устанавливаемая локально (см. рис. 1.40). Рис. 1.40  Информация о версии Splunk Cloud Полоса меню в Splunk Cloud Полоса меню в Splunk Cloud выглядит почти так же, с той лишь разницей, что в локальной версии ссылки (Messages (Сообщения), Settings (Настройки), Activity (Действия) и Find (Найти)) сдвинуты влево, как показано на рис. 1.41. Рис. 1.41  Полоса меню в Splunk Cloud А справа находится меню My Splunk (Мой Splunk), как показано на рис. 1.42. Рис. 1.42  Меню My Splunk (Мой Splunk) в Splunk Cloud Полоса меню в Splunk Cloud  49 Ссылка Instances в меню My Splunk (Мой Splunk) ведет на страницу Instan ces, изображенную на рис. 1.43, где можно увидеть и отредактировать информацию о доступных экземплярах Splunk. Эту страницу можно также использовать как портал для перехода между своими серверами щелчком на кнопке Access Instance (Перейти к серверу) рядом с выбранным сервером. Рис. 1.43  Страница Instances (Экземпляры) В списке приложений (слева на домашней странице) в Splunk Cloud присутствуют три предустановленных приложения: Splunk Reference App-PAS, Universal Forwarder и eventgen (см. рис. 1.44). Рис. 1.44  Список предустановленных приложений Powered by TCPDF (www.tcpdf.org) 50  Интерфейс Splunk Splunk reference App – PAS Подключаемая система аудита (Pluggable Auditing System, PAS), появившая ся в версии 1.0 в январе 2015 г., – это приложение Splunk, описывающее порядок разработки приложений для Splunk. Оно предназначено для демонстрации рекомендуемых приемов в дополнение к платформе разработчика Splunk. Кроме того, PAS позволяет: отслеживать неограниченное количество хранилищ документов и определять, кто просматривал, изменял, удалял либо загружал документы или другие артефакты; определять подозрительную активность; анализировать тренды. Universal forwarder Универсальный форвардер Splunk – это приложение, не требующее лицензирования, которое не является ни уникальным для Splunk Cloud, ни новым в Splunk 7.0 – оно доступно довольно давно, на протяжении нескольких выпусков. Поскольку это облачное приложение, мы не будем тратить на него много времени. Отметим только, что UF – это выделенная, легковесная версия Splunk Enterprise, содержащая только важнейшие компоненты, необходимые для пересылки данных, и предназначенная для использования на промышленных серверах, потребляя минимальное количество вычислительных ресурсов и памяти. Оно мало влияет на работу другого программного обеспечения, что делает его идеальным для использования в Splunk Cloud. eventgen eventgen – еще одно приложение, не являющееся ни уникальным для Splunk Cloud, ни новым. eventgen дает возможность случайно генерировать фиктивные события для тестирования приложений в Splunk. Генератор событий eventgen используется командой разработки Splunk для разработки многочисленных приложений, поэтому вам определенно стоит потратить время, чтобы познакомиться с ним поближе и его бесконечно гибкими настройками для имитации реальных данных. Что дальше Как отмечалось в начале этого раздела, после подписки на услугу Splunk Cloud вам будет отправлено электронное письмо с идентификатором Splunk ID, чтобы вы могли войти в свою учетную запись Splunk Cloud. Также в письме вы получите уникальное приложение, которое поможет вам настроить ваш фор- Итоги  51 вардер для передачи данных в ваш облачный экземпляр, как описывается в документации, доступной по адресу: http://docs.splunk.com/Documentation/SplunkCloud/latest/User/GetstartedwithSplunkCloud. На странице https://splunkbase.splunk.com/apps/#/product/cloud вы найдете список приложений, совместимых или доступных для Splunk Cloud. Итоги Как было показано выше, графический интерфейс Splunk дает богатые возможности для работы с результатами поиска. В этой главе мы лишь слегка затронули некоторые компоненты, но в последующих главах о многих из них расскажем гораздо подробнее. Новым в этом издании было обсуждение Splunk Cloud. В Splunk Cloud доступны многие особенности Splunk Enterprise и огромное число приложений в Splunkbase, а также есть возможность создавать свои собственные прило жения. В следующей главе мы углубимся в детали работы поиска, знание которых поможет вам эффективнее выполнять поиск и заполнять восхитительные отчеты, к созданию которых мы приступим в главе 3 «Таблицы, диаграммы и поля». Глава 2 Основы поиска Для успешного использования Splunk важно уметь эффективно выполнять поиск. Эффективное использование индексов ускорит поиск, а создаваемые вами отчеты будут работать быстрее. В этой главе мы рассмотрим следующие темы: эффективное выполнение поиска; использование полей в поиске; применение поиска по времени; сохранение и передача другим результатов поиска; аннотирование событий. Эффективное использование критериев поиска Применение индексов является ключевой технологией для создания высокой эффективности поиска. Индекс в Splunk фактически является гигантским словарем, фрагментированным по времени. Одним из важнейших факторов повышения производительности поиска является ограничение количества событий, читаемых с диска. Вот несколько ключевых моментов, которые вы должны запомнить: критерии поиска не чувствительны к регистру символов: поиск по словам error, Error, ERROR и ErRoR выдаст одинаковый результат; критерии поиска аддитивны: поиск “mary error” вернет только события, содержащие оба слова. Для изменения этого поведения по умолчанию существуют логические операторы и операторы группировки; мы поговорим о них ниже; Splunk ищет события только в указанном временном интервале: кому-то это покажется очевидным, но такое поведение сильно отличается от поведения баз данных, в которых всегда имеется единый индекс для всех событий в таблице. Так как каждый индекс разбивается на временные интервалы, проверяются только события из временного интервала, указанного в запросе; критерии поиска – это слова, а также части слов: поиск foo вернет и события со словом foobar. Зная и понимая эти предпосылки, вы сможете повысить эффективность поиска. Но давайте копнем чуть глубже. Логические операторы и операторы группировки  53 Словом считается все, что заключено между пробелами или знаками препинания (иногда даже отдельные части слов): например, из строки в журнале 2012-02-07T01:03:31.104-0600 INFO AuthClass Hello world. [user=Bobby, ip=1.2.3.3] будут индексированы слова: 2012, 02, 07T01, 03, 31, 104, 0600, INFO, AuthClass, Hello, world, user, Bobby, ip, 1, 2, 3 и 3. Такое деление может показаться странным и, возможно, немного избыточным, но именно так работает индексирование в Splunk, и во многом это правильно – иметь дело с большим количеством слов в большом количестве событий. Splunk – это не утилита grep с графическим интерфейсом: многие спрашивают – использует ли Splunk регулярные выражения для поиска. Строго говоря, нет. Но регулярные выражения используются для извлечения полей, включая поля, создаваемые автоматически, и во многих других случаях, где они могут пригодиться. Использование индекса позволяет добиться более высокой скорости поиска, а регулярные выражения вы сможете применять сами для дальнейшей фильтрации результатов или извлечения полей. Числа не считаются числами, пока не будут разобраны во время поиска: это означает, что поиск по критерию foo>5 не будет использовать индекс, так как значение foo остается неизвестным, пока событие не будет проанализировано во время поиска. Существуют разные способы обеспечить желаемое поведение, в зависимости от задачи, которую вы пытаетесь решить. Имена полей чувствительны к регистру символов: при поиске по критерию host=myhost имя поля host должно быть задано буквами нижнего регистра. Аналогично чувствительны к регистру имена любых извлекаемых или настраиваемых полей, но значения полей не чувствительны к регистру: – Host=myhost не даст нужного результата; – host=myhost будет работать; – host=MyHost будет работать. Поля не требуется определять до индексирования данных: индексированное поле – это поле, которое добавляется в метаданные события на этапе индексирования. Создание индексированных полей может объясняться самыми разными вескими причинами, но в большинстве случаев этого не требуется и даже вредно. Подробнее эта тема обсуждается в главе 3 «Таблицы, диаграммы и поля». Логические операторы и операторы группировки Есть несколько операторов, которые можно использовать для уточнения поиска (обратите внимание, что операторы должны записываться буквами верхнего регистра, чтобы они не интерпретировались как критерии поиска): 54  Основы поиска AND помещается между критериями по умолчанию. Например, error mary (два слова, разделенных пробелом) – то же самое, что и error AND mary; OR позволяет определить несколько значений. Например, error OR mary предполагает поиск событий, содержащих любое из слов; NOT помещается перед критерием или группой. Например, error NOT mary предполагает поиск событий со словом error и не содержащих слова mary; кавычки ("") отделяют целую фразу. Например, "Out of this world" предполагает поиск точной последовательности слов. Поиск по критерию Out of this world, напротив, отыщет события, содержащие все эти слова, но необязательно в таком порядке; круглые скобки ( ( ) ) используются для группировки критериев. Скобки помогают избежать путаницы в логике интерпретации. Например, следующие две инструкции эквивалентны: – bob error OR warn NOT debug; – (bob AND (error OR warn)) AND NOT debug; знак равно (=) зарезервирован для определения полей. Чтобы выполнить поиск знака равно, его можно заключить в кавычки. Также можно воспользоваться приемом экранирования, например \= то же самое, что и =; квадратные скобки ( [ ] ) используются для выполнения вложенного поиска. Подробнее об этом мы поговорим в главе 6 «Примеры продвинутого поиска». С помощью перечисленных операторов можно конструировать весьма сложные условия и даже отыскивать несколько подмножеств событий одним запросом. Вот несколько примеров: error mary NOT jacky; error NOT (mary warn) NOT (jacky error); index=myapplicationindex ( sourcetype=sourcetype1 AND ( (bob NOT error) OR (mary AND warn) ) ) OR ( sourcetype=sourcetype2 (jacky info) ). Вот как можно представить последний запрос, если добавить переносы строк и отступы для ясности: index=myapplicationindex ( sourcetype=security AND ( (bob NOT error) OR (mary AND warn) ) ) OR ( sourcetype=application (jacky info) ) Щелчки мышью могут менять критерии поиска  55 Щелчки мышью могут менять критерии поиска Возможно, вы сумеете разобраться с этим вопросом сами, щелкая мышью то тут, то там, но нам кажется, все же стоит подробнее обсудить реакцию графического интерфейса на движения и щелчки мышью: щелчок на любом слове или значении поля дает возможность добавить (Add to search (Добавить в поиск)) или исключить (Exclude from search (Исключить из поиска)) его из поиска, а также запустить новый поиск (New search (Новый поиск)), как показано на рис. 2.1; Рис. 2.1  Всплывающее меню, появляющееся после щелчок на любом слове или значении щелчок на слове или значении поля, уже имеющемся в критериях поиска, дает возможность исключить его из поиска или запустить новый поиск, как показано на рис. 2.2. Рис. 2.2  Всплывающее меню, появляющееся после щелчка на слове или значении поля, уже имеющемся в критериях поиска Сегментирование событий В предыдущих версиях Splunk сегментирование событий настраивалось с по мощью диалога Options (Параметры). В версии 6.2 этот диалог исчез, и хотя сегментирование событий (обсуждается далее в этой главе) по-прежнему остается важным понятием, его настройка в этой версии недоступна через веб-интерфейс. Виджеты полей Щелкая на полях в области Select Fields (Выбор полей) – в виджете выбора полей – или на значениях полей в результатах поиска, мы можем добавлять или исключать их из поиска, или, как было показано выше, запускать новый поиск. 56  Основы поиска Например, если под событием появится поле source=C:\Test Data\TM1Process Error_20140623213757_temp.log, вы сможете щелкнуть на значении и выбрать в открывшемся меню пункт Add to search (Добавить в поиск), чтобы добавить в поисковый запрос критерий source=C:\Test Data\TM1ProcessError_20140623213757_ temp.log, как показано на рис. 2.3. Рис. 2.3  Щелкнув на значении поля в результатах поиска, его можно добавить в число критериев Чтобы воспользоваться виджетом выбора полей, щелкните на ссылке All Fields (Все поля), как показано на рис. 2.4. Рис. 2.4  Ссылка All Fields (Все поля) В появившемся окне раскройте нужное поле, щелкнув на значке > в крайнем левом столбце. Щелкая на найденных значениях, вы сможете добавить их в критерии текущего поиска (см. рис. 2.5). Если в тексте события значение поля имеет вид key=value, воспользуйтесь одним из виджетов полей в результатах поиска, вместо того чтобы щелкать на исходном тексте события. В зависимости от настроек сегментации событий щелчок будет добавлять либо только часть значения value, либо весь текст key=value. В первом случае вы лишитесь преимущества использования поля; вместо поиска по полю будет выполнен поиск по всему тексту. Второй поиск будет искать события, содержащие точный текст в кавычках, но не найдет событий, в которых значения для данного поля извлекались другим способом. Щелчки мышью могут менять критерии поиска  57 Рис. 2.5  Щелкая на найденных значениях, можно добавить их в критерии текущего поиска Время Если щелкнуть на значении времени рядом с событием, откроется диалог _time (_время), как показано на рис. 2.6, позволяющий изменить поиск выбором конкретного интервала времени в разделе Events Before or After (События до или после). На выбор имеются следующие варианты: Before this time (До этого времени); After this time (После этого времени); At this time (В это время). Рис. 2.6  Значение времени рядом с событием Также в разделе Nearby Events (Близкие события) можно настроить плюс, минус или плюс/минус число секунд (по умолчанию), миллисекунд, минут, часов, дней или недель, как показано на рис. 2.7. 58  Основы поиска Рис. 2.7  Диалог _time (_время) Вот один из полезных приемов поиска: щелкните на времени события, выберите At this time (В это время) и затем щелкайте на кнопке Zoom out (Уменьшить масштаб) над хронологической последовательностью, пока не будет выбран желаемый диапазон времени. Использование полей в поиске Занимаясь исследованием графического интерфейса в главе 1 «Интерфейс Splunk», вы могли заметить, что поля присутствуют повсюду. Поля перечисляются в виджете выбора полей слева и под каждым событием в результатах поиска. Пользователю не нужно знать, откуда берутся поля, он просто ищет по критерию key=value. Подробнее о добавлении новых полей мы расскажем в главе 3 «Таблицы, диаграммы и поля» и в главе 11 «Настройка Splunk». Использование виджета выбора полей Виджет выбора полей дает простой доступ к полям (доступным в данный момент) в результатах поиска. Splunk может извлекать некоторые поля из найденных событий без нашей помощи, например хранящие имя хоста, источник и тип источника, значения времени и др. Также есть возможность определять свои поля. Щелчок на любом поле выводит подробную информацию об этом поле в текущих результатах поиска, как показано на рис. 2.8. Рис. 2.8  Щелчок на любом поле выводит подробную информацию о нем Эффективное использование метасимволов  59 Следуя по элементам в этом виджете, можно получить по-настоящему огромный объем информации. N Value, X% of events (Значение N, X% событий) – помогает оценить, получили ли мы результаты, которые хотели получить. Если каждое событие в результатах должно содержать это поле, но число процентов не равно 100, значит, запрос можно сделать еще более конкретным или определение поля должно быть изменено. Кроме того, N Value указывает количество уникальных значений в этом поле. Переключатель Selected (Выбрано) показывает – выбрано данное поле (Yes) или нет (No), то есть является ли частью запроса или просто было добавлено системой Splunk как потенциально интересное, обнаруженное в данных. Ссылки Top values (Топ значений), Top values by time (Топ значений по времени), Rare values (Редкие значения) и Events with this field (События с этим полем) в разделе Reports (Отчеты): – Top values (Топ значений) показывает таблицу значений, встречающихся в этом интервале времени; – Top values by time (Топ значений по времени) отображает график наиболее часто встречающихся значений, найденных в этом интервале времени; – Rare values (Редкие значения) отображает таблицу с самыми редкими значениями, встречающимися в этом поле и в этом интервале времени; – Events with this field (События с этим полем) добавляет fieldname="*" в существующий запрос, чтобы оставить в результатах только события, имеющие это поле. Если все события, которые вы пытаетесь найти, содержат имя поля (например, network), вы сможете увеличить эффективность запроса, добавив имя поля в запрос. В данном случае запрос мог бы выглядеть так: sourcetype="impl_splunk_gen" network="*" network. В разделе Values приводится список десяти наиболее часто встречающихся значений, в столбце Count (Количество) выводится число, отражающее, сколько раз встретилось это значение, а в столбце % – процент от общего числа значений, найденных в этом поле среди результатов поиска. Эффективное использование метасимволов Несмотря на то что индекс конструируется из слов, при необходимости можно использовать метасимволы (wildcard), хотя и с некоторой осторожностью. Вот несколько интересных фактов о них: эффективно обрабатываются только завершающие метасимволы: если задать критерий bob*, механизм поиска эффективно отыщет все события, содержащие слово Bobby, но для критерия *by или *ob* поиск будет 60  Основы поиска не настолько эффективен, фактически в последних двух случаях будут просканированы все события в заданном интервале времени; метасимволы проверяются последними: их проверка производится пос ле проверки всех других критериев; например, при поиске по фразе authclass *ob* hello world сначала будут найдены все совпадения со словами, кроме *ob*. Чем больше вы сможете ограничить результаты, используя полные слова и поля, тем эффективнее будут выполняться ваши запросы. Метасимволы в полях Если предположить, что имеются следующие два события: 2012-02-07T01:04:31.102-0600 INFO AuthClass Hello world. [user=Bobby, ip=1.2.3.3] 2012-02-07T01:23:34.204-0600 INFO BarClass Goodbye. [user=Bobby, ip=1.2.3.3, message="Out of this world"] тогда поиск по слову world вернет их оба. Как поступить, если требуется вернуть только второе событие, но при этом вам известно лишь, что событие содержит слово world в поле message? Запрос message="*world*" справится с задачей, но очень неэффективно, потому что система Splunk будет вынуждена проверить каждое событие на наличие *world*, а затем убедиться, что совпадение найдено в поле message. Чтобы повысить эффективность, можно взять на вооружение особенности поведения, упомянутые выше, – метасимволы проверяются последними. Переписав запрос как world message="*world*", вы дадите Splunk возможность отыскать все записи со словом world, а затем проверить найденные события на соответствие критерию с метасимволом. Все о времени Время – самый важный и самый запутанный аспект Splunk. Если вы решите пропустить этот раздел, запомните одно: время должно максимально точно анализироваться перед составлением индекса, потому что позже его нельзя будет изменить без повторного индексирования исходных данных. Как Splunk анализирует время Как бы вы интерпретировали дату 11-03-04? Ваш ответ почти наверняка будет зависеть от места, где вы живете. В США вы прочитаете эту дату как 3 ноября 2004 г. В Европе – как 11 марта 2004 г., а кто-то как 4 марта 2011 г. К счастью, большинство дат не так неоднозначно, и Splunk делает все возможное, чтобы найти и извлечь их, но вы все еще должны помочь Splunk, настроив формат времени. А как это сделать, мы подробно расскажем в главе 11 «Настройка Splunk». Все о времени  61 Как Splunk хранит время После анализа даты Splunk сохраняет ее как количество секунд в GMT от 1 января 1970 г. Сохранение всех событий в одном часовом поясе устраняет любые проблемы с выстраиванием в хронологическом порядке событий, имевших место в разных часовых поясах. Конечно, этот подход работает правильно, только если есть возможность определить часовой пояс события во время индексирования. Это числовое значение сохраняется в поле _time. Как Splunk отображает время Оригинальный текст события и содержащиеся в нем даты никогда не изменяются. События всегда отображаются в том виде, в каком они были получены. Дата, отображаемая слева от события (рис. 2.9), определяется часовым поясом сервера Splunk или предпочтениями пользователя, настроенными в его учетной записи. Рис. 2.9  Отображаемая дата определяется часовым поясом экземпляра Splunk или предпочтениями пользователя Как определяются часовые пояса, и почему это важно Поскольку время и дата всех событий хранятся как время GMT, часовой пояс события имеет значение только на этапе индексирования, но правильное его определение играет важную роль. После записи времени в индекс его нельзя будет изменить без повторной индексации исходных данных. Часовой пояс определяется по следующим значениям, в порядке предпоч тений: по часовому поясу в журнальных записях. Например, в формате записи даты 2012-02-07T01:03:23.575-0600 поле -0600 указывает, что часовой пояс отстает от GMT на 6 часов. Аналогично Tue 02 Feb, 01:03:23 CST 2012 представляет ту же самую дату; по настройкам, связанным с источником, хостом или типом источника, именно в таком порядке. Эти настройки определяются в файле props. conf. Фактически они могут иметь более высокий приоритет, чем значение часового пояса в журнальных записях. Подробнее об этом мы поговорим в главе 11 «Настройка Splunk»; по часовому поясу форвардера Splunk, переславшего события. Вместе с событиями пересылается и часовой пояс, на тот случай, если он не будет указан нигде больше. Обычно это значение используется по умолчанию. Исключением являются случаи, когда разные журналы записываются на одном хосте, но в разных часовых поясах, без указания часового 62  Основы поиска пояса в записях. В этом случае необходимо определить соответствующие настройки в props.conf; по часовому поясу сервера Splunk, выполняющего парсинг событий. Иногда это допустимо и может иметь интересные применения в распределенных окружениях. Из перечисленного следует важный вывод: часовой пояс должен быть известен на момент парсинга и индексирования события. Разные способы поиска по времени Убедившись в правильности индексирования, как выполнить поиск по времени? Виджет Date & Time Range (Дата и диапазон времени) дает на выбор полный набор параметров для поиска по времени, как показано на рис. 2.10. Рис. 2.10  Виджет Date & Time Range (Дата и диапазон времени) Здесь вы найдете следующие разделы: Presets (Предопределенные); Relative (Относительные); Real-time (В реальном времени); Data Range (Диапазон дат); Date & Time Range (Диапазон дат и времени); Advanced (Дополнительно). Рассмотрим каждый из них. Presets Раздел Presets (Предопределенные) содержит диапазоны времени, предопределенные в Splunk Enterprise. Но имейте в виду, что при поиске в потенциально больших объемах данных результаты будут возвращаться тем быстрее, чем короче период времени, в котором выполняется поиск (любой, кроме All time (real-time) (За все время (в реальном времени))). Все о времени  63 Рис. 2.11  Раздел с предопределенными настройками времени поиска Relative Если настройки в разделе Presets (Предопределенные), вам не подходят, определите в разделе Relative (Относительные) свои настройки временного интервала относительно настоящего момента времени. В раскрывающемся списке можно выбрать единицу времени, такую как Seconds Ago (Секунд тому назад), Minutes Ago (Минут тому назад) и так далее, как показано на рис. 2.12. Рис. 2.12  Раздел с настройками относительного времени поиска Splunk также дает возможность выбрать Beginning of second (По началу секунды) или No Snap-to (Без округления), чтобы указать ближайшую или последнюю единицу времени, до которой должно округляться значение времени. Если не выбрать единицу времени для округления, Splunk автоматически 64  Основы поиска выберет секунды. В отличие от предопределенных настроек в разделе Presets (Предопределенные), которые применяются к поиску сразу после выбора, здесь вам нужно щелкнуть на кнопке Apply (Применить). Real-time Настройки в разделе Real-time (В реальном времени) дают возможность определить время начала окна поиска. Имейте в виду, диапазоны времени для хронологического поиска устанавливаются относительно времени, когда выполняется поиск. При поиске в реальном времени диапазон поиска постоянно обновляется, и отображаются результаты, накопленные с начала поиска. Вы можете указать диапазон времени, представляющий скользящее окно, например последние 30 секунд, как показано на рис. 2.13. Выполняя поиск методом скользящего окна, Splunk сначала потратит время на сбор данных в этом интервале. Например, если вы выбрали размер скользя щего окна, равный 5 минутам, первые результаты вы увидите только через 5 минут. Рис. 2.13  Раздел с настройками поиска в реальном времени Поиск в реальном времени методом скользящего окна и за все время Проектируя поисковые запросы, важно помнить о различиях поиска в реальном времени внутри установленного окна (например, с протяженностью 30 секунд или 1 минуту) и за все время (All time). В поиске методом скользящего окна одни события могут исчезать из результатов, оказываясь за пределами установленного окна, а другие, появившиеся после запуска задания поиска, могут добавляться в результаты, оказываясь внутри скользящего окна. В поиске в реальном времени за все время окно распространяется на все события, поэтому они не исчезают из результатов, появившись в них. И при этом продолжают появляться новые события, появившиеся после запуска задания поиска. Для сравнения: в хронологическом поиске события никогда не исчезают из установленного диапазона времени, и последнее найденное событие всегда Все о времени  65 старше времени запуска задания поиска (за исключением случаев, когда в критерии поиска включены события с отметкой времени в будущем). Date range Раздел Date Range (Диапазон дат) можно использовать для добавления календарных дат в поиск. На выбор есть несколько вариантов возврата значений: Between (Между) начальной и конечной датами, Before (До) заданной даты и Since (После) заданной даты, как показано на рис. 2.14. В этом разделе можно вводить даты непосредственно или выбирать их с помощью виджета календаря. Рис. 2.14  Раздел с настройками поиска в диапазоне дат Date & time range В разделе Date & Time Range (Диапазон дат и времени), как показано на рисунке, можно указать календарные даты и время начала и конца интервала для поиска. И снова даты можно вводить непосредственно или воспользоваться виджетом календаря. Рис. 2.15  Раздел с настройками поиска в диапазоне дат и времени Advanced В разделе Advanced (Дополнительно) можно указать начальное и конечное время диапазона поиска. Время задавать в абсолютной форме – как количество секунд от начала эпохи Unix – или в относительной. Абсолютное время преоб- 66  Основы поиска разуется в локальное и отображается в расшифрованном виде под текстовым полем ввода для контроля, как показано на рис. 2.16. Рис. 2.16  Раздел с настройками поиска в диапазоне дат и времени Определение времени в строке запроса В запросах тоже можно указывать относительное и абсолютное время, определяющее интервал поиска. Например, выполняя поиск по словам bob error, можно напрямую определить интервал времени, задав значения полей earliest и latest: отыскать ошибки, обусловленные влиянием пользователя bob за последние 60 минут, можно с помощью запроса earliest=-60m bob error; отыскать ошибки, обусловленные влиянием пользователя bob за последние 3 часа, с привязкой к началу часа, можно с помощью запроса earliest=-3h@h bob error; отыскать вчерашние ошибки, обусловленные влиянием пользователя bob, можно с помощью запроса earliest=-1d@d latest=-0d@d bob error; отыскать ошибки, возникшие после полуночи в понедельник и обусловленные влиянием пользователя bob, можно с помощью запроса earliest=-0@w1 bob error. В одном запросе можно указать только один диапазон времени; например, логический запрос (earliest=-1d@d latest=-0d@d bob error) OR (earliest=-2d@d latest=-1d@d mary error) не будет работать. Добиться желаемого можно с по мощью команды append (или union). _indextime и _time Важно отметить, что события принимаются в другое время, отличное от указанного в них. Расхождение обычно составляет несколько секунд, но если журналы пересылаются пакетами, отставание может быть еще больше. Время, когда событие попало в индекс Splunk, хранится во внутреннем поле _indextime. Время, полученное из события, хранится в поле _time. Вам едва ли потребуется использовать _indextime в поисковых запросах, но вы должны понимать, что время в этом поле отличается от времени, с которым индексируются события. Ускорение поиска  67 Ускорение поиска Мы уже говорили, что использование индекса ускоряет поиск. Начиная новый эксперимент, выполните следующие несколько шагов, они помогут вам получить результаты быстрее. 1.Установите нижнюю границу интервала времени, которая, по вашему мнению, потребуется для обнаружения искомых событий. Даже для очень подробного журнала это займет меньше минуты. Если время события неизвестно, можно выполнить поиск на более широком интервале и затем увеличить масштаб, щелкая на временной шкале и увеличивая масштаб в процессе выполнения поиска. 2.Укажите индекс, если у вас их несколько. Это очень хорошая привычка – всегда начинать запросы с имени индекса. Например, index=myapplicationindex error bob. 3.Укажите другие поля, имеющие отношение к поиску. Обычно это поля sourcetype и host. Например, index=myapplicationindex sourcetype="impl_ splunk_gen" error bob. Если вы поймаете себя на том, что постоянно указываете поле source, возможно, вам поможет определение большего количества типов источников. Не используйте поле sourcetype для сохранения посторонней информации, например дата-центра или окружения. Возможно, вам также поможет добавление поля host в запросы или создание в индексе другого поля для таких случаев. 4.Добавьте в запрос больше слов или полей, которые присутствуют в искомых событиях. Для этого можно просто щелкать на словах или полях в событиях, или на значениях полей в виджете выбора полей. Например, index=myapplicationindex sourcetype="impl_splunk_gen" error bob authclass OR fooclass. 5.После обнаружения искомых событий увеличьте интервал времени и уточните критерии поиска. 6.Чтобы запретить автоматическое определение полей в ранних версиях Splunk, достаточно было щелкнуть на переключателе в верхней части в виджете выбора полей. В версии 6.2 (и выше) ситуация немного изменилась. Вы можете просто открыть виджет выбора полей и, используя кнопки Select All Within Filter (Выбрать все в фильтре) или Deselect All (Выключить все), удалить ненужные поля из списка извлекаемых системой Splunk. Это может значительно увеличить скорость, особенно если запрос извлекает большое количество событий. Извлечение всех полей из событий требует много времени, и отключение этой функции избавит Splunk от лишней работы. Взгляните на рис. 2.17. Если ваш запрос обрабатывается слишком долго и вы планируете использовать его регулярно – например, для получения предупреждений или в какомто дашборде, – возможно, вам поможет создание summary-индекса. Подробнее об этом мы поговорим в главе 10 «Сводные индексы и файлы CSV». 68  Основы поиска Рис. 2.17  Выбор всех полей отключен Передача результатов другим Часто бывает желательно поделиться результатами поиска с другими пользователями. Результаты можно экспортировать в файл CSV и переслать его, но это неудобно. В ранних версиях Splunk можно было определить адрес URL для сохранения и передачи результатов; однако в версии 6.2 произошли некоторые изменения (хотя возможность передавать результаты в определенный URL сохранилась). Адрес URL Чтобы поделиться результатами поиска через URL в закладках, щелкните на значке «Поделиться» и откройте диалог Share Job (Поделиться заданием), изображенный на рис. 2.18. Рис. 2.18  Диалог Share Job (Поделиться заданием) Здесь можно просто щелкнуть правой кнопкой на значке «Поделиться» и добавить URL в закладки для использования в будущем (рис. 2.19). Результатами поиска и текстом запроса также можно поделиться другими способами, для начала выбрав в меню пункт Save As link (Сохранить как ссылку), как показано на рис. 2.19. После этого будет предложено несколько вариантов сохранения запроса и результатов: Report (Отчет); Dashboard Panel (Панель мониторинга); Alert (Оповещение); Event Type (Тип события). Передача результатов другим  69 Рис. 2.19  Здесь можно добавить URL в закладки Сохранение в виде отчета Чтобы сохранить результаты поиска в виде отчета, щелкните на ссылке Report (Отчет). В результате откроется диалог Save As Report (Сохранить как отчет), изображенный на рис. 2.20. Рис. 2.20  Диалог Save As Report (Сохранить как отчет) Здесь вы должны: 1) ввести в поле Title (Название) название (или имя) отчета; 2)ввести в поле Description (Описание) необязательное описание, которое будет напоминать пользователям, что делает этот отчет; 3)указать, нужно ли включить в отчет виджет выбора времени, выбрав в переключателе Time Range Picker (Виджет выбора времени) значение Yes (Да) или No (Нет). После щелчка на кнопке Save (Сохранить) Splunk предложит определить дополнительные настройки вновь созданного отчета (Permissions (Разрешения), Schedule (Расписание), Acceleration (Ускорение) и Embed (Встраивание)), до- 70  Основы поиска бавить (отчет) в дашборд щелчком на кнопке Add to Dashboard (о дашбордах подробно рассказывается в главе 5 «Дашборды на упрощенном XML»), просмот реть отчет щелчком на кнопке View (Посмотреть) или продолжить редактирование щелчком на кнопке Continue Editing (Продолжить правку), как показано на рис. 2.21. Рис. 2.21  Диалог выбора варианта дальнейших действий после создания отчета В этом примере я дал отчету название My Error Report (Мой отчет об ошибках), добавил описание (a simple example of a save as report – простой пример сохранения результатов поиска в виде отчета) и включил поддержку виджета выбора времени. На рис. 2.22 показано, как выглядит сохраненный отчет после щелчка на кнопке View (Посмотреть). Рис. 2.22  Вид сохраненного отчета Вот какие дополнительные настройки доступны для отчета. Permissions (Разрешения): позволяет определить, кем может отображаться сохраненный отчет: владельцем, приложением или любыми приложениями. Также отчет можно сделать доступным только для чтения или редактируемым. Передача результатов другим  71 Schedule (Расписание): позволяет определить расписание запуска/обновления отчета. Например, раз в неделю, по понедельникам в 6:00 или в течение некоторого интервала времени (как описывалось выше). Acceleration (Ускорение): не все сохраненные отчеты можно ускорить, и не все пользователи (и даже администраторы) имеют возможность ускорить отчеты. Простыми словами, Splunk Enterprise позволит создать acceleration отчет, если определит, что тот выиграет от ускорения. Подробнее эту тему мы обсудим позже. Embed (Встраивание): встраивание отчета позволяет внедрить результаты из вашего отчета во внешние источники. Посредством механизма встраивания можно внедрять свои отчеты, выполняющиеся по расписанию, в страницы на внешних веб-сайтах (не Splunk), дашборды и порталы. Встраиваемые отчеты могут отображать результаты в форме списков событий, таблиц, диаграмм, карт, одиночных значений или любых других типов визуальных элементов. В них используется то же форматирование, что и в оригинальном отчете. Встраивание сохраняемого отчета производится копированием в веб-страницы адреса URL (см. рис. 2.23), сгенерированного системой Splunk. Рис. 2.23  Адрес URL встраиваемого отчета, сгенерированный системой Splunk Сохранение в виде дашборда Дашборды мы будем обсуждать в главе 5 «Дашборды на упрощенном XML», а пока просто запомните, что результаты поиска можно сохранить в виде новой панели или в виде вставки в существующей. При этом имеется возможность настроить дополнительные разрешения, как показано на рис. 2.24. 72  Основы поиска Рис. 2.24  Диалог сохранения в виде дашборда Сохранение в виде оповещения Оповещение – это действие, которое запускает сохраненный поиск, исходя из конкретных результатов. При создании оповещения вы указываете условие, при котором оно генерируется (обычно сохраненный отчет с условием запус ка). После щелчка на ссылке Save as Alert (Сохранить как оповещение) откроется диалог, изображенный на рис. 2.25, с настройками сохранения поиска в виде оповещения. Рис. 2.25  Диалог с настройками сохранения поиска в виде оповещения Настройки задания поиска  73 Сохранение в виде типа события Типы событий (event types) – это система категорий, помогающая разобраться в данных. Она упрощает поиск, позволяя классифицировать события. Event types определяют множества событий с общими характеристиками. В процессе поиска события сопоставляются с известными event types. Тип присваивается событию во время поиска, если оно соответствует определению типа. Самый простой способ создать новый тип события – воспользоваться вебинтерфейсом Splunk. После запуска поиска, который производит нужный вам тип событий, щелкните на меню Save As (Сохранить как) и выберите ссылку Event Type (Тип события). После этого откроется диалог Save as Event Type (Сохранить как тип события), где можно ввести имя типа и дополнительные теги, как показано на рис. 2.26. Рис. 2.26  Диалог Save as Event Type (Сохранить как тип события) Настройки задания поиска После запуска поиска можно получить доступ к информации о выполнении поиска (отдельному экземпляру выполняющегося или завершившегося поиска, сводной таблице или отчету, а также к его результатам), не покидая страницу поиска. Для этого щелкните на меню Job (Задание) и выберите один из доступных пунктов, как показано на рис. 2.27. Рис. 2.27  Меню Job (Задание) 74  Основы поиска Ниже перечислены ссылки, доступные в меню. Edit Job Settings (Изменить настройки задания): открывает диалог Job Settings (Настройки задания), где можно изменить разрешения на чтение задания, расширить срок действия и получить URL для передачи другим пользователям. Ссылку на задание также можно сохранить в закладках браузера. Send Job to Background (Перевести задание в фоновый режим): если задание выполняется слишком медленно, его можно перевести в фоновый режим и заняться чем-то другим в Splunk Enterprise (в том числе и запустить новое задание). Inspect Job (Исследовать задание): открывает новое окно и выводит информацию и параметры задания в инспекторе задания поиска Search Job Inspector. Delete Job (Удалить задание): используйте эту ссылку, чтобы удалить задание, выполняющееся в данный момент, приостановленное или завершенное. Даже удалив задание, вы все еще сможете сохранить поиск как отчет. Сохранение поиска для повторного использования Давайте в качестве примера сконструируем поисковый запрос, сохраним его (как отчет) и затем сделаем из него оповещение. Для начала отыщем ошибки, обусловленные действиями пользователя mary, одного из четырех основных пользователей. Этот запрос выглядит просто: mary error. Взглянув на некоторые результаты, соответствующие этому запросу, можно заметить, что не все найденные события представляют интерес (даты опущены для краткости): ERROR LogoutClass error, ERROR, Error! [user=mary, ip=3.2.4.5] WARN AuthClass error, ERROR, Error! [user=mary, ip=1.2.3.3] ERROR BarCLass Hello world. [user=mary, ip=4.3.2.1] WARN LogoutClass error, ERROR, Error! [user=mary, ip=1.2.3.4] DEBUG FooClass error, ERROR, Error! [user=mary, ip=3.2.4.5] ERROR AuthClass Nothing happened. This is worthless. Don't log this. [user=mary, ip=1.2.3.3] Мы могли бы пропустить сообщения DEBUG; сообщения LogoutClass нам тоже неинтересны, и последнее сообщение фактически говорит, что нет никакого смысла. Ограничим результаты, уточнив запрос mary error NOT debug NOT worthless NOT logoutclass: WARN AuthClass error, ERROR, Error! [user=mary, ip=1.2.3.3] ERROR BarCLass Hello world. [user=mary, ip=4.3.2.1] Следуя правилам хорошего тона, добавим также поле sourcetype и несколько круглых скобок: sourcetype="impl_splunk_gen" (mary AND error) NOT debug NOT worthless NOT logoutclass Сохранение поиска для повторного использования  75 Этот запрос можно записать иначе: sourcetype="impl_splunk_gen" mary error NOT (debug OR worthless OR logoutclass) Чтобы в будущем не вводить этот запрос вновь, сохраним его как отчет для быстрого получения результатов. Сначала выберите в меню Save As... (Сохранить как…) пункт Report (Отчет). В результате появится окно диалога Save As Report (Сохранить как отчет), как показано на рис. 2.28. Рис. 2.28  Сохранение запроса в виде отчета Введите название в поле Title (Название), в данном случае используем название errors affecting mary (ошибки пользователя mary). Добавьте также необязательное описание. Временной диапазон при каждом поиске будет устанавливаться заново, поэтому добавим виджет выбора времени в сохраняемый отчет. После щелчка на кнопке Save (Сохранить) откроется диалог, изображенный на рис. 2.29. Рис. 2.29  Варианты дальнейших действий после создания отчета 76  Основы поиска Затем щелкните на ссылке Permissions (Разрешения), чтобы перейти в диалог Edit Permissions (Изменить разрешения), изображенный на рис. 2.30. Рис. 2.30  Варианты дальнейших действий после создания отчета В разделе Display For (Отображать для) выберите App (Приложение) вместо значения по умолчанию Owner (Владелец), как показано на рис. 2.31. Рис. 2.31  Выбор разрешения App (Приложение) Затем установите флажок Read (Чтение) для всех ролей пользователей, кроме power, поскольку известно, что некоторые пользователи в нашей системе Splunk являются членами этой группы (включая нашего друга mary). Наконец, щелкните на кнопке Save (Сохранить). Теперь поиск в виде отчета стал доступен в разделе Reports (Отчеты), как показано на рис. 2.32. Создание оповещения на основе поиска  77 Рис. 2.32  Поиск в виде отчета доступен в разделе Reports (Отчеты) Если теперь выбрать этот отчет, запустится поиск по самым последним данным. Создание оповещения на основе поиска Давайте продолжим наш пример. Возьмем за основу наш запрос, определим расписание его выполнения и настроим создание оповещения. Любой сохраненный поисковый запрос можно также запускать по расписанию. Такие запросы с расписанием запуска часто используются для создания оповещений. А теперь продолжим наш пример. Перейдите на страницу Reports (Отчеты), изображенную на рис. 2.32, и щелкните на ссылке Open in Search (Открыть в приложении поиска) в строке с нашим отчетом (errors affecting mary). В результате отчет будет открыт не как отчет, но как поисковый запрос (который тут же запустится на выполнение). На этой странице выберите в меню Save As (Сохранить как) пункт Alert (Оповещение). В открывшемся окне Save As Alert (Сохранить как оповещение), изображенном на рис. 2.33, заполните поля соответствующей информацией: Рис. 2.33  Сохранение запроса в виде оповещения 78  Основы поиска Title (Название): я сохранил оригинальное название (errors affecting mary), но добавил слово alert (оповещение); Description (Описание): я сохранил прежнее описание, но вообще его можно было бы расширить; Alert Type (Тип оповещения): я выбрал Scheduled (По расписанию), потому что пожелал, чтобы это оповещение генерировалось каждый день; Time Range (Интервал времени): я выбрал предопределенный интервал Run every day (Запускать каждый день); Schedule At (Запускать в): здесь я выбрал предопределенное время запуска 12:00; Trigger condition (Условие отправки): я выбрал предопределенное условие Number of Results (Число результатов), поскольку хочу, чтобы оповещение посылалось, когда поиск вернет ненулевое число ошибок, вызванных действиями моего любимого пользователя mary; Trigger if number of results (Отправлять, если число результатов): я выбрал предопределенное значение is Greater than (Больше, чем) и указал ноль (то есть меня интересует любое число найденных ошибок). После заполнения всех полей щелкнем на кнопке Next (Далее), чтобы открыть следующую страницу диалога с дополнительной информацией, как показано на рис. 2.34. Рис. 2.34  Следующая страница диалога с дополнительной информацией Создание оповещения на основе поиска  79 На этот раз окно диалога разделено на три области: Enable Actions (Разрешенные действия), Action Options (Параметры действий) и Sharing (Совместное использование). Enable Actions Этот раздел содержит следующие поля: List in Triggered Alerts (Перечислять в сгенерированных оповещениях): если установить этот флажок, сгенерированное оповещение будет отображаться в диспетчере оповещений Splunk Alert Manager, который выводит список оповещений, сгенерированных за последние 24 часа или за другой указанный интервал; Send Email (Послать по электронной почте): оповещение можно настроить так, что оно будет посылаться по электронной почте выбранным пользователям; Run a Script (Запустить скрипт): при появлении оповещения Splunk может запускать скрипты. Action Options Раздел Action Options (Параметры действий) содержит следующие поля: When triggered, execute actions (Выполнять действия при появлении): Once (Один раз) или For each result (Для каждого результата), то есть должно ли указанное действие выполняться один раз для всех ошибок, допущенных пользователем mary в указанном интервале времени, или для каждой ошибки отдельно? Throttle (Прекращать): выполнение действия можно прекратить (обычно исходя из времени или количества ошибок), чтобы уменьшить частоту отправки оповещений, потому что для похожих результатов поиска оповещения могут приходить слишком часто. Sharing Значения Private (Скрыто) и Shared in App (Совместное использование в приложении) в разделе Permissions (Разрешения), как показано на рис. 2.35, определяют доступность оповещения для других пользователей. В этом примере я решил посылать пользователю mary электронное письмо (marys@splunker.com) со ссылкой на оповещение и результаты поиска, чтобы она могла видеть свои ошибки. Кроме того (как показано на рис. 2.36), я решил посылать письмо только один раз (для всех событий/ошибок, случившихся в течение суток) и оставил оповещение скрытым от других пользователей. 80  Основы поиска Рис. 2.35  Настройка доступности для других пользователей Рис. 2.36  Письмо посылается только один раз, и само оповещение скрыто от других пользователей После щелчка на кнопке Save (Сохранить) система Splunk будет готова посылать оповещение (рис. 2.37). Аннотирование событий  81 Рис. 2.37  Система Splunk готова посылать оповещение Аннотирование событий Аннотация – это пояснение или комментарий; аннотирование событий – это новая возможность, появившаяся в Splunk 7.0. Благодаря ей теперь можно добавлять пояснения к временным графикам в Splunk. Аннотации к событиям отображаются в виде цветных флажков со временем и текстом описания, которые появляются при наведении указателя мыши на них, как показано на рис. 2.38. Рис. 2.38  Отображение аннотации на временном графике Чтобы показать, как можно использовать аннотации, Splunk предлагает пример, где администраторы отслеживают журналы, отыскивая ошибки входа пользователей. В Splunk есть пример диаграммы, созданной для отображения количества ошибок входа с течением времени, и добавленной аннотацией, чтобы отметить время, когда доступ к серверам был закрыт на время обслуживания. С аннотированными периодами отключения серверов легко понять, что два события (остановка серверов и ошибки входа) взаимосвязаны. Такое использование аннотаций дает возможность определять зависимости между двумя дискретными наборами данных. Аннотации событий создаются в виде простых фрагментов XML, отыскиваются системой Splunk командой поиска search type="annotation" и поддерживаются только для линейных графиков, столбчатых диаграмм и гистограмм. 82  Основы поиска Иллюстрация Для иллюстрации рассмотрим запрос timecount в дашборде Splunk. Открыв дашборд, вы увидите следующий запрос, подсчитывающий вхождения слова error в журналах, индексированных с типом источника, название которого начинается с tm1: sourcetype="tm1*" error | timechart count Допустим, нам известно, что иногда разные процессы ETL неактивны, и нам хотелось бы найти связь между этими простоями и числом возникающих ошибок. Для этого создадим следующий аннотирующий запрос: <query>sourcetype="tm1*" error | timechart count</query> <earliest>-30week</earliest> <latest>-1weeks</latest> <sampleRatio>1</sampleRatio> Затем добавим его в разметку XML панели (в виде элемента search type="annotation"), как показано на рис. 2.39. Рис. 2.39  Разметка XML с определением дашборда и добавленной аннотацией Сохранив дашборд, можно посмотреть на получившийся результат (рис. 2.40). Рис. 2.40  Результат добавления аннотации в дашборд Итоги  83 Теперь можно получить контекст события для любой временной диаграммы, а маркеры аннотаций и метки событий можно получать из таких источников, как журналы, файлы или внешние источники. И все в единственном представлении! Итоги В этой главе мы познакомились с особенностями поиска в Splunk и узнали, что можно сделать с результатами. По мере продвижения вперед мы познакомимся еще со множеством разных маленьких хитростей. В Splunk 7.0 появилась возможность аннотирования событий, поэтому мы добавили раздел, посвященный этой теме. В следующей главе мы начнем использовать поля; научимся создавать таб лицы и графики, а затем узнаем, как выделить свои поля. Глава 3 Таблицы, диаграммы и поля Теперь мы знаем, как искать и извлекать исходные события, но вам почти наверняка понадобится создавать таблицы или диаграммы для демонстрации выявленных закономерностей. К счастью, в Splunk имеются команды, упрощающие создание отчетов. В этой главе мы рассмотрим несколько типичных случаев их использования. Потом вы узнаете, как создавать свои поля для событий с целью дополнительной настройки отчетов. В частности, в этой главе рассматриваются следующие темы: символ вертикальной черты (|); использование команды top для вывода типичных значений полей; использование команды stats для агрегирования значений; использование команды chart для представления данных; использование команды timechart для вывода графика изменения значений с течением времени; работа с полями; acceleration (агрегирование); расширенная поддержка диаграмм в версии 7.0. О символе вертикальной черты Прежде чем приступать к изучению конкретных команд, важно разобраться с особенностями использования символа вертикальной черты (|) в Splunk. В командной строке этот символ используется для организации передачи данных от одного процесса другому. Например, в Unix-подобных операционных системах можно записать такую команду: grep foo access.log | grep bar Первая команда (grep foo access.log) отыщет в файле access.log строки с последовательностью символов foo. Ее вывод будет подхвачен и передан на вход следующей команды (grep bar), которая в предыдущих результатах строки с последовательностью символов bar. Окончательный результат будет отправлен туда, куда ему суждено попасть, обычно в окно терминала. Вывод типичных значений полей командой top  85 В Splunk символ вертикальной черты имеет два важных отличия. В отличие от командной строки, события – это не просто текст, каждое из них представлено множеством пар ключ/значение. Событие можно рассматривать как запись в базе данных, словарь в Python, объект в Java Script, ассоциативный массив в Java или Perl. Некоторые поля скрыты от пользователя, но доступны внутренним механизмам. Имена многих скрытых полей начинаются с символа подчеркивания, например поле _raw содержит исходный текст события, а поле _time – время UTC в виде числа секунд от начала эпохи Unix. В отличие от записей в базе данных, структура событий не имеет строго предопределенной схемы и поля в них определяются динамически. Команды могут выполнять любые операции с полученными событиями. Обычно команда производит одно из следующих действий: – изменяет или создает поля, как, например, eval и rex; – фильтрует события, как, например, head и where; – заменяет события отчетами, как, например, top и stats; – сортирует результаты поиска с помощью sort. Некоторые команды могут действовать в роли генераторов, производя то, что мы обычно называем синтетическими (искусственными) событиями, как, например, |metadata и |inputcsv. А теперь продолжим знакомство с особенностями использования символа вертикальной черты на примерах. Вывод типичных значений полей командой top В практике часто возникает вопрос: «Какие значения встречаются чаще всего?» При поиске ошибок почти всегда важно выяснить, какой фрагмент кода производит больше всего ошибок. Команда top позволяет легко ответить на этот вопрос. Рассмотрим несколько примеров. Сначала запустим поиск ошибок: sourcetype="tm1*" error Этот запрос отыщет слово error во всех событиях с типом источника, начинающимся с символов "tm1*" (звездочка здесь – это шаблонный символ). На рис. 3.1 показан скриншот с событиями, найденными этим запросом в моих данных. 86  Таблицы, диаграммы и поля Рис. 3.1  Фрагмент списка событий, в которых найдено слово error Поскольку я знаю, что поиск выполняется в данных, состоящих из файлов журналов приложения, накопившихся за год, мне интересно узнать, в каком месяце было зафиксировано ошибок больше всего. Для этого достаточно добавить | top date_month в запрос: sourcetype="tm1*" error | top date_month Команда top преобразовала результаты в таблицу, как показано на рис. 3.2. Рис. 3.2  Результат работы команды top Из результатов видно, что в октябре было зафиксировано значительно больше ошибок, чем в другие месяцы. Возможно, стоит обратить особое внимание на происходившее в тот период. Далее, у вас может возникнуть желание определить дни недели, когда эти ошибки случались чаще. Добавим в конец команды еще одно имя поля, потребовав от команды top выполнить дополнительное дробление данных. Например, добавим в команду поле date_wday: sourcetype="tm1*" error | top date_month date_wday У меня получились результаты, изображенные на рис. 3.3. Из этих результатов видно, что большая часть ошибок фиксировалась в октябре по средам (wednesday). Чтобы просто увидеть распределение ошибок по дням недели, достаточно указать только одно поле: sourcetype=tm1* error | top date_wday Вывод типичных значений полей командой top  87 Рис. 3.3  Результат добавления имени поля date_wday Управление выводом команды top По умолчанию команда top отбирает 10 самых часто встречающихся значений. Максимально возможное количество равно произведению всех указанных полей, в данном случае date_month и date_wday. В данных, использованных для этого примера, возможно восемь комбинаций. Чтобы увидеть меньше десяти строк (или меньше восьми, как в этом примере), добавьте аргумент limit: sourcetype=tm1* error | top limit=4 date_month date_wday Аргументы изменяют поведение команд; они имеют форму имя=значение. Многие команды требуют, чтобы аргументы следовали сразу за ними, поэтому старайтесь всегда следовать этой структуре. Команды принимают разные аргументы в зависимости от обстоятельств. При вводе запроса в строке поиска появляется всплывающая подсказка со справкой для последней введенной команды, как показано на рис. 3.4. Рис. 3.4  Всплывающая подсказка со справкой для последней введенной команды Вверху слева на рис. 3.4 можно видеть раздел Matching searches (Похожие запросы); если справочной системе не удастся подобрать похожие запросы, этот раздел не появится. 88  Таблицы, диаграммы и поля Щелчок на ссылке Help (Справка) откроет страницу документации с описанием команды, размещенную на http://www.splunk.com, а щелчок на ссылке More >> (Еще >>) откроет краткую встроенную справку. Попробуем воспользоваться доступными аргументами, чтобы сократить список с результатами и включить все невместившиеся результаты в отдельную строку: sourcetype=tm1* error | top limit=4 useother=true otherstr=everything else date_month date_wday Этот запрос выведет таблицу, изображенную на рис. 3.5. Рис. 3.5  Ограничение размера списка с результатами Последняя строка представляет все результаты поиска, не попавшие в первые четыре строки. Эта последняя строка создается благодаря добавлению параметра useother, а параметр otherstr определяет текст подписи в этой строке, который будет выводиться вместо текста по умолчанию other (другие). Дополнительную информацию о команде top и ее параметрах можно найти в документации Splunk по адресу: http://docs.splunk.com/Documentation/ Splunk/7.0.0/SearchReference/Top. Противоположностью команде top является команда rare. Агрегирование значений с помощью команды stats Хотя команда top очень удобна, она уступает по гибкости команде stats. Команда stats имеет следующий базовый синтаксис: stats functions by fields Команда stats поддерживает большое количество функций, похожих на функции в SQL или Excel, но также есть функции, уникальные для Splunk. Самая простая функция – count. Следующий запрос вернет точно одну строку со значением счетчика: sourcetype=tm1* error | stats count Если добавить предложение by, команда stats выведет по одной строке на каждое уникальное значение для каждого указанного поля, как это делает команда top. Например, следующий запрос: Агрегирование значений с помощью команды stats  89 sourcetype=tm1* error | stats count by date_month date_wday вернет результаты, изображенные на рис. 3.6. Рис. 3.6  Результаты подсчета уникальных значений по полям Из представленных результатов можно сделать следующие важные выводы. Результаты сортируются в порядке перечисления полей в предложении by, в данном случае сначала по месяцу (date_month), а затем по дню недели (date_wday). В отличие от команды top, наибольшее значение может оказаться не в самой верхней строке. Чтобы отсортировать по нужному столбцу, в графическом интерфейсе достаточно щелкнуть на его заголовке, или воспользоваться командой sort. На количество строк не накладывается никаких ограничений – их число равно числу всех возможных комбинаций значений в полях. Результат функции отображается в последнем столбце. В следующем примере мы добавим еще несколько функций, и это утверждение станет очевиднее. Команде stats можно передать столько функций и полей, сколько понадобится. Попробуем выполнить такой запрос: sourcetype=tm1* error | stats count avg(linecount) max(linecount) as "Slowest Time" by date_month date_wday Результат показан на рис. 3.7. Для большей ясности рассмотрим каждую часть запроса: sourcetype=tm1* error – это сам запрос; | stats – вызов команды stats; count – вернет число событий; avg(linecount) – вернет среднее значение в поле linecount; max(linecount) as Slowest Time – выберет максимальное значение в поле linecount и поместит его в поле с именем Slowest Time (Наибольшее время); кавычки в данном случае совершенно необходимы ("Slowest Time"), потому что имя поля содержит пробел; by – указывает, что список функций закончился и далее следует список полей для дробления результатов; если дробить результаты не нужно, предложение by и имена полей за ним можно опустить; 90  Таблицы, диаграммы и поля date_month date_wday – список полей для дробления результатов; все функции фактически оперируют всеми данными, отобранными по всем возможным комбинациям date_month и date_user. Рис. 3.7  Результат применения нескольких функций в команде stats Если в событии отсутствует поле, указанное в команде stats, вы можете увидеть не те результаты, что ожидаете. Например, при подсчете среднего может потребоваться учитывать события без указанного поля, как имеющие нулевое значение в нем. Кроме того, события, не имеющие полей, перечисленных в списке by, просто игнорируются. Решить обе эти проблемы можно с помощью команды fillnull, добавляющей отсутствующие поля. Подробнее мы рассмотрим ее в главе 6 «Примеры продвинутого поиска». Теперь рассмотрим другой пример, где используем функции времени и одну небольшую хитрость. Представьте, что нам захотелось узнать, когда в последний раз пользователь наблюдал ошибку каждый день. Для этого воспользуемся таким запросом: sourcetype=tm1* Error TheUser="Admin" | stats count first(date_wday) max(_time) as _time by source Этот запрос выведет таблицу, изображенную на рис. 3.8. Рис. 3.8  Когда в последний раз пользователь наблюдал ошибку каждый день Рассмотрим этот запрос по шагам: sourcetype=tm1* Error TheUser="Admin" – запрос, который отыщет все ошибки, обусловленные действиями пользователя "Admin"; | stats – наша команда; Представление данных с помощью команды chart  91 count – подсчитает, сколько раз этот пользователь наблюдал ошибку каждый день; first(date_wday) – вернет день недели, когда в последний раз зафиксирована ошибка, обусловленная действиями этого пользователя; это будет самое последнее событие, потому что результаты возвращаются в порядке сортировки от самых свежих к самым старым; max(_time) as _time вернет время, когда пользователь в последний раз наблюдал ошибку в этот день; в данном случае используются три аспекта учета времени в Splunk: – _time всегда представляет время, указанное в исходном событии; как обсуждалось в главе 2 «Основы поиска», это поле хранит время UTC в виде числа секунд, прошедших с полуночи 1 января 1970 г.; – _time хранится и интерпретируется как число; – если в результатах присутствует поле с именем _time, Splunk всегда будет отображать его первым, преобразуя его значение в часовой пояс, выбранный пользователем; by source – поле для дробления результатов, в данном случае дробление происходит по источнику данных, то есть по именам файлов журналов, где обнаружены ошибки. Мы увидели здесь лишь несколько функций, поддерживаемых командой stats. На самом деле их несколько десятков, и многие имеют довольно сложный синтаксис, но о них мы поговорим в последующих главах. Отыскать полный список этих функций вы легко сможете с помощью своей любимой поисковой системы. Представление данных с помощью команды chart Команду chart удобно использовать для представления двумерных данных, в виде таблиц или диаграмм. Возьмем для примера один из предыдущих запросов с командой stats: sourcetype="tm1*" error | chart count over date_month by date_wday На рис. 3.9 показано, как выглядят результаты в табличном представлении. Рис. 3.9  Результаты в табличном представлении Если вернуться к результатам, возвращаемым командой stats, можно увидеть, что для каждой комбинации выводится отдельная строка. Вместо строки на комбинацию команда chart генерирует пересечение двух полей. Вы можете задать несколько функций, но только по одному полю для каждой в предложениях over и by. 92  Таблицы, диаграммы и поля Поменяв поля местами (в инструкции поиска), можно представить данные в другом виде, как показано на рис. 3.10. Рис. 3.10  Результаты после изменения порядка полей Щелкнув на вкладке Visualization (Визуализация), справа от вкладки Statistics (Статистики), можно увидеть те же данные в виде диаграммы, как показано на рис. 3.11. Рис. 3.11  Результаты в виде диаграммы Это площадная диаграмма с определенными настройками. Внутри диаграммы можно выбрать меню Area (Площадная) и изменить тип диаграммы (Line (Линейная), Area (Площадная), Column (Столбиковая), Bar (Гистограмма) и т. д.) или меню Format (Формат) и изменить параметры оформления (Stack (С накоплением), Null Values (Пустые значения), Multi-series Mode (Несколько графиков) и Drilldown (Детализированная)). Названия типов диаграмм говорят за себя сами, поэтому двинемся дальше и познакомимся с параметрами Format (Формат), сгруппированными в разделы. General (Общие): в разделе General (Общие) находятся параметры: Stack Model (Модель с накоплением), который определяет, как Splunk будет отображать столбики диаграммы для разных серий – рядом друг с другом или как один столбик; Null Values (Пустые значения) – управляет обработкой пустых (отсутствующих) значений (в соответствующих им точках можно оставлять пустые места, присваивать нулевые значения или просто соединять со следующей имеющейся точкой); Multi-series Mode (Несколько графиков) – подразумевает два варианта – Yes (Да) или No (Нет); и Drilldown (Детализированная) – тоже два варианта, on (включено) и off (выключено). Отображение шкалы времени с помощью timechart  93 X-Axis (Ось X): управляет визуальным представлением. Здесь можно задать свой заголовок, возможность усечения меток и угол поворота текстовых меток. Y-Axis (Ось Y): здесь можно задать не только свой заголовок, но также масштаб (линейный или логарифмический), интервал и минимальное и максимальное значения. Chart Overlay (Накладываемая диаграмма): здесь можно настроить следующие параметры: – Overlay (Наложение): позволяет выбрать поле для наложения; – View as Axis (Показать как ось): выбор значения On (Включить) позволяет отобразить вторую ось Y; – Title (Заголовок): заголовок для наложения; – Scale (Масштаб): предлагает на выбор значения Inherit (Унаследованный), Linear (Линейный) и Log (Логарифмический). В случае выбора значения Inherit (Унаследованный) будет использоваться масштаб, принятый в базовой диаграмме; в случае выбора Log (Логарифмический) будет использоваться логарифмический масштаб, что очень удобно для отображения графиков, в которых имеются значительные пиковые значения; – Interval (Интервал): расстояние между отметками на осях; – Min Value (Минимальное значение): минимальное значение для отображения; значения меньше этой величины не появятся на диаграмме; – Max Value (Максимальное значение): максимальное значение для отображения; значения больше этой величины не появятся на диаграмме. Legend (Легенда): в этом разделе с помощью параметра Position (Позиция) можно определить местоположение легенды или исключить ее из отображения, а с помощью параметра Truncation (Усечение) настроить отображение длинных названий. Имейте в виду, что в зависимости от результатов поиска и параметров визуализации вы можете получить бесполезный результат. По этой причине рекомендуется не отступать, а попробовать поэкспериментировать с разными настройками. Отображение шкалы времени с помощью timechart Команда timechart дает возможность вывести график изменения числовых значений с течением времени. Она похожа на команду chart, с той лишь разницей, что вдоль оси X всегда отображаются значения времени. Вот пара замечаний, которые желательно запомнить. События должны иметь поле _time. Если просто передавать результаты поиска в команду timechart, это условие соблюдается автоматически. 94  Таблицы, диаграммы и поля Если вы используете какие-то промежуточные команды, не забудьте про это условие. Данные во времени всегда объединяются в интервалы, в том смысле, что нет возможности нарисовать каждое событие отдельно. Давайте посмотрим, как много ошибок возникало в разные времена: sourcetype="tm1*" error | timechart count С параметрами по умолчанию диаграмма выглядит, как показано на рис. 3.12. Рис. 3.12  Результат выполнения команды timechart с параметрами по умолчанию Теперь посмотрим, как много ошибок возникало в разные дни недели за тот же период. Для этого просто добавим в запрос предложение by date_wday: sourcetype="tm1*" error | timechart count by date_wday В результате получилась диаграмма, изображенная на рис. 3.13. Рис. 3.13  Число ошибок в разные дни недели за тот же период Как отмечалось выше, вдоль оси X всегда откладывается время. Ось Y может быть: значением одной или нескольких функций; значением единственной функции с предложением by; значениями нескольких функций с предложениями by (новая возможность, появившаяся в Splunk 4.3); например, вот как могла бы выглядеть команда timechart с несколькими функциями: sourcetype="tm1*" error | timechart count as "Error Count" count(sourcetype) as "Source Count" Отображение шкалы времени с помощью timechart  95 В результате ее выполнения получилась бы диаграмма, изображенная на рис. 3.14. Рис. 3.14  Результат выполнения команды timechart с несколькими функциями Параметры команды timechart Команда timechart имеет множество аргументов и параметров форматирования. Мы рассмотрим несколько примеров форматирования, но этих парамет ров слишком много, чтобы детально рассмотреть каждый из них. Другие типы диаграмм будут продемонстрированы в последующих главах. А теперь давайте используем несколько параметров (простой поиск) и посмотрим, что они делают: sourcetype="*" GET | timechart bins=100 limit=3 useother=false usenull=false count as "Error count" by user Рассмотрим каждый из аргументов в отдельности. sourcetype="*" GET – наш запрос. bins определяет количество отрезков, на которые будет разбит временной интервал. Число отрезков равно 100 примерно, но не точно, потому что время делится на логические единицы. В данном примере каждый отрезок равен 10 минутам. Для большей точности можно воспользоваться параметром span (например, span=1h) для создания часовых интервалов, но имейте в виду, если значение span создаст слишком много интервалов, диаграмма будет усечена. limit ограничивает количество возвращаемых серий. Выбираться будут серии с наибольшими значениями, подобно тому, как действует команда top. В данном случае будут возвращены наиболее типичные значения в поле user. useother требует от timechart сгруппировать все серии, не попавшие в число ограниченных. По умолчанию имеет значение true. usenull требует от timechart объединить в группу NULL все события, не имеющие значений в полях, перечисленных в предложении by. По умолчанию имеет значение true. С этой комбинацией аргументов получится диаграмма, изображенная на рис. 3.15. 96  Таблицы, диаграммы и поля Рис. 3.15  Графики изменения числа ошибок, обусловленных разными пользователями Как отмечалось выше в этой главе, Splunk предлагает большое разнообразие параметров форматирования визуальных представлений. Меню на вкладке Visualization (Визуализация), как показано на рис. 3.16, дает нам довольно богатый выбор. Рис. 3.16  Выбор вариантов диаграмм для отображения На рис. 3.16 изображена типичная столбиковая диаграмма с накоплением. Эта диаграмма позволяет показать, как много возникло событий определенного типа, а цветовая раскраска позволяет судить об их распределении. Некоторые великолепные примеры диаграмм разных видов можно найти на сайте http://www.splunk.com/, а кроме того, некоторые другие типы мы продемонстрируем в последующих главах. Работа с полями Все поля, использовавшиеся нами до сих пор, были или индексируемыми полями (например, host, sourcetype и _time), или автоматически извлекаемыми из пар ключ=значение. К сожалению, большинство журналов не следует этому формату, особенно это относится к первым нескольким значениям в каждом собы- Работа с полями  97 тии. Новые поля можно создавать с помощью встраиваемых команд или путем изменения конфигурации. Пример регулярного выражения Большая часть способов создания новых полей в Splunk связана с регулярными выражениями. Как отмечается в документации Splunk: «Регулярные выражения составляют важную часть интерфейса поиска в Splunk, и понимание этого обстоятельства является важной предпосылкой оптимального использования механизма поиска в Splunk». Регулярным выражениям посвящено много книг и сайтов, поэтому здесь мы затронем только то, что относится к Splunk. Следующие примеры представлены только ради полноты обсуждения; многим пользователям достаточно будет возможностей веб-интерфейса Splunk. Допустим, что в событиях в нашем журнале имеется ссылка на IP-адрес в виде ip=1.2.3.4, давайте вытащим адрес подсети (1.2.3) в новое поле с именем subnet. Самый простой шаблон, решающий эту задачу, имеет вид: ip=(?P<subnet>1.2.3).4 Но в таком шаблоне мало пользы, так как он вычленяет подсеть только из данного конкретного IP-адреса. Попробуем немного усовершенствовать ре шение: ip=(?P<subnet>\d+\.\d+\.\d+)\.\d+ и рассмотрим его поближе: ip= просто находит последовательность символов ip=; ( открывает сохраняющий буфер; все, что окажется внутри круглых скобок, будет сохранено в этом буфере; ?P<subnet> внутри круглых скобок создает поле с именем subnet из содержимого сохраняющего буфера; \d соответствует любой одной цифре от 0 до 9; + квантификатор, требующий наличия одного или более предыдущих элементов; \. соответствует символу точки; точке без обратного слеша соответствует один любой символ; \d+\.\d+ соответствует двум другим элементам IP-адреса; ) закрывает сохраняющий буфер; \.d\+ соответствует последней части IP-адреса; так как этот фрагмент находится за пределами сохраняющего буфера, он будет потерян. Теперь усложним пример, чтобы проиллюстрировать еще несколько идей: ip=(?P<subnet>\d+.\d*\.[01234-9]+)\.\d+ Рассмотрим этот шаблон поближе: ip= просто находит последовательность символов ip=; 98  Таблицы, диаграммы и поля (?P<subnet> открывает сохраняющий буфер и задает имя поля; \d означает цифру; это одна из нескольких комбинаций с обратным слешем, представляющих группы символов; + квантификатор, требующий наличия одного или более предыдущих элементов, в данном случае d; . соответствует одному символу; в данном случае будет соответствовать точке после первой группы цифр, хотя может соответствовать любому одному символу; \d* означает ноль или больше цифр; \. соответствует точке; обратный слеш отменяет специальную интерпретацию любого специального знака препинания. Не все знаки препинания имеют специальную интерпретацию, но их довольно много, поэтому не будет большого вреда, если добавить обратный слеш перед знаком препинания, когда требуется буквальное совпадение; [ открывает класс (множество) символов; совпадение с классом считается найденным, если один символ из исходной строки совпадет с любым символом в квадратных скобках; 01234-9 означает символы 0, 1, 2, 3 и диапазон 4-9; ] закрывает класс (множество) символов; + квантификатор, требующий наличия одного или более предыдущих элементов, в данном случае одного из символов, перечисленных во мно жестве; ) закрывает сохраняющий буфер; \.\d+ заключительная часть IP-адреса, которая просто отбрасывается. Этот фрагмент можно было бы не включать в шаблон, но он гарантирует совпадение только с полным IP-адресом, состоящим из четырех групп цифр. Стоящую перед нами задачу можно решить множеством способов. Вот некоторые примеры: ip=(?P<subnet>\d+\.\d+\.\d+)\.\d+ ip=(?P<subnet>(\d+\.){2}\d+)\.\d+ ip=(?P<subnet>[\d\.]+)\.\d ip=(?P<subnet>.*?\..*?\..*?)\. ip=(?P<subnet>\S+)\. Дополнительную информацию вы найдете в руководстве по Perl-совмести мым регулярным выражениям «Perl Compatible Regular Expressions» (PCRE) по адресу: http://www.pcre.org/pcre.txt1, или в одной из множества книг, или на вебсайтах, посвященных этой теме. Далее в книге мы неоднократно будем возвращаться к регулярным выражениям, и все же вам определенно стоит иметь под рукой хоть какое-то справочное руководство. 1 Powered by TCPDF (www.tcpdf.org) Похожее руководство на русском языке можно найти по адресу: http://www.pcre.ru/. – Прим. перев. Работа с полями  99 Команды создания полей В Splunk поля извлекаются из исходных событий; чтобы максимально использовать возможности Splunk, вы можете определять дополнительные поля и извлекать их. Это даcт возможность собрать и проанализировать важную для вас информацию, которая не обнаруживается и не извлекается автоматически. Есть несколько команд для создания новых полей, но чаще других используются eval и rex. eval Команда eval дает возможность использовать функции для создания новых полей, подобно тому, как конструируются формулы в Excel, например: sourcetype="impl_splunk_gen" | eval req_time_seconds=date_second/1000 | stats avg(req_time_seconds) Эта команда создаст поле с именем req_time_seconds в каждом событии, имеющем значение в date_second. Команды, следующие за этой инструкцией, будут видеть поле, как если бы оно было частью оригинального события. Команда stats в этом примере создаст таблицу со средним значением вновь созданного поля (рис. 3.17). Рис. 3.17  Среднее значение для нового поля В команде eval можно использовать много разных функций. Полный их список вы с легкостью найдете, выполнив поиск в Google по фразе Splunk eval functions. Я советую сохранить адрес найденной страницы в закладках, потому что вы часто будете обращаться к ней. rex Команда rex позволяет создавать поля с использованием регулярных выражений. Она может работать с любыми существующими полями, но по умолчанию использует поле _raw. Давайте попробуем задействовать один из шаблонов, написанных в коротком обсуждении регулярных выражений: sourcetype="impl_splunk_gen" | rex "ip=(?P<subnet>\d+\.\d+\.\d+)\.\d+" | chart values(subnet) by date_minute Этот запрос создаст таблицу, как показано на рис. 3.18. 100  Таблицы, диаграммы и поля Рис. 3.18  Результат создания поля командой rex С использованием дополнительного аргумента field можно задействовать поле ip, уже созданное из пары имя=значение в событие: sourcetype="impl_splunk_gen" | rex field=ip "(?P<subnet>.*)\."| chart values(subnet) by date_minute Это даст тот же результат, что и предыдущий пример. Извлечение уровня журналирования В некоторых наших примерах мы просто искали слово error. Как вы могли заметить, многие из событий, найденных таким способом, в действительности не являются ошибками – они просто содержат слово «error» где-то в тексте сообщения. Например, из следующих двух событий интерес для нас будет представлять только второе: 2012-03-21T18:59:55.472-0500 INFO This is not an error 2012-03-21T18:59:42.907-0500 ERROR Something bad happened Используя прием извлечения полей, мы легко можем определить свои поля без повторного индексирования и производить поиск по значениям, встречаю щимся в конкретных местах в наших событиях. Интерфейс извлечения полей Определить поле можно несколькими способами. Начнем с интерфейса Extract Fields (Извлечение полей). Чтобы получить доступ к этому интерфейсу, выберите в меню Event Actions (Действия с событиями) пункт Extract Fields (Извлечь поля), находящийся рядом с любым событием, как показано на рис. 3.19. Работа с полями  101 Рис. 3.19  Меню Event Actions (Действия с событиями) В результате откроется представление Extract Fields (Извлечение полей), как показано на рис. 3.20. Рис. 3.20  Представление Extract Fields (Извлечение полей) Начиная с версии Splunk 6.2 появилась возможность воспользоваться услугами мастера, помогающего подготовить информацию, необходимую системе Splunk, чтобы создать регулярное выражение для определения поля. Здесь можно выбрать несколько полей, но в данном случае выберем только Error, как показано на рис. 3.21. 102  Таблицы, диаграммы и поля Рис. 3.21  Выбор фрагмента в событии для извлечения поля В открывшемся диалоге можно указать свое имя поля в поле ввода Field Name (Имя поля) – я выбрал имя CognosError – и щелкнуть на кнопке Add Extraction (Добавить извлечение). В форме Preview (Предварительный просмотр) можно заметить две вкладки – вкладку Events (События) и вкладку с именем нашего нового поля CognosError, как показано на рис. 3.22. Рис. 3.22  Форма Preview (Предварительный просмотр) На вкладке Events (События) можно видеть, какие фрагменты соответствуют определению нового поля, а на вкладке CognosError – наше новое поле. Наконец, перейдя по ссылке Show Regular Pattern (Показать регулярное выражение), можно увидеть регулярное выражение, сгенерированное системой Splunk: ^(?P<CognosError>\w+) Вы можете проверить его и при необходимости отредактировать (см. рис. 3.23). Работа с полями  103 Рис. 3.23  Регулярное выражение, сгенерированное системой Splunk Для этого нужно щелкнуть на кнопке Edit the Regular Expression (Изменить регулярное выражение), которую можно видеть на рис. 3.23, после чего откроется диалог (рис. 3.24), где можно изменить шаблон вручную. Рис. 3.24  Диалог редактирования регулярного выражения После внесения любых изменений вновь активируется форма Preview (Предварительный просмотр) и запустится новый поиск с измененным регулярным выражением, где вы сможете увидеть извлеченные значения. После щелчка на кнопке Save (Сохранить) вам будет предложено указать имя нового поля. Например, после изменения оригинального шаблона можно ввести другое имя (отличное от CognosError) и установить необходимые разрешения для доступа к новому полю, как показано на рис. 3.25. Рис. 3.25  Диалог после изменения шаблона Теперь, определив поле, мы можем использовать его разными способами: можно выполнить поиск по значению поля, например loglevel=Cognos Error; 104  Таблицы, диаграммы и поля когда поиск производится по значению поля, имя поля чувствительно к регистру, но его значение – нет; в данном случае запрос loglevel=CognosError даст желаемые результаты, но запрос LogLevel=cognoserror не вернет ничего; можно получить отчет по полю, например sourcetype="impl_splunk_gen" user=mary | top loglevel; можно отыскать только события, содержащие поле: sourcetype="impl_ splunk_gen" user=mary loglevel="*". Прототипирование поля с помощью rex При определении полей часто бывает удобно включить шаблон непосредственно в запрос и затем скопировать шаблон в конфигурацию. Возможно, вы заметили, что тест в Extract Fields (Извлечение полей) использует rex. Давайте преобразуем в поле шаблон определения подсети, созданный выше. Для начала напишем запрос с инструкцией rex: sourcetype="impl_splunk_gen" ip="*" | rex "ip=(?P<subnet>\d\.\d\.\d+)\.\d+" | table ip subnet Поскольку известно, что события будут содержать поле ip, можно воспользоваться выражением ip="*", чтобы в результаты попали только события, имеющие значение в этом поле. Команда table принимает список полей и выводит таблицу, содержащую по одной строке на событие, как показано на рис. 3.26. Рис. 3.26  Команда table выводит таблицу, содержащую по одной строке на событие Как видите, инструкция rex не всегда дает желаемый результат. Взглянув на шаблон еще раз, можно заметить, что в первых двух экземплярах \d теперь отсутствует квантификатор +. Без него совпадать с выражением будут только IP-адреса, содержащие по одной цифре в первой и второй тетрадах. После добавления в шаблон недостающих знаков «плюс» все строки получат поле subnet, как показано на рис. 3.27: Работа с полями  105 sourcetype="impl_splunk_gen" ip="*" | rex "ip=(?P<subnet>\d+\.\d+\.\d+)\.\d+" | table ip subnet Рис. 3.27  Все строки получили поле subnet Теперь можно взять шаблон из инструкции rex и использовать его в конфигурации. Создание поля с помощью административного интерфейса Шаблон из предыдущего примера можно включить в конфигурацию, чтобы организовать извлечение этого поля. Для этого щелкните на ссылке Settings (Настройки) в верхней полосе меню. Затем щелкните на ссылке Fields (Поля). Раздел Fields (Поля) содержит все, как ни странно, что относится к полям. Здесь можно просматривать и редактировать правила извлечения полей, а также определять разрешения. Определять операции с полями, псевдонимы полей и даже переименовывать типы источников. Но сейчас нас интересует только извлечение полей. После щелчка на ссылке Add new (Добавить новое) справа в диалоге Field Extractions (Извлечение полей) или на кнопке New (Новый) после щелчка на Field Extractions (Извлечение полей) откроется диалог создания нового поля, как показано на рис. 3.28. В диалоге вы увидите следующие поля ввода. Destination app (Целевое приложение) позволяет выбрать приложение, куда по умолчанию будет помещено и где будет действовать это правило извлечения полей. Область действия конфигураций мы подробно обсудим в главе 11 «Настройка Splunk». Name (Имя) определяет имя правила извлечения полей. Сюда можно ввести любое описательное имя. 106  Таблицы, диаграммы и поля Apply to (Применить к) позволяет выбрать, к чему привязать это правило. Вы можете выбрать sourcetype, source и host. Чаще всего выбирается sourcetype. named (с именем) – это имя элемента, к которому привязывается правило извлечения. Type (Тип) позволяет выбрать Inline (Встроенный), что означает регулярное выражение, или Uses transform (Использовать преобразование), то есть именованное преобразование, уже существующее в конфигурации. Extraction/Transform (Извлечение/Преобразование) – сюда следует вписать регулярное выражение, если в раскрывающемся списке Type выбран пункт Inline (Встроенный), или имя объекта преобразования Transform. Рис. 3.28  Диалог добавления нового правила извлечения полей После щелчка на кнопке Save (Сохранить) вы вернетесь к списку правил извлечения. По умолчанию правило объявляется частным (скрытым) и будет действовать только в приложении, где оно создано. При наличии соответствующего уровня привилегий вы можете дать право использовать правило другим пользователям и изменить область его действия. Щелкните на ссылке Permissions (Разрешения) в списке, чтобы открыть диалог настройки разрешений, как показано на рис. 3.29. Радиокнопки в верхней части диалога управляют контекстом, в котором будет действовать правило извлечения. Подумайте, где это правило может пригодиться, и выберите соответствующий контекст. Избыточное применение правил может ухудшить производительность, поэтому по мере возможности старайтесь ограничивать область их действия конкретными приложениями. Подробнее о создании приложений рассказывается в главе 8 «Работа с приложениями». Работа с полями  107 Рис. 3.29  Диалог с настройками разрешений Второй раздел содержит элементы управления, определяющие разрешения для ролей на доступ к этой конфигурации. В большинстве случаев для роли Everyone (Все) выбирается разрешение Read (Чтение) и для роли admin – разрешение Write (Запись). Вы близко познакомитесь с этим диалогом в будущем, когда начнете создавать объекты. Разрешения и настройки безопасности в целом могут быть очень сложными и влиять на видимость приложений, поэтому всегда проверяйте, действительно ли установленные разрешения соответствуют вашим ожиданиям. Индексируемые и извлекаемые поля Когда событие записывается в индекс, сохраняется исходный текст события и набор индексируемых полей. В число индексируемых полей входят: host, source type, source и _time. Индексирование полей имеет свои достоинства и недостатки. Сначала перечислим преимущества индексирования полей (более полное обсуждение настройки индексирования вы найдете в главе 11 «Настройка Splunk»). Так как индексируемые поля хранятся в индексе вместе с самими событиями, их вычисление производится только на этапе индексирования и в действительности может вычисляться лишь в этот момент. Способно увеличить эффективность поиска по наиболее распространенным терминам (например, см. раздел «Индексируемые поля, случай 1 – редкие экземпляры распространенных терминов»). Дает возможность создавать новые слова для поиска, отсутствующие в исходном тексте или входящие в состав других слов (например, см. разделы от «Индексируемые поля, случай 2 – разбиение слов» до «Индексируемые поля, случай 4 – медленные запросы»). Позволяет эффективно искать слова в индексированных полях (например, см. раздел «Индексируемые поля, случай 3 – приложение по источ нику»). А теперь недостатки. Не имеет обратной силы. Этим индексируемые поля отличаются от извлекаемых, когда все события, прошлые и настоящие, получат вновь 108  Таблицы, диаграммы и поля определенное поле при совпадении с шаблоном. Это большой недостаток индексируемых полей и имеет несколько следствий: – новое индексируемое поле получат только вновь индексированные события; если в некоторых случаях шаблон действует неверно, нет никакой практической возможности применить поле к уже индексированным событиям; – аналогично, если изменится формат журнала, индексируемые поля могут не генерироваться (или генерироваться неправильно). Увеличивает размер индекса на диске. Увеличивает объем лицензирования. Любые изменения требуют перезапуска и временного прерывания потока данных. В большинстве случаев значение поля уже является индексированным словом и создание индексируемого поля не дает никаких преимуществ, за исключением случаев, когда это значение очень распространено. Но оставим недостатки и рассмотрим несколько случаев, когда индексируемые поля способны улучшить скорость поиска, а потом познакомимся со случаем, когда индексирование поля не дает положительного эффекта. Индексируемые поля, случай 1 – редкие экземпляры распространенных терминов Допустим, что у нас в журнале фиксируются коды завершения процессов. Если предположить, что код 1 означает ошибку, тогда наверняка будет желательно иметь возможность эффективного поиска таких событий. Представим, что содержимое журнала выглядит как-то так: 4/1/12 6:35:50.000 PM process=important_process.sh, exitcode=1 Мы легко можем отыскивать такие события по критерию exitcode=1. Но бе да в том, что при использовании извлекаемых полей поиск фактически сводится к: 1 | search exitcode="1" Поскольку дата содержит 1, этот запрос выберет все события, случившиеся в течение всего дня, и затем отфильтрует результат, оставив несколько искомых событий. Напротив, если exitcode определить как индексируемое поле, запрос сразу будет выбирать и загружать с диска только нужные события. Имейте в виду, что привязка индексированного поля к любому значению времени не сулит ничего хорошего. Это рискованно для целостности данных и считается неудачным решением. Индексируемые поля, случай 2 – разбиение слов В некоторых форматах журналов в одном слове может кодироваться несколько видов информации, причем без использования пробелов и знаков препинания для их разделения. Например, взгляните на следующее сообщение: 4/2/12 6:35:50.000 PM kernel: abc5s2: 0xc014 (UNDEFINED). Работа с полями  109 Представьте, что последовательность символов 5s2 несет важную информацию для нас и нам требуется организовать ее эффективный поиск. Запрос *5s2 отыщет нужные события, но будет работать очень неэффективно (фактически ему придется просканировать весь журнал). Определив индексируемое поле, можно обеспечить высокую эффективность поиска подстроки 5s2, потому что в этом случае в метаданных события будет создано новое слово. Определять индексируемые поля имеет смысл, только если формат журнала известен до индексирования, если вы уверены, что такое поле действительно увеличит эффективность поиска (см. предыдущий раздел), и если вы собираетесь выполнять поиск по значению поля. Если значения из этого поля потребуются лишь в отчетах, предпочтительнее использовать прием динамического извлечения полей, кроме случаев крайне жестких требований к производительности. Индексируемые поля, случай 3 – приложение по источнику В практике часто требуется отыскать события, сгенерированные конкретным веб-приложением. Нередко единственный простой способ определить приложение, создавшее журналы, – проверить пути к ним, которые Splunk сохраняет в индексируемом поле source. Например, пусть следующий путь соответствует приложению с именем app_one: /opt/instance19/apps/app_one/logs/important.log Определить принадлежность к заданному приложению можно с помощью критерия source="*/app_one/*", но он фактически приведет к полному сканированию таблицы. Можно определить извлекаемое поле и выполнить поиск по критерию app="app_one", но такой подход тоже не особенно эффективен, потому что искомое слово может не содержаться в поле _raw. Если определить это поле как индекси руемое, поиск по критерию app="app_one" будет выполняться очень быстро. И снова если значения из этого поля потребуются лишь в отчетах, лучше воспользоваться приемом динамического извлечения полей. Индексируемые поля, случай 4 – медленные запросы Рассмотрим журнал доступа к веб-серверу, в котором события завершаются информацией о времени в микросекундах, затраченном на обслуживание запросов: [31/Jan/2012:18:18:07 +0000] "GET / HTTP/1.1" 200 7918 "" "Mozilla/5.0..." 11/11033255 Допустим, нам нужно найти все запросы, обрабатывавшиеся дольше 10 секунд. Мы легко можем извлечь время в поле, например request_ms, а затем выполнить поиск по критерию request_ms>10000000. Но беда в том, что такому запросу придется проверить все события в заданном интервале времени. Как бы вы не определили это поле – как извлекаемое или индексируемое, вы столк нетесь с одной и той же проблемой: системе Splunk придется преобразовать значение поля в число перед его проверкой. А что, если определить другое поле и выполнять поиск, например, по критерию slow_request=1? В этом случае можно воспользоваться тем фактом, что 110  Таблицы, диаграммы и поля при определении индексируемого поля его значение может быть статическим. Поиск статического значения вместо преобразования поля и последующей его проверки выполняется намного эффективнее. Добиться подобного поведения можно с помощью такого преобразования: REGEX = .*/(\d{7,})$ FORMAT = slow_request::1 Подробнее о преобразованиях и их настройке мы расскажем в главе 11 «Настройка Splunk». И снова использовать этот прием имеет смысл, только если действительно нужно добиться высокой скорости поиска таких событий, а не просто собрать отчет со значениями request_ms. Индексируемые поля, случай 5 – бессмысленная работа После знакомства с индексируемыми полями у многих возникает соблазн превратить все важные поля в индексируемые. Часто такая работа лишена какого-либо смысла, просто увеличивает используемый объем дискового пространства и влечет разбазаривание лицензий, не давая ощутимого прироста эффективности. Например, рассмотрим такое сообщение в журнале: 4/2/12 6:35:50.000 PM [vincentbumgarner] [893783] sudo bash Допустим, что это сообщение имеет следующую структуру: date [userid] [pid] action и у вас возникло желание сделать поля userid и pid индексируемыми. Поскольку значения этих полей встречаются редко и едва ли будут возникать в несвязанных местоположениях, объявление этих полей индексируемыми почти наверняка не даст никаких выгод. Намного проще определить эти поля как извлекаемые и оградить себя от недостатков, присущих индексируемым полям. Расширение поддержки диаграмм в версии 7.0 Splunk предлагает превосходную коллекцию ресурсов по созданию дашбордов с диаграммами. Дополнительную информацию можно найти в справочнике по настройке диаграмм «Chart configuration reference» по адресу: https://docs.splunk. com/Documentation/Splunk/latest/Viz/ChartConfigurationReference. В версии 7.0 коллекция диаграмм увеличилась еще больше, в ней появились некоторые новые и интересные расширения, увеличивающие выбор визуального оформления и разновидностей диаграмм, улучшающих визуализацию мет рик и облегчающих мониторинг множественных графиков. В эти расширения включены возможность выбора толщины линий, стиля линий и новый параметр сравнения последовательностей в легенде, и все они доступны для редактирования. Рассмотрим некоторые из этих новых возможностей. Расширение поддержки диаграмм в версии 7.0  111 charting.lineWidth Этот параметр дает возможность задать толщину линий в пикселях (px) на диаграмме. Этот новый параметр не предъявляет никаких особых требований. Вы можете просто включить его в определение своей диаграммы: <option name="charting.linewidth">2px</option> Ниже мы добавили параметр linewidth в код XML, использовавшийся в главе 2 «Основы поиска», для демонстрации аннотирования событий: <dashboard> <label>Errors with Process Issues Annoted</label> <row> <panel> <chart> <search> <!—Вторичный поиск, управляющий аннотациями --> <query>sourcetype="tm1*" error | timechart count</query> <earliest>-30week</earliest> <latest>-1weeks</latest> <sampleRatio>1</sampleRatio> </search> <search type="annotation"> <query>sourcetype="tm1*" Process | eval annotation_label = "Processes Offline"</query> <earliest>-30week</earliest> <latest>-15weeks</latest> </search>  <option name="charting.axisLabelsX.majorLabelStyle.overflowMode"> ellipsisNone</option> <option name="charting.axisLabelsX.majorLabelStyle.rotation"> 0</option> <option name="charting.axisTitleX.visibility">visible</option> <option name="charting.axisTitleY.visibility">visible</option> <option name="charting.axisTitleY2.visibility">visible</option> <option name="charting.axisX.abbreviation">none</option> <option name="charting.axisX.scale">linear</option> <option name="charting.axisY.abbreviation">none</option> <option name="charting.axisY.scale">linear</option> <option name="charting.axisY2.abbreviation">none</option> <option name="charting.axisY2.enabled">0</option> <option name="charting.axisY2.scale">inherit</option> <option name="charting.chart">line</option> <option name="charting.chart.bubbleMaximumSize">50</option> <option name="charting.chart.bubbleMinimumSize">10</option> <option name="charting.chart.bubbleSizeBy">area</option> <option name="charting.chart.nullValueMode">gaps</option> <option name="charting.chart.showDataLabels">none</option> <option name="charting.chart.sliceCollapsingThreshold">0.01</option> <option name="charting.chart.stackMode">default</option> <option name="charting.chart.style">shiny</option> 112  Таблицы, диаграммы и поля <option name="charting.drilldown">none</option> <option name="charting.layout.splitSeries">0</option> <option name="charting.layout.splitSeries.allowIndependentYRanges"> 0</option> <option name="charting.legend.labelStyle.overflowMode"> ellipsisMiddle</option> <option name="charting.legend.mode">standard</option> <option name="charting.legend.placement">right</option> <option name="charting.lineWidth">9px</option> <option name="trellis.enabled">0</option> <option name="trellis.scales.shared">1</option> <option name="trellis.size">medium</option> </chart> </panel> </row> </dashboard> Результат увеличения толщины линии до 9px можно видеть на рис. 3.30. Рис. 3.30  Результат увеличения толщины линии charting.data.fieldHideList С помощью этого параметра можно скрыть искомые поля на диаграмме, чтобы сделать ее более акцентированной на конкретной точке данных. Например, на рис. 3.31 показан пример визуализации полей host и count. Рис. 3.31  Пример визуализации полей host и count Расширение поддержки диаграмм в версии 7.0  113 Чтобы получить этот результат, в код XML дашборда нужно добавить следующий параметр: <option name="charting.data.fieldHidelList">["host"]</otion> Аналогично можно скрыть поле host, как показано на рис. 3.32. Рис. 3.32  Поле host скрыто charting.legend.mode Этот новый параметр удобно использовать для сравнения разных серий данных. По умолчанию этот параметр имеет значение "standard" и реализует поведение, наблюдавшееся в предыдущих версиях механизма отображения графиков с несколькими сериями, как показано на рис. 3.33. Рис. 3.33  Стандартное отображение графика с несколькими сериями Новый вариант "seriesCompare" извлекает значения из всех последовательностей, присутствующих в легенде, что упрощает сравнение значений в разных точках на графике, как показано на рис. 3.34. Рис. 3.34  Вариант "seriesCompare" извлекает значения из всех последовательностей charting.fieldDashStyles Новый параметр fieldDashStyles дает возможность экспериментировать с разными видами пунктиров (dash, dashDot, dot, longDash, longDashDot, longDashDot 114  Таблицы, диаграммы и поля Dot, shortDash, shortDot, shortDashDot, shortDashDotDot, solid) для каждого поля на графике. Подобно другим параметрам, стиль линий можно определять в коде XML: <option name="charting.fieldDashStyles">{count":"shortDashDotDot"}</option> На рис. 3.35 показан пример применения стиля shortDashDotDot. Рис. 3.35  Пример применения стиля shortDashDotDot charting.axisY.abbreviation Наконец, в зависимости от вида диаграммы можно использовать следующие новые параметры: charting.axisX.abbreviation charting.axisX.abbreviation charting.axisY.abbreviation charting.axisY2.abbreviation Они управляют сокращением надписей вдоль осей X и Y до ближайшей приставки в системе мер СИ. На этом мы завершаем обзор новых расширений в поддержке диаграмм, появившихся в версии 7.0. А вам мы советуем поэкспериментировать с ними. Итоги Это была очень насыщенная глава, но в действительности мы лишь слегка коснулись некоторых важных тем. В последующих главах мы покажем более интересные варианты применения представленных здесь команд и приемов. Перед нами открываются потрясающие перспективы, поэтому мы постараемся представить побольше практических примеров, чтобы охватить как можно более широкий круг сценариев. Хотя в этой главе было рассказано о новых ценных расширениях в поддержке диаграмм, появившихся в версии 7.0, мы советуем читателям найти время (загрузите пример обзорного приложения Splunk 7.0 Overview App) и поэкспериментировать с ними, потому что они способны улучшить внешний вид ваших диаграмм в Splunk. В следующей главе мы познакомимся с моделями данных и сводными таб лицами (и особенностями их определения), редактором сводных таблиц, их элементами и фильтрами, а также со встраиваемыми диаграммами. Глава 4 Модели данных и сводные таблицы В версии Splunk 7.0 в основной механизм поиска добавлено множество важных оптимизаций, способствующих уменьшению времени поиска и потребления ресурсов за счет использования моделей данных и приемов ускоренного поиска. По этой причине мы добавили новый раздел, охватывающий эту тему. В этой главе рассматриваются следующие темы: модели данных; сводные таблицы (а также элементы и фильтры сводных таблиц); sparklines. Модели данных и сводные таблицы в Splunk должны обсуждаться вместе, потому что модели данных управляют сводными таблицами. Поэтому начнем с определения моделей данных. Что такое модель данных? В документации Splunk (2015–2017) дается такое определение модели данных: «иерархически структурированное отображение семантических знаний об одном или нескольких наборах данных (которое кодирует предметные знания, необходимые для специализированного поиска в этих наборах данных), дающее пользователям системы Splunk возможность применять специализированный поиск для создания отчетов и диаграмм в сводных таблицах». Модели данных позволяют создавать отчеты и дашборды без необходимости писать поисковые запросы для Splunk (необходимые для работы этих отчетов и дашбордов) и могут играть важную роль в разработке приложений Splunk. Вы можете определять свои модели данных, но перед этим вам стоит познакомиться с моделями данных, которые могли быть созданы в вашей организации. Обычно модели данных разрабатываются специалистами, разбирающимися в специфике формата, понимающими семантику конкретных данных и особенности работы пользователей с этими данными. При построе- 116  Модели данных и сводные таблицы нии моделей данных часто используют типы объектов знаний (такие как поисковые запросы, транзакции, правила извлечения полей во время поиска и вычисляемые поля). Кроме того, если вы знакомы с реляционными базами данных, модели данных в Splunk можно рассматривать как своеобразные схемы баз данных. Используя модели данных в редакторе сводных таблиц Splunk Pivot Editor, вы сможете генерировать статистические таблицы и диаграммы, опираясь на выбранные настройки строк и столбцов. Роль моделей данных в поиске Модель данных в Splunk в действительности является группой или набором элементов определенной информации (объектами), объединенных для создания конкретных поисковых запросов, возвращающих конкретные наборы данных. Набор данных, возвращаемый выбранным вами объектом, определяется ограничениями и атрибутами этого объекта. Объекты модели данных Как уже говорилось, модели данных конструируются из объектов четырех типов – событие, поиск, транзакция и потомок. Они образуют иерархическую структуру, в которой дочерние объекты наследуют родительские объекты, с которыми они связаны. Event objects – самые типичные объекты моделей данных, представляющие типы событий. Обычно объекты событий определяют ограничения (которые мы обсудим ниже). Transaction objects позволяют создавать модели данных, представляющие транзакции (группы связанных событий в одном интервале времени) на основе полей, уже добавленных в модель через объекты событий и поиска. Это означает, что нельзя создать модель данных, состоящую только из объектов транзакций и их потомков. Прежде чем создать объект транзакции, в дереве модели уже должны присутствовать объекты событий и поиска. Search objects используют произвольные запросы Splunk, включающие команды преобразования для определения набора данных, который они представляют. На вершине иерархии в модели данных находятся root objects, каждый из которых может быть родителем множества дочерних объектов. Отношения родитель/потомок в терминологии Splunk называются деревом объекта. Данные, которые представляет дерево, первоначально выбираются корневым объектом, затем фильтруются и уточняются потомками. Ограничения Все объекты в модели данных определяются набором ограничений, фильтрующим информацию, не относящуюся к объекту. Ограничением может быть прос Acceleration в версии 7.0  117 той поиск (без дополнительных команд), сложный поиск и даже транзакция. Ограничения наследуются дочерними объектами. Наследование ограничений гарантирует, что каждый дочерний объект будет представлять подмножество данных, возвращаемых родительским объектом. Например, модель данных может иметь корневой объект, определяющий конкретный индексированный источник (sourcetype=speciallogs_*), и дочерний объект, сужающий поиск до событий-ошибок (error*). Эту модель данных можно использовать, если известно, что требуется выполнить поиск только ошибок в источнике speciallogs. Атрибуты Объекты моделей данных также включают атрибуты – простые поля (доступные для использования в отчетах), – связанные с наборами данных, которые эти объекты представляют. Всего имеется пять типов атрибутов: автоматически извлекае мые (поля, которые Splunk порождает в процессе поиска), eval-выражения (поля, получаемые из eval-выражений, указанных в определениях атрибутов), подстановочные (поля из внешних источников данных, таких как файлы CSV и сценарии), регулярные выражения (поля, извлекаемые из объектов событий с использованием регулярных выражений) и GeoIP (подстановочные поля, добавляющие атрибуты географической привязки, такие как широта, долгота, страна и город). Атрибуты делятся на три категории: унаследованные (от родительского объекта), извлеченные (добавленные вами) и вычисляемые (являющиеся результатом вычислений или подстановки). При определении атрибутов (каждого объекта в модели данных) можно управлять их видимостью. По умолчанию все атрибуты видимы. Это особенно важно, когда каждый объект в модели имеет много атрибутов, но отображаться должны лишь некоторые из них. Определение, какие атрибуты должны иметься в модели данных и какие из них должны отображаться, является важным аспектом общей архитектуры модели. Обычно каждый объект экспортирует только те данные, которые относятся к нему, что упрощает их понимание и использование обычными пользователями Splunk. Атрибуты могут быть не только видимыми или невидимыми, но также обязательными и необязательными. Если атрибут объявлен обязательным, каждое событие, представляемое этим объектом, должно иметь данный атрибут. Когда атрибут объявляется необязательным, это означает, что объект может включать события, не имеющие этого атрибута. Acceleration в версии 7.0 До и вместе с выходом версии 7.0 в Splunk был опубликован материал, рек ламирующий «оптимизации в базовом механизме поиска», способствующие уменьшению времени поиска и потребления ресурсов за счет использования моделей данных и приемов ускоренного поиска. Судя по отзывам пользователей Splunk Enterprise, они неизменно наблюдают трехкратное ускорение моделей данных. 118  Модели данных и сводные таблицы Другие виды поиска, также по сообщениям пользователей, показывают ускорение от двух до десяти раз. Как отмечается в компании Splunk, в версии 7.0 применяются приемы параллельной и многопоточной обработки для максимального использования всех имеющихся в системе процессоров, а также усовершенствованные параллельные алгоритмы для улучшения производительности некоторых типов поиска или (как минимум) сохранения прежней производительности, при использовании не более трети прежде необходимых ресурсов. Для ясности отметим, что эти улучшения в основном наблюдаются при переходе с версии 5.0, и в окружениях, где эти выгоды делают обновление стоящим, на том же аппаратном обеспечении можно получить значительное улучшение производительности и/или уменьшить потребление ресурсов. Создание модели данных Теперь, получив общее представление о моделях данных Splunk, сделаем шаг вперед и создадим такую модель. Но, прежде чем приступить к работе, нужно убедиться, что идентификатор пользователя обладает необходимыми для этого привилегиями. По умолчанию создавать модели могут только пользователи с ролями admin и power. Возможность создания моделей другими пользователями определяется наличием у них права записи в приложение. Убедившись в наличии необходимых привилегий, можно щелкнуть на ссылке Settings (Настройки) и затем на ссылке Data models (Модели данных, в разделе KNOWLEDGE), как показано на рис. 4.1. Рис. 4.1  Ссылка Data models (Модели данных) в разделе KNOWLEDGE Создание модели данных  119 После этого откроется страница Data Models (Модели данных), изображенная на рис. 4.2. Здесь выводится список доступных моделей данных. Отсюда можно управлять разрешениями и ускорением, клонировать и удалять существующие модели данных. Эту страницу также можно использовать для создания новых моделей данных и их выгрузки, используя кнопки New Data Model (Новая модель данных) и Upload Data Model (Выгрузить модель данных) в правом верхнем углу соответственно. Рис. 4.2  Страница Data Models (Модели данных) Поскольку мы решили создать новую модель, щелкните на кнопке New Data Model (Новая модель данных). В результате откроется диалог New Data Model (Новая модель данных), изображенный на рис. 4.3. Заполним поля этого диалога. Рис. 4.3  Диалог New Data Model (Новая модель данных) Заполнение полей в диалоге создания новой модели данных В диалоге мы должны заполнить четыре поля ввода, чтобы описать новую модель данных (Title (Название), ID (Идентификатор), App (Приложение) и Description (Описание)). 120  Модели данных и сводные таблицы Title (Название): здесь вы должны ввести название своей модели данных. Это поле допускает ввод любых символов, а также пробелов. Введенное вами название будет отображаться на странице со списком моделей. ID (Идентификатор): это необязательное поле. Оно предварительно заполняется последовательностью символов, введенной в поле Title (Название), при этом пробелы заменяются символами подчеркивания. Остановитесь на минутку и окиньте взглядом идентификатор – достаточно ли он хорош, потому что после ввода идентификатора вы не сможете изменить его. App (Приложение): здесь вы должны выбрать (из раскрывающегося списка) приложение Splunk, которое будет обслуживать модель. Description (Описание): это поле тоже необязательное, но советую ввес ти сюда краткое описание, чтобы потом было проще идентифицировать модель. После заполнения полей можно щелкнуть на кнопке Create (Создать). Пос ле этого откроется страница Edit Objects (Правка объектов) с определением модели данных (в данном примере Aviation Games), как показано на рис. 4.4. Рис. 4.4  Страница Edit Objects (Правка объектов) с определением модели данных Следующий шаг на пути к определению модели данных – добавление первого объекта. Как уже отмечалось, модели данных обычно образуются из иерархий объектов, начинающихся с корневых объектов событий. Каждый корневой объект событий представляет набор данных, определяемый ограничениями, то есть простой поисковый запрос, отбрасывающий события, не соответствую щие объекту. Вернемся к нашему примеру и создадим объект, извлекающий запросы на покупки на веб-сайте Aviation Games. Создание модели данных  121 Чтобы определить первый объект, щелкните на раскрывающемся списке Add Dataset (Добавить набор данных), как показано на рис. 4.5. Рис. 4.5  Список Add Dataset (Добавить набор данных) Первым объектом в модели данных может быть Root Event (Корневое событие) или Root Search (Корневой поиск). Добавим корневое событие, поэтому выберите пункт Root Event (Корневое событие). После этого откроется диалог Add Event Dataset (Добавить набор данных с событиями), как показано на рис. 4.6. Рис. 4.6  Диалог Add Event Dataset (Добавить набор данных с событиями) Наш пример будет отбирать события с фразой error, представляющие ошибки обработки, возникшие в нашем источнике данных. Поэтому в поле Dataset Name (Имя набора данных) введите Processing Errors. Поле Dataset ID (Идентификатор набора данных) автоматически заполнится после ввода имени в Dataset Name (при желании вы можете исправить его). В поле Constraints (Ограничения) введите sourcetype=tm1* error. Это ограничение определяет возвращаемые объектом события (все события со словом error и поступившие из источника с именем, начинающимся с tml). После определения ограничений щелкните на кнопке Preview (Предварительный просмотр), чтобы проверить, действительно ли указанные ограничения возвращают желаемые события. На рис. 4.7 показаны результаты, получаемые с ограничениями, заданными в этом примере. 122  Модели данных и сводные таблицы Рис. 4.7  Результат применения ограничений После просмотра результатов щелкните на кнопке Save (Сохранить). После этого появится список (рис. 4.8) атрибутов корневого объекта: host, source, sourcetype и _time. Чтобы добавить дочерние объекты для получения ошибок на стороне клиента и на стороне сервера, нужно отредактировать список и включить в него дополнительные атрибуты. Рис. 4.8  Список атрибутов корневого объекта Добавление полей (атрибутов) Добавим в модель данных автоматически извлекаемый атрибут. Как говорилось выше, автоматически извлекаемые атрибуты генерируются системой Splunk во время поиска. Итак, щелкните на раскрывающемся списке Add Field (Добавить поле), как показано на рис. 4.9. Создание модели данных  123 Рис. 4.9  Раскрывающийся список Add Field (Добавить поле) Выберите элемент Auto-Extracted (Автоматически извлекаемый). После этого откроется окно Add Auto-Extracted Field (Добавить автоматически извлекаемое поле), изображенное на рис. 4.10. Рис. 4.10  Окно Add Auto-Extracted Field (Добавить автоматически извлекаемое поле) Прокрутите список автоматически извлекаемых полей и отметьте те из них, которые требуется добавить в модель. Поскольку в этом примере создается модель для работы с ошибками, я выбрал поля date_mday, date_month и date_ year, как показано на рис. 4.11. 124  Модели данных и сводные таблицы Рис. 4.11  Выбор полей для включения в модель Обратите внимание, что для отмеченных полей предоставляется возможность выбрать другое имя и задать его тип. Назначение колонки Rename (Переименовать) вполне очевидно, поэтому остановимся только на колонке Type (Тип). Система Splunk позволяет выбрать тип поля String (Строка), Number (Число), Boolean (Логический) или IPV$ и указать, является ли атрибут обязательным (Required), необязательным (Optional), скрытым (Hidden) или скрытым и обязательным (Hidden & Required). Значение Optional (Необязательный) подразумевает, что атрибут может присутствовать не во всех событиях, представляемых объектом. Проверив еще раз выбранные типы полей, щелкните на кнопке Save (Сохранить), чтобы вернуться к списку атрибутов корневого объекта. Рис. 4.12  Список атрибутов корневого объекта после добавления новых полей Подстановочные атрибуты  125 Подстановочные атрибуты Давайте теперь рассмотрим подстановочные (lookup) атрибуты. Splunk может использовать существующие определения подстановки и по фактическому значению заданного атрибута выбирать нужную запись из таблицы подстановки. Полученная комбинация поле/значение применяется к объекту как подстановочный атрибут. Снова щелкните на раскрывающемся списке Add Field (Добавить поле) и выберите пункт Lookup (Подстановка). После этого откроется окно Add Fields with a Lookup (Добавить поля подстановки), как показано на рис. 4.13. На этой странице выберите нужные определения подстановки. В этом примере я выбрал dnslookup. Рис. 4.13  Список определений подстановки Подстановка dnslookup преобразует clienthost в clientip. Мы можем настроить атрибут, используя это определение подстановки, чтобы добавить его результат в объект обработки ошибок. В разделе Input (Вход) выберите clienthost в списке Field in Lookup (Поле в таблице) и host в списке Field in Dataset (Поле в наборе данных), как показано на рис. 4.14. Field in Lookup (Поле в таблице) – это имя поля в таблице подстановки. Field in Dataset (Поле в наборе данных) – это имя поля в событии. В нашем простом примере поле clienthost должно сопоставляться с полем host. В разделе Output (Выход) я выбрал поле clientip как выходное поле. При желании в колонке Display Name (Отображаемое имя) можно указать имя, под каким это поле будет отображаться. Это имя будет использоваться как имя поля в ваших событиях. Я выбрал отображаемое имя AviationLookupName (см. рис. 4.15). 126  Модели данных и сводные таблицы Рис. 4.14  Настройка сопоставления Рис. 4.15  Выбрано отображаемое имя AviationLookupName Здесь также можно щелкнуть на кнопке Preview (Предварительный просмотр) и убедиться, что добавлены все необходимые поля. На странице предварительного просмотра можно выбрать вкладку Events (События), чтобы просмотреть таблицу с событиями, или вкладки с именами полей, указанными в разделе Output (Выход), чтобы просмотреть их значения. Например, на рис. 4.16 показан список значений в поле AviationLookupName. Подстановочные атрибуты  127 Рис. 4.16  Список значений в поле AviationLookupName Закончив, щелкните на кнопке Save (Сохранить), чтобы вернуться к списку атрибутов корневого объекта. Рис. 4.17  Список атрибутов корневого объекта после добавления подстановочного поля Потомки Мы только что добавили в модель данных корневой (родительский) объект. Теперь добавим несколько его потомков. Дочерние объекты наследуют все ограничения и атрибуты родителя, а также позволяют добавлять дополнительные ограничения с целью дальнейшей фильтрации набора данных, представляемых объектом. Чтобы добавить в модель дочерний объект, выберите в раскрывающемся списке Add Field (Добавить поле) пункт Child (Потомок), как показано на рис. 4.18. 128  Модели данных и сводные таблицы Рис. 4.18  Пункт Child (Потомок) в раскрывающемся списке Add Field (Добавить поле) Splunk откроет страницу Add Child Dataset (Добавление дочернего набора данных), изображенную на рис. 4.19. Рис. 4.19  Страница Add Child Dataset (Добавление дочернего набора данных) На этой странице выполните следующие шаги: введите в поле Dataset Name (Имя набора данных) имя Dimensional Errors; оставьте в поле Dataset ID (Идентификатор набора данных) идентификатор Dimensional_Errors; в списке Inherit From (Наследует) выберите Processing Errors – этот дочерний объект будет наследовать все атрибуты корневого объекта Processing Errors; в поле Additional Constraints (Дополнительные ограничения) добавьте dimension; теперь модели данных, использующие этот объект для поиска событий, будут выполнять запрос sourcetype=tm1* error dimension; щелкните на кнопке Save (Сохранить), чтобы сохранить изменения для возврата к списку атрибутов корневого объекта, как показано на рис. 4.20. Что такое сводная таблица?  129 Рис. 4.20  Список атрибутов корневого объекта после добавления дочернего объекта Следуя шагам, описанным выше, можно добавить дополнительные дочерние объекты, последовательно фильтрующие результаты поиска. Теперь модель данных готова, и ее можно использовать. Давайте посмот рим, как это делается. Что такое сводная таблица? Как отмечалось выше в этой главе, модели данных управляют сводными таб лицами (pivot). Но что такое сводная таблица? Сводные таблицы создаются с помощью редактора сводных таблиц Splunk Pivot Editor и могут быть простыми (или сложными) таблицами, диаграммами и дашбордами. Редактор Pivot Editor используется для отображения полей из модели данных в определенные визуальные представления без использования языка Splunk Enterprise Search Processing Language. Сводная таблица в Splunk – это простой интерфейс типа «перетащил и бросил», использующий предопределенные модели данных и объекты из них. Эти модели данных (спроектированные менеджерами с применением методов, описанных в предыдущих разделах) используются сводными таблицами для определения, разделения и задания атрибутов интересующих вас событий. В прежних версиях Splunk создание сводной таблицы можно было начать с выбора ссылки Pivot (Сводная таблица) на домашней странице. В версии 7.0 порядок создания немного изменился. Теперь, чтобы создать сводную таблицу, нужно выполнить следующие шаги. 1.Открыть домашнюю страницу Splunk и щелкнуть на ссылке Settings (Настройки); затем щелкнуть на ссылке Data Models (Модели данных). 2.Выбрать модель данных для сводной таблицы (в этом примере мы будем использовать созданную ранее модель Aviation Games, как показано на рис. 4.21). 130  Модели данных и сводные таблицы Рис. 4.21  Выбор модели данных для сводной таблицы 3.После выбора модели откроется страница Datasets Editor (Редактор наборов данных), где нужно щелкнуть на ссылке Pivot (Сводная таблица), как показано на рис. 4.22. Рис. 4.22  Ссылка Pivot (Сводная таблица) 4.Далее на странице Select a Dataset (Выбор набора данных) выберите набор данных для использования в сводной таблице, как показано на рис. 4.23. Рис. 4.23  Выбор набора данных 5.После выбора набора данных нужно выбрать объект из списка (который может быть объектом событий, транзакции, поиска или потомком и представляет определенный срез результатов поиска) с необходимым набором данных (или щелкнуть на кнопке Edit Datasets (Редактировать наборы данных), чтобы отредактировать объекты, имеющиеся в модели, или добавить новые), как показано на рис. 4.24. Рис. 4.24  Выбор объекта Что такое сводная таблица?  131 6.После выбора объекта Splunk откроет страницу Pivot Editor (Редактор сводных таблиц), где вы сможете создать свою сводную таблицу, как показано на рис. 4.25. Рис. 4.25  Страница редактора сводных таблиц Редактор Pivot Editor Редактор Pivot Editor запускается в режиме, который называют режимом сводной таблицы (pivot table mode). В этом режиме отображается только одна строка, представляющая общее количество результатов в объекте за все время. Под этим количеством под разумевается: Event type: общее количество событий (отобранных объектом); Transaction type: общее количество транзакций (выявленных объектом); Search type: общее количество строк в возвращаемой таблице. Сводные таблицы конструируются из элементов четырех основных типов: Filters (Фильтры), Split Rows (Разбить на строки), Split Columns (Разбить на столбцы) и Column Values (Столбцы значений). Первоначально определены два элемента: элемент фильтра (по умолчанию всегда получает значение All time (За все время)) и столбцы значений (по умолчанию всегда выбирается Count_of, то есть количество результатов, зависящее от типа выбранного объекта, как показано на рис. 4.26). Рис. 4.26  Элементы для конструирования сводной таблицы 132  Модели данных и сводные таблицы В редакторе можно добавлять, изменять и удалять элементы сводной таб лицы: Filters (Фильтры): используются для фильтрации результатов, возвращаемых объектом; Split rows (Разбить на строки): используются для разбиения результатов по строкам; Split columns (Разбить на столбцы): используются для разбиения значений по столбцам; Column values (Столбцы значений): используются для вывода агрегированных значений, таких как счетчики, суммы и средние значения. Работа с элементами сводных таблиц Со всеми элементами в редакторе Pivot Editor можно совершать определенные действия: щелчок на значке + откроет диалог элемента, где можно выбрать атрибут и определить, как он должен использоваться данным элементом; щелчок на значке с карандашом откроет диалог элемента, где можно увидеть и отредактировать определение элемента; пункты в элементе сводной таблицы можно перетаскивать мышью и таким способом изменять их порядок; также можно мышью перетаскивать пункты между элементами сводной таблицы (разумеется, существуют определенные ограничения на то, что можно перетаскивать между категориями); щелчок на значке с карандашом откроет диалог элемента, где можно щелкнуть на кнопке Remove (Удалить), чтобы удалить элемент (также можно ухватить элемент мышью и перетащить его вверх или вниз, пока он не окрасится в красный цвет, и отпустить – мой любимый способ). Все управление элементами сводной таблицы осуществляется посредством диалога. Процедура управления разбита на два этапа: выбор элемента и его настройка. Давайте поближе познакомимся с каждым из четырех типов элементов. Элементы фильтрации Сводные таблицы в Splunk поддерживают фильтрацию с помощью фильтров. Имеется три вида фильтров для использования в сводных таблицах. Важно знать и понимать, как они работают: Time (Время): присутствует всегда и не может быть удален; определяет интервал времени, которому должны принадлежать результаты; Match (Соответствие): позволяет настроить сопоставление для строк, чисел, меток времени, логических значений и адресов IPv4 (в настоящее время для сопоставлений поддерживается только оператор AND, но не OR); Limit (Предел): позволяет прямо ограничить число возвращаемых результатов. Что такое сводная таблица?  133 Перечень настроек для фильтров Match (Соответствие) и Limit (Предел) зависит от типа атрибута, выбранного для элемента. Разбиение (на строки или столбцы) Настройки разбиения (на строки и столбцы) зависят от типа выбранного атрибута. Некоторые настройки доступны только для строк или столбцов, тогда как другие – и для строк, и для столбцов. Вот настройки, не зависящие от типа атрибута: и для строк, и для столбцов: – Max rows (Максимальное число строк) и Max columns (Максимальное число столбцов): определяют максимальное число строк и столбцов в таблице с результатами; – Totals (Всего): флаг, определяющий необходимость включения в таб лицу итоговой строки или столбца, включающей(го) все остальное в атрибут с именем ALL; только для разбиения на строки: – Label (Метка): переопределяет имя атрибута другим текстом или строкой символов; – Sort (Сортировка): используется для переупорядочения строк; только для разбиения на столбцы: – Group Others (Группировать остальные): флаг, определяющий необходимость группировки результатов, исключенных из таблицы настройкой Max columns (Максимальное число столбцов), в отдельный столбец OTHER. Настройки, зависящие от типа атрибута: для строковых атрибутов: – для строковых атрибутов нет настроек, общих для разбиения на строки и столбцы; для числовых атрибутов: – Create ranges (Создавать диапазоны): флаг, определяющий необходимость представления числовых значений в виде диапазонов (yes) или отдельных значений (no); для логических атрибутов: – позволяет определить альтернативные метки для обозначения истинных и ложных значений; для отметок времени: – Period (Интервал): позволяет сгруппировать метки времени по году, месяцу, дню месяца, часу, минуте или секунде. Столбцы значений По умолчанию для сводной таблицы создаются столбцы значений, представляющие общее количество результатов, возвращаемое выбранным объектом за 134  Модели данных и сводные таблицы весь период времени. Вы можете сохранить этот элемент, изменить его метку или удалить его. Также можно добавить новые элементы столбца значений: список отдельных значений; первое/последнее значение; счетчик и счетчик уникальных значений; сумма; среднее; максимальное и минимальное значения; стандартное отклонение; список уникальных значений; продолжительность; ранний/поздний. Форматирование сводной таблицы Результаты в сводной таблице можно отформатировать множеством способов. Можно определить количество результатов, отображаемых на одной странице (10, 20 или 50). Также можно управлять переносом строк в таблице, отображением их номеров, выводом детализированной информации и наложением данных. Сводные таблицы с детализированной информацией по умолчанию действуют в режиме ячейки (cell mode), подобно детализированным таблицам, описанным в главе 3 «Таблицы, диаграммы и поля». Короткий пример Рассмотрим короткий пример. После выбора модели данных (в данном случае Aviation Games) на странице Select a Dataset (Выбор набора данных) выберите объект Processing Errors, после чего откроется страница New Pivot (Новая сводная таблица), как показано на рис. 4.27. Рис. 4.27  Страница New Pivot (Новая сводная таблица) Чтобы получить простую сводную таблицу, выполним следующие шаги. 1. Добавим и проверим фильтры. Напомню, что по умолчанию создается единственный фильтр All time (За все время); он пропускает все результаты за все время. Вы можете Короткий пример  135 щелкнуть на значке карандаша и изменить этот фильтр, используя один из готовых интервалов или определив свой в разделе Date Range (Диапазон дат), как показано на рис. 4.28. Рис. 4.28  Настройки фильтра В данном примере просто оставим настройки фильтра по умолчанию. 2. Настроим разбиение на строки. Непосредственно под элементом Filters (Фильтры) находится элемент Split Rows (Разбить на строки). Я решил выполнить разбиение по атрибуту date_month, как показано на рис. 4.29. Рис. 4.29  Выбор атрибута для разбиения на строки 136  Модели данных и сводные таблицы 3.Выбрав атрибут, можно определить дополнительные настройки, как показано на рис. 4.30. Рис. 4.30  Дополнительные настройки после выбора атрибута для разбиения на строки Я задал новое имя my_Month для строки в поле Label (Метка) и оставил значения по умолчанию в полях Sort (Сортировка), Max Rows (Максимальное число строк) и Totals (Всего). 4. Настроим разбиение на столбцы. Справа вверху на странице создания сводной таблицы имеется элемент Split Columns (Разбить на столбцы). Я решил выполнить разбиение по атрибуту date_mday, как показано на рис. 4.31. Рис. 4.31  Выбор атрибута для разбиения на столбцы После выбора атрибута можно определить дополнительные настройки, как показано на рис. 4.32. Короткий пример  137 Рис. 4.32  Дополнительные настройки после выбора атрибута для разбиения на столбцы Я оставил во всех полях значения по умолчанию и щелкнул на кнопке Add To Table (Добавить в таблицу). 5.Настроим столбцы значений. После щелчка на значке с карандашом рядом с элементом Column Values (Столбцы значений) откроется диалог с настройками по умолчанию для столбцов счетчиков ошибок обработки, найденных в индексированных данных (как показано на рис. 4.33). Здесь просто щелкните на кнопке Update (Обновить). Рис. 4.33  Настройки столбца значений по умолчанию 6. Взгляните на рис. 4.34, где показано, что у нас получилось. 138  Модели данных и сводные таблицы Рис. 4.34  Предварительный просмотр получившейся сводной таблицы Теперь у вас на выбор есть два пути: щелкнуть на кнопке Clear (Очис тить) и начать все сначала или выбрать меню Save As (Сохранить как) и сохранить сводную таблицу в виде отчета или дашборда для последую щего использования. Рис. 4.35  Теперь сводную таблицу можно сохранить в виде отчета или дашборда Sparklines Sparklines, или встраиваемые диаграммы (популярность которых как средства визуализации продолжает расти), помогают показать общий характер изменения (обычно во времени) некоторой характеристики (такой как мили на галлон или стоимость в стране производства) простым и очень компактным способом. Splunk дает возможность добавлять встраиваемые диаграммы в статистики и диаграммы, созданные по результатам поиска, и увеличивать их ценность и информативность. Рассмотрим простой поисковый запрос: sourcetype=csv "0001" "USD" | chart AVG(Jan) by PERIOD Он создает таблицу с результатами, изображенную на рис. 4.36. Sparklines  139 Рис. 4.36  Таблица с результатами Как видите, для поля PERIOD в таблице создается всего два столбца со средними значениями. Если теперь добавить в запрос ключевое слово sparkline, как показано ниже: sourcetype=csv "0001" "USD" | chart sparkline AVG(Jan) by PERIOD Splunk добавит в таблицу встраиваемые диаграммы, как показано на рис. 4.37. Ключевое слово sparklines всегда используется в комбинации с командами chart и stats, потому что это имя функции (этих двух команд), а не самостоятельная команда. Если теперь вновь запустить поиск, Splunk выведет таблицу, похожую на предыдущую, но теперь в каждой строке будет присутствовать встроенная диаграмма (см. рис. 4.37). Рис. 4.37  Теперь в каждой строке присутствует встроенная диаграмма Вот еще один пример использования встраиваемых диаграмм: демонстрация изменчивости сумм (округленного значения за январь) по полю COMPANY: sourcetype=csv "0001" "USD" | eval RJan= round(Jan) | chart sparkline Sum(RJan) by COMPANY Получившийся результат изображен на рис. 4.38. 140  Модели данных и сводные таблицы Рис. 4.38  Еще один пример использования встраиваемых диаграмм Теперь закономерности в данных, которые раньше не замечались, видны достаточно отчетливо. Встраиваемые диаграммы в Splunk отображают информацию о событиях, охватываемых этими диаграммами, но они не связаны с другими диаграммами. Итоги В этой главе представлено определение моделей данных, сводных таблиц (вместе с их элементами) и встраиваемых диаграмм. Познакомившись с прос тыми примерами, читатель наверняка оценил широту их возможностей. Система Splunk всегда показывала высокую производительность, тем не менее в основные модули в версии 7.0 были добавлены дополнительные оптимизации, обеспечившие увеличение производительности до 20 раз ускоренных алгоритмов обработки данных (tstats) и до 200 раз неускоренных алгоритмов при запросе метрик. Кроме того, запросы на получение метрик в режиме реального времени потребляют меньше ресурсов. Эти улучшения могут зависеть от фактического окружения, тем не менее вы вправе ожидать заметного улучшения. В следующей главе мы познакомимся с простыми дашбордами на упрощенном XML, их назначением, конструированием с помощью мастеров, запуском по расписанию, приемами прямой правки кода XML и с созданием форм. Глава 5 Простые дашборды на XML Дашборды (dashboard) – это инструмент для автоматического получения, группировки и представления данных в виде таблиц и диаграмм наиболее информативным способом. В этой главе мы бегло познакомимся с инструментом построения дашбордов в Splunk 7.0 и затем углубимся в изучение кода на языке XML. Используя XML, вы легко сможете создавать интерактивные формы, настраивать панели, задействовать одни и те же запросы в нескольких панелях и многое другое. XML – индустриальный стандарт метаязыка – это мощный инструмент. В этой главе предполагается, что читатель уже знаком с основами данного языка. Читатели, незнакомые с ним, найдут массу других источников информации, кроме этой книги. Здесь также рассказывается, как и когда генерировать дашборды, чтобы уменьшить время ожидания и нагрузку на сервер. Эта глава охватывает следующие темы: назначение дашбордов; конструирование дашбордов с помощью мастеров; выполнение запросов по расписанию; непосредственная правка кода на XML; приложение с примерами пользовательского интерфейса; конструирование форм. Назначение дашбордов Любой поиск, таблицу или диаграмму, созданные вами, можно сохранить и добавить в меню для других пользователей. Обладая такой возможностью, почему бы не создать дашборд? Вот несколько причин для этого: дашборд может включать несколько панелей, каждая из которых выполняет свой запрос; каждый дашборд имеет уникальный URL, которым легко поделиться с другими; дашборды намного гибче отдельных запросов; 142  Простые дашборды на XML устраняется полоса поиска, что делает дашборд менее пугающим для пользователей; формы позволяют создавать настраиваемый интерфейс поиска, требующий ввода только определенных значений; дашборды имеют превосходный внешний вид. Во многих организациях дашборды выводятся на проекторы и мониторы для получения оперативной информации о состоянии инфраструктуры. Есть возможность наполнять дашборды информацией по расписанию и рассылать по электронной почте в виде файлов PDF. Это не самый лучший способ использования дашбордов, но, приложив определенные усилия, его можно применять с высокой эффективностью. При всем при этом, если сохраненный поиск прекрасно справляется со своей задачей, нет веских причин превращать его в дашборд. Конструирование дашбордов с помощью мастеров Цель этой главы – познакомить вас с дашбордами Splunk (а не с основами поиска), поэтому для иллюстрации некоторых моментов мы используем несколько новых поисковых запросов, а также несколько запросов из предыдущих глав. Итак, начнем с создания дашборда для отображения событий с предсказаниями (Forecast) в наших индексированных данных. Для начала используем следующий простой поисковый запрос: sourcetype="*" Forecast | timechart count as "Forecast Events" by date_month Он показан в строке поиска на рис. 5.1. Рис. 5.1  Строка поиска с примером запроса Кроме запроса, я также выбрал предопределенный параметр периода времени Previous Year (Предыдущий год), как показано на рис. 5.1. В результате получилась диаграмма, изображенная на рис. 5.2. Рис. 5.2  Диаграмма с результатами запроса Конструирование дашбордов с помощью мастеров  143 Чтобы добавить ее в дашборд, выполним следующие шаги: 1.В меню Save As (Сохранить как) выберите пункт Dashboard Panel (Панель дашборда), как показано на рис. 5.3. Рис. 5.  Пункт Dashboard Panel (Панель дашборда) 2.В результате откроется диалог, в котором можно сохранить запрос в виде дашборда, как показано на рис. 5.4. Рис. 5.4  Диалог, где можно сохранить запрос в виде дашборда 3.Заполните поля ввода, как предлагается ниже, и щелкните на кнопке Save (Сохранить). Dashboard New/Existing (Дашборд новый/существующий): позволяет указать, как сохранить поиск – как часть существующего дашборда или нового. В данном примере я выбрал New (Новый). Dashboard Title (Название дашборда): просто введите название для своего дашборда. 144  Простые дашборды на XML Dashboard ID (Идентификатор дашборда): идентификатор дашборда в Splunk, который по умолчанию получается из названия с заменой специальных символов (таких как пробелы). Dashboard Description (Описание дашборда): сюда можно ввести короткий текст, описывающий назначение дашборда. Dashboard Permissions (Разрешения дашборда): определяет, будет ли дашборд скрыт от других пользователей или его можно использовать в приложении. Panel Title (Название панели): короткий подзаголовок, который будет отображаться на панели дашборда (где выполняется поиск). Panel Powered By (Панель управляемая): заполняется системой Splunk. Данный пример выполняется встроенным запросом. Panel Content (Содержимое панели): здесь можно определить формат представления результатов поиска. 4. После этого появится сообщение, как показано на рис. 5.5. Рис. 5.5  Сообщение, появляющееся после щелчка на кнопке Save (Сохранить) Теперь новый дашборд готов к использованию. При создании большого количества дашбордов вам придется определить множество поисковых запросов. Выработка концепции именования поможет вам быстро определять принадлежность запроса тому или иному дашборду. Вот несколько рекомендаций: Dashboard - [имя дашборда] - [имя запроса и тип панели] Если количество дашбордов и запросов достаточно велико, их можно объединить в группы и создать еще один организационный уровень. После сохранения дашборда он появится в меню Dashboards (Дашборды), как показано на рис. 5.6. Конструирование дашбордов с помощью мастеров  145 Рис. 5.6  После сохранения дашборд появится в меню Dashboards (Дашборды) Если на странице Dashboards (Дашборды) щелкнуть на имени дашборда (например, Forecast Events), Splunk отобразит единственную панель дашборда, как показано на рис. 5.7. Рис. 5.7  Панель дашборда Добавление еще одной панели В какой-то момент у вас появится желание добавить в свой дашборд еще одну панель. Для этого откройте дашборд и щелкните на кнопке Edit (Редактировать), как показано на рис. 5.8. Рис. 5.8  Кнопка для перехода к редактированию дашборда 146  Простые дашборды на XML В версии 7.0 щелчок на кнопке Edit (Редактировать) откроет страницу Edit Dashboard (Редактирование дашборда), как показано на рис. 5.9. Рис. 5.9  Страница Edit Dashboard (Редактирование дашборда) Щелкните на кнопке Add Panel (Добавить панель), как показано на рис. 5.10. Рис. 5.10  Кнопка Add Panel (Добавить панель) После этого появится диалог с вариантами выбора, как показано на рис. 5.11. Этот диалог перечисляет источники, откуда можно получить панель для добавления в дашборд: New (Новая): создаст новую панель; New from Report (Новая из отчета): создаст панель из существующего отчета; Clone from Dashboard (Копировать из дашборда): создаст панель из существующего дашборда; Add Prebuilt Panel (Добавить предопределенную панель): как можно заключить из названия, щелчок на этой ссылке добавит предопределенную панель. Конструирование дашбордов с помощью мастеров  147 Рис. 5.11  Диалог с вариантами выбора Для нашего примера выберем вариант New (Новая). Рис. 5.12  Перечень вариантов для создания новой панели Powered by TCPDF (www.tcpdf.org) 148  Простые дашборды на XML И снова на выбор будет предложено несколько вариантов (см. рис. 5.12). Давайте выберем вариант Pie Chart (Круговая диаграмма) и заполним поля настройки в диалоге New Pie Chart (Новая круговая диаграмма), как показано на рис. 5.13. Я просто выбрал предопределенный интервал времени (Previous year (Предыдущий год)), ввел свое название в поле Content Title (Название содержимого) и ту же самую строку поиска. Идея состоит в том, чтобы отобразить ту же информацию, что и в первой панели, но в ином виде. Рис. 5.13  Диалог New Pie Chart (Новая круговая диаграмма) Далее щелкните на кнопке Add to Dashboard (Добавить в дашборд). Конструирование дашбордов с помощью мастеров  149 Рис. 5.14  Новая панель в дашборде На рис. 5.14 показано, как выглядит новая панель в нашем двухпанельном дашборде. Как видите, круговая диаграмма смотрится не особенно эффектно, поэтому давайте заменим ее. Обратите внимание на четыре значка в правом верхнем углу нижней панели. Если щелкнуть на втором значке слева (с изображением маленькой круговой диаграммы), вы увидите, что у вас есть возможность изменить тип визуализации и что Splunk просмотрел ваши данные и подобрал некоторые рекомендации. Вы можете попробовать все предложенные варианты; я выбрал Area (Площадная диаграмма) и получил результат, изображенный на рис. 5.15. Рис. 5.15  Результат выбора площадной диаграммы 150  Простые дашборды на XML Обратите внимание, что в версии 7.0 появились дополнительные и более сложные типы визуализации, как показано на рис. 5.16. Рис. 5.16  В версии 7.0 появились дополнительные типы визуализации Интересный трюк По умолчанию новые панели добавляются в дашборд снизу, как можно видеть на рис. 5.14. Однако у вас есть возможность переупорядочить панели в дашборде; обычно пространства на странице достаточно, чтобы разместить до трех панелей в ряд по горизонтали (конечно, вы не ограничены тремя панелями). Ухватив панель мышью за верхнюю границу, ее можно переместить в любое место на странице, как показано на рис. 5.17. Конструирование дашбордов с помощью мастеров  151 Рис. 5.1  Панель можно переместить в любое место на странице, ухватив мышью за верхнюю границу А теперь вернемся к четырем значкам на панелях в дашборде. Рис. 5.18  Значки в правом верхнем углу панели 152  Простые дашборды на XML Щелкните на первом (слева) значке с изображением лупы. Теперь, в версии 7.0, этот значок открывает страницу Edit Search (Редактировать запрос), как показано на рис. 5.18. Рис. 5.19  Страница Edit Search (Редактировать запрос) В нашем примере дашборда панели используют встроенный запрос. Использование встроенного запроса позволяет сконструировать запрос непосредственно внутри дашборда. Часто это удобно, потому что в большинстве случаев запросы не имеют никакой другой цели, кроме использования их в конкретном дашборде, поэтому нет причин для появления этих запросов в меню Splunk. Кроме того, такой подход уменьшает количество внешних зависимостей и упрощает перенос дашборда в другое приложение. На странице Edit Search (Редактировать запрос) можно изменить строку поиска, интервал времени, параметры автоматического обновления и индикатор выполнения обновления. Кроме того, можно щелкнуть на кнопке Convert to Report (Преобразовать в отчет) и преобразовать панель в отчет. С помощью этих настроек можно изменить панель дашборда, как вам заблагорассудится. Чтобы удалить панель из дашборда и начать все заново, в версии 7.0 достаточно щелкнуть на значке с изображением крестика (×) в правом верхнем углу панели. Преобразование панели в отчет В какой-то момент у вас может появиться желание преобразовать в отчет панель из дашборда (основанную на встроенном запросе), поэтому панели на основе отчетов имеют определенные преимущества перед панелями на основе Преобразование панели в отчет  153 встроенных запросов, например они загружаются намного быстрее благодаря действию механизма ускорения отчетов. Если щелкнуть на кнопке Convert to Report (Преобразовать в отчет), откроется диалог, как показано на рис. 5.20. В этом диалоге я заполнил поля Report Title (Название отчета) и Description (Описание). Рис. 5.20  Диалог преобразования панели в отчет Теперь панель основана на отчете Splunk (рис. 5.21). Рис. 5.21  Панель основана на отчете Splunk Заметили, как изменился значок с изображением лупы? Теперь он уже не открывает страницу Edit Search (Редактировать запрос). Давайте щелкнем на нем и посмотрим, что за ним скрывается (см. рис. 5.22). 154  Простые дашборды на XML Рис. 5.22  Информация об отчете Мы видим название отчета Prior Year Forecasting Events (которое ввели выше) и подтверждение, что теперь панель основана на отчете, как показано на рис. 5.23. Рис. 5.23  Мы видим название отчета и подтверждение, что панель основана на отчете Преобразование панели в отчет  155 Теперь Splunk предлагает больше вариантов для настройки панели дашборда, например View (Просмотр), Open in Search (Открыть в приложении поиска), Clone to an Inline Search (Преобразовать в панель со встроенным поиском), Select a New Report (Выбрать новый отчет) и Use Report’s Formatting for this Content (Использовать форматирование отчета для этого содержимого). Чаще всего, пожалуй, используется ссылка View (Просмотр), щелчок на которой открывает полноценный отчет Splunk, как показано на рис. 5.24. Рис. 5.24  Щелчок на ссылке View (Просмотр) открывает полноценный отчет Splunk Двинемся дальше. Мы уже знаем назначение второго значка (мы использовали его для замены круговой диаграммы площадной). Поэтому добавлю лишь, что после щелчка на нем вы сможете выбрать ссылку View Events (Просмотреть события), чтобы увидеть список исходных событий в панели (см. рис. 5.25), похожий на тот, что выводится при выполнении обычного поиска. 156  Простые дашборды на XML Рис. 5.25  Ссылка View Events (Просмотреть события) выводит список исходных событий в панели Перейдем к третьему значку с изображением кисточки. Щелчок на нем выводит диалог с дополнительными настройками панели (параметрами форматирования, в зависимости от выбранного формата панели). Например, левая панель в дашборде форматируется как статистическая таблица, поэтому для нее доступны настройки, показанные на рис. 5.26. Рис. 5.26  Настройки, доступные для статистической таблицы Вы можете поэкспериментировать с ними (они применяются динамически), пока не получите желаемый результат, а затем снова щелкните на значке, чтобы закрыть диалог. И снова о дашборде  157 Дополнительные настройки Также в правом верхнем углу панели имеется значок с изображением шестеренки (см. рис. 5.27). Щелкнув на этом значке, можно преобразовать данную панель в предопределенную панель или в панель со встроенным поиском. Рис. 5.27  Дополнительные настройки В первый момент может быть непонятно, что означает Convert to Prebuilt Panel (Преобразовать в предопределенную панель)? Дело в том, что до сих пор наша панель была встроенной панелью, которую можно редактировать в редакторах дашбордов и панелей (а также править код XML непосредственно; подробнее об этом мы поговорим ниже в этой главе). Предопределенная панель – это панель, которую можно использовать в нескольких дашбордах. Предопределенные панели не позволяют редактировать их названия, поисковые запросы или параметры визуализации по ссылке из дашборда. И снова о дашборде Меню дашборда (немного изменилось в версии 7.0) слева вверху находится набор переключателей, как показано на рис. 5.28. Мы уже рассмотрели первый из них (Add Panel (Добавить панель)). Теперь перейдем к следующему – Add Input (Добавить ввод). Переключатели UI (Пользовательский интерфейс) и Source (Исходный код) мы рассмотрим позже. Рис. 5.28  Меню дашборда Добавление полей ввода Добавление поддержки ввода в дашборд превратит его в форму. На самом деле все дашборды определяются в виде кода XML (мы уже коротко упоминали об этом). В следующем разделе «Редактирование исходного кода» мы чуть больше углубимся в эту тему, а пока просто помните, что дашборд, созданный нами, определяется кодом на языке XML, и добавление любых полей ввода влечет изменение исходного кода на XML (после добавления полей ввода XML-тег <dashboard> заменяется на <form>). 158  Простые дашборды на XML После щелчка на кнопке Add Input (Добавить ввод) будет предложен список доступных типов полей ввода, как показано на рис. 5.29. Рис. 5.29  Доступные типы полей ввода Например, можно выбрать Text (Текст) и добавить текстовое поле ввода. Поля ввода можно не только добавлять в дашборд, но также перетаскивать их мышью в нужные места в форме (дашборде). Можно даже перетащить поле ввода на панель в дашборде и использовать его исключительно в этой панели. Закончив добавлять и размещать поля ввода, щелкните на кнопке Done (Завершить), чтобы сообщить Splunk, что редактирование закончено. Далее, в разделе, посвященном формам, мы рассмотрим эту тему подробнее. Редактирование исходного кода Теперь перейдем к третьему переключателю, Source (Исходный код). Как уже говорилось, все дашборды в Splunk определяются в коде на XML. Если у вас нет опыта использования XML, можете создавать, настраивать и сопровождать дашборды, используя редактор дашбордов (подобно тому, как мы делали это в примерах выше). Однако доступность исходного кода на XML дает нам возможность создавать очень сложные дашборды. Редактирование пользовательского интерфейса Последний переключатель, UI (Пользовательский интерфейс), вернет вас в обычный режим визуального редактирования (из редактора исходного кода). Непосредственное редактирование XML Прежде чем продолжить, позвольте мне воспользоваться моментом и поблагодарить разработчиков Splunk за создание редактора дашбордов. В действительности не так много причин, по которым вам придется заниматься правкой кода XML с определением дашбордов, и основные из них – редактирование форм и заключительная обработка данных. Я верю, что в будущем, с расширением возможностей редактора дашбордов, эти причины исчезнут. Документацию с описанием упрощенного языка XML для определения панелей можно найти на сайте http://www.splunk.com/, если воспользоваться по- Создание форм  159 иском по сайту. Для начала загляните по следующей ссылке: http://docs.splunk. com/Documentation/Splunk/latest/Viz/PanelreferenceforSimplifiedXML. Приложение с примерами пользовательского интерфейса Перед тем как углубиться в код XML дашбордов, нелишним будет установить приложение с примерами пользовательского интерфейса для Splunk 4.1+, доступное на Splunkbase (см. главу 8 «Работа с приложениями», где приводится информация о Splunkbase). Примеры в этом приложении позволяют получить хорошее представление о возможностях, доступных при использовании упрощенного и продвинутого XML для создания дашбордов. После установки приложение станет доступно в разделе Splunk Apps (Приложения Splunk), ссылка на который имеется на домашней странице Splunk. Создание форм Формы позволяют создать шаблон, для запуска которого необходима некоторая дополнительная информация. Формы можно описывать непосредственно на языке XML, но, как мне кажется, проще сконструировать простой дашборд, а потом вносить нужные правки в сгенерированный код XML. Другой способ – скопировать имеющийся дашборд и изменить его под свои потребности. Рассмотрим простой пример в следующем разделе. Создание формы из дашборда Для начала представим ситуацию, где мог бы пригодиться наш дашборд из предыдущего примера. Может быть, из него создать форму, отображающую события за произвольно выбранный год? Начнем с запроса в предыдущем примере: sourcetype="*" Forecast | timechart count as "Forecast Events" by date_month Поскольку у нас уже есть дашборд, основанный на этом запросе, откроем его исходный код на XML и заглянем внутрь. Итак, щелкните в редакторе дашбордов на переключателе Source (Исходный код). После этого откроется редактор с кодом XML нашего дашборда, который показан ниже. Обратите внимание на два тега <panel>, они указывают на наличие двух панелей в нашем дашборде: <dashboard> <label>Forecast Events</label> <description>This is my wonderful save as dashboard example.</description> <row> <panel> <table> <title>Forecast Events From Previous Year</title> <search> <query> sourcetype="*" Forecast | timechart count as "Forecast Events" by date_month 160  Простые дашборды на XML </query> <earliest>-1y@y</earliest> <latest>@y</latest> </search> </table> </panel> <panel> <chart> <title>Prior Year Forecasting Events</title> <search ref="Prior Year Forecasting Events"></search> <option name="list.drilldown">full</option> <option name="list.wrap">1</option> <option name="maxLines">5</option> <option name="raw.drilldown">full</option> <option name="rowNumbers">0</option> <option name="table.drilldown">all</option> <option name="table.wrap">1</option> <option name="type">list</option> <fields>["host","source","sourcetype"]</fields> <option name="charting.axisLabelsX.majorLabelStyle.overflowMode">ellipsisNone </option> <option name="charting.axisLabelsX.majorLabelStyle.rotation">0</option> <option name="charting.axisTitleX.visibility">visible</option> <option name="charting.axisTitleY.visibility">visible</option> <option name="charting.axisTitleY2.visibility">visible</option> <option name="charting.axisX.scale">linear</option> <option name="charting.axisY.scale">linear</option> <option name="charting.axisY2.enabled">false</option> <option name="charting.axisY2.scale">inherit</option> <option name="charting.chart">line</option> <option name="charting.chart.bubbleMaximumSize">50</option> <option name="charting.chart.bubbleMinimumSize">10</option> <option name="charting.chart.bubbleSizeBy">area</option> <option name="charting.chart.nullValueMode">gaps</option> <option name="charting.chart.sliceCollapsingThreshold">0.01</option> <option name="charting.chart.stackMode">default</option> <option name="charting.chart.style">shiny</option> <option name="charting.drilldown">all</option> <option name="charting.layout.splitSeries">0</option> <option name="charting.legend.labelStyle.overflowMode"> ellipsisMiddle </option> <option name="charting.legend.placement">right</option> </chart> </panel> </row> </dashboard> Это довольно простой код. Чтобы превратить дашборд в форму, нужно сначала заменить тег <dashboard> на <form>. Не забудьте также заменить закрывающий тег </dashboard> на </form>. Затем добавить тег <fieldset> с элементами формы, например: Создание форм  161 <form> <label>Chapter 5 Build a Form 1</label> <fieldset> <input type="text" token="myyear"> <label>MyYear</label> </input> </fieldset> После этого добавить переменную в <query>, получающую значение из поля ввода: <query> sourcetype="*" Forecast date_year=$myyear$ | timechart count as "Forecast Events" by date_month </query> По окончании должен получиться такой код на XML: <form> <label>Forecast Events</label> <description>This is my wonderful save as dashboard example.</description> <label>Chapter 5 Build a Form 1</label> <fieldset> <input type="text" token="myyear"> <label>MyYear</label> </input> </fieldset> <row> <panel> <table> <title>Forecast Events From Previous Yeaar</title> <search> <query> sourcetype="*" Forecast date_year=$myyear$ | timechart count as "Forecast Events" by date_month </query> <earliest>-1y@y</earliest> <latest>@y</latest> </search> </table> </panel> <panel> <chart> <title>Prior Year Forecasting Events</title> <search ref="Prior Year Forecasting Events"></search> <option name="list.drilldown">full</option> <option name="list.wrap">1</option> <option name="maxLines">5</option> <option name="raw.drilldown">full</option> <option name="rowNumbers">0</option> <option name="table.drilldown">all</option> <option name="table.wrap">1</option> <option name="type">list</option> <fields>["host","source","sourcetype"]</fields> <option name="charting.axisLabelsX.majorLabelStyle.overflowMode"> 162  Простые дашборды на XML ellipsisNone </option> <option name="charting.axisLabelsX.majorLabelStyle.rotation">0</option> <option name="charting.axisTitleX.visibility">visible</option> <option name="charting.axisTitleY.visibility">visible</option> <option name="charting.axisTitleY2.visibility">visible</option> <option name="charting.axisX.scale">linear</option> <option name="charting.axisY.scale">linear</option> <option name="charting.axisY2.enabled">false</option> <option name="charting.axisY2.scale">inherit</option> <option name="charting.chart">line</option> <option name="charting.chart.bubbleMaximumSize">50</option> <option name="charting.chart.bubbleMinimumSize">10</option> <option name="charting.chart.bubbleSizeBy">area</option> <option name="charting.chart.nullValueMode">gaps</option> <option name="charting.chart.sliceCollapsingThreshold">0.01</option> <option name="charting.chart.stackMode">default</option> <option name="charting.chart.style">shiny</option> <option name="charting.drilldown">all</option> <option name="charting.layout.splitSeries">0</option> <option name="charting.legend.labelStyle.overflowMode"> ellipsisMiddle </option> <option name="charting.legend.placement">right</option> </chart> </panel> </row> </form> Щелкните на кнопке Save (Сохранить) и затем попробуйте выполнить поиск событий, возникших в конкретном году. Обратите внимание, как изменился наш дашборд: в нем появились поле ввода MyYear (Мой год) и кнопка Submit (Послать), а также сообщение Search is waiting for input... (Поиск ожидает ввода...), как показано на рис. 5.30. Рис. 5.30  В дашборде появились поле ввода, кнопка и сообщение Создание форм  163 Теперь у нас есть удобная форма для отображения событий за любой выбранный год. Управление несколькими панелями из одной формы Единственная форма также может управлять сразу несколькими панелями. Ранее мы создали дашборд с двумя панелями, одну из которых преобразовали в отчет. Давайте ненадолго вернемся к этому дашборду. При желании можно снова отредактировать исходный код XML дашборда и преобразовать все поисковые запросы, по аналогии с предыдущим примером, чтобы использовать в них поле формы: <form> <label>Forecast Events</label> <description>This is my wonderful save as dashboard example.</description> <fieldset> <input type="text" token="myyear"> <label>MyYear</label> </input> </fieldset> <row> <panel> <table> <title>Forecast Events From Previous Yeaar</title> <search> <query>sourcetype="*" Forecast date_year=$myyear$ | timechart count as "Forecast Events" by date_month</query> <earliest>-1y@y</earliest> <latest>@y</latest> </search> </table> </panel> </row> <row> <panel> <chart> <title>Forecast Events From Previous Yeaar</title> <search> <query>sourcetype="*" Forecast date_year=$myyear$ | timechart count as "Forecast Events" by date_month</query> <earliest>-1y@y</earliest> <latest>@y</latest> </search> <option name="wrap">true</option> <option name="rowNumbers">true</option> <option name="dataOverlayMode">none</option> <option name="count">10</option> <option name="charting.axisLabelsX.majorLabelStyle.overflowMode"> ellipsisNone </option> <option name="charting.axisLabelsX.majorLabelStyle.rotation">0</option> 164  Простые дашборды на XML <option name="charting.axisTitleX.visibility">visible</option> <option name="charting.axisTitleY.visibility">visible</option> <option name="charting.axisTitleY2.visibility">visible</option> <option name="charting.axisX.scale">linear</option> <option name="charting.axisY.scale">linear</option> <option name="charting.axisY2.enabled">false</option> <option name="charting.axisY2.scale">inherit</option> <option name="charting.chart">area</option> <option name="charting.chart.bubbleMaximumSize">50</option> <option name="charting.chart.bubbleMinimumSize">10</option> <option name="charting.chart.bubbleSizeBy">area</option> <option name="charting.chart.nullValueMode">gaps</option> <option name="charting.chart.sliceCollapsingThreshold">0.01</option> <option name="charting.chart.stackMode">default</option> <option name="charting.chart.style">shiny</option> <option name="charting.drilldown">all</option> <option name="charting.layout.splitSeries">0</option> <option name="charting.legend.labelStyle.overflowMode"> ellipsisMiddle </option> <option name="charting.legend.placement">right</option> </chart> </panel> </row> </form> После щелчка на кнопке Save (Сохранить) вы вернетесь к своему дашборду, но теперь поле формы будет управлять обеими панелями. На рис. 5.31 я расположил панели по горизонтали, чтобы их проще было охватить взглядом. Рис. 5.31  Теперь поле формы управляет обеими панелями Создание форм  165 Существует большое количество элементов форм с разнообразными настройками их поведения. Официальную документацию с описанием создания и редактирования форм на простом XML вы можете найти на сайте http://www. splunk.com/. В документации и в приложении с примерами пользовательского интерфейса (см. раздел «Приложение с примерами пользовательского интерфейса» выше) имеется много интересных примеров. Постобработка результатов поиска В предыдущем примере вы могли заметить, что оба запроса выглядят совершенно одинаково: sourcetype="*" Forecast date_year=$myyear$ | timechart count as "Forecast Events" by date_month Конечно, было бы пустой тратой времени четырежды запускать один и тот же запрос. В предыдущих версиях Splunk можно было использовать тег <searchPostProcess>, чтобы выполнить запрос один раз и применять команды к результатам в каждой панели. Для этого вынесем запрос из определений панелей на верхний уровень XML. Результаты из <searchTemplate> будут использоваться панелью, если она не имеет своего запроса или если этот запрос указан как источник в <searchPostProcess>. Нам нужно лишь указать поле формы, используемое обеими панелями. Сделать это можно, как показано ниже: <?xml version='1.0' encoding='utf-8'?> <form> <searchTemplate> sourcetype="*" Forecast date_year=$myyear$ | timechart count as "Forecast Events" by date_month </searchTemplate> При такой организации дашборд будет строиться точно так же, как дашборд в предыдущем примере, с той лишь разницей, что запрос выполнится только один раз, результаты появятся на экране быстрее и будет использовано меньше ресурсов. Но для этого требуется приложить больше усилий, как будет показано в следующем разделе. Другой способ ограничить число выполняемых запросов – определить тег <search> с атрибутом id, а потом просто ссылаться на значение этого атрибута. Ограничения постобработки Тег <searchPostProcess> накладывает одно большое и несколько маленьких ограничений, из-за которых часто приходится прикладывать дополнительные усилия. Из исходного запроса передаются только первые 10 000 результатов. Чтобы обойти это ограничение, нужно передать события команде stats, 166  Простые дашборды на XML timechart или table. Команды преобразования, такие как stats, уменьшают количество строк в результатах и увеличивают производительность. Из исходных событий передаются только явно указанные поля. Это ограничение можно обойти с командой table или агрегируя результаты в меньшее количество строк с помощью stats. Первое ограничение встречается на практике чаще всего. Типичное решение этой проблемы заключается в предварительном объединении событий в надмножество, требуемое панелям. Для этого на первом этапе можно исследовать запросы и выяснить, какие необходимы для всех последующих запросов, и т. д. Устаревшие функции В ходе развития Splunk на смену XML-тегам <searchString>, <searchTemplate>, <searchName> и <searchPostProcess> пришел новый тег <search>. Следующий дашборд с двумя панелями использует тег <search> и команду stats для преодоления ограничений постобработки. Запрос определяется на уровне дашборда (за пределами определений панелей). Вот как выглядит наш базовый запрос (обратите внимание на атрибут id в элементе <search>): <dashboard> <label>Dashboard with post-process search</label>    <search id="baseSearch"> <query>sourcetype=tm1* dimension | stats count by date_month, date_wday</query> </search> </dashboard> Далее, в панелях, используется базовый запрос с дополнительными строками поиска: <panel> <chart> <title>Dimension Events count by Month</title> <search base="baseSearch"> <query>stats sum(count) AS count by date_month</query> </search>  <option name="charting.axisLabelsX.majorLabelStyle.overflowMode"> ellipsisNone </option> <option name="charting.axisLabelsX.majorLabelStyle.rotation">0</option> <option name="charting.axisTitleX.visibility">visible</option> <option name="charting.axisTitleY.visibility">visible</option> <option name="charting.axisTitleY2.visibility">visible</option> <option name="charting.axisX.scale">linear</option> Устаревшие функции  167 <option name="charting.axisY.scale">linear</option> <option name="charting.axisY2.enabled">false</option> <option name="charting.axisY2.scale">inherit</option> <option name="charting.chart">column</option> <option name="charting.chart.bubbleMaximumSize">50</option> <option name="charting.chart.bubbleMinimumSize">10</option> <option name="charting.chart.bubbleSizeBy">area</option> <option name="charting.chart.nullValueMode">gaps</option> <option name="charting.chart.sliceCollapsingThreshold">0.01</option> <option name="charting.chart.stackMode">default</option> <option name="charting.chart.style">shiny</option> <option name="charting.drilldown">all</option> <option name="charting.layout.splitSeries">0</option> <option name="charting.legend.labelStyle.overflowMode"> ellipsisMiddle </option> <option name="charting.legend.placement">right</option> </chart> </panel> <panel> <chart> <title>Dimension Events count by Day</title> <search base="baseSearch"> <query>stats sum(count) AS count by date_wday</query> </search>  <option name="charting.chart">pie</option> <option name="charting.axisLabelsX.majorLabelStyle.overflowMode"> ellipsisNone </option> <option name="charting.axisLabelsX.majorLabelStyle.rotation">0</option> <option name="charting.axisTitleX.visibility">visible</option> <option name="charting.axisTitleY.visibility">visible</option> <option name="charting.axisTitleY2.visibility">visible</option> <option name="charting.axisX.scale">linear</option> <option name="charting.axisY.scale">linear</option> <option name="charting.axisY2.enabled">false</option> <option name="charting.axisY2.scale">inherit</option> <option name="charting.chart.bubbleMaximumSize">50</option> <option name="charting.chart.bubbleMinimumSize">10</option> <option name="charting.chart.bubbleSizeBy">area</option> <option name="charting.chart.nullValueMode">gaps</option> <option name="charting.chart.sliceCollapsingThreshold">0.01</option> <option name="charting.chart.stackMode">default</option> <option name="charting.chart.style">shiny</option> <option name="charting.drilldown">all</option> <option name="charting.layout.splitSeries">0</option> <option name="charting.legend.labelStyle.overflowMode"> ellipsisMiddle </option> <option name="charting.legend.placement">right</option> <option name="wrap">true</option> 168  Простые дашборды на XML <option name="rowNumbers">false</option> <option name="dataOverlayMode">none</option> <option name="count">10</option> <option name="mapping.data.maxClusters">100</option> <option name="mapping.map.center">(0,0)</option> <option name="mapping.map.zoom">2</option> <option name="mapping.markerLayer.markerMaxSize">50</option> <option name="mapping.markerLayer.markerMinSize">10</option> <option name="mapping.markerLayer.markerOpacity">0.8</option> <option name="mapping.tileLayer.maxZoom">7</option> <option name="mapping.tileLayer.minZoom">0</option> </chart> </panel> </row> </dashboard> На рис. 5.32 показано, как выглядит дашборд, сгенерированный из предыдущего исходного кода на XML. Рис. 5.32  Получившийся дашборд Автоматический запуск дашборда Дашборды имеют еще одну важную настройку: автоматический запуск. В предыдущих версиях Splunk на странице редактирования дашбордов имелся флажок Autorun dashboard (Автоматически запускать дашборд), как показано на рис. 5.33. Рис. 5.33  Флажок Autorun dashboard (Автоматически запускать дашборд) Начиная с версии 7.0 автоматический запуск настраивается в исходном коде дашборда. С помощью атрибута autoRun можно указать, должен ли запускаться Выполнение запросов по расписанию  169 поиск в панелях сразу после загрузки страницы. По умолчанию он получает значение false, это означает, что после загрузки дашборд будет ждать, пока пользователь введет данные и щелкнет на кнопке Submit. Но представьте, что сразу после загрузки дашборд должен отображать данные, используя некоторые параметры по умолчанию. Для этого можно изменить исходный код XML, как показано ниже: <fieldset autoRun="true"> <input type="text" token="myyear"><default>2014</default> <label>MyYear</label> </input> </fieldset> Здесь мы добавили атрибут autoRun в тег <fieldset> и задали значение по умолчанию с помощью тега <default>. После сохранения такой дашборд сразу после загрузки будет выполнять поиск для значения по умолчанию (2014), и в панелях сразу появятся результаты. При этом пользователь, как и прежде, может ввести свое значение и выполнить поиск. В зависимости от разных факторов автоматический запуск может быть или не быть полезным – глупо повторно запускать поиск всякий раз после загрузки дашборда, если исходные данные почти не меняются. В этом случае лучше присвоить атрибуту autoRun значение false и выполнять поиск по расписанию, но об этом мы поговорим в следующем разделе. Выполнение запросов по расписанию Создавая панели с помощью мастера, мы приняли настройку по умолчанию. запускающую запрос в момент загрузки дашборда. Как уже говорилось, это вынуждает пользователя предпринять какие-то действия после загрузки дашборда в браузер. Однако было бы глупо повторно запускать поиск (и впустую тратить ресурсы), если исходные данные меняются очень редко. Например, если данные индексируются раз в сутки по вечерам, тогда многократное выполнение одного и того же запроса в течение дня не даст никаких новых результатов и потому не имеет никакого смысла. Разумнее было бы изменить панели дашборда так, чтобы вместо запросов, выполняемых в момент загрузки, они ссылались на отчеты (см. раздел «Преобразование панели в отчет» выше в этой главе) или использовали запросы, выполняемые по расписанию. При использовании отчетов или запросов, выполняемых по расписанию, сразу после загрузки дашборд будет использовать уже готовые результаты этого запроса. В этом случае дашборд будет отображаться очень быстро, потому что браузеру останется только нарисовать панели. Это особенно удобно, когда одним и тем же дашбордом пользуется большое количество пользователей. Если прежде запрос еще не выполнялся, он выполнится немедленно, как обычно. 170  Простые дашборды на XML Подумайте о том, насколько свежими должны быть данные в дашборде. Если просматриваются данные за неделю, допустимо ли отсутствие данных за последний час? За последние 4 часа? За последние 24 часа? Чем реже выполняется поиск, тем меньше ресурсов будет расходоваться и тем более отзывчивой будет система. С увеличением объемов данных на поиск будет уходить все больше времени. Если вы заметили, что система стала менее отзывчивой, проверьте производительность запросов, выполняемых по расписанию в дашбордах Jobs (Задания) или Status (Состояние) в приложении поиска Search. Для дашборда, осуществляющего постоянный мониторинг данных, вероятно, эффективнее использовать запросы в реальном времени, особенно если этот дашборд просматривает несколько человек. Запросы в реальном времени используют прием постоянного пополнения. Например, запрос в реальном времени, извлекающий данные за последние 24 часа, при первом запуске извлечет данные за предыдущие 24 часа, а потом будет добавлять в результаты только новые события, по мере их появления. Это делает запросы в реальном времени особенно удобными и практичными в дашбордах, отображающихся длительное время. Итоги И снова мы лишь бегло ознакомились с имеющимися возможностями, которые дает использование исходного кода XML. Я настоятельно советую исследовать приложение с примерами пользовательского интерфейса (см. раздел «Приложение с примерами пользовательского интерфейса» выше). Когда вы будете готовы использовать дополнительные настройки или модули, доступные в Splunk, вы сможете использовать продвинутые особенности XML, о которых рассказывается в главе 9 «Создание продвинутых дашбордов». В главе 6 «Примеры продвинутого поиска» мы познакомимся с очень интересными примерами продвинутого поиска. Здесь мы раскроем некоторые понастоящему мощные возможности языка поиска и рассмотрим несколько трюков, которые я накопил за годы работы. Глава 6 Примеры продвинутого поиска В этой главе мы подробно рассмотрим несколько примеров продвинутого поиска. Примеры и данные, которые будут показаны здесь, вымышленные, но я надеюсь, что вы почерпнете из них полезные идеи, которые сможете применить в своей практике. Еще больше примеров и справочной информации вы найдете на сайте Splunk Answers по адресу: https://answers.splunk.com. В этой главе рассматриваются следующие темы: использование подзапросов для поиска дополнительных событий; использование транзакций; команда concurrency; вычисление событий за отрезок времени; имитация команды top; ускорение; расширенная поддержка метрик в версии 7.0. Использование подзапросов для поиска дополнительных событий В реальном мире редко возникает потребность в подзапросах, но там, где они действительно необходимы, подзапросы могут оказаться палочкой-выручалочкой. Давайте сначала рассмотрим пример, а потом поговорим о некоторых правилах. Подзапрос Допустим, у нас имеются следующие события: 2015-02-10 12:59:59 msgid=704783 from=tuck@companyx.com to=taylor@VENDOR1.com 2015-02-10 12:59:59 msgid=171755 from=steve@companyx.com to=lou@VENDOR1.com 2015-02-10 12:59:59 msgid=668955 from=lou@companyx.com to=steve@Vendor2.com 2015-02-10 12:59:59 msgid=001404 from=mary@companyx.com 172  Примеры продвинутого поиска to=richard@Vendor2.com 2015-02-10 12:59:59 msgid=284794 from=ronnie@companyx.com to=toto@Vendor2.com 2015-02-10 12:59:59 msgid=362127 from=nanette@companyx.com to=sam@Vendor2.com 2015-02-10 12:59:59 msgid=571419 from=paige@companyx.com to=ronnie@g&r.com Найдем в этих событиях, кому mary посылала сообщения. В этих событиях, как можно заметить, имеются отдельные поля from и to. Мы можем воспользоваться командой stats, чтобы объединить события по этим полям и затем отфильтровать результат, как показано ниже: sourcetype=webmail to OR from | stats values(from) as from values(to) as to by msgid | search from=mary@companyx.com Проблема в том, что на высоконагруженном почтовом сервере такой поиск может извлечь миллионы событий и затем отбросить большую часть результатов. Нам требуется максимально эффективно использовать индекс, и в этом нам поможет подзапрос. Вот как можно решить задачу с помощью подзапроса: [search sourcetype=webmail from=mary@companyx.com | fields msgid] sourcetype=webmail to Давайте подробно рассмотрим, что здесь происходит. 1. Сначала выполнится запрос в квадратных скобках: sourcetype=webmail from=mary@companyx.com В этом примере он обнаружит несколько событий в исходном наборе, как показано на рис. 6.1. Рис. 6.1  События, найденные первой частью подзапроса Использование подзапросов для поиска дополнительных событий  173 2.Вторая часть подзапроса, | fields msgid, требует вернуть только поле msgid. Далее результаты подзапроса добавятся к результатам внешнего запроса с оператором ИЛИ (OR): ( (msgid=123456) OR (msgid=234567) .).. и так далее sourcetype=webmail to Такой запрос выполнится намного эффективнее и эффективнее будет использовать индекс. 3.Новый запрос вернет нужный нам ответ. Обратите внимание на значения msgid на рис. 6.2. Эти значения Splunk использует во внутреннем поиске. Рис. 6.2  Новый запрос вернул нужный ответ Ограничения подзапросов Чтобы избежать слишком больших затрат на выполнение (то есть затрат времени и ресурсов), подзапросы ограничиваются временем выполнения и количеством возвращаемых событий. По умолчанию подзапросу выделяется 60 секунд на выполнение. Если по истечении этого времени подзапрос продолжает выполняться, он прерывается, и во внешний запрос передаются те события, которые удалось найти. Аналогично подзапрос ограничивается 10 000 результатов. Все остальные события, соответствующие критерию подзапроса, будут отброшены. Если достигнуто любое из этих ограничений, вероятно, стоит поискать другой способ решить поставленную задачу. 174  Примеры продвинутого поиска Еще одно ограничение: поля, возвращаемые подзапросом, должны быть доступны для поиска. Существует одно особое поле с именем search, которое будет добавлено в запрос как исходный критерий поиска, но вам придется особо позаботиться о нем. Пример контекстного поиска вы найдете далее в этой главе. Вложенные подзапросы Подзапросы могут также вкладываться друг в друга. При работе с журналами почтового сервера иногда требуется отыскать все события, связанные с конкретным сообщением. Вот для примера несколько записей из фиктивного журнала: ... in=123 msgid=123456 from=mary@companyx.com ... msgid=123456 out=987 subject=Important ... out=987 to=bob@vendor1.co.uk Как видите, первое событие имеет искомое значение в поле from, но последнее событие – с полем to – не имеет с ним ничего общего. К счастью, здесь есть промежуточное событие, содержащее поля out и msgid, связывающее первое и третье события. Мы могли бы использовать такой запрос для поиска этих связанных событий: [search sourcetype=WebMailIfoDatas out [search sourcetype=WebMailIfoDatas from=mary@companyx.com | fields msgid] | fields out] sourcetype=WebMailIfoDatas to Далее перечислены части этого запроса в порядке их выполнения: 1.[search sourcetype=WebMailIfoDatas from=mary@companyx.com | fields msgid] 2.[search sourcetype=WebMailIfoDatas out | fields out] 3. sourcetype=WebMailIfoDatas to Разберем, как они работают: 1. Первым выполняется самый внутренний запрос (1): sourcetype=WebMailIfoDatas from=mary@companyx.com | fields msgid 2. Его результат включается в запрос уровнем выше (2): sourcetype=WebMailIfoDatas out (msgid=123456) | fields out 3.Результат этого запроса, в свою очередь, включается в самый внешний запрос (3): (out=987) sourcetype=WebMailIfoDatas to 4. Этот последний запрос возвращает искомый ответ: ... out=987 to=bob@vendor1.co.uk Использование транзакций  175 Использование транзакций Команда transaction позволяет сгруппировать события по степени близости друг к другу. Близость определяется либо диапазоном времени, либо текстом, содержащимся в первом и/или последнем событии в транзакции. Это довольно дорогостоящий процесс, но иногда оказывается лучшим способом группировки событий. В отличие от других команд преобразований, transaction работает с исходными событиями и группирует их в многозначные события (событие, которое содержит несколько объединенных событий). Вот некоторые правила использования transaction, выработанные практикой: если ответ можно получить с помощью команды stats (часто так и есть), почти всегда эффективнее будет использовать ее; все события, включаемые в транзакцию, должны содержаться в одном поиске; если группировка основана на значениях полей, то каждое событие должно иметь хотя бы одно общее поле с одним другим событием, тогда его можно рассматривать как часть транзакции. Это не означает, что все события должны иметь то же самое поле, но все события должны иметь некоторое поле из заданного списка; если группировка основана исключительно на startswith и endswith, важно, чтобы транзакции не пересекались в результатах поиска; необходимо приложить все усилия, чтобы сократить количество открытых транзакций, так как из-за этого неэффективные запросы могут потреблять большой объем ресурсов. Добиться этого можно ограничением времени с помощью maxspan и maxpause и/или с помощью startswith и endswith. Рассмотрим далее несколько примеров использования команды transaction. Определение продолжительности сеанса Возьмем за основу следующие вымышленные события. Допустим, что мы анализируем журнал высоконагруженного сервера и между запросами в рамках определенного сеанса может происходить огромное число других событий: 2012-04-27T03:14:31 user=mary GET /foo?q=1 uid=abcdefg ...сотни других событий... 2012-04-27T03:14:46 user=mary GET /bar?q=2 uid=abcdefg ... сотни тысяч других событий... 2012-04-27T06:40:45 user=mary GET /foo?q=3 uid=abcdefg ... сотни других событий... 2012-04-27T06:41:49 user=mary GET /bar?q=4 uid=abcdefg Определение понятия «огромное число» зависит от инфраструктуры, выделенной для Splunk. Чтобы получить больше информации о возможностях увеличения ее размеров, загляните в главу 12 «Продвинутое развертывание» или обратитесь в службу поддержки Splunk. 176  Примеры продвинутого поиска Сконструируем запрос, извлекающий транзакции пользователя mary. Будем считать сеанс завершившимся, если в течение 5 минут не последовало ни одного события: sourcetype="impl_splunk_web" user=mary | transaction maxpause=5m user Разберем этот запрос по шагам. 1.Начальный запрос просто возвращает все события, связанные с пользователем mary: sourcetype="impl_splunk_web" user=mary 2. | transaction запускает команду. 3.maxpause=5m указывает, что транзакцию следует закрыть, если в течение 5 минут не последовало ни одного события. В больших наборах данных этот интервал времени может стоить слишком дорого, если огромное число транзакций будет оставаться открытым дольше, чем это необходимо. 4.user – это поле, используемое для связывания событий. Если событие имеет другое значение в поле user, создается новая транзакция с новым значением user. Для наших вымышленных событий были получены четыре группы (см. рис. 6.3). Рис. 6.3  Четыре группы событий Каждую группу можно интерпретировать как одно событие. Команда transaction обладает рядом интересных свойств: поле _time получит значение _time из первого события в транзакции; поле duration получит разность значений _time в первом и последнем событиях в транзакции; поле eventcount получит число событий в транзакции (исходя из настройки объектов знаний в окружении); все поля будут объединены в уникальные наборы. В данном случае поле user может иметь только значение mary, но поле q может содержать значения [1,2] и [3,4] соответственно. Используя эти дополнительные поля, можно сформировать таблицу (см. рис. 6.4) транзакций пользователя mary: Использование транзакций  177 sourcetype="impl_splunk_web" user=mary | transaction maxpause=5m user | table _time duration eventcount q Рис. 6.4  Таблица транзакций пользователя mary Объединив transaction с командой stats или timechart, можно получить статистику о самих транзакциях: sourcetype="impl_splunk_web" user=mary | transaction maxpause=5m user | stats avg(duration) avg(eventcount) В результате получится таблица, изображенная на рис. 6.5. Рис. 6.5  Статистика о самих транзакциях Получение агрегированных статистических показателей Используя значения, добавляемые командой transaction, можно, пусть и несколько упрощенно, ответить на вопрос о том, сколько времени пользователи проводят на сайте и сколько страниц они просматривают за сеанс. Попробуем для этого выделить сеансы по полю uid в событиях. Затем с по мощью команды stats мы сможем определить среднее значение duration и среднее значение eventcount, а заодно подсчитать число уникальных пользователей и идентификаторов сеансов: sourcetype="impl_splunk_web" | transaction maxpause=5m uid | stats avg(duration) avg(eventcount) dc(user) dc(uid) В результате получится таблица, изображенная на рис. 6.6. Рис. 6.6  Средние значения duration и eventcount, а также число уникальных пользователей и идентификаторов сеансов 178  Примеры продвинутого поиска Как видите, в среднем один сеанс длится 892 секунды и насчитывает 227 событий. Для больших объемов веб-трафика транзакции следует определять по укороченным интервалам времени в summary-индексе. Подробнее о summaryиндексах мы поговорим в главе 10 «Summary индексы и файлы CSV». Подзапросы в транзакциях Давайте теперь объединим наши знания о подзапросах с транзакциями. Допус тим, что q=1 представляет определенную точку входа на сайт, например ссылку из рекламного объявления. Мы могли бы использовать подзапрос, чтобы отыскать пользователей, щелкнувших на ссылке в рекламе, и затем с помощью transaction определить, как долго эти пользователи оставались на нашем сайте. Для этого сначала нужно отыскать сеансы, инициированные щелчком на заданной ссылке. Требуемый запрос выглядит просто: sourcetype="impl_splunk_web" q=1 Он вернет список событий, как на рис. 6.7. Рис. 6.7  Сеансы, инициированные щелчком на заданной ссылке В наших вымышленных журналах поле uid представляет идентификатор сеанса. Используем stats, чтобы вернуть по одной строке на каждое уникальное значение uid: sourcetype="impl_splunk_web" q=1 | stats count by uid В результате мы увидим таблицу, изображенную на рис. 6.8 (здесь показаны только первые 10 строк). Добавим еще одну команду, fields, чтобы ограничить число полей, возвращаемых подзапросом: sourcetype="impl_splunk_web" q=1 | stats count by uid | fields uid Теперь вернем результаты во внешний запрос: [search sourcetype="impl_splunk_web" q=1 Использование транзакций  179 | stats count by uid | fields uid ] sourcetype="impl_splunk_web" Рис. 6.8  Список уникальных идентификаторов сеансов После выполнения подзапроса объединенный запрос фактически примет следующий вид: ( (uid=MTAyMjQ2OA) OR (uid=MTI2NzEzNg) OR (uid=MTM0MjQ3NA) ) sourcetype="impl_splunk_web" Этот запрос вернет нам каждое событие для каждого uid, соответствующее щелчку на ссылке с q=1 в заданных временных рамках. Теперь можно добавить transaction, как было показано выше, чтобы объединить эти сеансы в группы: [search sourcetype="impl_splunk_web" q=1 | stats count by uid | fields uid] sourcetype="impl_splunk_web" | transaction maxpause=5m uid Это даст нам список транзакций (на рис. 6.9 показана только часть этого списка). Обратите внимание, что не все транзакции начинаются с q=1. Это означает, что такие транзакции начались не тогда, когда пользователь щелкнул на ссылке в рекламном объявлении. Давайте потребуем, чтобы транзакции начинались с момента перехода по q=1: [search sourcetype="impl_splunk_web" q=1 | stats count by uid | fields uid] sourcetype="impl_splunk_web" | transaction maxpause=5m startswith="q=1" uid 180  Примеры продвинутого поиска Рис. 6.9  Список транзакций Поле startswith указывает, что новая транзакция должна начинаться с события, содержащего q=1. Поле startswith работает только с полем _raw (фактическим текстом события). В данном случае startswith="q=1" отыскивает буквальную фразу "q=1", а не поле q. Это изменение приведет к тому, что каждое вхождение q=1 будет начинать новую транзакцию. Но у нас все еще остается несколько транзакций, не содержащих q=1 (см. рис. 6.10), от которых мы избавимся далее. Чтобы избавиться от транзакций, не содержащих q=1, добавим команду search: [search sourcetype="impl_splunk_web" q=1 | stats count by uid | fields uid] sourcetype="impl_splunk_web" | transaction maxpause=5m startswith="q=1" uid | search q=1 Наконец, добавим stats для подсчета количества транзакций, уникальных значений uid, средней продолжительности каждой транзакции и среднего количества щелчков на ссылке в транзакции: [search sourcetype="impl_splunk_web" q=1 | stats count by uid | fields uid] sourcetype="impl_splunk_web" | transaction maxpause=5m startswith="q=1" uid | search q=1 | stats count dc(uid) avg(duration) avg(eventcount) Использование транзакций  181 Рис. 6.10  У нас все еще остается несколько транзакций, не содержащих q=1 В результате получится таблица, изображенная на рис. 6.11. Рис. 6.11  Число транзакций и уникальных значений uid, средняя продолжительность транзакций и среднее количество щелчков на ссылке в одной транзакции Чтобы увидеть, как эти статистики меняются с течением времени, команду stats можно заменить командой timechart: [search sourcetype="impl_splunk_web" q=1 | stats count by uid | fields uid] sourcetype="impl_splunk_web" | transaction maxpause=5m startswith="q=1" uid | search q=1 | timechart bins=500 avg(duration) avg(eventcount) 182  Примеры продвинутого поиска Команда concurrency Определить число пользователей, работающих в системе в настоящее время, сложно, особенно если журнал не содержит событий начала и конца транзакции. С журналами веб-сервера, в частности, не всегда можно узнать, когда пользователь покинул сайт. Давайте рассмотрим несколько стратегий получения ответа на этот вопрос. Использование команд transaction и concurrency Если вас интересует, сколько транзакций происходило одновременно, можно с помощью команды transaction объединить связанные события и вычислить длительность каждой транзакции. Затем воспользоваться командой concurrency, чтобы увеличить счетчик при нахождении начального события, и уменьшить по истечении времени каждой транзакции. Начнем с запроса из предыдущего раздела: sourcetype="impl_splunk_web" | transaction maxpause=5m uid Он вернет транзакции для всех идентификаторов uid, исходя из предположения, что если в течение 5 минут не поступало запросов, то сеанс автоматически завершался. Он вернет результаты, изображенные на рис. 6.12. Рис. 6.12  Результаты, возвращаемые запросом Просто добавив команду concurrency, можно определить перекрытия транз акций и выяснить количество транзакций, протекающих одновременно. Добавим также команды table и sort, чтобы вывести результаты в табличной форме: Команда concurrency  183 sourcetype="impl_splunk_web" | transaction maxpause=5m uid | concurrency duration=duration | table _time concurrency duration eventcount | sort _time В итоге получится таблица, изображенная на рисунке. Рис. 6.13  Результат команды concurrency в табличной форме Как можно судить по результатам, с началом транзакции уровень concurrency (счетчика) увеличивается, а по истечении периода действия – уменьшается. В наборе данных, использованном в этом примере, наибольший уровень счетчика равен 6. Использование команды concurrency для оценки нагрузки на сервер В предыдущем примере число конкурирующих сеансов было довольно невелико, так как каждая транзакция учитывается как одно событие, независимо от числа составляющих ее событий. Это позволяет получить достаточно точное количество параллельных транзакций, но не позволяет судить о величине нагрузки на сервер. Взглянув на распределение событий во времени, можно заметить большой всплеск в начале журнала, как показано на рис. 6.14. Это никак не отразилось на предыдущем примере, потому что большинство этих событий относится к одному сеансу. Рис. 6.14  Всплеск в начале журнала 184  Примеры продвинутого поиска Некоторые веб-журналы включают время, потребовавшееся для обработки запроса. В нашем журнале нет этой информации, поэтому используем eval для оценки длительности обработки каждого запроса: sourcetype="impl_splunk_web" | eval duration=2 | concurrency duration=duration | timechart max(concurrency) Пусть длительность обработки каждого запроса равна 2 секундам (возможно, разумное время для события?). Команда concurrency будет использовать значение duration, обрабатывая каждое событие, как если бы это была 2-секундная транзакция. На рис. 6.15 показана получившаяся временная диаграмма. Рис. 6.15  Временная диаграмма нагрузки на сервер Как видите, увеличение числа одновременно обрабатываемых запросов в определенные моменты времени влечет увеличение уровня concurrency. Далее в этой главе мы подсчитаем число событий за некоторый промежуток времени, чтобы получить похожий ответ более эффективно. Но это будет не совсем тот же ответ, так как подсчет будет производиться за фиксированные интервалы времени, а не c динамическим счетчиком, меняющимся с каждым событием. Определение уровня concurrency с использованием предложения by Одно из ограничений команды concurrency заключается в невозможности определения уровня concurrency сразу по нескольким наборам данных. Например, представьте, что у нас появилось желание узнать уровень concurrency для каждого узла, а не для всего окружения. В нашем наборе данных есть только один хост, но поле network имеет несколько значений. Попробуем задействовать это поле в наших упражнениях. В предыдущем разделе мы использовали такой запрос для определения нагрузки на сервер: sourcetype=impl_splunk_gen network="*" | eval d=2 | concurrency duration=d | timechart max(concurrency) Команда concurrency  185 Для начала задействуем в этом запросе команду streamstats. Она вычисляет скользящие статистики и добавляет вычисленные значения в события. Для включения команды streamstats нам потребуется событие, представляющее начало и конец каждой транзакции. Для этого можно создать многозначное поле (по сути, массив), а затем дублировать события на основе значений в этом поле. Сначала добавим поле, определяющее время окончания. Напомню, что поле _time содержит число секунд, прошедших от начала эпохи UNIX до того, когда случилось данное событие (UTC epoch time), поэтому его можно интерпретировать как число: sourcetype=impl_splunk_gen network="*" | eval endtime=_time+2 Передав результат этого запроса команде table с аргументами _time, network и endtime, получим результат, изображенный на рис. 6.16. Рис. 6.16  Результат добавления поля endtime Далее объединим _time и endtime в одно многозначное поле, которое назовем t: sourcetype=impl_splunk_gen network="*" | eval endtime=_time+2 | eval t=mvappend(_time,endtime) 186  Примеры продвинутого поиска Передав результат этого запроса команде table с аргументами _time, network и t, получим результат, изображенный на рис. 6.17. Рис. 6.17  Результат добавления поля t Как видите, у нас есть поле _time с фактическим временем, которое Splunk всегда выводит в соответствии с настройками пользователя. Далее следует поле network, потом поле t с двумя значениями, созданное с помощью mvappend. Теперь каждое событие можно разбить на два, отмечающие начало и конец обработки запроса: sourcetype=impl_splunk_gen network="*" | eval endtime=_time+2 | eval t=mvappend(_time,endtime) | mvexpand t Команда mvexpand копирует каждое событие для каждого значения в указанном поле. В нашем случае из каждого исходного события будет создано два события, так как t всегда содержит два значения. Все остальные поля копируются в новое событие как есть. Передав результат этого запроса команде table с аргументами _time, network и t, получим результат, изображенный на рис. 6.18. Команда concurrency  187 Рис. 6.18  Результат деления каждого исходного события на два события Теперь, когда у нас есть события начала и конца, пометим их соответственно. Для этого добавим поле с именем increment и используем его для создания текущего итога. События начала будут иметь положительное значение в этом поле, а события конца – отрицательные. По мере прохождения событий через streamstats положительные значения будут увеличивать наш счетчик, а отрицательные – уменьшать. События начала будут иметь в поле t значение, скопированное из _time, поэтому используем eval для проверки и записи в поле increment соответствующего значения. После записи в поле increment сбросим значение _time в значение t, чтобы события конца выглядели, как произошедшие в будущем: sourcetype=impl_splunk_gen network="*" | eval endtime=_time+2 | eval t=mvappend(_time,endtime) | mvexpand t | eval increment=if(_time=t,1,-1) | eval _time=t Передав результат этого запроса команде table с аргументами _time, network и increment, получим результат, изображенный на рис. 6.19. 188  Примеры продвинутого поиска Рис. 6.19  Результат добавления поля increment Команда streamstats ожидает, что события будут следовать в том порядке, в каком должны вычисляться статистики. Прямо сейчас наши фиктивные события конца следуют сразу за событиями начала, но нам нужно вычислить нарастающий итог в зависимости от времени _time. Добавим команду sort, которая позаботится об этом. Значение 0 перед спис ком полей отменит ограничение по умолчанию на количество строк, равное 10 000. sourcetype=impl_splunk_gen network="*" | eval endtime=_time+2 | eval t=mvappend(_time,endtime) | mvexpand t | eval increment=if(_time=t,1,-1) | eval _time=t | sort 0 _time network increment Обратите внимание, что в этом запросе мы изменяем значения некоторых полей, в частности мы изменили поля _time и increment. Любое поле можно изменить столько раз, сколько потребуется, но в окончательный результат попадет последнее изменение. Теперь, отсортировав события по полю _time, можно добавить команду streamstats. Она вычисляет скользящие статистики в порядке следования событий. В сочетании с нашим полем increment эта команда будет действовать так же, как concurrency, но вернет итоги для каждого из полей, перечисленных после нее: Команда concurrency  189 sourcetype=impl_splunk_gen network="*" | eval endtime=_time+2 | eval t=mvappend(_time,endtime) | mvexpand t | eval increment=if(_time=t,1,-1) | eval _time=t | sort 0 _time network increment | streamstats sum(increment) as concurrency by network | search increment="1" Последняя команда search устранит наши синтетические события конца. Передав результат этого запроса команде table с аргументами _time, network, increment и concurrency, получим результат, изображенный на рис. 6.20. Рис. 6.20  Результат команды streamstats Если добавить команду timechart max(concurrency) для вывода временной диаграммы по полю network, мы получим результат, изображенный на рис. 6.21. Рис. 6.21  Временная диаграмма, отражающая нагрузку на сервер Это было довольно интересное упражнение, но в реальной жизни вы, вероятно, не стали бы оценивать нагрузку на веб-сервер таким способом. Часто количество событий очень велико, и время, которое занимает каждое собы- 190  Примеры продвинутого поиска тие, обычно незначительно. Описанный выше подход будет более интересен для длительных процессов, таких как пакетная обработка или взаимодействия с базами данных. На практике при работе с веб-журналами обычно используется другой подход, основанный на простом подсчете событий за период времени. Рассмот рим далее несколько вариантов его реализации. Подсчет событий в интервалах времени Есть несколько способов подсчета событий за определенный период времени. Все они основаны на округлении _time до некоторого периода времени и последующей группировке результатов округления. С помощью timechart Самый простой способ подсчета событий – задействовать команду timechart: sourcetype=impl_splunk_gen network=prod | timechart span=1m count В табличном представлении мы увидим результаты, как показано на рис. 6.22. Рис. 6.22  Простой подсчет событий с timechart Splunk не стремится отобразить на диаграмме больше точек, чем пикселей на экране. Как предполагается, пользователь должен сам задать количество точек на графике, используя атрибут bins или span. Другой способ борьбы с этим поведением – вычисление среднего числа событий в минуту или в час. Если нас интересуют только минуты, в которые действительно происходили события, а не каждая минута в течение дня, мы можем использовать команды bucket и stats, как показано ниже: sourcetype=impl_splunk_gen network=prod | bucket span=1m _time | stats count by _time Подсчет событий в интервалах времени  191 Команда bucket округляет поле _time каждого события до минуты, в которой оно произошло, что, собственно, внутренне делает команда timechart. В этом случае результаты будут выглядеть одинаково, но минуты без событий не будут включены в график. То же самое можно сделать иначе: sourcetype=impl_splunk_gen network=prod | timechart span=1m count | where count>0 Вычисление среднего числа запросов в минуту Если взять предыдущий запрос и передать его результаты команде stats, мы сможем получить среднее число событий в минуту: sourcetype=impl_splunk_gen network=prod | timechart span=1m count | stats avg(count) as "Average events per minute" В результате мы получим число, как показано на рис. 6.23. Рис. 6.23  Среднее число событий в минуту Можно подойти к задаче иначе: сгруппировать события по минутам с по мощью bucket и, используя stats, подсчитать (count) события только по минутам, имеющим значение: sourcetype=impl_splunk_gen | bucket span=1m _time | stats count by _time | stats avg(count) as "Average events per minute" Теперь мы получили более высокое значение (см. рис. 6.24). Рис. 6.24  Подсчет событий только по минутам, имеющим значение, дает более высокое значение Почему? Потому что наш фиктивный сервер некоторое время не работал. В этом втором примере в результаты были включены только минуты, в которых действительно происходили события, поскольку stats не создает событий 192  Примеры продвинутого поиска для каждого отрезка времени, как это делает timechart. Для большей ясности рассмотрим результаты двух запросов: sourcetype=impl_splunk_gen | timechart span=1h count Этот запрос выведет таблицу, изображенную на рис. 6.25. Рис. 6.25  Подсчет событий с помощью timechart Теперь сгруппируем события (bucket) и используем команду stats: sourcetype=impl_splunk_gen | bucket span=1m _time | stats count by _time Этот запрос выведет таблицу, изображенную на рис. 6.26. Рис. 6.26  Подсчет событий с помощью bucket и stats В данном случае я использовал интервалы времени, равные 1 минуте (1m). Подсчет событий в интервалах времени  193 Вычисление среднего числа событий в минуту за каждый час Одно из ограничений механизма диаграмм в Splunk – невозможность вывода числа событий, превышающего число пикселей. При подсчете или добавлении значений в течение различных периодов времени порой трудно понять шаг временной шкалы. Например, рассмотрим следующий запрос: earliest=-1h sourcetype=impl_splunk_gen | timechart count В ответ на этот запрос Splunk выведет диаграмму, изображенную на рис. 6.27. Рис. 6.27  Порой трудно понять шаг временной шкалы Каждый из столбиков представляет 1 минуту. Давайте увеличим временное окно до 24 часов: earliest=-24h sourcetype=impl_splunk_gen | timechart count В результате получится диаграмма, изображенная на рис. 6.28. Рис. 6.28  Диаграмма после изменения временного окна до 24 часов На графике нет ничего, что помогло бы определить интервал времени, представленный каждым столбиком, если не выполнить расчеты вручную. В данном случае каждый столбик представляет 30 минут. Это затрудняет оценку значимости оси Y. В обоих случаях можно добавить span=1m в команду timechart, и тогда мы будем точно знать, что каждый столбик представляет одну минуту. 194  Примеры продвинутого поиска Этот прием годится для диаграммы, представляющей 1 час, но для периода в 24 часа будет получено слишком много точек, и мы увидим усеченную диаграмму. Другое решение: подсчитать среднее число событий в минуту и затем выполнить вычисления за просматриваемый период времени. Команда timechart в Splunk предлагает для этой цели удобную функцию, но, чтобы воспользоваться ею, придется приложить дополнительные усилия: earliest=-24h sourcetype=impl_splunk_gen | eval eventcount=1 | timechart span=1h per_minute(eventcount) Функция per_minute вычислит сумму eventcount в минуту, затем найдет среднее значение за период времени, представляемый каждым столбиком. В данном случае мы увидим среднее число событий за каждый час (см. рис. 6.29). Рис. 6.29  Среднее число событий за каждый час График имеет размер столбца, равный 1 часу, высота которого показывает среднее количество событий за 1 час. По аналогии с приемом в разделе «Вычисление среднего числа запросов в минуту» мы можем игнорировать минуты без данных, как показано ниже: earliest=-24h sourcetype=impl_splunk_gen | bucket span=1m _time | stats count by _time | timechart span=1h avg(count) В этом случае не искажаются значения за неполные часы (например, за текущий). Диаграмма тогда примет вид, как показано на рис. 6.30. Это позволяет получить более точную картину за текущий час, однако в отношении первого часа данный график выглядит не совсем достоверно. Имитация команды top  195 Рис. 6.30  Если игнорировать минуты без данных, значения за неполные часы, можно избежать искажения данных за неполные часы Имитация команды top Команда top очень проста в использовании, но в действительности не делает ничего особенно интересного. Я часто начинаю с top, затем переключаюсь на stats count, а далее добавляю то, что top обеспечивает автоматически. В этом упражнении я покажу, как сымитировать работу команды top, чтобы вы могли выбрать то, что вам нужно. Итак, создадим аналог команды top, используя другие команды. Вот запрос, который мы попытаемся воспроизвести: sourcetype="impl_splunk_gen" error | top useother=t limit=5 logger user Его результат показан на рис. 6.31. Рис. 6.31  Результат запроса с командой top Добавить поле count можно командой stats: sourcetype="impl_splunk_gen" error | stats count by logger user В результате мы пройдем почти весь путь к нашей цели, как показано на рис. 6.32. 196  Примеры продвинутого поиска Рис. 6.32  Результат создания поля count командой stats Чтобы вычислить процент, как это делает команда top, сначала нужно подсчитать общее число событий. С помощью команды eventstats можно добавить нужные статистики во все строки без замены: sourcetype="impl_splunk_gen" error | stats count by logger user | eventstats sum(count) as totalcount Powered by TCPDF (www.tcpdf.org) Имитация команды top  197 На рис. 6.33 показан результат добавления поля totalcount. Рис. 6.33  Результат добавления поля totalcount Теперь, имея общее число, можно вычислить процент для каждой строки. Одновременно давайте отсортируем результаты в порядке убывания значений в поле count: sourcetype="impl_splunk_gen" error | stats count by logger user | eventstats sum(count) as totalcount | eval percent=count/totalcount*100 | sort -count 198  Примеры продвинутого поиска Получившийся результат показан на рис. 6.34. Рис. 6.34  Результат после добавления вычисления процента и сортировки Если бы не параметр useother=t в оригинальном запросе с командой top, мы могли бы просто добавить в запрос head 5 и получить первые пять строк. Чтобы добавить строку other, нам придется пометить некоторым значением все строки, не попавшие в число первых 5, и выполнить свертку, используя stats. Для этого потребуется выполнить несколько шагов. Сначала добавим поле счетчика с именем rownum: sourcetype="impl_splunk_gen" error | stats count by logger user | eventstats sum(count) as totalcount | eval percent=count/totalcount*100 | sort -count | eval rownum=1 В результате получим вывод, изображенный на рис. 6.35 (здесь показаны только первые 10 строк). Имитация команды top  199 Рис. 6.35  Результат после добавления поля rownum Затем используем команду accum, которая последовательно будет увеличивать значение rownum: sourcetype="impl_splunk_gen" error | stats count by logger user | eventstats sum(count) as totalcount | eval percent=count/totalcount*100 | sort -count | eval rownum=1 | accum rownum Это даст нам результат, изображенный на рис. 6.36 (здесь показаны только первые 10 строк). Рис. 6.36  Результат после добавления команды accum rownum Теперь, с помощью eval, можно пометить все записи, не попавшие в число первых 5, как OTHER и свернуть записи с rownum больше 5: sourcetype="impl_splunk_gen" error | stats count by logger user | eventstats sum(count) as totalcount | eval percent=count/totalcount*100 | sort -count | eval rownum=1 200  Примеры продвинутого поиска | accum rownum | eval logger=if(rownum>5,"OTHER",logger) | eval user=if(rownum>5,"OTHER",user) | eval rownum=if(rownum>5,6,rownum) Это даст нам результат, изображенный на рис. 6.37 (здесь показаны только первые 10 строк). Рис. 6.37  Результат маркировки записей, не попавших в число первых 5, как OTHER Далее выполним объединение значений с помощью команды stats. События сортируются по полям, перечисленным после by, что поможет нам обеспечить исходный порядок: sourcetype="impl_splunk_gen" error | stats count by logger user | eventstats sum(count) as totalcount | eval percent=count/totalcount*100 | sort -count | eval rownum=1 | accum rownum | eval logger=if(rownum>5,"OTHER",logger) | eval user=if(rownum>5,"OTHER",user) | eval rownum=if(rownum>5,6,rownum) | stats sum(count) as count sum(percent) as percent by rownum logger user Получившийся результат показан на рис. 6.38. Рис. 6.38  Результат объединения значений Ускорение  201 Мы почти у цели. Осталось только скрыть поле rownum. Для этого можно воспользоваться командой fields: sourcetype="impl_splunk_gen" error | stats count by logger user | eventstats sum(count) as totalcount | eval percent=count/totalcount*100 | sort -count | eval rownum=1 | accum rownum | eval logger=if(rownum>5,"OTHER",logger) | eval user=if(rownum>5,"OTHER",user) | eval rownum=if(rownum>5,6,rownum) | stats sum(count) as count sum(percent) as percent by rownum logger user | fields - rownum Получившийся результат показан на рис. 6.39. Рис. 6.39  Окончательный результат имитации команды top Вот и все! Напомню, что все вышеперечисленное было сделано для имитации следующей команды: top useother=t limit=5 logger user Нам пришлось написать довольной длинный запрос, чтобы воспроизвести действие однострочной команды. Несмотря на то что имитация команды top не имеет особой практической ценности, я надеюсь, что этот пример прольет некоторый свет на возможности комбинирования команд разными интересными способами. Ускорение В Splunk можно выполнять поиск по огромным объемам данных (постоянно растущему, пропорционально числу событий, а также числу пользователей, обращающихся к данным), что потенциально может потребовать времени, не укладывающегося в приемлемые границы. 202  Примеры продвинутого поиска Большие данные – стратегия получения сводной информации В общем случае вам придется делать агрегацию для отчетов по большим объ емам данных. Эти агрегации создаются фоновыми задачами поиска, на которых основаны отчеты. При использовании предварительно агрегированных отчетов поиск выполняется значительно быстрее, потому после агрегации мы имеем меньший объем, чем общее число событий, в которых выполняется поиск. Идею предварительного формирования сводной информации о событиях можно использовать в отчетах, моделях данных и индексах. В данный момент мы остановимся на ускорении отчетов. Ускорение отчетов Как уже говорилось, предварительная агрегация информации о событиях ускоряет работу определенных типов отчетов, и для этого можно использовать агрегации (summary acceleration), автоматически создаваемые системой Splunk. Чтобы заставить Splunk создавать агрегации, нужно включить ускорение отчетов (acceleration), выполнив следующие действия. На странице Reports (Отчеты) выберите отчет и в меню Edit (Правка) выберите пункт Edit Acceleration (Изменить ускорение), как показано на рис. 6.40. Рис. 6.40  Пункт Edit Acceleration (Изменить ускорение) в меню Edit (Правка) Если выбранный отчет доступен для ускорения и ваши привилегии позволяют управлять ускорением, откроется диалог Edit Acceleration (Изменить ускорение) с флажком Accelerate Report (Ускорить отчет). Выберите его. Появится поле Summary Range (Диапазон агрегации), как показано на рис. 6.41. Выберите диапазон времени для отчета, затем щелкните на кнопке Save (Сохранить). После этого Splunk создаст агрегацию по событиям (состоящую только из событий в выбранном диапазоне), которую будет анализировать отчет, тем самым уменьшив объем информации для обработки отчетом, и поэтому ускорит его выполнение. Ускорение  203 Рис. 6.41  Поле Summary Range (Диапазон обобщения) Другой способ ускорить отчет – перейти на страницу Settings (Настройки) и щелкнуть на ссылке Searches, reports, and alerts (Поиск, отчеты и оповещения), как показано на рис. 6.42. Рис. 6.42  Ссылка Searches, reports, and alerts (Поиск, отчеты и оповещения) 204  Примеры продвинутого поиска На странице ссылки Searches, reports, and alerts (Поиск, отчеты и оповещения) отыщите отчет и в меню Edit (Правка) выберите пункт Edit Acceleration (Изменить ускорение), как показано на рис. 6.43. Рис. 6.43  Пункт Edit Acceleration (Изменить ускорение) в меню Edit (Правка) Ускоренные отчеты на странице Searches, reports, and alerts (Поиск, отчеты и оповещения) отмечаются значком с изображением молнии, как показано на рис. 6.44. Рис. 6.44  Ускоренные отчеты отмечаются значком с изображением молнии Расширенная поддержка метрик в версии 7.0  205 Доступность ускорения отчетов Проектируя отчеты, всегда думайте о возможности их ускорения, потому что ускорение можно применить не ко всем отчетам. Отчет нельзя ускорить, если: он был создан из pivot; у вас нет привилегий для ускорения поиска (вы должны обладать привилегиями schedule_search и accelerate_search) или права на запись для отчета; лежащий в его основе запрос использует подробный режим поиска (Verbose mode). Расширенная поддержка метрик в версии 7.0 В любом бизнесе есть важные или, по крайней мере, интересные метрики. Это просто индикаторы, которые можно использовать для визуализации или измерения чего-то важного. С технической точки зрения метрики определяются как «...группы чисел, описывающие некоторый процесс или деятельность (всегда в течение некоторого интервала времени)...» Метрики – это рекомендуемые улучшения в Splunk версии 7.0 и, возможно, будут наиболее интересны системным администраторам и инженерам ИТ-инструментов. Это связано с тем, что функция фокусируется на сборе, исследовании, мониторинге и совместном использовании метрик из технологической инфраструктуры, систем безопасности и бизнес-приложений в режиме реального времени – областях, которые представляют основной интерес для этих людей. Метрики – это новая особенность, появившаяся в Splunk 7.0. В большей мере они будут интересны системным администраторам и разработчикам ИТ-ин струментов. Механизм метрик фокусируется на сборе, исследовании, мониторинге и совместном использовании показателей из технологической инфраструктуры, систем безопасности и бизнес-приложений в режиме реального времени, то есть областях, представляющих основной интерес для этих людей. Определение метрик в Splunk Механизм метрик в Splunk использует свой тип индекса, оптимизированный для хранения и извлечения метрик. Каждая метрика состоит из отметки времени, имени (метрики), значения и размерности: отметка времени: определяет время, когда данная метрика была записана; имя: строка символов, идентифицирующая метрику; значение: значение метрики, например счетчик или вычисленное значение; размерности: метаданные, определяющие метрику. 206  Примеры продвинутого поиска Использование метрик в Splunk Splunk собирает метрики из разных источников и сохраняет данные в индексе нового типа, оптимизированном для эффективного сохранения и извлечения данных метрик. Метрический индекс может использоваться только для данных с метриками. Splunk предлагает (или поддерживает) два основных метода сбора метрик: collectId и StatsD. В общем случае идея состоит в том, чтобы установить и настроить один из перечисленных выше инструментов, которые принимают данные метрик, обобщают их и записывают каждые несколько секунд в индекс метрик. Программа StatsD доступна в репозитории GitHub (https://github.com/etsy/statsd) и имеет конфигурационные файлы, необходимые для ее компиляции в конфигурируемый пакет. Создание индекса из метрик Splunk хранит метрики в индексе нового типа, специально предназначенном для метрик; фактически индекс этого типа можно использовать только для хранения данных метрик. Проще всего создать индекс метрик в веб-интерфейсе Splunk (см. рис. 6.45). 1.Откройте страницу Settings (Настройки) и щелкните на ссылке Indexes (Индексы). 2. На странице Indexes (Индексы) щелкните на ссылке New (Новый). Рис. 6.45  Диалог создания нового индекса для метрик Итоги  207 3.В поле Index Name (Имя индекса) введите имя для своего индекса. Имена пользовательских индексов могут состоять только из цифр, букв нижнего регистра, подчеркиваний и дефисов. Имя индекса не должно начинаться с подчеркивания или дефиса или содержать слово kvstore. 4.В поле Index Data Type (Тип данных в индексе) выберите Metrics (Мет рики). 5. Заполните остальные свойства индекса по своему усмотрению. 6. Щелкните на кнопке Save (Сохранить). Выбрав инструмент, загрузите, скомпилируйте и настройте его; затем подготовьте индекс. Последний шаг – настройка ввода данных метрик – также проще всего выполнить в веб-интерфейсе Splunk. Настройка ввода данных через UDP или TCP Как уже упоминалось, в Splunk необходимо настроить сетевой порт для приема данных от StatsD. Для этого выполните следующие действия. 1.На главной странице Splunk перейдите в раздел Settings (Настройки) и щелкните на ссылке Data inputs (Ввод данных). 2.В разделе Local inputs (Локальный ввод) щелкните на ссылке Add new (Добавить новый) рядом с названием протокола UDP или TCP (в зависимости от типа создаваемого ввода). 3.В поле Port (Порт) введите номер порта, который должен использоваться для связи с StatsD. 4.Щелкните на Next  Select Source Type (Далее  Выбрать тип источ ника). 5. Выберите Metrics  statsd (Метрики  statsd). 6.В поле Index (Индекс) выберите индекс метрик, созданный в предыдущем разделе. 7.Наконец, щелкните на ссылке Review (Просмотр), а затем на кнопке Submit (Отправить). Вот и все! Итоги Я надеюсь, эта глава была достаточно информативной и смогла подсказать некоторые идеи, которые вы сможете применить к своим данным. Как указано во введении, сайт «Splunk answers» (https://answers.splunk.com) – отличное мес то, где можно найти примеры и справочную информацию. На этом сайте вы сможете задавать свои вопросы и давать ответы другим членам сообщества. В следующей главе мы воспользуемся более продвинутыми возможностями Splunk, позволяющими расширять язык запросов и дополнять данные во время поиска. Глава 7 Расширенный поиск В этой главе мы рассмотрим некоторые возможности, предлагаемые системой Splunk вдобавок к мощному языку запросов. Далее мы рассмотрим следующие темы на примерах: теги и eventtypes, помогающие классифицировать события для нужд поиска и отчетов; запросы, позволяющие добавлять в события внешние поля, как если бы они были частью исходных данных; использование фрагментов поиска в макросах; workflow actions, позволяющие конструировать поисковые запросы и создавать ссылки на основе значений полей в событиях; внешние команды, позволяющие использовать код на Python для работы с результатами поиска. В этой главе мы рассмотрим часть обширного множества команд, поддерживаемых в Splunk. А в главе 13 «Расширение Splunk» вы увидите, как создавать свои команды. Использование тегов для упрощения поиска Теги дают возможность добавлять метки к полям и eventtypes (типам событий). После добавления теги можно включать в поисковые запросы и отчеты. Давайте добавим тег к паре пользователей, выполняющих административные функции. Начнем с такого запроса: sourcetype="impl_splunk_gen" | top user Он вернет список пользователей, таких как ronnie, tuck, jarde, shelby и т. д. (см. рис. 7.1). Допустим, пользователи shelby и steve наделены полномочиями админист раторов. Используя стандартный запрос, мы можем легко отыскать их: sourcetype="impl_splunk_gen" (user=shelby OR user=steve) Этот запрос в будущем будет работать, как и сейчас. Но если организовать поиск по значению тега, в будущем можно избежать необходимости обновлять множество сохраненных запросов. Использование тегов для упрощения поиска  209 Рис. 7.1  Первоначальный список пользователей Чтобы создать тег, сначала нужно определить поле (см. рис. 7.2). Рис. 7.2  Выбор поля в событии Если поле user не видно, щелкните на виджете выбора полей, а затем на ссылке Select (Выбрать), чтобы увидеть все доступные поля, и поставьте галочку для поля user, как показано на рис. 7.3. Рис. 7.3  Список в виджете выбора полей 210  Расширенный поиск В списке событий выберите событие и щелкните на значке со стрелкой вправо в столбце i, как показано на рис. 7.4. Рис. 7.4  Щелкните на значке со стрелкой вправо в столбце i Затем щелкните на значке со стрелкой вниз в столбце Actions (Действия) для поля, к которому вы намереваетесь добавить тег, и в раскрывшемся меню выберите пункт Edit Tags (Редактировать теги), как показано на рис. 7.5. Рис. 7.5  Выберите пункт Edit Tags (Редактировать теги) В результате откроется диалог Create Tags (Создать теги), изображенный на рис. 7.6. Рис. 7.6  Диалог Create Tags (Создать теги) Использование тегов для упрощения поиска  211 Для значения поля user=steve добавьте тег admin, как показано на рис. 7.7. Рис. 7.7  Добавьте тег admin После этого тег должен появиться рядом с полем user, как показано на рис. 7.8. Рис. 7.8  Рядом с полем user должен появиться тег admin Закончив, проделайте то же самое для user=shelby. Добавив теги к этим двум пользователям, вы сможете использовать их вместо фактических имен пользователей: sourcetype="impl_splunk_gen" tag::user="admin" Внутренне этот запрос разворачивается в тот же самый запрос, с которого мы начинали. Преимущество данного подхода состоит в том, что после добавления и удаления тегов для тех или иных пользователей вам не придется изменять сами запросы. Далее перечислены некоторые интересные особенности тегов. Теги доступны для поиска глобально, достаточно просто добавить в запрос критерий tag=tag_name; в данном случае tag=admin. Благодаря этому 212  Расширенный поиск можно добавлять теги к любым полям или типам событий и затем выполнять простой поиск по тегу. Эта возможность широко используется в приложениях безопасности для маркировки хостов, пользователей и типов событий, требующих особенно пристального внимания. Любое поле или тип события может иметь сколько угодно тегов. Просто откройте редактор тегов и перечислите нужные теги через пробел. Чтобы удалить тег, откройте редактор тегов и удалите тег, ставший ненужным. Теги также можно редактировать на странице Settings (Настройки), пос ле щелчка на ссылке Settings  Tags (Настройки  Теги). Классификация результатов по типам событий (eventtypes) Тип события является простым поисковым критерием, не требующим использования каких-либо команд. Чтобы определить тип события, сначала нужно выполнить поиск. Возьмем за основу такой запрос: sourcetype="impl_splunk_gen_SomeMoreLogs" logger=AuthClass Допустим, нас интересуют события входа в систему. Чтобы создать тип события, откройте страницу Settings (Настройки) и щелкните на ссылке Event types (Типы событий), как показано на рис. 7.9. Рис. 7.9  Откройте страницу Settings (Настройки) и щелкните на ссылке Event types (Типы событий) Классификация результатов по типам событий (eventtypes)  213 После этого откроется страница Event types (Типы событий), где можно увидеть список имеющихся типов событий и добавить новый (см. рис. 7.10). Рис. 7.10  Страница Event types (Типы событий) со списком имеющихся типов событий Сначала щелкните на кнопке New (Создать). Splunk откроет страницу Add New (Добавить новый), как показано на рис. 7.11. Рис. 7.11  Страница Add New (Добавить новый) Дадим нашему новому типу событий имя login. Теперь те же события можно отыскать, используя вновь созданный тип событий: eventtype=login Типы событий можно использовать в комбинации с другими критериями поиска: eventtype=login loglevel=error 214  Расширенный поиск Определения типов событий могут также ссылаться на другие типы событий. Например, допустим, что все события входа со значением error в поле loglevel фактически представляют неудачные попытки входа. Теперь мы можем добавить еще один тип событий, выполнив те же шаги, что были описаны выше. Назовем его failed_login. Сейчас все такие события можно отыскать с помощью простого запроса: eventtype="failed_login" Давайте попробуем объединить этот тип события с критерием поиска по тегу admin, добавленному в предыдущем разделе: eventtype="failed_login" tag::user="admin" В результате мы получим все неудачные попытки входа наших администраторов. Давайте для всех таких событий добавим новый тип с именем failed_admin_login. Теперь мы легко сможем отыскать их запросом: eventtype="failed_admin_login" И в заключение добавим тег к этому типу события. Сначала убедитесь, что поле eventtype видимо. События должны выглядеть, как показано на рис. 7.12. Рис. 7.12  Поле eventtype должно быть видимо Обратите внимание на три значения eventtype. Мы выполнили поиск только по критерию eventtype=failed_admin_login, но события этого типа также соответствуют определениям eventtype=failed_login и eventtype=login. Также обратите внимание на теги в поле user. Мы не искали специально по тегу admin, но пользователю steve соответствует тег tag::user=admin, поэтому значение тега появилось в результатах. Следуя инструкциям в предыдущем разделе, добавьте к значению event type=failed_admin_login тег actionable, как показано на рис. 7.13. Рис. 7.13  Добавьте к значению eventtype=failed_admin_login тег actionable Классификация результатов по типам событий (eventtypes)  215 Теперь все такие события можно найти по критерию: tag::eventtype="actionable" Этот прием удобно использовать для построения многоуровневых определений событий, которые должны появляться в уведомлениях и отчетах. Например, взгляните на следующий запрос: sourcetype="impl_splunk_gen_SomeMoreLogs" tag::eventtype="actionable" | table _time eventtype user Он возвращает полезный отчет, изображенный на рис. 7.14. Рис. 7.14  Полезный отчет Поразмышляйте, как эти типы событий используются в таком, казалось бы, простом запросе: поиск: тип события определяется поисковым запросом, поэтому очень удобно и естественно искать события по их типу; классификация: в процессе извлечения событий, если они соответствуют определению любого типа событий, эти события получают имя соответствующего типа в поле eventtype; тегирование: поскольку к типам событий тоже можно добавлять теги, эти теги с успехом можно использовать для поиска и классификации. Это очень удобно для назначения типичных тегов разным наборам результатов; например, событий, которые должны отображаться в отчете или вызывать отправку уведомления. 216  Расширенный поиск Для ясности развернем этот запрос, чтобы увидеть, что в действительности делает Splunk за кулисами. Определения тегов и типов событий будут развернуты в запросе, как показано ниже: tag::eventtype="actionable" eventtype="failed_admin_login" eventtype="failed_login" tag::user="admin" (eventtype=login loglevel=error) tag::user="admin" ((sourcetype="impl_splunk_gen" logger="AuthClass") loglevel=error) tag::user="admin" ((sourcetype="impl_splunk_gen" logger="AuthClass") loglevel=error) (user=steve OR user=shelby) Рассмотрим этот запрос по шагам. 1. Начальный поиск. 2.Выполняется подстановка всех типов событий с тегом actionable. В данном случае у нас имеется только один такой тип, но если бы их было несколько, они были бы объединены через OR. 3. Добавляется определение типа события failed_admin_login. 4. Добавляется определение failed_login. 5. Добавляется определение login. 6.Выполняется подстановка всех значений для поля user, соответствующих тегу admin, объединяемых через OR. Любые изменения в определениях тегов или типов событий вступят в силу при следующем же поиске или попытке получить отчет. Использование lookups для обогащения данных Иногда информация, которая может пригодиться в отчетах или при поиске, находится не в самих журналах, а в других местах. Механизм обогащения (lookup) позволяет добавлять данные и даже выполнять поиск по полям в дополнительных данных, как если бы они были частью исходных событий. Источником данных для подстановки могут служить файлы с данными, разделенными запятыми (Comma-Separated Values, CSV), или скрипты. В сле дующем разделе мы рассмотрим наиболее типичные случаи использования файлов CSV, а о скриптах поговорим в главе 13 «Расширение Splunk». Чтобы определить lookup, нужно выполнить три шага: создать файл, написать определение lookup (по сути, определить заголовки таблицы) и, необязательно, организовать автоматический запуск lookup. Определение файла с lookup-таблицей Файл с lookup-таблицей – это обычный файл CSV. Первая строка в файле интерпретируется как список имен полей для всех остальных строк. Использование lookups для обогащения данных  217 Управление файлами с lookup-таблицами осуществляется на странице Settings  Lookups  Lookup table files. Просто загрузите новый файл и дайте ему имя, предпочтительно с расширением .csv. Вот пример содержимого файла с lookup-таблицей (users.csv): user,city,department,state steve,Dallas,HR,TX shelby,Dallas,IT,TX mary,Houston,HR,TX nanette,Houston,IT,TX tuck,Chicago,HR,IL Загрузив файл, мы сразу же получаем возможность использовать его в коман де lookup. В простейшем случае команда lookup имеет следующий формат: lookup [определение lookup или имя файла] [поле для подстановки] Вот как выглядит использование этой команды: sourcetype=" impl_splunk_gen_SomeMoreLogs" | lookup users.csv user Как видите, поля из lookup-таблицы стали частью события, как если бы они присутствовали в нем изначально (рис. 7.15). Рис. 7.15  Поля из таблицы подстановки стали частью события Эти поля можно использовать в отчетах, как показано ниже: sourcetype=" impl_splunk_gen_SomeMoreLogs" | lookup users.csv user | stats count by user city state department В результате получится таблица, изображенная на рис. 7.16. 218  Расширенный поиск Рис. 7.16  Результат использования в отчете полей из lookup-таблицы Это все, что необходимо знать для использования файлов CSV с lookupтаблицами с целью обогащения данных. Однако, приложив немного усилий и выполнив дополнительные настройки, можно сделать механизм подстановки еще более полезным. Настройка определений lookup Доступ к данным для обогащения можно получить сразу, по имени файла, однако в определении lookup можно задать другие параметры, повторно использовать тот же файл и заставить lookup выполняться автоматически. Создание определения также устраняет предупреждающее сообщение, которое появляется при простом использовании имени файла. Перейдите на страницу Settings | Lookups | Lookup definitions и щелкните на кнопке New (Создать), как показано на рис. 7.17. Рис. 7.17  Страница создания нового определения подстановки Использование lookups для обогащения данных  219 На этой странице присутствуют поля с настройками, перечисленные ниже. Destination app (Целевое приложение): определяет место для хранения определения. Это поле играет важную роль, потому что может понадобиться ограничить область действия lookup определенным приложением по соображениям производительности. Name (Имя): имя, которое будет использоваться в запросах. Type (Тип): здесь на выбор доступны два варианта: File-based (На основе файла) и External (Внешний). Подробнее о типе External (Внешний), предполагающем использование сценариев, рассказывается в главе 13 «Расширение Splunk». Lookup file (Файл с lookup-таблицей): в данном случае мы должны указать файл users.csv. Configure time-based lookup (Настроить подстановку в зависимости от времени): благодаря этой настройке мы можем определить несколько значений, сменяющих друг друга в определенных точках по мере продвижения вдоль оси времени. Например, определив подстановку номеров версий программного обеспечения, развернутого на разных хостах в разные моменты времени, можно сгенерировать отчет с ошибками или временами отклика с классификацией по номерам версий программ. Advanced options (Дополнительные настройки): открывает доступ к ос тальным полям. Minimum matches (Минимальное число совпадений): определяет число элементов в lookup-таблице, совпадение с которыми должно быть найдено. При значении 1 в этом поле и в отсутствие совпадений будет использовано значение из поля Default matches (Совпадения по умолчанию). Maximum matches (Максимальное число совпадений): определяет максимальное число совпадений, после которого сопоставление будет прекращено. Например, если бы в нашем файле с lookup-таблицей имелось по нескольку записей для каждого пользователя, с помощью этого значения мы могли бы ограничить число записей, применяемых к каждому событию. Default matches (Совпадения по умолчанию): это значение будет использовано для заполнения всех полей, требующих подстановки, если в lookup-таблице не найдено ни одного совпадения и поле Minimum matches (Минимальное число совпадений) содержит значение больше 0. После щелчка на кнопке Save (Сохранить) можно сразу начинать использовать новое определение lookup: sourcetype="impl_splunk_gen_SomeMoreLogs" | lookup userslookup user | stats count by user city state department Этот запрос вернет результат, изображенный на рис. 7.18. 220  Расширенный поиск Рис. 7.18  Результат использования нового определения подстановки Lookup-таблицы поддерживают еще некоторые особенности, включая поиск по шаблонным символам, CIDR-подстановку и подстановку по времени. Мы будем использовать их в последующих главах. Определение автоматического Lookup Автоматический Lookup – по мнению автора, одна из самых крутых особенностей в Splunk. Она не только добавляет дополнительные данные в события, создавая впечатление, что они всегда были там, но и позволяет добавлять поля из lookup-таблицы в критерии поиска. Чтобы настроить автоматический lookup, перейдите на страницу Settings  Lookups  Automatic lookups, как показано на рис. 7.19, и щелкните на кнопке New (Создать). Рис. 7.19  Страница создания нового определения автоматической подстановки Использование lookups для обогащения данных  221 На этой странице присутствуют поля с настройками, перечисленные ниже. Destination app (Целевое приложение): определяет место для хранения определения. Влияние выбора в этом поле мы обсудим в главе 8 «Работа с приложениями». Name (Имя): имя, которое будет использоваться в настройках. Оно не должно содержать пробелов и специальных символов. Важность этого поля мы обсудим в главе 11 «Настройка Splunk». Lookup table (Таблица подстановки): имя определения lookup. Apply to (Применить к): позволяет выбрать события для автоматического применения lookup. Обычно выбор событий производится по полю sourcetype, содержимое которого должно точно совпадать с указанным в поле named. Для выбора также доступны поля source и host, а в поле named допускается использовать wildcard-символы. Lookup input fields (Входные поля подстановки): определяет поля, запрашиваемые из lookup-таблицы. Должно быть указано хотя бы одно поле, также можно указать несколько полей. Эту настройку можно рассматривать как операцию соединения в базе данных. Слева – имя поля в lookup-таблице. Справа – имя поля, существующего в событиях. Lookup output fields (Выходные поля подстановки): здесь можно указать, какие столбцы из lookup-таблицы должны включаться в события, и при необходимости переопределить их имена. Слева – имя поля в lookupтаблице. Справа – имя, под которым данное поле будет добавляться в события. Если левое поле ввода оставить пустым, по умолчанию будут добавлены все поля из lookup-таблицы с их фактическими именами. Overwrite field values (Затирать значения полей): если установить этот флажок, существующие значения полей в событиях будут затираться значениями из одноименных полей в lookup-таблице. После щелчка на кнопке Save (Сохранить) откроется список Automatic lookups (Автоматические подстановки). Первоначально параметр Sharing (Совместное использование) имеет значение Private (Скрыто), что станет источником проблем, если вы попытаетесь поделиться своими запросами с другими. Чтобы открыть доступ к lookup, щелкните на ссылке Permissions (Разрешения), как показано на рис. 7.20. Рис. 7.20  Щелкните на ссылке Permissions (Разрешения) в колонке Sharing (Совместное использование) 222  Расширенный поиск В результате откроется страница Permissions (Разрешения). В разделе Object should appear in (Объект должен быть доступен в) выберите флажок All apps (Все приложения), как показано на рис. 7.21. Подробнее о разрешениях мы поговорим в главе 11 «Настройка Splunk». Рис. 7.21  Выберите флажок All apps (Все приложения) Итак, мы определили lookup, который выполняется автоматически, обогащая события с определенным типом источника (sourcetype) новыми данными, опираясь на значение в поле user. Чтобы показать мощь этой подстановки, попробуем выполнить поиск по полю из lookup-таблицы, как если бы оно изначально было частью событий: sourcetype="impl_splunk_gen_SomeMoreLogs" department="HR" | top user Даже притом что поле department отсутствует в исходных событиях, система Splunk выполнила поиск в lookup-таблице по значению поля user, добавила поле department и затем произвела поиск по заданному критерию. Этот запрос вернет результаты, изображенные на рис. 7.22. Рис. 7.22  Результаты поиска по полю department Использование lookups для обогащения данных  223 Попробуем объединить этот запрос с типом события, который мы определили выше. Чтобы отыскать самые последние ошибки входа всех сотрудников отдела HR, можно выполнить такой запрос: sourcetype="impl_splunk_gen_SomeMoreLogs" department="HR" eventtype="failed_login" | dedup user | table _time user department city state Он вернет результаты, изображенные на рис. 7.23. Рис. 7.23  Самые последние ошибки входа всех сотрудников отдела HR Команда dedup использована здесь, только чтобы оставить в результатах по одному событию для каждого уникального значения в поле user. Так как события возвращаются в обратном хронологическом порядке, этот запрос вернет самую последнюю ошибку входа для каждого пользователя. В последующих главах мы познакомимся с более продвинутыми обогащениями. Проблемы с lookups Проблемы с lookup чаще всего связаны с недостаточностью разрешений. Проверьте разрешения на всех трех страницах: Settings  Lookups  Lookup table files (Настройки  Подстановки  Файлы с таблицами подстановки); Settings  Lookups  Lookup definitions (Настройки  Подстановки  Определения подстановок); Settings  Lookups  Automatic lookups (Настройки  Подстановки  Автоматические подстановки). После корректировки разрешений убедитесь, что учли следующие обстоятельства: имена полей должны быть записаны правильно, с учетом регистра символов; по умолчанию значения в полях подстановки чувствительны к регистру; если в вашей системе используется несколько узлов для индексирования, может понадобиться какое-то время, чтобы файлы с lookup-таблицами и определения скопировались на все узлы, это особенно верно для больших файлов или когда установлено очень много приложений с пересылаемыми ресурсами; желательно, чтобы файлы с lookup-таблицами содержали не больше двух миллионов строк. Если lookup-таблица содержит слишком много записей, подумайте о создании внешнего скрипта подстановки. 224  Расширенный поиск Применение макросов Основное назначение макросов – служить заменой фрагментов запросов (мак росы имеют также другие применения, например чтобы оказать помощь в создании сценариев реагирования). Макросы позволяют повторно использовать логику и значительно уменьшить длину запросов. Рассмотрим, например, следующий запрос: sourcetype="impl_splunk_gen_SomeMoreLogs" user=mary | transaction maxpause=5m user | stats avg(duration) avg(eventcount) Создание простого макроса Преобразуем в макрос две последние строки из предыдущего запроса. Для этого перейдите на страницу Settings  Advanced search  Search macros (Настройки  Продвинутый поиск  Макросы поиска) и щелкните на кнопке New (Создать), как показано на рис. 7.24. Рис. 7.24  Перейдите на страницу Settings  Advanced search  Search macros (Настройки  Продвинутый поиск  Макросы поиска) и щелкните на кнопке New (Создать) На этой странице вы увидите поля с настройками, перечисленные ниже. Destination app (Целевое приложение): определяет место для хранения макроса. Применение макросов  225 Name (Имя): имя, которое будет использоваться в запросах. Definition (Определение): текст, который будет замещать имя макроса в запросах. Use eval-based definition? (Определение как аргумент eval?): если установить этот флажок, строка в поле Definition (Определение) будет интерпретироваться не как простой текст, а как инструкция eval. Мы воспользуемся этой настройкой позже. Остальные поля используются, если задано значение в поле Arguments (Аргументы). Мы используем их в нашем следующем примере. После щелчка на кнопке Save (Сохранить) макрос станет доступен для использования. Вот как можно его задействовать: sourcetype="impl_splunk_gen_SomeMoreLogs" user=mary `webtransactions` Слово webtransactions заключено в обратные апострофы. Это напоминает использование обратных апострофов в командной строке Unix, когда требуется выполнить программу, чтобы сгенерировать аргумент. В данном случае подстрока `webstransactions` будет просто замещена текстом из определения макроса, в результате чего получится исходный запрос, с которого мы начали. Создание макроса с аргументами Давайте поместим весь запрос в макрос, принимающий два аргумента – user и maxpause, – как показано на рис. 7.25. Рис. 7.25  Определение макроса с аргументами 226  Расширенный поиск Не забудьте убрать переносы строк из текста запроса в определении, иначе макрос просто не будет работать. Пройдемся по полям с настройками. Name (Имя): имя, которое будет использоваться в запросах. Круглые скобки и целое число в них, (2), определяют количество аргументов мак роса. Definition (Определение): на этот раз мы поместили в определение запрос целиком. Переменные определяются как $user$ и $maxpause$. Мы можем использовать эти имена, потому что они определены в поле Arguments (Аргументы). Arguments (Аргументы): список имен переменных, используемых внут ри макроса. После щелчка на кнопке Save (Сохранить) макрос станет доступен для использования. Вот как можно его задействовать: webtransactions_user_maxpause(mary,5m) или: `webtransactions_user_maxpause("mary","5m")` Мы будем использовать эту возможность в сочетании со сценариями реагирования (workflow action) далее в этой главе (см. раздел «Создание сценария реагирования для отображения контекста поля»). Создание сценариев реагирования Сценарии реагирования (workflow actions) позволяют определять нестандартные операции, опирающиеся на значения в результатах поиска. Поддерживаются два вида действий: запуск поиска или ссылка на URL. Запуск нового поиска с использованием значения из события Чтобы создать сценарий реагирования, перейдите на страницу Settings  Fields  Workflow actions (Настройки  Поля  Сценарии реагирования) и щелкните на кнопке New (Создать). После этого откроется форма, изображенная на рис. 7.26. Рассмотрим поля формы поближе. Destination app (Целевое приложение): определяет приложение для хранения определения сценария реагирования. Name (Имя): имя, которое будет использоваться в конфигурационных файлах. Имя не может содержать пробелы, но допускаются символы подчеркивания. Label (Метка): текст, отображаемый в меню. Может содержать переменные. В данном случае мы включили переменную $user$, получающую значение из поля user в событии. Создание сценариев реагирования  227 Рис. 7.26  Форма определения нового сценария реагирования 228  Расширенный поиск Apply only to the following fields (Применять только к следующим полям): этот сценарий реагирования будет появляться только в событиях, имеющих значения во всех перечисленных здесь полях. Apply only to the following event types (Применять только к событиям следующих типов): этот сценарий реагирования будет появляться лишь в событиях указанного типа. Например, если определен тип событий с именем login, вы сможете создать свой сценарий реагирования для поиска всех таких событий для данного конкретного пользователя в течение последней недели. Show action in (Показать сценарий в): определяет меню, где будет отображаться этот сценарий реагирования. На выбор доступны три варианта: Event menu (Меню события), Fields menus (Меню полей) и Both (В обоих). – Вариант Event menu (Меню события) определяет меню слева от события. Если поле формы Apply only to the following fields (Применять только к следующим полям) не пустое, сценарий реагирования появится в меню, только если в событии присутствуют все перечисленные поля. – Вариант Fields menus (Меню полей) определяет меню справа от каждого поля в событии. Если поле формы Apply only to the following fields (Применять только к следующим полям) не пустое, сценарий реагирования появится в меню лишь для перечисленных полей. – В случае выбора варианта Both (В обоих) сценарий появится в обоих меню, следуя тем же правилам. Action type (Тип действия): на выбор доступны два варианта, search (поиск) и link (ссылка). Здесь мы выберем search, а вариант link опробуем в следующем разделе. Search string (Строка запроса): определяет шаблон поискового запроса для выполнения. Здесь почти всегда используются значения полей, но это необязательно. Run in app (Запускать в приложении): если оставить это поле пустым, будет использоваться текущее приложение, иначе поиск будет производиться в указанном приложении. В большинстве случаев это поле оставляют пустым. Open in view (Открыть в представлении): если оставить это поле пус тым, будет использоваться текущее представление. Если предполагается выводить панель со списком событий в дашборде, желательно указать flashtimeline. Run search in (Запускать поиск в): на выбор доступны два варианта: New window (Новое окно) и Current window (Текущее окно). Time range (Интервал времени): здесь можно определить конкретный интервал времени, указав либо абсолютное число секунд от начала эпохи, либо относительное время. Если оставить поле Latest time (Конец интервала), поиск будет выполняться по самым последним данным. Создание сценариев реагирования  229 Use the same time range as the search that created the field listing (Использовать тот же интервал, как в запросе, создавшем этот список полей): в практике обычно либо устанавливают этот флажок, либо определяют значение, по меньшей мере, в поле Earliest time (Начало интервала). Если этого не сделать, запрос проверит все доступные данные за все время, но такое поведение редко соответствует нашим желаниям. Границы интервала также можно указать в самом запросе. После сохранения сценария реагирования щелчком на кнопке Save (Сохранить) его можно увидеть в меню действий, доступных для события, как показано на рис. 7.27. Рис. 7.27  После сохранения сценарий реагирования появится в меню действий, доступных для события После выбора этого пункта откроется новое окно с результатами, как показано на рис. 7.28. Рис. 7.28  Результат выполнения сценария реагирования Ссылки на внешние сайты Сценарий реагирования также может переходить на ссылки внешних сайтов, используя информацию из события. Представьте, что в вашей организации есть некоторый другой веб-инстру мент. Если этому инструменту можно передать аргументы в составе запроса GET или POST, тогда вы сможете обратиться к нему прямо из результатов Splunk. 230  Расширенный поиск Создайте новый сценарий реагирования, как описывалось в предыдущем разделе, но в поле Action type (Тип действия) выберите вариант link. После этого содержимое формы изменится, как показано на рис. 7.29. Рис. 7.29  Поля формы для настройки ссылки на внешний сайт Система Splunk сама позаботится о кодировании содержимого переменных перед вставкой в URL, чтобы обеспечить передачу специальных символов. Если автоматическое кодирование нежелательно, например когда содержимое переменной фактически должно стать частью URL, добавьте восклицательный знак перед именем переменной: $!user$ Если в поле Link method (Метод ссылки) выбрать POST, появятся дополнительные поля ввода (рис. 7.30), в которых можно определить аргументы для передачи в теле запроса POST. Рис. 7.30  Если выбрать метод POST, появятся дополнительные поля ввода Если в меню выбрать этот сценарий реагирования, откроется страница с указанным URL, в текущем или в новом окне, в зависимости от значения, выбранного в поле Open link in (Открывать ссылку в). В сценариях реагирования также можно использовать поля, полученные через lookup. Это очень удобно, когда внешний инструмент требует дополнительной информации, отсутствующей в событиях непосредственно, но которую можно сгенерировать на основании имеющейся информации. Создание сценариев реагирования  231 Создание сценария реагирования для отображения контекста поля В меню для всех событий доступен пункт Show Source (Показать источник), реализованный как сценарий реагирования. Если выбрать его, запустится запрос, отыскивающий события, которые принадлежат тому же источнику и хос ту. Это очень полезная возможность, но иногда желательно увидеть события, которые имеют еще что-то общее, помимо источника, в обычном интерфейсе поиска, в комплекте со шкалой времени и виджетом выбора полей. Для этого создадим сценарий реагирования и макрос для использования в запросе. Это довольно сложный пример, поэтому не волнуйтесь, если не сможете до конца разобраться в нем. Создание контекстного сценария реагирования Сначала определим сценарий реагирования. Как и прежде, в поле Action type (Тип действия) выберите вариант search, как показано на рис. 7.31. Рассмотрим поближе значения в полях, определяющих этот сценарий реагирования. Name (Имя): здесь можно указать любое имя. Давайте дадим ему имя, содержащее интервал времени. Label (Метка): текст, отображаемый в меню. Обратите внимание на два специальных поля, @field_name и @field_value. Они определены, только когда в поле Show action in (Показать сценарий в) выбран вариант Fields menus (Меню полей). Для сценариев реагирования доступно несколько таких специальных переменных. Полный их список вы найдете в документации http://docs.splunk.com/, поискав по фразе Create workflow actions in Splunk. Apply only to the following fields (Применять только к следующим полям): это поле можно оставить пустым или ввести в него символ звездочки (*), чтобы указать, что сценарий реагирования относится ко всем полям. Show action in (Показать сценарий в): в данном случае выберем Fields menus (Меню полей). Action type (Тип действия): мы собираемся выполнять поиск. Это довольно странный поиск, потому что используется макрос, но технически это все еще поиск. Search string (Строка запроса): тот факт, что запрос является макросом, не имеет никакого значения для сценария реагирования, `context("$@ field_name$", "$@field_value$", "$_ time$", "-1m", "+5m")`. Макрос context мы создадим ниже. Run in app (Запускать в приложении): если оставить это поле пустым, макрос будет производить поиск в текущем приложении. Open in view (Открыть в представлении): мы должны обеспечить выполнение запроса в flashtimeline, поэтому явно выбрано это представление. 232  Расширенный поиск Рис. 7.31  Определение нового сценария реагирования Создание сценариев реагирования  233 Run search in (Запускать поиск в): выберем New window (Новое окно). Time (Время): вопреки предыдущему совету оставим интервал времени неопределенным – он будет задаваться в самом запросе и отменять любые рамки, указанные здесь. После сохранения щелчком на кнопке Save (Сохранить) сценарий реагирования появится в меню действий для всех полей, как показано на рис. 7.32. Рис. 7.32  Сценарий реагирования доступен в меню действий для всех полей Если выбрать этот пункт меню, он выполнит поиск: `context("ip", "1.22.3.3", "2012-05-16T20:23:59-0500", "-1m", "+5m")` Давайте рассмотрим поближе сам запрос: `context("$@field_name$", "$@field_value$", "$_time$", "-1m", "+5m")` Как видите, имена переменных были заменены их значениями, а в остальном запрос не изменился. Значение переменной _time оказалось не в том формате, в каком я ожидал (я предполагал получить число секунд, прошедших от начала эпохи), впрочем, мы позаботимся об этом ниже. Макрос context Выполняя поиск, интервал времени можно указать непосредственно в запросе. Для этого поддерживается несколько полей. earliest: определяет начальный момент времени, включительно. Здесь можно задать относительное время или абсолютное, в секундах от начала эпохи. latest: определяет конечный момент времени, исключительно. Запрос отберет только события, происшедшие до этого времени. Здесь можно задать относительное время или абсолютное, в секундах от начала эпохи. now: с помощью этого поля можно переопределить текущий момент времени, относительно которого вычисляется интервал на основе earliest и latest. Должно определяться в секундах от начала эпохи. 234  Расширенный поиск Теперь определим имена переменных: field_name = ip; field_value = 1.22.3.3; event_time = 2012-05-16T20:23:59-0500; earliest_relative = -1m; latest_relative = +5m. Нам нужно, чтобы запрос выглядел так: earliest=-1m latest=+5m now=[время в секундах от начала эпохи] ip=1.22.3.3 Единственная переменная, не имеющая значения, – переменная now. Чтобы вычислить недостающее значение, можно воспользоваться функцией strptime, доступной для команды eval. Для проверки функции используем |stats, чтобы создать событие, сконструируем поле event_time и вычислим значение: |stats count | eval event_time="2012-05-16T20:23:59-0500" | eval now=strptime(event_time,"%Y-%m-%dT%H:%M:%S%z") В результате получится таблица, изображенная на рис. 7.33. Рис. 7.33  Результат использования функции strptime Отличный справочник по форматам, поддерживаемым функцией strptime, можно получить в современных системах Linux, выполнив команду man strptime или man date. Эту же информацию можно найти в http://www.google.com. В Splunk имеются специализированные расширения для strptime, получить информацию о которых можно, выполнив поиск по фразе enhanced strptime() support на сайте http://docs.splunk.com/. Теперь, получив значение для now в секундах от начала эпохи, можно создать запрос и протестировать его: earliest=-1m latest=+5m now=1337217839 ip=1.22.3.3 В результате мы получим обычный список событий, от момента за минуту до выбранного события и до момента через пять минут после него. При этом отобразятся только события с общими полями. Теперь, имея запрос и инструкцию eval для преобразования значения now, можно приступать к созданию макроса. Откройте страницу Settings  Advanced search  Search macros  Add new (Настройки  Продвинутый поиск  Макросы поиска  Добавить новый), как показано на рис. 7.34. Создание сценариев реагирования  235 Рис. 7.34  Форма создания нового макроса В этом макросе используется несколько интересных особенностей. Макросы могут принимать аргументы. Число аргументов задается в имени макроса добавлением круглых скобок с числом аргументов. В данном случае предполагается получить пять аргументов. Определение макроса фактически может быть инструкцией eval. То есть можно использовать функции eval для построения запроса на основе некоторого значения, получаемого макросом. В данном случае мы используем функцию strptime. Для этого важно учитывать следующие особенности: – инструкция eval должна возвращать строку. Если ей не удастся вернуть строку по какой-то причине, пользователь увидит сообщение об ошибке; – имена переменных будут заменены их значениями до вызова инструкции eval. То есть могут возникнуть проблемы с экранированием значений переменных, поэтому важно гарантировать, чтобы значение содержало кавычки, где это необходимо. Use eval-based definition? (Определение как аргумент eval?): если этот флажок установлен, макрос будет интерпретироваться как инструкция eval. В поле Arguments (Аргументы) мы указали имена поддерживаемых аргументов. Это имена, на которые мы ссылаемся в поле Definition (Определение). Щелкнув на кнопке Save (Сохранить), мы получим действующий макрос. При желании вы можете внести изменения в этот сценарий реагирования, приспособив его под свои потребности. Давайте изменим определение и отсортируем события по возрастанию времени и заодно предотвратим поиск по индексам. Измените поле Search string (Строка запроса), как показано ниже: `context("$@field_name$", "$@field_value$", "$_time$", "-1m","+5m")` index=$index$ | reverse 236  Расширенный поиск Далее этот же запрос приводится в развернутой форме, исключительно для ясности: `context("$@field_name$", "$@field_value$", "$_time$", "-1m", "+5m")` index=$index$ | reverse `context("ip", "1.22.3.3", "2012-05-16T20:23:59-0500", "-1m", "+5m")` index=implsplunk | reverse earliest=-1m latest=+5m now=1337217839 ip=1.22.3.3 index=implsplunk | reverse Теперь вы можете создать дополнительные сценарии реагирования, определяющие другие интервалы времени или включающие другие поля, например host. Использование внешних команд Splunk имеет очень мощный язык запросов, но иногда трудно или даже невозможно реализовать какую-то логику без привлечения чего-то другого, кроме языка запросов. Для преодоления этой проблемы Splunk поддерживает внешние команды на языке Python. В состав системы уже входит множество таких команд, и еще немалое их количество доступно на сайте http://splunk-base. splunk.com/. Давайте познакомимся с некоторыми такими командами, включенными в систему. Документацию с их описанием вы найдете в одном разделе с командами поиска на сайте http://docs.splunk.com/. Там же вы найдете список всех команд, доступных по умолчанию, внутренних и внешних. Как писать свои команды, будет показано в главе 13 «Расширение Splunk». Извлечение значений из XML Очень часто машинные данные распространяются в формате XML. Система Splunk без проблем индексирует такие данные, но в ней отсутствует встроенная поддержка XML. Даже притом что XML – далеко не идеальный формат для логирования, его парсинг реализуется достаточно просто. В составе приложения поиска имеются две команды, помогающие извлекать поля из XML. xmlkv Команда xmlkv создает поля из имен тегов, используя регулярные выражения. Например, для фрагмента в формате XML <doc><a>foo</a><b>bar</b></doc> команда xmlkv сгенерирует два поля, a=foo и b=bar. Проверим это: |stats count | eval _raw="<doc><a>foo</a><b>bar</b></doc>" | xmlkv В результате получится таблица, изображенная на рис. 7.35. Использование внешних команд  237 Рис. 7.35  Результат применения команды xmlkv Так как команда выполняет парсинг, используя регулярные выражения, она генерирует результаты даже для неполных и неправильно сформированных XML-документов. Внешние команды работают существенно медленнее, чем встроенные команды языка запросов. Их низкая производительность особенно заметна при обработке больших наборов данных. Если необходимые поля можно получить с помощью встроенных команд rex и eval, используйте их, потому что запрос с этими командами будет работать быстрее и создаст меньшую нагрузку на серверы Splunk. Например, поля из фрагмента XML в предыдущем примере можно извлечь иначе: | rex "<a.*?>(?<a>.*?)<" | rex "<b.*?>(?<b>.*?)<" XPath XPath – мощный язык для извлечения значений из документов XML. В отличие от команды xmlkv, применяющей регулярные выражения, XPath использует полноценный парсер XML. Это означает, что событие должно содержать до пустимый XML-документ. Например, взгляните на следующий документ XML: <d> <a x="1">foo</a> <a x="2">foo2</a> <b>bar</b> </d> Получить значение тега a с атрибутом x="2" можно с помощью такого кода на XPath: //d/a[@x='2'] Чтобы убедиться в этом, сгенерируем единственное событие, используя трюк с |stats, и выполним инструкцию xpath: |stats count | eval _raw="<d><a x='1'>foo</a><a x='2'>foo2</a><b>bar</b></d>" | xpath outfield=a "//d/a[@x='2']" Этот запрос вернет результат, изображенный на рис. 7.36. Рис. 7.36  Результат применения команды xpath 238  Расширенный поиск Команда xpath может также извлекать поля с несколькими значениями. Например, следующая инструкция xpath просто отыскивает любое поле: |stats count | eval _raw="<d><a x='1'>foo</a><a x='2'>foo2</a><b>bar</b></d>" | xpath outfield=a "//a" Результат этого запроса изображен на рис. 7.37. Рис. 7.37  Команда xpath может извлекать поля с несколькими значениями В интернете есть масса руководств по языку XPath. Мне, например, очень нравится краткий справочник на веб-сайте Mulberry Technologies: http://www. mulberrytech. com/quickref/xpath2.pdf. Генерирование результатов с помощью Google Внешние команды могут действовать так же, как генераторы данных, подобно команде stats, которую мы использовали для создания тестовых событий. Существует несколько таких команд, но я предлагаю рассмотреть забавный пример с Google (в некоторых организациях интернет может быть недоступен приложениям Splunk, но в следующих примерах предполагается, что такое подключение возможно). Команда google принимает один аргумент, строку поиска, и возвращает результаты в виде множества событий. Выполним поиск для слова «Splunk»: |google "splunk" В результате получится таблица, изображенная на рис. 7.38. Рис. 7.38  Результат выполнения команды |google "splunk" Итоги  239 Этот пример, может быть, не самый полезный, зато наглядно демонстрирует возможность использования внешних источников для получения данных на начальном этапе или даже для заполнения подмножества для другого запроса. Пример более полноценного генератора данных мы рассмотрим в главе 13 «Расширение Splunk». Итоги В этой главе мы кратко познакомились с тегами, типами событий, подстановкой, макросами, сценариями реагирования и внешними командами. Я надеюсь, что представленные примеры и их обсуждение послужат вам отправной точкой для создания своих приложений. Больше примеров можно найти в официальной документации Splunk, по адресам: http://docs.splunk.com/ и http:// splunk-base.splunk.com/. В следующей главе мы займемся созданием и настройкой своих приложений. Глава 8 Работа с приложениями Приложения Splunk – это то, что в Splunk-индустрии называют знаниями. Приложения – это набор объектов знаний (knowledge objects). Объект знаний – это предопределенный набор настроек внутри Splunk, основанный на некоторой логике и соответствующий некоторым потребностям и соображениям. Приложения Splunk создаются с целью расширения или настройки возможностей для пользователей Splunk. В этой главе мы рассмотрим элементы, составляющие приложения Splunk, а также исследуем новый механизм самостоятельного управления приложениями (первоначально появившийся в версии 6.6), обновившийся в версии 7.0. В этой главе мы: исследуем встроенные приложения; установим приложения из Splunkbase; создадим свое приложение; настроим навигацию по приложениям; настроим внешний вид приложений; познакомимся с механизмом самостоятельного управления приложе ниями. Определение приложения Строго говоря, приложение – это каталог в файловой системе, включающий набор конфигурационных файлов и иногда код. Каталоги и файлы внутри приложения имеют определенную структуру. Все конфигурации имеют вид текстовых файлов и могут редактироваться с помощью обычного текстового редактора. Как правило, приложения преследуют одну или несколько целей, перечисленных ниже. Служить контейнером для поисковых запросов, дашбордов и связанных с ними конфигурационных файлов: именно для этого используются приложения большинством пользователей. В этом качестве приложения применяются не только для логической группировки, но также для ограничения применяемых конфигурационных файлов. Приложения этого вида редко влияют на другие приложения. Встроенные приложения  241 Предоставить дополнительные возможности: приложения могут экспортировать свои объекты для использования в других приложениях. К ним относятся: списки извлекаемых полей, lookup, внешние команды, сохраненные результаты поиска, сценарии реагирования (workflow actions) и даже дашборды. Такие приложения часто не имеют пользовательского интерфейса – они просто расширяют возможности других приложений. Настройка сервера Splunk для определенной цели: в распределенной архитектуре разные серверы Splunk часто решают разные задачи. Поведение каждого сервера определяется его конфигурацией, и такие конфигурации очень удобно оформлять в виде приложений. Подобные приложения полностью изменяют поведение конкретного сервера. Встроенные приложения Весь пользовательский интерфейс Splunk сосредоточен в приложениях, и без них он становится практически бесполезным. К счастью, в состав Splunk входит несколько встроенных приложений, благодаря которым мы можем приступить к использованию системы. Давайте познакомимся с некоторыми из них. Первое из них – Splunk Web Framework, которое в действительности не является приложением. Это основа для разработчиков, желающих создавать чтото полезное, используя систему Splunk и ее инструменты анализа. С помощью Splunk Web Framework можно быстро создать свое приложение, используя предопределенные компоненты, стили, шаблоны и объекты, и добавить в него свою логику, компоненты и пользовательский интерфейс. Introspection_generator_addon: описывает данные, которые Splunk Enterprise фиксирует и использует для заполнения индекса _introspection. Эти данные содержат информацию о сервере Splunk и его окружении и записываются в файлы журналов для отчетов об использовании системных ресурсов и помощи в устранении неполадок. splunk_monitoring_console (прежде называлось distributed management console): дает возможность получить подробную информацию о работе сервера Splunk Enterprise. gettingstarted: это приложение выводит страницу со справкой; доступно из страницы запуска приложений. Оно не выполняет поиск и содержит единственный дашборд, состоящий из простой HTML-страницы. Search and Reporting: это приложение, где пользователи проводят большую часть своего времени. Содержит главный дашборд и внешние команды поиска, которые могут использоваться другими приложениями, дашборды администрирования, нестандартные средства навигации и стили CSS, пользовательский значок приложения, пользовательский логотип приложения и множество других полезных элементов. SplunkForwarder и SplunkLightForwarder: эти приложения отключены по умолчанию, просто чтобы сделать сервер Splunk более легковесным. Мы подробно обсудим их в главе 12 «Продвинутое развертывание». Даже если вы никогда не будете создавать или устанавливать другие приложе- 242  Работа с приложениями ния и собираетесь пользоваться только хранимыми запросами и дашбордами в приложении поиска, вы все равно сможете извлечь немалую пользу из Splunk. Установка и создание дополнительных приложений, однако, позволяют воспользоваться плодами чужого труда, организовать свою работу и в конечном итоге поделиться своими наработками с другими. Установка приложений Приложения можно устанавливать из репозитория Splunkbase или загружать через интерфейс администратора. Для начала нужно щелкнуть на ссылке Apps (Приложения) на домашней странице, как показано на рис. 8.1. Рис. 8.1  Ссылка Apps (Приложения) на домашней странице После этого откроется страница Apps (Приложения), изображенная на рис. 8.2. Рис. 8.2  Страница Apps (Приложения) на домашней странице Установка приложений  243 Установка приложений из Splunkbase Если сервер Splunk имеет прямой доступ к интернету, вы сможете устанавливать на него приложения из Splunkbase всего несколькими щелчками мыши. На странице Apps (Приложения) щелкните на ссылке Browse More Apps (Дополнительные приложения), и на открывшейся странице вы увидите список наиболее популярных из доступных приложений, как показано на рис. 8.3. Рис. 8.3  Страница Browse More Apps (Дополнительные приложения) В предыдущем издании книги был показан пример установки приложения MAXMIND, которое пользовалось большой популярностью начиная с версии Splunk 5.0. Оно было обновлено для поддержки последней версии Splunk (в настоящее время приложение имеет версию 10.6), и вам определенно стоит установить и попробовать его. Давайте сделаем это! Чтобы установить приложение Geo Location Lookup Script (основанное на MAXMIND), найдите его в списке доступных приложений. Также можно открыть в браузере страницу https://apps.splunk.com, выполнить поиск по имени приложения, загрузить файл с ним и затем загрузить его в Splunk, как показано на рис. 8.4. Для загрузки приложения вам будет предложено ввести свои учетные данные. Это те же самые учетные данные, что были созданы, когда вы загружали Splunk. Если у вас нет своей учетной записи – создайте ее. Далее (как и в предыдущих изданиях) установим приложение Google Maps. Это приложение было создано пользователем Splunk, который решил внести свой вклад в развитие сообщества. После установки вам может быть предложено перезапустить Splunk. 244  Работа с приложениями Рис. 8.4  Страница приложения и кнопка для загрузки После перезапуска и повторного входа обратите внимание на список доступных приложений (см. рис. 8.5). Рис. 8.5  В списке появилось приложение Google Maps Итак, приложение Google Maps появилось, но где приложение Geo Location Lookup Script? Напомню, что не все приложения имеют дашборды, некоторые могут вообще не иметь отображаемых компонентов. Использование Geo Location Lookup Script Приложение Geo Location Lookup Script – это скрипт для lookup, используемый для подстановки географических координат по IP-адресу. В документации можно найти такой пример: Установка приложений  245 eventtype=firewall_event | lookup geoip clientip as src_ip Любое приложение в Splunkbase имеет свою документацию, которую можно найти на сайте https://splunkbase.com или щелкнув на ссылке View details (Показать подробности) в приложении Splunk (сопровождающей любое установленное приложение). Щелкните на ссылке Apps (Приложения) и познакомьтесь с содержимым страницы Apps (Приложения). А теперь перечислим аргументы команды lookup. geoip: имя поля подстановки, создаваемого приложением Geo Location Lookup Script. Доступные lookup можно найти, перейдя по ссылке Settings  Lookups  Lookup definitions (Настройки  Подстановки  Определения подстановок). clientip: имя поля, по которому производится поиск значения для lookup. as src_ip: эта инструкция требует использовать значение src_ip для заполнения предшествующего ему поля, в данном случае clientip. Я лично считаю такой синтаксис запутывающим и со временем выработал привычку читать as (как) как using (используя). В приложении ImplementingSplunkDataGenerator (доступном на http://packtpub.com/support) имеется экземпляр sourcetype с именем impl_splunk_ips, который выглядит примерно так: 2012-05-26T18:23:44 ip=64.134.155.137 IP-адреса в этом фиктивном журнале взяты из журнала одного из моих веб-сайтов. Давайте посмотрим, какую информацию можно получить по этим адресам: sourcetype="impl_splunk_ips" | lookup geoip clientip AS ip | top client_country В результате появится таблица, похожая на изображенную на рис. 8.6 (обратите внимание, что после запуска команды в результаты добавятся новые поля, такие как client_country): Рис. 8.6  После запуска команды в результаты добавятся новые поля Powered by TCPDF (www.tcpdf.org) 246  Работа с приложениями Мне показалось интересным, что мой сайт посетил кто-то из Словении. Использование Google Maps Теперь попробуем выполнить аналогичный поиск в приложении Google Maps. Выберите Google Maps в меню Apps (Приложения). Его интерфейс напоминает интерфейс стандартного приложения поиска, но с картой вместо списка событий. Попробуем выполнить в приложении Google Maps похожий (но не идентичный) запрос с командой lookup: sourcetype="impl_splunk_ips" | lookup geo ip В результате получится карта, изображенная на рис. 8.7. Рис. 8.7  Приложение Google Maps Ничего удивительного, что большая часть трафика для этого маленького сайта приходится на город Остин (Техас), где живет автор. В главе 9 «Создание продвинутых дашбордов» я покажу еще одно интересное применение приложению Google Maps. Наше первое приложение  247 Установка приложений из файлов Нередко серверы Splunk не имеют выхода в интернет, особенно это характерно для дата-центров. Чтобы установить приложение в этом случае, выполните следующие шаги. 1.Загрузите приложение с сайта https://splunkbase.com. Файл будет иметь расширение .spl или .tgz. 2. Откройте в Splunk страницу Apps (Приложения). 3.Щелкните на кнопке Install app from the file (Установить приложение из файла). 4. В открывшейся форме выберите загруженный файл приложения. 5. Перезапустите Splunk, если приложение потребует этого. 6. Настройте приложение. Вот и все. Некоторые приложения включают форму с настройками. В этом случае вы увидите ссылку Setup (Настроить) рядом с приложением на странице Manager  Apps (Диспетчер  Приложения). Если что-то пойдет не так, обратитесь к автору приложения. В распределенных архитектурах приложение часто достаточно установить только на Search Head. Компоненты, необходимые индексерам, Search Head передаст автоматически. За более подробной информацией обратитесь к документации с описанием приложения. Наше первое приложение Для создания своего первого приложения используем один из шаблонов, входящих в состав Splunk. Для начала откройте страницу Apps (Приложения), как описывалось выше в этой главе, и щелкните на кнопке Create app (Создать приложение). Откроется страница, изображенная на рис. 8.8. Настройте поля, как описывается ниже. В поле Name (Имя) введите имя приложения Implementing Splunk App One. Оно будет отображаться на домашней странице в меню Apps (Приложения) и в заголовке, вверху слева, на странице приложения. В поле Folder name (Имя папки) введите is_app_one. Так будет называться каталог приложения в файловой системе, поэтому используйте только буквы, цифры и символы подчеркивания. В поле Version (Версия) введите 1.0 (это первая версия нашего приложения!). В поле Visible (Отображаемое) выберите Yes (Да). Когда вы будете создавать приложение, просто предоставляющее ресурсы другим приложениям, в этом поле лучше выбрать No (Нет), так как нет причин делать такое приложение видимым. В поле Author (Автор) введите свое имя, а в поле Description (Описание) – краткое описание приложения. 248  Работа с приложениями Рис. 8.8  Форма создания нового приложения В поле Template (Шаблон) выберите barebones. Шаблон barebones содержит элементы навигации и минимальную конфигурацию для приложения. Шаблон sample_app включает несколько примеров дашбордов и конфигураций. Поле Upload asset (Загрузить ресурсы) пока можно оставить пустым (мы займемся им позже). После щелчка на кнопке Save (Сохранить) можете вернуться назад на страницу Apps (Приложения) или на домашнюю страницу Splunk. На рис. 8.9 можно заметить, что вдобавок к приложениям Goggle Maps и MAXMIND, установленным выше, появилось приложение Implementing Splunk App One: Наше первое приложение  249 Рис. 8.9  В меню появилось приложение Implementing Splunk App One Теперь вновь созданное приложение можно использовать для создания запросов и дашбордов. Самый простой способ убедиться, что создаваемые объекты окажутся именно в нашем приложении, – взглянуть на заголовок окна перед их созданием. В данном случае заголовок нашего приложения выглядит, как показано на рис. 8.10. Рис. 8.10  Заголовок окна с нашим приложением Создадим дашборд с именем Errors, использовав следующие запросы (подроб ные инструкции по созданию дашбордов вы найдете в главе 5 «Дашборды на упрощенном XML»): error sourcetype="impl_splunk_gen" | timechart count by user error sourcetype="impl_splunk_gen" | top user error sourcetype="impl_splunk_gen" | top logger 250  Работа с приложениями В результате должен получиться дашборд, изображенный на рис. 8.11. Рис. 8.11  Вновь созданный дашборд Наш новый дашборд появится в навигационном меню, в разделе Dashboards (Дашборды), как показано на рис. 8.12. Рис. 8.12  Дашборд в навигационном меню, в разделе Dashboards (Дашборды) Настройка навигации  251 Настройка навигации Навигация контролируется XML-файлом, который доступен на странице Settings  User interface  Navigation menus (Настройки  Интерфейс пользователя  Меню навигации), как показано на рис. 8.13. Рис. 8.13  Страница Settings  User interface  Navigation menus (Настройки  Интерфейс пользователя  Меню навигации) Для каждого приложения доступен только один активный файл навигации, и он всегда называется default. Щелкнув на имени, вы увидите XML-код из шаблона barebones: <nav search_view="search" color="#65A637"> <view name="search" default='true' /> <view name="data_models" /> <view name="reports" /> <view name="alerts" /> <view name="dashboards" /> </nav> Обратите внимание, что если открыть файл навигации для другого приложения (search), вы увидите тот же самый код XML. В общем случае разметка XML имеет следующую структуру: nav view saved collection view a href saved divider collection Понять работу логики навигации, вероятно, лучше всего, изменяя код XML и наблюдая за тем, как это отражается на навигации. Перед этим обязательно сохраните резервную копию, потому что испортить XML-код очень легко и Splunk не поддерживает никаких механизмов управления версиями. Далее перечисляются некоторые общие сведения об элементе nav. Элементы, вложенные в nav, отображаются в полосе навигации. collection: теги, вложенные в collection, отображаются в виде меню или подменю. Если вложенный тег не производит никаких результатов, соответствующее меню не отображается. Тег divider всегда производит результат, поэтому его можно использовать, чтобы обеспечить гарантированное отображение меню. 252  Работа с приложениями view: этот тег представляет дашборд и имеет следующие атрибуты: – name – имя файла с дашбордом без расширения .xml; – первый элемент view с атрибутом default='true' будет загружаться автоматически при выборе приложения; – подпись для каждого элемента view определяется содержимым тега label в XML-коде дашборда, а не именем файла; – match="dashboard" выбирает все дашборды, имена файлов которых содержат dashboard; если вам понадобится сгруппировать дашборды, определите для себя правила наименований, чтобы группировка была более предсказуемой; – source="unclassified", по сути, означает «все элементы view, еще не добавленные в меню»; иными словами, все дашборды, явно не выбранные по имени, не соответствующие атрибуту match или не указанные в других тегах view. a href: позволяет включать стандартные HTML-ссылки в форме <a href= "http://a.b/c">; ссылки никак не преобразуются и отображаются как есть. saved: этот тег представляет хранимый запрос и имеет следующие атрибуты: – name – имя хранимого запроса; – match="report" выбирает все хранимые запросы с именами, включающими report; source="unclassified", по сути, означает «все запросы, не добавленные в меню»; иными словами, все запросы, явно не выбранные по имени, не соответствующие атрибуту match или не указанные в других тегах saved. Давайте настроим навигацию. Для этого внесем следующие изменения: создадим элемент для нашего дашборда Errors; добавим default='true', чтобы обеспечить автоматическую загрузку дашборда; добавим простые коллекции Views и Searches. Эти изменения отражены в следующем коде: <nav> <view name="errors" default='true' /> <view name="flashtimeline" /> <collection label="Views"> <view source="unclassified" /> </collection> <collection label="Searches"> <saved source="unclassified" /> </collection> </nav> На рис. 8.14 показано, как выглядит эта измененная полоса навигации. Настройка внешнего вида приложения  253 Рис. 8.14  Измененная полоса навигации В результате этих изменений все новые дашборды будут добавляться в меню Views, а все новые хранимые запросы – в меню Searches. Обратите внимание, что в меню Views появились пункты Advanced Charting и Google Maps. Ни один из этих дашбордов не является частью нашего приложения, но они видимы, потому что так настроены разрешения доступа к ним. Более подробно о разрешениях мы поговорим в разделе «Разрешения доступа к объектам». Настройка внешнего вида приложения Часто полезно придать приложению особый внешний вид, чтобы легко можно было понять, какое приложение в данный момент активно. Настройка значка запуска Значок запуска отображается на главной странице и на сайте Splunkbase (если вы решите поделиться своим приложением с другими). Значок – это PNG-файл с изображением размером 36×36 и именем appIcon.png. Для нашего примера я нарисовал простой значок (не судите строго мои навыки в изобразительном искусстве), изображенный на рис. 8.15. Рис. 8.15  Значок для приложения Implementing Splunk App One Чтобы задействовать этот значок, выполните следующие шаги. 1.Перейдите на страницу Apps  Manage Apps (Приложения  Управление приложениями). 2.Щелкните на ссылке Edit properties (Редактировать свойства) рядом с приложением Implementing Splunk App One. 3.Щелкните на ссылке Upload asset (Загрузить ресурс) и выберите файл значка. 4. Щелкните на кнопке Save (Сохранить). После этого значок появится на странице запуска, как показано на рис. 8.16. 254  Работа с приложениями Рис. 8.16  Значок появится на странице запуска Использование своих стилей оформления CSS В предыдущих версиях Splunk имелась возможность использовать таблицы стилей CSS для настройки внешнего вида приложений. Один из элементов, который изменялся особенно часто, – значок приложения. Поменять значок можно было, выполнив следующие шаги. 1.Создать файл с именем application.css. Этот файл автоматически загружается с каждым дашбордом, содержащимся в приложении. Содержимое этого файла будет представлено ниже в данном разделе. Начиная с версии Splunk 4.3.2, когда файл application.css впервые добавлялся в приложение, требовалось перезапустить систему, чтобы файл был доставлен пользователям. Последующие обновления файла не требовали перезапуска. 2.Создать файл с именем appLogo.png. В принципе, этому файлу можно дать любое имя, если явно сослаться на него в файле CSS. 3.Для каждого файла необходимо выполнить одну и ту же последовательность действий: 1)перейти на страницу Apps  Manage Apps (Приложения  Управление приложениями); 2)щелкнуть на ссылке Edit properties (Редактировать свойства) рядом с приложением; 3) щелкнуть на ссылке Upload asset (Загрузить ресурс) и выбрать файл; 4) щелкнуть на кнопке Save (Сохранить). Начиная с версии Splunk 6.2 такая возможность больше не поддерживается. Более подробную информацию об изменении этой возможности вы найдете на https://www.splunk.com. Использование своей разметки HTML В некоторых приложениях можно заметить статические блоки разметки HTML. Их можно использовать в любых дашбордах, простых и сложных. Своя разметка HTML в простых дашбордах В простом дашборде можно вставить элемент <html> внутрь элемента <row> (внутри тега dashboard, конечно) и добавить в него статическую разметку HTML. Настройка внешнего вида приложения  255 Например, после загрузки файла изображения с именем graph.png в любой дашборд можно добавить такой блок: <dashboard> <row> <html> <table> <tr> <td><img src="/static/app/is_app_one/graph.png" /></td> <td> <p>Lorem ipsum ...</p> <p>Nulla ut congue ...</p> <p>Etiam pharetra ...</p> </td> </tr> </table> </html> </row> <dashboard> Этот XML-код отобразит панель, изображенную на рис. 8.17. Рис. 8.17  Результат добавления статической разметки HTML Достоинство такого подхода – в отсутствии необходимости добавлять дополнительные файлы. А недостаток – невозможность конструировать документы HTML с использованием внешних программ. Также можно добавить свои классы CSS в application.css и использовать их в блоке с разметкой HTML. Включение файлов в сложные дашборды на стороне сервера Также есть возможность создавать статические страницы как документы HTML и ссылаться на них из других файлов в том же каталоге. Давайте создадим чуть 256  Работа с приложениями более сложную страницу, использующую изображение graph.png и стили из application.css. Для этого нам потребуется выполнить следующие шаги: 1) скопировать graph.png и application.css в каталог; 2) создать новый файл HTML с именем intro.html; 3) добавить в application.css какие-нибудь стили для нашей страницы; 4) загрузить новый файл HTML и измененный файл CSS; 5) создать дашборд, ссылающийся на файл HTML. Начнем с создания полноценного документа HTML в отдельном файле. Добавим в CSS ссылку на изображение и класс оформления текста: <html> <head> <link rel="stylesheet" type="text/css" href="application.css" /> </head> <body> <table> <tr> <td class="graph_image"></td> <td> <p class="lorem">Lorem ipsum ...</p> <p class="lorem">Nulla ut congue ...</p> <p class="lorem">Etiam pharetra ...</p> </td> </tr> </table> </body> </html> Сохраним классы оформления полосы навигации и добавим классы для оформления нашей страницы: .appHeaderWrapper h1 { display: none; } .appLogo { height: 43px; width: 155px; padding-right: 5px; float: left; background: url(appLogo.png) no-repeat 0 0; } .appHeaderWrapper { background: #612f00; } .lorem { font-style:italic; background: #CCCCCC; padding: 5px; } Настройка внешнего вида приложения  257 .graph_image { height: 306px; width: 235px; background: url(graph.png) no-repeat 0 0; } Если теперь открыть эту страницу в браузере, она должна выглядеть, как показано на рис. 8.18. Рис. 8.18  Вид вновь созданной страницы в браузере Чтобы подключить внешний документ HTML, нужно изменить продвинутый код XML дашборда. Более подробно этот вопрос мы рассмотрим в главе 9 «Создание продвинутых дашбордов». Сначала создадим простой дашборд: <view template="dashboard.html"> <label>Included</label>  <module name="ServerSideInclude" layoutPanel="panel_row1_col1"> <param name="src">intro.html</param> </module> </view> Код на упрощенном XML любого дашборда за кулисами преобразуется в продвинутый. Мы воспользуемся этой особенностью позже. Теперь загрузим файлы, как делали это в разделе «Настройка значка запус ка» выше. Страница должна выглядеть почти точно так же, когда мы открывали ее в браузере, с той лишь разницей, что вокруг панели появится рамка, как показано на рис. 8.19. 258  Работа с приложениями Рис. 8.19  Вид дашборда со встроенной страницей Отметим несколько важных моментов в этом простом примере. 1.Результат объединения ваших классов CSS со стилями, подключаемыми системой Splunk, может оказаться неожиданным. Избежать таких неожиданностей вам помогут инструменты, входящие в состав всех современных браузеров. 2.Определения навигации и заголовка дашборда были исключены из примера для краткости. Обычно они находятся в том месте, где я добавил комментарий . Это интересная возможность, которая может пригодиться в редких случаях, когда желательно убрать полосу навигации, чего нельзя сделать в упрощенном XML. 3.Статические файлы, такие как application.css, можно править непосредственно в файловой системе, и изменения в них будут вступать в силу немедленно. Это не относится к XML-файлам с определениями дашбордов. Подробнее о местоположении этих файлов мы поговорим в разделе «Структура каталога приложения». Разрешения доступа к объектам Почти все объекты в Splunk имеют определенные разрешения, связанные с ними. По сути, все разрешения сводятся к трем вариантам, перечисленным ниже. Private: только пользователь, создавший запрос, может видеть и использовать объект, и только в приложении, где этот объект создан. App: все пользователи имеют право читать и использовать объект в контексте приложения, содержащего его. Global: все пользователи имеют право читать и использовать объект в любом приложении. Разрешения доступа к объектам  259 Как разрешения влияют на навигацию Чтобы понять, как действуют разрешения, посмотрим на нашу навигацию. В приложении Implementing Splunk App One, созданном выше, навигация отображается, как показано на рис. 8.20. Рис. 8.20  Полоса навигации в приложении Implementing Splunk App One В коде XML, описывающем навигацию, который мы написали выше, это меню определяется так: <collection label="Views"> <view source="unclassified" /> </collection> Как видите, здесь не упоминается ни один из этих дашбордов. И вот откуда они взялись: Advanced Charting унаследован из приложения Search, и для него установлены разрешения Global; Included определен в этом приложении и имеет разрешения App; Google Maps унаследован из приложения Google Maps, и для него установлены разрешения Global. Если для дашборда или запроса установлены разрешения Private, рядом с его именем в навигационном меню появится зеленая точка. На дашборды и запросы, доступные в других приложениях, можно ссылаться по их именам. Например, большинство приложений, в том числе и наше, включает в меню Search (Поиск) ссылку на flashtimeline – имя, которое в коде XML дашборда определяется так: <view name="flashtimeline" /> Это позволяет использовать данный дашборд в контексте нашего приложения и гарантировать доступность всех других объектов, относящихся исключительно к этому приложению. Как разрешения влияют на другие объекты Почти все, что вам доведется создавать в Splunk, имеет разрешения. Чтобы увидеть все объекты, откройте страницу Settings  All configurations (Настройки  Все конфигурации), изображенную на рис. 8.21. 260  Работа с приложениями Рис. 8.21  Страница Settings  All configurations (Настройки  Все конфигурации) Все объекты со значением system в столбце App (Приложение) поставляются вместе с Splunk. Они находятся в каталоге $SPLUNK_HOME/etc/system. Разные типы конфигураций мы будем рассматривать в главе 11 «Настройка Splunk», однако сейчас я хотел бы подчеркнуть, что настройки в столбце Sharing (Совместное использование) влияют практически на все. Создавая новые объекты и конфигурации, важно обеспечить одинаковые разрешения на доступ ко всем связанным объектам. Например, в главе 7 «Расширенный поиск» мы определяли lookup. Все три составляющих определения lookup должны иметь одинаковые разрешения, иначе пользователи будут получать сообщения об ошибках. Исправление проблем с разрешениями Если вы столкнулись с проблемой, связанной с разрешениями, это почти наверняка связано с тем, что какой-то объект в поле Sharing (Совместное использование) имеет разрешение Private или App, в то время как требуется Global. Подобные ошибки часто допускаются, когда приложение создается в приложении Search, но предполагается, что оно должно быть доступно другим приложениям. Выполните следующие шаги, чтобы отыскать объект. 1.Откройте страницу Settings  All configurations (Настройки  Все конфигурации). 2.В раскрывающемся списке App context (Контекст приложения) выберите All (Все). 3.Отсортируйте список по столбцу Sharing (Совместное использование), щелкнув на заголовке дважды, чтобы объекты с разрешениями Private оказались в начале списка. Структура каталога приложения  261 4.Если таких объектов слишком много, отфильтруйте список, добавив условия в строку поиска в правом верхнем углу, или измените значение в раскрывающемся списке App context (Контекст приложения). 5.Исправьте разрешения, установив нужные флажки. В большинстве случаев достаточно разрешений, показанных на рис. 8.22. Рис. 8.22  Исправьте разрешения Будьте осторожны с выбором All apps (Всем приложениям). Например, определяя lookup, обычно принято открывать доступ к файлу с lookup-таблицей и определению lookup всем приложениям. Это даст возможность использовать lookup в других приложениях. К автоматическому lookup общий доступ открывается реже, потому что это может оказать нежелательное влияние на производительность других приложений. Структура каталога приложения Если в ваши обязанности входит не только конструирование запросов и дашбордов, рано или поздно вам понадобится редактировать файлы прямо в файловой системе. Все приложения располагаются в каталоге $SPLUNK_HOME/ etc/apps/. В UNIX по умолчанию Splunk устанавливается в каталог /opt/splunk, в Windows – в каталог C:\Program Files\Splunk. Имя этого каталога присваивается переменной $SPLUNK_HOME при запуске. Рассмотрим подкаталоги в этом каталоге, наиболее интересные для нас. appserver: содержит файлы, составляющие веб-приложение Splunk. Файлы, которые мы загружали в предыдущих разделах этой главы, сохраняются в каталоге appserver/static. 262  Работа с приложениями bin: здесь хранятся скрипты команд. Эти скрипты перечисляются в файле commands.conf. Часто в этот каталог помещают скрипты для загрузки данных; несмотря на то что эти скрипты могут находиться где угодно, считается хорошей практикой хранить их все в одном месте, в папке bin. default и local: в этих двух каталогах содержится подавляющее большинство конфигурационных файлов приложений. Обсуждать эти файлы и порядок их объединения мы будем в главе 11 «Настройка Splunk». Вот некоторые дополнительные сведения о них: – вновь создаваемые объекты, недоступные за пределами приложения, помещаются в: $SPLUNK_HOME/etc/users/USERNAME/APPNAME/local – после присваивания объекту разрешений App или Global объект перемещается в каталог: $SPLUNK_HOME/etc/APPNAME/local – файлы в каталоге local имеют преимущество перед их эквивалентами в каталоге default; – дашборды помещаются в каталог (default|local)/data/ui/views; – определения навигации помещаются в каталог (default|local)/data/ui/ nav. Редактируя файлы вручную, я обычно помещаю их в каталог local, если не предполагаю распространять приложение. Подробнее об этом мы поговорим в разделе «Добавление приложения в Splunkbase». lookups: в этот каталог помещаются определения подстановок. Затем они перечисляются в файле (default|local)/transforms.conf; metadata: файлы default.meta и local.meta в этом каталоге сообщают системе Splunk разрешения на доступ к конфигурационным файлам в этом приложении. Обычно эти настройки лучше править вручную, чем с помощью веб-интерфейса. Давайте заглянем в каталог is_app_one нашего приложения, созданного выше: appserver/static/appIcon.png appserver/static/application.css appserver/static/appLogo.png appserver/static/graph.png appserver/static/intro.html bin/README default/app.conf default/data/ui/nav/default.xml default/data/ui/views/README local/app.conf local/data/ui/nav/default.xml local/data/ui/views/errors.xml local/data/ui/views/included.xml local/savedsearches.conf Структура каталога приложения  263 local/viewstates.conf metadata/default.meta metadata/local.meta Файл metadata/default.meta и все файлы в каталоге default/ были получены из шаблона приложения. Все остальные файлы были созданы нами. Кроме файлов PNG, все остальные являются простыми текстовыми файлами. Добавление приложения в Splunkbase Splunkbase (https://splunkbase.splunk.com/) – это замечательный сайт, поддерживаемый сообществом, объединяющий пользователей и разработчиков Splunk и помогающий им распространять приложения для Splunk. На Splunkbase можно найти полностью автономные приложения, расширения разного рода и просто примеры кода. Подготовка приложения Прежде чем выгрузить приложение, убедитесь, что для всех объектов установлены правильные разрешения, переместите файлы в каталог default и отредактируйте конфигурационный файл app.conf. Установка разрешений Чтобы увидеть разрешения, присвоенные всем объектам в приложении, пе рейдите на страницу Settings  All configurations (Настройки  Все конфигурации) и в раскрывающемся списке App context (Контекст приложения) выберите вариант, как показано на рис. 8.23. Рис. 8.23  Выберите контекстное приложение В автономных приложениях, подобных нашему, все объекты должны иметь разрешения App (в столбце Sharing (Совместное использование)). Если ваше приложение экспортирует подстановки или команды, они должны иметь разрешения Global. Очистка каталогов Прежде чем выгрузить приложение, переместите все файлы из каталога local в каталог default. Это важно, потому что все изменения, вносимые пользователем, будут сохраняться в каталоге local. 264  Работа с приложениями После обновления приложения все его файлы (кроме локальных) будут замещены, что приведет к потере изменений, добавленных пользователем. Следующие команды Unix иллюстрируют, что нужно сделать. 1. Скопировать приложение в другой каталог, например /tmp: cp -r $SPLUNK_HOME/etc/apps/is_app_one /tmp/ 2.Переместить файлы из каталога local в каталог default. Если файлы .xml можно просто переместить, то с файлами .conf дело немного сложнее, мы должны объединить их вручную: cd /tmp/is_app_one mv local/data/ui/nav/*.xml default/data/ui/nav/ mv local/data/ui/views/*.xml default/data/ui/views/ # переместит файлы *conf, но не заменит одноименные файлы в default mv -n local/*conf default/ 3.Объединить все файлы .conf, оставшиеся в каталоге local. В данном случае у нас есть только один такой файл – app.conf: local/app.conf default/app.conf [ui] [launcher] [package] check_for_updates = 1 [install] is_configured = 0 [ui] is_visible = 1 label = Implementing Splunk App One [launcher] author = description = version = 1.0 Объединение конфигураций производится аддитивным способом: любые значения из файла в local добавляются к значениям в файле в default. Ниже показан результат объединения, получившийся в данном случае: [install] is_configured = 0 [ui] Working with Apps [ 198 ] is_visible = 1 label = Implementing Splunk App One [launcher] author = description = version = 1.0 Структура каталога приложения  265 [package] check_for_updates = 1 4.Сохранить объединенную конфигурацию в default/app.conf и удалить local/app.conf. Более подробно объединение конфигураций мы рассмотрим в главе 11 «Настройка Splunk». Упаковка приложения Перед упаковкой нужно поправить несколько значений в default/app.conf и только потом создавать архив. Отредактируем файл default/app.conf, как показано ниже: [install] is_configured = 0 build = 1 [ui] is_visible = 1 label = Implementing Splunk App One [launcher] author = My name description = My great app! version = 1.0 [package] check_for_updates = 1 id = is_app_one Идентификатор приложения и номер сборки (id и build) используются во всех URL, и номер сборки обязательно нужно увеличивать, чтобы предотвратить использование браузером старой версии из кеша. Кроме того, идентификатор id должен быть уникальным в Splunkbase – если это не так, вы получите предупреждение. Затем нужно создать архив .tar, сжатый утилитой gzip. При использовании современных версий tar эта задача решается просто: cd /tmp tar -czvf is_app_one.tgz is_app_one # при желании можно поменять расширение на spl mv is_app_one.tgz is_app_one.spl Более полное обсуждение, включая подсказки и рекомендации, вы найдете в документации Splunk (https://dev.splunk.com/view/webframework-developapps/ SP-CAAAEMY). Выгрузка приложения После создания архива осталось лишь отправить его в Splunkbase. В версии 7.0 для отправки приложения достаточно открыть в браузере страницу https:// splunkbase.splunk.com/new/ и следовать подсказкам, как показано на рис. 8.24. 266  Работа с приложениями Рис. 8.24  Инструкции на странице https://splunkbase.splunk.com/new/ Если ваше приложение соответствует всем критериям, после одобрения персоналом Splunk оно появится в Splunkbase, готовое для загрузки другими. Чтобы ускорить одобрение приложения, воспользуйтесь утилитой AppInspect, которая оценит соответствие приложения набору критериев Splunk, чтобы убедиться в его ка честве и надежности. Самостоятельное управление приложениями Как было показано в этой главе, приложения Splunk состоят из дашбордов, отчетов, уведомлений и процессов, оптимизированных для решения определенной задачи. Расширения Splunk – это разновидность приложений, предлагающих конкретные функции для других приложений, такие как извлечение данных, отображение данных или хранимые запросы и макросы. В облачном окружении Splunk Cloud установить можно только предварительно одобренные приложения и расширения. Одобренными называют приложения, которые были проверены персоналом Splunk на соответствие требованиям безопасности в Splunk Cloud. После развертывания в облачном окружении управление приложениями начинается с создания заявки в службу поддержки. Иногда для обработки заявки требуется некоторое время, а бывает, что надо даже оплатить услугу. Решить эту проблему можно с помощью идеи самостоятельного управления и инструмента Splunk Packaging Toolkit. Splunk Packaging Toolkit – это инструмент для разработки, упаковки и проверки приложений Splunk, упрощающий управление приложениями и помогающий произвести установку, настройку и обновление. Вот как он описывается в документации Splunk: «Инструмент Packaging Toolkit обеспечивает поддержку всех этапов управления жизненным циклом приложения Splunk. Благодаря ему разработчики приложений Splunk могут сосредоточиться на создании приложений без учета разнообразия топологий развертывания или деталей процесса развертывания». Итоги  267 Механизмы управления приложениями в облаке теперь позволяют обновлять приложение напрямую, не полагаясь на службу поддержки и без создания заявки, в точности как в локальной установке. Дополнительно в версии 7.0 появилось большое количество приложений, одобренных разработчиками Splunk для использования в облаке, а также несколько головных конфигураций поиска. Итоги В этой главе мы рассмотрели установку, создание и настройку приложений, а также настройку разрешений на доступ к ним. Понятие приложения имеет особый смысл в Splunk. Под ним понимается простой каталог с файлами, преследующими самые разные цели. Надеюсь, нам удалось достаточно охватить основы приложений, чтобы вы могли начать создавать свои замечательные приложения. В последующих главах мы будем создавать еще более сложные объекты, а также писать код, расширяющий Splunk новыми уникальными возможностями. Приводя текст книги в соответствие с последней версией Splunk, мы также добавили раздел, описывающий возможность самостоятельного управления приложениями. В следующей главе мы погрузимся в знакомство с продвинутыми дашбордами и посмотрим, что доступно с использованием стандартной конфигурации Splunk и что могут дать некоторые популярные приложения. Глава 9 Создание продвинутых дашбордов В главе 5 «Дашборды на упрощенном XML» мы познакомились с приемами создания дашбордов с использованием упрощенного XML. Сначала мы воспользовались мастером, входящим в состав Splunk, а затем скорректировали получившийся код XML. Столкнувшись с ограничениями упрощенного XML, вы сможете преодолеть их, углубившись в продвинутую разметку XML. В этой главе мы рассмотрим продвинутые приемы построения дашбордов на XML и следующие темы: символ вертикальной черты; использование top для вывода наиболее частых значений полей; использование stats для агрегирования значений; использование chart для преобразования данных; использование timechart для вывода значений на временном графике; работа с полями. Причины использования продвинутого XML Далее перечислено несколько причин использования продвинутого XML. Полный контроль над оформлением: продвинутый XML дает полный контроль над размещением и оформлением элементов форм, а также имеется возможность более точного управления размещением и отображением. Создание своих детализаций: определить свою логику детализации таблиц и диаграмм можно только с использованием продвинутого XML. Доступность дополнительных параметров: модули в упрощенном XML в действительности используют модули из продвинутого XML, но при этом скрывают многие параметры. Иногда бывает желательно отключить какие-то особенности, а это возможно только при использовании продвинутого XML. Доступность дополнительных модулей: существуют модули, недоступные из упрощенного XML, например сама строка поиска. Все допол- Процесс разработки  269 нительные модули, предлагаемые приложениями из Splunkbase, например Google Maps, доступны только из продвинутого XML. Причины отказаться от использования продвинутого XML Существует также ряд причин не использовать продвинутый XML. Некоторые из них перечислены ниже. Крутая кривая обучения: в зависимости от привычных вам технологий и, может быть, от того, насколько понятной покажется вам эта глава, кривая обучения может оказаться очень крутой. Отсутствие прямого контроля над разметкой HTML: если вы хотите создать определенную разметку HTML из результатов, это может оказаться не так просто, как вы могли бы надеяться. Помимо написания своего модуля, вам придется действовать в рамках параметров, предлагаемых существующими модулями, изменять CSS с помощью приложения или HTML-код с использованием JavaScript. Отсутствие прямого контроля над логикой: если вам нужно, чтобы щелчки на ячейках таблицы генерировали определенные события, особенно с использованием других значений в той же строке, вы сможете добиться желаемого, только изменяя документ с помощью JavaScript. Такая возможность есть, но она плохо документирована. Примеры можно найти на https://splunkbase.splunk.com, в ответах на вопросы и в примерах приложений. Альтернативное решение можно увидеть в модуле customBehaviors, в стороннем приложении Sideview Utils (LGPL). Если у вас имеются конкретные требования к размещению компонентов на экране или к логике выполнения, возможно, вам лучше подойдет один из Splunk API, доступных https://dev.splunk.com, используя которые, вы сможете писать приложения на наиболее удобном вам языке. Процесс разработки Создавая дашборды, я обычно придерживаюсь следующей последовательности этапов. 1. Создать нужные запросы. 2.Добавить запросы в дашборд на упрощенном XML. Максимально настроить дашборд с помощью инструментов с графическим интерфейсом. Если возможно, полностью завершить графическое оформление дашборда на этом этапе. 3.Если необходимы элементы ввода, преобразовать дашборд в форму. Если возможно, реализовать всю логику работы с использованием упрощенного XML. 270  Создание продвинутых дашбордов 4.Преобразовать код дашборда на упрощенном XML в код на продвинутом XML. Обратное преобразование невозможно, поэтому это преобразование желательно откладывать на как можно более поздний срок и прибегать к нему, только если оно действительно необходимо. 5. Отредактировать код дашборда на продвинутом XML. Идея состоит в том, чтобы максимально использовать преимущества вебинтерфейса Splunk, дабы после преобразования вам пришлось как можно меньше заниматься ручной работой. Шаги 1–3 мы уже рассмотрели в предыдущих главах. Шаг 4 будет рассмотрен в разделе «Преобразование упрощенного XML в продвинутый». Структура продвинутого XML Прежде чем перейти к знакомству с доступными модулями, рассмотрим структуру самого кода XML и пару идей, лежащих в его основе. Код документов на продвинутом XML имеет следующую структуру: view module param ... module ... Главная идея такой организации XML в Splunk состоит в том, что влияние верхних модулей распространяется вниз по потоку на дочерние модули. Это очень важная идея. Структура XML практически не имеет ничего общего со структурой размещения визуальных элементов и полностью связана с потоком данных. Рассмотрим следующий простой пример: <view template="dashboard.html"> <label>Chapter 9, Example 1</label> <module name="HiddenSearch" layoutPanel="panel_row1_col1" autoRun="True"> <param name="earliest">-99d</param> <param name="search">error | top user</param> <module name="SimpleResultsTable"></module> </module> </view> Этот документ определяет дашборд, изображенный на рис. 9.1, с единственной панелью. Структура продвинутого XML  271 Рис. 9.1  Простой дашборд с единственной панелью Пройдемся по этому коду строка за строкой. <view: внешний открывающий тег. С этого тега начинаются все дашборды на продвинутом XML. template="dashboard.html">: определяет шаблон HTML. Шаблоны, определяющие внешний вид дашбордов, хранятся в следующем каталоге: $SPLUNK_HOME/share/splunk/search_mrsparkle/templates/view/ Кроме всего прочего, шаблоны определяют панели, сослаться на которые можно в атрибуте layoutPanel. <label>Chapter 9, Example 1</label>: определяет метку для использования в полосе навигации. <module: начинает объявление первого модуля. name="HiddenSearch": имя используемого модуля. Модуль HiddenSearch запускает поиск, но ничего не отображает, полагаясь в этом на дочерние модули. layoutPanel="panel_row1_col1": определяет место для отображения панели в дашборде. Наличие этого атрибута в определении модуля, который ничего не выводит, может показаться странным, тем не менее layoutPanel должен быть определен в каждом дочернем модуле, вложенном в тег view. Подробнее об этом рассказывается в разделе «Знакомство с layoutPanel». autoRun="True">: без этого атрибута поиск не будет запущен сразу после загрузки дашборда, вместо этого дашборд будет ждать, пока пользователь не даст команду с помощью элементов формы. Поскольку в данном случае элементы формы отсутствуют, нужно добавить этот атрибут, чтобы увидеть результаты. 272  Создание продвинутых дашбордов <param name="earliest">-99d</param>: очень важно указать значение для параметра earliest, иначе запрос по умолчанию просмотрит данные за все время. Значения param действуют только в теге module, где они определены. <param name="search">error | top user</param>: фактический запрос. <module name="SimpleResultsTable"></module>: этот модуль отображает прос тую таблицу с результатами, произведенными родительским модулем. Поскольку данный модуль не имеет вложенных тегов param, он использует настройки по умолчанию. </module>: тег, закрывающий определение модуля HiddenSearch. Он требуется не только, чтобы обеспечить допустимость кода XML, но также ограничивает область действия закрываемого модуля. Повторю еще раз, что только модули, вложенные в HiddenSearch, получат произведенные им результаты. </view>: закрывает документ. Это очень простой дашборд. В нем отсутствуют навигация, элементы форм, состояние задания и поддержка детализации. Добавлять все эти элементы вручную довольно сложно. К счастью, можно сконструировать дашборд на упрощенном XML, преобразовать в продвинутый и потому отредактировать полученный код XML. Преобразование упрощенного XML в продвинутый Теперь вернемся к одному из дашбордов, созданных в главе 5 «Дашборды на упрощенном XML – errors_user_form". Мы создали его до нашего первого приложения, поэтому он остается в стандартном приложении Search. Просто чтобы освежить память, ниже приводится определение дашборда на упрощенном XML: <?xml version='1.0' encoding='utf-8'?> <form> <fieldset> <input type="text" token="user"> <label>User</label> </input> <input type="time" /> </fieldset> <label>Errors User Form</label> <row> <chart> <searchString> sourcetype="impl_splunk_gen" loglevel=error user="$user$" | timechart count as "Error count" by network </searchString> Преобразование упрощенного XML в продвинутый  273 <title> Dashboard - Errors - errors by network timechart </title> <option name="charting.chart">line</option> </chart> </row> <row> <chart> <searchString> sourcetype="impl_splunk_gen" loglevel=error user="$user$" | bucket bins=10 req_time | stats count by req_time </searchString> <title> Error count by req_times </title> <option name="charting.chart">pie</option> </chart> <chart> <searchString> sourcetype="impl_splunk_gen" loglevel=error user="$user$" | stats count by logger </searchString> <title>Errors by logger</title> <option name="charting.chart">pie</option> </chart> </row> <row> <event> <searchString> sourcetype="impl_splunk_gen" loglevel=error user="$user$" </searchString> <title>Error events</title> <option name="count">10</option> <option name="displayRowNumbers">true</option> <option name="maxLines">10</option> <option name="segmentation">outer</option> <option name="softWrap">true</option> </event> </row> </form> В упрощенном XML размещение визуальных элементов и поток логики тесно связаны друг с другом. Прежде чем отобразить такой дашборд, Splunk динамически преобразует его упрощенный код XML в продвинутый. Увидеть код на продвинутом XML можно, добавив ?showsource=advanced в конец URL: http://localhost:8000/en-US/app/is_app_one/errors?showsource=advanced В результате Splunk отобразит страницу, как показано на рис. 302 (в ранних версиях Splunk в ответ на параметр showsource=1 выводилась немного другая страница): 274  Создание продвинутых дашбордов Рис. 9.2  Страница с URL, включающим параметр showsource=1 Внизу страницы имеется текстовое поле с исходным кодом XML, как показано на рис. 9.3. Рис. 9.3  Текстовое поле с исходным кодом XML Преобразование упрощенного XML в продвинутый  275 Ниже приводится немного сокращенная версия кода дашборда errors_user_ form: <view ... template="dashboard.html"> <label>Errors User Form</label> <module name="AccountBar" layoutPanel="appHeader"/> <module name="AppBar" layoutPanel="navigationHeader"/> <module name="Message" layoutPanel="messaging"> ...<module name="Message" layoutPanel="messaging"> ...<module name="TitleBar" layoutPanel="viewHeader"> ...<module name="ExtendedFieldSearch" layoutPanel="viewHeader"> <param name="replacementMap"> <param name="arg"> <param name="user"/> </param> </param> <param name="field">User</param> <param name="intention"> ... <module name="TimeRangePicker"> <param name="searchWhenChanged">False</param> <module name="SubmitButton"> <param name="allowSoftSubmit">True</param> <param name="label">Search</param> <module name="HiddenSearch" layoutPanel="panel_row1_col1" group="Dashboard - Errors - errors by network timechart" autoRun="False"> <param name="search"> sourcetype="impl_splunk_gen" loglevel=error user="$user$" | timechart count as "Error count" by network </param> <param name="groupLabel"> Dashboard - Errors - errors by network timechart </param> <module name="ViewstateAdapter"> <param name="suppressionList"> <item>charting.chart</item> </param> <module name="HiddenFieldPicker"> <param name="strictMode">True</param> <module name="JobProgressIndicator"> <module name="EnablePreview"> <param name="enable">True</param> <param name="display">False</param> <module name="HiddenChartFormatter"> <param name="charting.chart">line</param> <module name="JSChart"> <param name="width">100%</param> <module name="Gimp"/> 276  Создание продвинутых дашбордов <module name="ConvertToDrilldownSearch"> <module name="ViewRedirector"> ... </module> <module name="ViewRedirectorLink"> ... </module> <module name="HiddenSearch" layoutPanel="panel_row2_col1" group="Error count by req_times" autoRun="False"> <param name="search"> sourcetype="impl_splunk_gen" loglevel=error user="$user$" | bucket bins=10 req_time | stats count by req_time </param> <param name="groupLabel">Error count by req_times</param> ... </module> <module name="HiddenSearch" layoutPanel="panel_row2_col2" group="Errors by logger" autoRun="False"> <param name="search"> sourcetype="impl_splunk_gen" loglevel=error user="$user$" | stats count by logger </param> <param name="groupLabel">Errors by logger</param> ... </module> <module name="HiddenSearch" layoutPanel="panel_row3_col1" group="Error events" autoRun="False"> <param name="search"> sourcetype="impl_splunk_gen" loglevel=error user="$user$" </param> <param name="groupLabel">Error events</param> <module name="ViewstateAdapter"> ... <module name="HiddenFieldPicker"> ... <module name="JobProgressIndicator"/> <module name="Paginator"> <param name="count">10</param> ... <module name="EventsViewer"> ... <module name="Gimp"/> ... </module> ... </view> Этот XML-код содержит много ненужных нам деталей, но, к счастью, удалять код проще, чем писать! Логика модулей  277 Логика модулей Главная идея, стоящая за вложением модулей друг в друга, – родительские модули (выше в потоке) влияют на дочерние модули (ниже в потоке). Вот как выглядит полный поток логики для первой панели: <module name="ExtendedFieldSearch"> <module name="TimeRangePicker"> <module name="SubmitButton"> <module name="HiddenSearch"> <module name="ViewstateAdapter"> <module name="HiddenFieldPicker"> <module name="JobProgressIndicator"> <module name="EnablePreview"> <module name="HiddenChartFormatter"> <module name="JSChart"> <module name="ConvertToDrilldownSearch"> <module name="ViewRedirector"> <module name="ViewRedirectorLink"> Список модулей, установленных на сервере Splunk, можно найти по URL /modules. В моем случае полный URL имеет следующий вид: http://localhost:8000/en-US/modules Давайте пройдемся по этим модулям в порядке их следования и обсудим их назначение. ExtendedFieldSearch: создает текстовое поле для записи. Этот модуль имеет обширный набор параметров, представляющих, пожалуй, самые сложные аспекты intentions в продвинутом XML. Intentions оказывают влияние на дочерние модули, в частности на модуль HiddenSearch. Мы подробнее рассмотрим их в разделе «Использование intentions». TimeRangePicker: реализует стандартный виджет выбора времени. Влияет на дочерние модули HiddenSearch, для которых не указано время в параметрах или в самом запросе. Времена определяются дочерними модулями в следующем порядке: – если имеется, используется время, указанное в самом запросе; – иначе используется время, указанное в параметрах earliest и latest; – иначе берется значение, определяемое модулем TimeRangePicker. SubmitButton: отображает кнопку Search (Искать), щелчок на которой запускает любые дочерние модули поиска. HiddenSearch: как мы уже видели выше, этот модуль выполняет запрос и формирует список событий для модулей, находящихся ниже в потоке логики. В данном случае параметр autoRun имеет значение false, поэтому запрос выполняется только по команде пользователя. ViewstateAdapter: в Splunk имеется объект с настройками, который описывает параметры представления (viewstate), выбранные пользователем в веб-интерфейсе, такие как порядок сортировки, размер страницы или 278  Создание продвинутых дашбордов тип диаграммы. Всякий раз, когда пользователь изменяет настройки диаграммы или выбирает другой диапазон времени, создается новый объект с настройками и сохраняется в Splunk. Этот модуль используется для доступа к существующему объекту с настройками представления или для подавления выбранных настроек. Если производится подавление каких-то настроек, дочерние модули будут использовать значения по умолчанию или заданные явно. На практике этот модуль используется в основном только для хранимых запросов, с предопределенными настройками представления. HiddenFieldPicker: этот модуль ограничивает перечень полей, доступных модулям ниже в потоке. Его удобно использовать для запросов, возвращающих много полей, когда требуется только ограниченное их подмножество. Ограничивает перечень полей, отображаемых в списках событий, или столбцов в таблицах. Этот модуль редко используется на практике. JobProgressIndicator: отображает индикатор прогресса (хода выполнения операции) в течение выполнения задания. В данном случае, в соответствии с его местоположением в XML, этот модуль будет отображать индикатор над результатами. Этот модуль не влияет на последующие модули, поэтому его можно вставлять куда угодно. EnablePreview: этот модуль позволяет организовать вывод и обновление предварительных результатов прямо в процессе поиска. Стандартные модули Splunk по умолчанию выводят и обновляют результаты в ходе поиска, и применение EnablePreview позволяет переопределить такое поведение. Данный модуль не влияет на последующие модули, поэтому его можно вставлять куда угодно. Запрет отображения предварительных результатов может значительно увеличить производительность, но при этом пользователь не увидит никакой информации до завершения запроса, что может вызывать у него неприятные психологические переживания, особенно если запрос выполняется очень долго. HiddenChartFormatter: определяет настройки диаграммы. Эти настройки влияют на поведение любых дочерних модулей, ответственных за отображение диаграмм. JSChart: рисует диаграмму с использованием JavaScript. В версиях до Splunk 4.3 все диаграммы рисовались с использованием Flash. Модуль FlashChart все еще входит в состав Splunk для обратной совместимости. ConvertToDrilldownSearch: получает значения из события в родительском модуле, на котором пользователь произвел щелчок, и создает запрос, опираясь на запрос, с помощью которого были получены результаты. Этот модуль не всегда позволяет добиться желаемого, особенно если родительский запрос очень сложен. Далее мы увидим, как создавать свои запросы для получения более детальной информации. Знакомство с layoutPanel  279 ViewRedirector: обычно получает запрос из вышестоящего модуля и делегирует отображение его результатов представлению, указанному в параметре viewTarget, – обычно flashtimeline, но это может быть любой другой дашборд. Запрос оказывает влияние на модули HiddenSearch и SearchBar. ViewRedirectorLink: открывает новую страницу поиска с результатами, найденными этим модулем. Обобщая вышесказанное, можно утверждать, что этот поток модулей делает следующее: генерирует события; изменяет запрос; изменяет поведение нижеследующего модуля; выводит элемент в дашборде; обрабатывает щелчки мышью. В модуле также можно: организовать постобработку событий, найденных запросом; добавить в дашборд свой код на JavaScript. Знакомство с layoutPanel В дашборде на продвинутом XML атрибут layoutPanel определяет панель для отображения модуля. Такое разделение логики и пользовательского интерфейса может оказаться очень удобной возможностью. Благодаря ей, например, сгенерированные запросом данные можно повторно использовать в нескольких разных модулях, но отображать результаты в разных местах на странице. Вот некоторые правила выбора значения для этого атрибута: атрибут layoutPanel должен присутствовать во всех прямых потомках <view>; атрибут layoutPanel может присутствовать в тегах потомков; если модуль не имеет атрибута layoutPanel, используется значение из ближайшего вышестоящего модуля; модули, отображающие какую-то информацию в веб-интерфейсе, добавляются в соответствующие атрибуты layoutPanel в порядке их появления в XML; результаты работы модуля выводятся в панель, с которой они связаны; большинство модулей занимает всю ширину панели, но некоторые имеют ограниченную ширину, и такие модули упорядочиваются слева направо. Заглянув в наш код XML, можно увидеть следующие элементы с атрибутом layoutPanel: <module name="AccountBar" layoutPanel="appHeader"/> <module name="AppBar" layoutPanel="navigationHeader"/> <module name="Message" layoutPanel="messaging"> <module name="TitleBar" layoutPanel="viewHeader"> 280  Создание продвинутых дашбордов <module name="ExtendedFieldSearch" layoutPanel="viewHeader"> <module name="TimeRangePicker"> <module name="SubmitButton"> <module name="HiddenSearch" layoutPanel="panel_row1_col1">... <module name="HiddenSearch" layoutPanel="panel_row2_col1">... <module name="HiddenSearch" layoutPanel="panel_row2_col2">... <module name="HiddenSearch" layoutPanel="panel_row3_col1"> ... В первой половине в атрибуте layoutPanel указываются панели, которые определены в оформлении страницы. В них отображаются сведения из учетной записи, элементы навигации и сообщения пользователю. Второй набор модулей создает заголовок и элементы формы. Обратите внимание, что TimeRangePicker и SubmitButton не имеют атрибута layoutPanel – они наследуют его из ExtendedFieldSearch. Панели с результатами начинаются с модуля HiddenSearch. Все потомки каждого из этих модулей унаследуют их значения атрибута layoutPanel. Размещение панелей Для определения панелей в своих дашбордах вы почти всегда будете использовать атрибут layoutPanel, определяя значения в формате panel_rowX_colY. В данном случае наши модули размещают панели, как показано на рис. 9.4. Рис. 9.4  Размещение панелей в нашем дашборде В версии дашборда на упрощенном XML размещение панелей определялось непосредственно: <row> <chart></chart> </row> <row> <chart></chart> <chart></chart> </row> <row> <event></event> </row> Этот простой код XML транслируется в следующую структуру: <row> <chart></chart> == panel_row1_col1 </row> Повторное использование запроса  281 <row> <chart></chart> == panel_row2_col1 <chart></chart> == panel_row2_col2 </row> <row> <event></event> == panel_row3_col1 </row> В данном случае можно использовать еще одно расширение, _grp1, и с его помощью создавать столбцы внутри панелей. Мы попробуем использовать его в разделе «Создание своих детализаций». Повторное использование запроса Чтобы продемонстрировать возможность отделения пользовательского интерфейса от логики, рассмотрим пример повторного использования запроса для заполнения таблицы и диаграммы. Ниже приводится код на продвинутом XML для этого примера: <view template="dashboard.html"> <label>Chapter 9 - Reusing a query</label> <module name="StaticContentSample" layoutPanel="panel_row1_col1"> <param name="text">Text above</param> </module> <module name="HiddenSearch" layoutPanel="panel_row1_col1" autoRun="True"> <param name="search"> sourcetype="impl_splunk_gen" loglevel=error | top user </param> <param name="earliest">-99d</param> <module name="HiddenChartFormatter"> <param name="charting.chart">pie</param> <module name="JSChart"></module> <module name="StaticContentSample" layoutPanel="panel_row1_col1">  <param name="text">Text below</param> </module> </module> <module name="SimpleResultsTable" layoutPanel="panel_row1_col2"></module> </module> </view> Этот код XML отображает дашборд, изображенный на рис. 9.5. 282  Создание продвинутых дашбордов Рис. 9.5  Внешний вид дашборда с таблицей и диаграммой Вот несколько замечаний относительно кода XML: данные, которые производит HiddenSearch, используются двумя его дочерними модулями; JSChart наследует layoutPanel="panel_row1_col1" от HiddenSearch; SimpleResultsTable имеет свой атрибут layoutPanel со значением panel_ row1_col2, поэтому таблица отображается справа; оба модуля StaticContentSample имеют атрибут layoutPanel="panel_row1_ col1" и поэтому отображаются в одной панели с диаграммой. Даже находясь в XML на разных уровнях, они отображаются в порядке их следования в XML. Использование intentions Intentions1 позволяют воздействовать на запросы ниже с использованием значений, полученных из других модулей, например из полей или результатов щелчка. Существует несколько доступных типов intention, но мы охватим только два из них, наиболее часто используемых на практике, stringreplace и addterm. Примеры использования других типов intentions можно найти в приложении с примерами пользовательского интерфейса (UI examples app) на http:// splunkbase.com. stringreplace Это, пожалуй, самый часто используемый тип intention, отображающийся непосредственно в действии замены переменной, доступный только в упрощенном XML. Рассмотрим наше поле для ввода строки поиска из примера дашборда на продвинутом XML: <module name="ExtendedFieldSearch" layoutPanel="viewHeader"> <param name="replacementMap"> 1 В переводе на русский язык – цель, намерение, замысел. – Прим. перев. Использование intentions  283 <param name="arg"> <param name="user"/> </param> </param> <param name="field">User</param> <param name="intention"> <param name="name">stringreplace</param> <param name="arg"> <param name="user"> <param name="fillOnEmpty">True</param> </param> </param> </param> Рассмотрим по порядку теги param: field: метка поля, отображаемая в дашборде; replacementMap: этот параметр определяет имя переменой, создаваемой модулем ExtendedFieldSearch. Я уже говорил, что вложенность ничего не значит, и мы должны просто скопировать весь блок XML, ничего не меняя, кроме значения самого глубоко вложенного тега param, в данном случае user; intention: intentions имеют определенную структуру, описывающую строительные блоки для запросов. В случае с stringreplace (наиболее распространенный вариант использования) мы фактически можем скопировать весь код XML и снова ничего не менять, кроме значения тега param на третьем уровне, в данном случае user. Значение fillOnEmpty определяет необходимость подстановки, когда переменная user пуста; весь этот код просто требует в любых запросах заменить $user$ значением входного поля. Первое значение HiddenSearch имеет следующий вид: <module name="HiddenSearch" ... <param name="search"> sourcetype="impl_splunk_gen" loglevel=error user="$user$" | timechart count as "Error count" by network </param> На место $user$ Splunk подставит значение входного поля и запустит запрос. Если вам интересно увидеть, что происходит в действительности, вставьте модуль SearchBar в элемент формы, и он отобразит получившийся текст запроса. Например, загляните в код дашборда drilldown_chart1 в приложении с примерами пользовательского интерфейса UI examples app на http://splunkbase.com. addterm Этот тип intention удобно использовать для добавления в запрос новых критериев, возможно, полученных от пользователя. Например, представьте, что нам нужно, чтобы в запросах всегда фигурировало определенное значение для поля source. В этом случае перед выполнением в запрос можно добавить критерий поиска по полю search. Вот пример из дашборда advanced_lister_with_. 284  Создание продвинутых дашбордов Строка поиска приложения с примерами пользовательского интерфейса доступна на http://splunkbase.com. Дальнейшее обсуждение будет строиться на основе следующего фрагмента кода: <module name="HiddenIntention"> <param name="intention"> <param name="name">addterm</param> <param name="arg"> <param name="source">*metrics.log</param> </param>  <param name="flags"><list>indexed</list></param> </param> Рассмотрим по порядку теги param: name: определяет тип intention – в данном случае addterm; arg: определяет поле для добавления в запрос. Вложенный тег param задает имя поля и значение, которые должны использоваться в запросе. В данном случае в запрос будет добавлен критерий source="*metrics.log". В атрибуте name или в теле этого вложенного тега param допускается использовать переменные. Пример этого мы увидим в разделе «Создание своих детализаций»; flags: во всех примерах использования addterm, которые я смог найти, включают этот атрибут именно в таком виде. Фактически он требует добавить критерий в запрос перед первым символом вертикальной черты, а не в конец. Например, запрос error | top logger будет преобразован этим тегом, как показано ниже: error source="*metrics.log" | top logger Создание нестандартных детализаций Под детализацией подразумевается запрос, построенный с использованием значений, полученных предыдущим запросом. Модуль ConvertToDrilldownSearch автоматически конструирует запросы из таблиц или графиков, в которые он вложен. К сожалению, он хорошо работает, только когда запрос достаточно прост и требуется выбрать исходные события. Чтобы создать свою детализацию, мы должны объединить intentions и вложенную природу модулей. Определение детализации в своем запросе Возьмем за основу диаграмму из раздела «Повторное использование запроса» выше и определим для нее свою детализацию, которая по щелчку мыши будет отображать наиболее часто встречающиеся значения другого поля. Создание нестандартных детализаций  285 Вот пример дашборда, который рисует диаграмму и после щелчка на ней запускает запрос: <view template="dashboard.html"> <label>Chapter 9 - Drilldown to custom query</label>  <module name="HiddenSearch" layoutPanel="panel_row1_col1" autoRun="True" group="Errors by user"> <param name="search"> sourcetype=* loglevel=error | top user </param> <param name="earliest">-99d</param>  <module name="HiddenChartFormatter"> <param name="charting.chart">pie</param> <module name="JSChart">   <module name="HiddenSearch"> <param name="search"> sourcetype=* loglevel=error | top logger </param>  <module name="ConvertToIntention"> <param name="intention"> <param name="name">addterm</param> <param name="arg"> <param name="user">$click.value$</param> </param> <param name="flags"> <item>indexed</item> </param> </param>  <module name="ViewRedirector"> <param name="viewTarget">flashtimeline</param> </module> </module> </module> </module> </module> </module> </view> Все выглядит знакомо до модуля JSChart. Внутри модуля находится модуль HiddenSearch. Идея состоит в том, чтобы последующие модули отображения не вызывались до щелчка мышью. 286  Создание продвинутых дашбордов В данном случае цель модуля HiddenSearch – сконструировать запрос, но результаты запроса обрабатывает не модуль отображения, а ViewRedirector. Самое загадочное поле во всем этом – click.value. Оно содержит значение в диаграмме, на котором был выполнен щелчок. Посмотрим, как выглядит этот дашборд (см. рис. 9.6). Рис. 9.6  Внешний вид дашборда с поддержкой нестандартной детализации На рис. 9.7 показано, как выглядят результаты, полученные после щелчка на секторе круговой диаграммы, соответствующем пользователю shelby. Рис. 9.7  Результаты для пользователя shelby Если необходимо, вернитесь к разделу addterm, чтобы вспомнить, как работает intention. Создание детализации в отдельной панели Другой способ вывести детализированную информацию – добавить новую панель в тот же дашборд. Это позволит создавать разные детализации без обновления всего содержимого экрана, что, в свою очередь, будет меньше раздражать пользователей. Вот XML-код такого дашборда: Создание нестандартных детализаций  287 <?xml version="1.0"?> <view template="dashboard.html"> <label>Chapter 9 - Drilldown to new graph</label>  <module name="HiddenSearch" layoutPanel="panel_row1_col1" autoRun="True" group="Errors by user"> <param name="search"> sourcetype=impl_splunk_gen_more error loglevel=error | top user </param> <param name="earliest">-99d</param> <module name="HiddenChartFormatter"> <param name="charting.chart">pie</param>  <module name="JSChart">  <module name="HiddenSearch"> <param name="earliest">-99d</param> <param name="search"> Sourcetypeimpl_splunk_gen_more error loglevel=error user=$user$ | timechart count by logger </param> <module name="ConvertToIntention"> <param name="intention"> <param name="name">stringreplace</param> <param name="arg"> <param name="user"> <param name="value">$click.value$</param> </param> </param> </param>  <module name="SimpleResultsHeader"> <param name="entityName">results</param> <param name="headerFormat"> Errors by logger for $click.value$ </param> </module>  <module name="HiddenChartFormatter"> <param name="charting.chart">area</param> <param name="chart.stackMode">stacked</param> <module name="JSChart"/> </module> </module> </module> </module> </module> </module> </view> 288  Создание продвинутых дашбордов На рис. 9.8 показано, как выглядит этот дашборд после щелчка на секторе диаграммы, соответствующем пользователю shelby. Рис. 9.8  Результаты для пользователя shelby в дополнительной панели Применение HiddenPostProcess для создания детализаций с несколькими панелями Продолжим работу над последним дашбордом и создадим несколько панелей для отображения информации на основе одного и того же детализирующего запроса. Как рассказывалось в главе 5 «Дашборды на упрощенном XML», была показана возможность постобработки результатов, позволяющая многократно использовать результаты одного и того же запроса. В продвинутом XML эту возможность реализует модуль HiddenPostProcess. В следующем примере мы также добавим оформление в наш дашборд. Ниже приводится сокращенная версия примера. Полный код дашборда вы найдете в файле Chapter9_drilldown_to_new_graph_with_postprocess.xml, в приложении Implementing Splunk App One: <view template="dashboard.html"> <Label>Chapter 9 - Drilldown to new graph with postprocess</label>  <module name="AccountBar" layoutPanel="appHeader"/> <module name="AppBar" layoutPanel="navigationHeader"/> <module name="Message" layoutPanel="messaging"> <param name="filter">*</param> <param name="clearOnJobDispatch">False</param> <param name="maxSize">1</param> </module> <module name="DashboardTitleBar" layoutPanel="viewHeader"/> <module name="Message" layoutPanel="navigationHeader"> <param name="filter">splunk.search.job</param> <param name="clearOnJobDispatch">True</param> <param name="maxSize">1</param> Создание нестандартных детализаций  289 <param name="level">warn</param> </module> <! -- Запуск начального поиска для заполнения круговой диаграммы --> <module name="HiddenSearch" layoutPanel="panel_row1_col1" autoRun="True" group="Errors by user"> <param name="search"> sourcetype="impl_splunk_gen" loglevel=error | top user </param> <param name="earliest">-99d</param> <module name="HiddenChartFormatter"> <param name="charting.chart">pie</param> <module name="JSChart">  <module name="HiddenSearch"> <param name="earliest">-24h</param> <param name="search"> sourcetype="impl_splunk_gen" loglevel=error user="$user$" | bucket span=30m _time | stats count by logger _time </param> <module name="ConvertToIntention"> <param name="intention"> <param name="name">stringreplace</param> <param name="arg"> <param name="user"> <param name="value">$click.value$</param> ...  <module name="SimpleResultsHeader" layoutPanel="panel_row2_col1"> <param name="entityName">results</param> <param name="headerFormat"> Errors by logger for $click.value$ </param> </module>  <module name="HiddenPostProcess"> <param name="search"> stats sum(count) as count by logger | sort -count | head 1 | eval f=logger + " is most common (" + count + ")" | table f </param> <module name="SingleValue" layoutPanel="panel_row2_col1"></module> </module> ...  290  Создание продвинутых дашбордов <module name="HiddenPostProcess"> <param name="search"> timechart span=30m sum(count) by logger </param> <module name="HiddenChartFormatter"> <param name="charting.chart">area</param> <param name="chart.stackMode">stacked</param> <module name="JSChart" layoutPanel="panel_row4_col1_grp1"/> </module> </module>  <module name="HiddenPostProcess"> <param name="search"> stats sum(count) as count by logger </param> <module name="SimpleResultsTable" layoutPanel="panel_row4_col1_grp2"/> </module> ... </module> </view> Этот дашборд содержит дополнительное оформление, что очень удобно для отображения сообщений об ошибках, возникших в intentions и запросах. А теперь разберем запросы. Начальный запрос остался прежним: sourcetype="impl_splunk_gen" loglevel=error | top user Следующий запрос может показаться странным, но тому есть веская причина: sourcetype="impl_splunk_gen" loglevel=error user="$user$" | bucket span=30m _time | stats count by logger _time Как рассказывалось в главе 6 «Примеры продвинутого поиска», команды bucket и stats используются для группировки запросов по полю _time и другим полям. Это удобный способ группировки события для постобработки, где один или несколько последующих запросов используют timechart. Этот запрос возвращает строку с полем count для каждого уникального значения в поле logger в каждом 30-минутном интервале. Постобработка ограничена 10 000 событий. Чтобы не превысить это ограничение, по возможности все необходимое агрегирование должно выполняться в начальном запросе. В идеале начальный запрос должен возвращать только то, что потребуется дочерним запросам. Также важно отметить, что начальный запрос должен возвращать все поля, необходимые последующим запросам. Первый модуль HiddenPostProcess конструирует значение для модуля Single Value, который нами еще не использовался. Он получает первое значение и отображает его, как показано в следующем коде: Сторонние расширения  291 stats sum(count) as count by logger | sort -count | head 1 | eval f=logger + " is most common (" + count + ")" | table f Запрос является аддитивным, то есть полный запрос для этого модуля фактически выглядит так: sourcetype="impl_splunk_gen" loglevel=error user="bob" | bucket span=30m _time | stats count by logger _time | stats sum(count) as count by logger | sort -count | head 1 | eval f=logger + " is most common (" + count + ")" | table f Остальные модули SingleValue действуют аналогично: выбирают уникальные значения в поле logger и определяют максимальное и среднее число ошибок за час. Чтобы лучше понять, как действуют эти запросы, просто скопируйте их и добавьте к основному запросу в строке поиска. Вот еще несколько важных замечаний относительно этого дашборда: grp создает столбцы внутри панели, например в layoutPanel="panel_row4_ col1_grp2"; модули SingleValue выводят информацию друг за другом не по вертикали, а по горизонтали, с переносом на следующую строку, если ширина окна окажется недостаточной; в команде bucket используется инструкция span – это минимум, что должно содержаться в любом запросе постобработки, и максимум, чтобы уменьшить число возвращаемых событий. Сторонние расширения На сайте http://splunkbase.com можно найти много замечательных приложений, часть из которых определяет свои модули. В этом разделе мы рассмотрим два наиболее популярных из них: Google Maps и Sideview Utils. Google Maps Как мы уже видели в главе 8 «Работа с приложениями», приложение Google Maps включает дашборд и определение подстановки для отображения результатов на карте. Модуль внутри этого приложения с успехом можно использовать в других приложениях. Вот очень простой дашборд, использующий модуль GoogleMaps: <?xml version="1.0"?> <view template="search.html">  292  Создание продвинутых дашбордов <label>Chapter 9 - Google Maps Search</label> <module name="AccountBar" layoutPanel="appHeader"/> <module name="AppBar" layoutPanel="navigationHeader"/> <module name="Message" layoutPanel="messaging"> <param name="filter">*</param> <param name="clearOnJobDispatch">False</param> <param name="maxSize">1</param> </module>  <module name="SearchBar" layoutPanel="splSearchControls-inline"> <param name="useOwnSubmitButton">False</param> <module name="TimeRangePicker"> <param name="selected">Last 60 minutes</param> <module name="SubmitButton">  <module name="GoogleMaps" layoutPanel="resultsAreaLeft" group="Map" /> </module> </module> </module> </view> Этот код отображает строку поиска и карту под ней, как показано на рис. 9.9. Рис. 9.9  Дашборд со строкой поиска и картой Обычно модуль GoogleMaps используется для преобразования значений в географические координаты. Как правило, это достигается с помощью подстановки geoip (см. примеры в главе 8 «Работа с приложениями»), преобразующей IPадреса в координаты, или с помощью своего lookup. Сторонние расширения  293 Только чтобы показать, что данные могут поступать откуда угодно, определим логику, вычисляющую значения поля _geo для событий из одного из примеров: sourcetype="impl_splunk_gen_more" req_time | eventstats max(req_time) as max | eval lat=(req_time/max*360)-180 | eval lng=abs(lat)/2-15 | eval _geo=lng+","+lat Этот запрос воспроизведет V-образную кривую на основе поля req_time, как показано на рис. 9.10. Более подробную информацию о поле _geo вы найдете в документации на http://splunkbase.com. Рис. 9.10  V-образная кривая на основе поля req_time Это очень упрощенный пример, использующий настройки по умолчанию. Более полный пример можно найти в дашборде Google Maps, в приложении Google Maps. Исходный код дашборда вы сможете увидеть в окне диспетчера или добавив параметр showsource в URL. Для моего сервера этот URL выглядит так: http://localhost:8000/en-US/app/maps/maps?showsource=advanced. Sideview Utils Sideview Utils – стороннее приложение для Splunk, включающее альтернативный набор модулей для создания интерактивных дашбордов. Эти модули избавляют от сложностей использования intentions и значительно упрощают конструирование форм, давая возможность использовать переменные в разметке HTML, а также существенно облегчая обработку значений, находящихся в разных панелях и дашбордах. Попробуем воспользоваться этими модулями, чтобы создать форму и связать несколько дашбордов по значениям в URL. В Splunkbase можно найти более старую, но достаточно богатую возможностями версию Sideview Utils. Последняя версия, доступная по адресу http:// sideviewapps.com/, добавляет множество новых возможностей, включая ви зуальный редактор для сборки дашбордов. 294  Создание продвинутых дашбордов Модуль search в Sideview Начнем с простого поиска: <?xml version="1.0"?> <view template="dashboard.html">  <module layoutPanel="appHeader" name="SideviewUtils"/>  <label>Chapter 9 - Sideview One</label> <module name="AccountBar" layoutPanel="appHeader"/> <module name="AppBar" layoutPanel="navigationHeader"/> <module name="Message" layoutPanel="messaging"> <param name="filter">*</param> <param name="clearOnJobDispatch">False</param> <param name="maxSize">1</param> </module>  <module name="Search" autoRun="True" group="Chapter 9 - Sideview One" layoutPanel="panel_row1_col1"> <param name="earliest">-99d</param> <param name="search">source="impl_splunk_gen_more" | top user</param>  <module name="HiddenChartFormatter"> <param name="charting.chart">pie</param> <module name="JSChart"/> </module> </module> </view> Этот дашборд воспроизводит ту же картинку, что и первая панель, описанная в разделе «Определение детализации в своем запросе». Вот на что нужно обратить внимание в этом примере: модуль SideviewUtils необходим для подключения кода, который требуется всем приложениям, использующим Sideview Utils; для демонстрации первого модуля Sideview здесь вместо HiddenSearch используется альтернативный модуль Search. В этом упрощенном примере также можно использовать стандартный модуль HiddenSearch. Связывание дашбордов с помощью Sideview Возьмем за основу наш простой дашборд и используем модуль Redirector для создания связи. Таким способом дашборд можно связать с чем угодно, и в данном случае мы свяжем его с другим дашбордом Splunk, который создадим ниже. ... <module name="JSChart"> <module name="Redirector"> Powered by TCPDF (www.tcpdf.org) Сторонние расширения  295 <param name="arg.user">$click.value$</param> <param name="url">chapter_9_sideview_2</param> </module> </module> ... После щелчка на shelby на основе поля user будет создан новый URL. В моем случае он будет иметь вид: http://localhost:8000/en-US/app/is_app_one/chapter_9_sideview_2?user=shelby В настоящий момент дашборд, на который ссылается этот URL, пока не определен, поэтому щелчок вернет сообщение об ошибке. Теперь создадим второй дашборд. Модуль URLLoader из Sideview Модуль URLLoader дает очень полезную возможность присвоить переменным значения из строки запроса в URL. Наш следующий дашборд будет выводить таблицу со счетчиками ошибок для пользователя, указанного в URL: <view template="dashboard.html">  <module name="SideviewUtils" layoutPanel="appHeader"/>  <label>Chapter 9 - Sideview Two</Label> <module name="AccountBar" layoutPanel="appHeader"/> <module name="AppBar" layoutPanel="navigationHeader"/> <module name="Message" layoutPanel="messaging"> <param name="filter">*</param> <param name="clearOnJobDispatch">False</param> <param name="maxSize">1</param> </module>  <module name="URLLoader" layoutPanel="panel_row1_col1" autoRun="True"> <module name="HTML"> <param name="html"><![CDATA[ <h2>Errors by logger for $user$.</h2> ]]> </param> </module> <module name="Search" group="Chapter 9 - Sideview Two"> <param name="earliest">-199d</param> <param name="search"> sourcetype="*" user="$user$" | top user </param>  <module name="SimpleResultsTable"> <param name="drilldown">row</param> <module name="Redirector"> 296  Создание продвинутых дашбордов <param name="url">chapter_9_sideview_3</param> <param name="arg.logger"> $click.fields.logger.rawValue$ </param> <param name="arg.user">$user$</param> <param name="arg.earliest"> $search.timeRange.earliest$ </param> </module> </module> </module> </module> </view> Важно не забыть добавить autoRun="true" в один и только в один из модулей – в данном случае в URLLoader. Со значением shelby в параметре user в URL этот дашборд (для моих данных) создаст простое представление, изображенное на рис. 9.11 (обратите внимание, что для пользователя shelby обнаружены ошибки только одного типа). Рис. 9.11  Вид дашборда, получившего значение shelby из параметра user в URL Рассмотрим модули, использованные в этом примере: SideviewUtils: этот модуль необходим для всех других модулей из Sideview; он не имеет визуального представления, но совершенно необходим; URLLoader: этот модуль извлекает строку запроса из URL и преобразует ее в переменные для использования последующими модулями. Наш URL содержит user=shelby, поэтому подстрока $user$ будет замещена значением shelby; HTML: этот модуль отображает заданную разметку HTML, при этом производит замену переменных значениями из URLLoader и элементов форм; Search: используется взамен HiddenSearch, может получать значения для переменных из URLLoader и элементов форм. Полностью устраняет необходимость в intentions. В данном примере замещает переменную $user$; Redirector: в этом примере этот модуль передает два значения следующему дашборду – имя пользователя из URLLoader и поле logger из самой таблицы. Сторонние расширения  297 Обратите также внимание на следующие аспекты: поле logger получает значение из $click.fields.logger.rawValue$; когда выполняется щелчок на таблице, переменная click.fields получит все поля из строки, на которой выполнен щелчок; rawValue возвращает неэкранированное значение. Как утверждается в документации для Sideview: «Для отображения в заголовках и отправки через Redirector используйте $foo.rawValue$, а в запросах – $foo$". Это правило применяется к значениям в Redirector, не предназначенным для отображения; search.timeRange содержит информацию о диапазоне времени для этого запроса, откуда бы этот диапазон не был получен – из URL, из TimeRangePicker или из тегов param в определении модуля Search. arg.earliest добавляет значение в URL. Если щелкнуть в таблице на строке со значением LogoutClass в поле logger, будет создан такой URL: http://localhost:8000/en-US/app/is_app_one/chapter_9_sideview_3? user=mar&ylogger=LogoutClass&earliest=1344188377 Дашборд с этим URL мы создадим в следующем разделе. Формы Sideview В завершение обсуждения модулей Sideview создадим дашборд с формой, поля которой предварительно заполняются из URL, позволяющий пользователю изменить интервал времени. Преимущество такого дашборда заключается в возможности автономного его использования. Если пользователь обращается к этому дашборду непосредственно, он заполняет поля формы предопределенными значениями по умолчанию. Рассмотрим его код: <?xml version="1.0"?> <view template="dashboard.html">  <module name="SideviewUtils" layoutPanel="appHeader"/>  <label>Chapter 9 - Sideview Three</label> <module name="AccountBar" layoutPanel="appHeader"/> <module name="AppBar" layoutPanel="navigationHeader"/> <module name="Message" layoutPanel="messaging"> <param name="filter">*</param> <param name="clearOnJobDispatch">False</param> <param name="maxSize">1</param> </module>  <module name="URLLoader" layoutPanel="panel_row1_col1" 298  Создание продвинутых дашбордов autoRun="True">   <module name="Search" layoutPanel="panel_row1_col1"> <param name="search"> source="impl_splunk_gen" user user="*" | top user </param> <param name="earliest">-24h</param> <param name="latest">now</param> <module name="Pulldown"> <param name="name">user</param>  <param name="searchFieldsToDisplay"> <list> <param name="value">user</param> <param name="label">user</param> </list> </param> <param name="label">User</param> <param name="float">left</param>  <module name="TextField"> <param name="name">logger</param> <param name="default">*</param> <param name="label">Logger:</param> <param name="float">left</param> <module name="TimeRangePicker"> <param name="searchWhenChanged">True</param> <param name="default">Last 24 hours</param>  <module name="SubmitButton"> <param name="allowSoftSubmit">True</param>  <module name="HTML"> <param name="html"><![CDATA[ <h2>Info for user $user$, logger $logger$.</h2> ]]></param> </module>  <module name="Search" group="Chapter 9 - Sideview Three"> <param name="search"> source="impl_splunk_gen" user="$user$" logger="$logger$" | fillnull value="unknown" network | timechart count by network </param>  <module name="JobProgressIndicator"/> Сторонние расширения  299  <module name="HiddenChartFormatter"> <param name="charting.chart">area</param> <param name="charting.chart.stackMode"> stacked </param> <module name="JSChart"/> </module> </module>  <module name="Search" group="Chapter 9 - Sideview Three"> <param name="search"> source="impl_splunk_gen" user="$user$" logger="$logger$" | fillnull value="unknown" network | top network </param>  <module name="SimpleResultsTable"/> </module> </module> </module> </module> </module> </module> </module> </view> Внешний вид этого дашборда показан на рис. 9.12. Рис. 9.12  Дашборд с формой 300  Создание продвинутых дашбордов В данном примере появилось довольно много нового, поэтому разберем этот код XML небольшими фрагментами. Сначала требуется подключить модуль SideviewUtils, необходимый другим модулям Sideview, используемым в этом примере: URLLoader, HTML, Pulldown, Search и TextField. Это делает следующий код: <module layoutPanel="appHeader" name="SideviewUtils"/> Основную часть дашборда нужно заключить в URLLoader, чтобы получить значения из URL: <module name="URLLoader" layoutPanel="panel_row1_col1" autoRun="True"> Далее выполняется запрос, чтобы заполнить раскрывающийся список с именами пользователей. Этот запрос отыщет всех пользователей, проявивших активность за последние 24 часа: <module name="Search" layoutPanel="panel_row1_col1"> <param name="search"> source="impl_splunk_gen" user user="*" | top user </param> <param name="earliest">-24h</param> <param name="latest">now</param> Использование запроса для заполнения раскрывающегося списка может оказаться слишком дорогим удовольствием, особенно при обработке больших объемов данных. Чтобы избежать избыточных накладных расходов, подобные значения можно вычислять предварительно, сохранять в файлах CSV с помощью outputcsv и inputcsv или использовать summary-индексы. Примеры использования механизма summary-индексов и файлов CSV для хранения промежуточных данных можно найти в главе 10 «Summary-индексы и файлы CSV». Модуль Pulldown отображает раскрывающийся список. Он заполняется результатами, полученными предшествующим модулем Search, но обратите внимание, что текущее выбранное значение устанавливается из URL: <module name="Pulldown">  <param name="searchFieldsToDisplay"> <list> <param name="value">user</param> <param name="label">user</param> </list> </param> <param name="name">user</param> <param name="label">User</param> <param name="float">left</param> Сторонние расширения  301 Далее следует текстовое поле ввода logger. Это – версия ExtendedFieldSearch в Sideview. Оно автоматически заполняется значениями переменных, которые определены в потоке выше: <module name="TextField"> <param name="name">logger</param> <param name="default">*</param> <param name="label">Logger:</param> <param name="float">left</param> Модуль TimeRangePicker извлекает значения earliest и latest из URL. Обратите внимание, что для правильной работы модуля в данном конкретном случае параметру searchWhenChanged присваивается значение True. Впрочем, он должен иметь значение True в подавляющем большинстве случаев: <module name="TimeRangePicker"> <param name="searchWhenChanged">True</param> <param name="default">Last 24 hours</param> Модуль SubmitButton запускает поиск при изменении значений. Параметр allowSoftSubmit позволяет внешним модулям запустить поиск выбором значения или нажатием клавиши Enter в текстовом поле: <module name="SubmitButton"> <param name="allowSoftSubmit">True</param> Следующие два модуля Search включают вложенные модули вывода: <module name="Search" group="Chapter 9 - Sideview Three"> <param name="search"> source="impl_splunk_gen" user="$user$" logger="$logger$" | fillnull value="unknown" network | timechart count by network </param>  <module name="JobProgressIndicator"/>  <module name="HiddenChartFormatter"> <param name="charting.chart">area</param> <param name="charting.chart.stackMode"> stacked </param> <module name="JSChart"/> </module> </module>  <module group="Chapter 9 - Sideview Three" name="Search"> <param name="search"> 302  Создание продвинутых дашбордов source="impl_splunk_gen" user="$user$" logger="$logger$" | fillnull value="unknown" network | top network </param>  <module name="SimpleResultsTable"> <param name="drilldown">row</param> </module> Для большей эффективности эти два запроса можно объединить в один и использовать модуль PostProcess. Итоги В этой главе мы рассмотрели огромное количество вопросов. Среди них мы исследовали такие сложные понятия, как вложение модулей друг в друга, атрибут layoutPanel, механизм intentions и его альтернативу – SideView Utils. Как всегда, лучший способ освоить новые знания – продолжить их исследование на практике! Примеры в данной главе должны помочь вам на этом пути. В следующей главе мы рассмотрим механизм summary-индексов в Splunk, способный значительно улучшить эффективность выполнения ваших запросов. Глава 10 Summary-индексы и файлы CSV По мере увеличения числа событий, извлекаемых запросами, их производительность линейно снижается. Механизм summary-индексов позволяет заблаговременно вычислять статистики и затем использовать их в отчетах, что способствует значительному увеличению производительности. В этой главе мы рассмотрим следующие темы: общие сведения о summary-индексах; когда следует использовать summary-индексы; когда не следует использовать summary-индексы; заполнение summary-индексов в хранимых запросах; использование summary-индексов в запросах; использование sistats, sitop и sitimechart; как задержка влияет на запросы, использующие summary-индексы; как и когда добавлять исторические данные в summary-индексы; уменьшение размеров summary-индексов; подсчет наиболее часто встречающихся данных в больших интервалах времени; использование файлов CSV для хранения промежуточных данных; ускорение запросов и заполнение summary-индексов. Общие сведения о summary-индексах Summary-индексы – это место для хранения событий, вычисляемых Splunk. Обычно эти события создаются путем агрегирования исходных событий по времени. Примером может служить количество ошибок, возникших в течение часа. Вычисляя эту информацию на почасовой основе, легко можно ускорить выполнение запроса, просматривающего более долгие интервалы времени, например длиной в несколько дней, недель или месяцев. Заполнение summary-индекса обычно производится хранимыми запросами с включенной поддержкой summary-индексов. Но это не единственная возможность и, безусловно, не самая распространенная. 304  Summary-индексы и файлы CSV Summary-индексы хранятся на диске, точно так же как любые другие индексы Splunk. Разница исключительно в источнике данных. Summary-индексы создаются посредством редактирования конфигурации или с помощью графического интерфейса, как любые другие индексы, и управление размером индекса осуществляется точно так же. Индекс можно представить как таблицу или даже как табличное пространство в типичной базе данных SQL. Ограничение индексов осуществляется по размеру или времени, по аналогии с табличным пространством, но все данные хранятся вместе, как в таблице. Подробнее об управлении индексами мы поговорим в главе 11 «Настройка Splunk». Создание summary-индекса Чтобы создать индекс, перейдите на страницу Settings  Indexes  New Index (Настройки  Индексы  Новый индекс), как показано на рис. 10.1. Рис. 10.1  Страница Settings  Indexes  New Index (Настройки  Индексы  Новый индекс) Когда следует использовать summary-индексы  305 В версии 7.0 страница New Index (Новый индекс) немного изменилась, но в данном примере не будем акцентироваться на различиях, а просто введем имя индекса и оставим остальные значения по умолчанию. Все эти настройки мы обсудим в разделе indexes.conf главы 11 «Настройка Splunk». Для summary-индексов я предпочитаю добавлять в начало названия слово summary, но вообще имя может быть каким угодно. Я советую следовать своим соглашениям об именовании, имеющим определенный смысл для вас. Теперь, создав индекс для хранения событий, давайте сделаем с ним чтонибудь. Когда следует использовать summary-индексы Если для ответа на вопрос требуется просмотреть все или большинство событий с заданным типом источника, их количество может оказаться огромным. Это то, что обычно называют тяжеловесным поиском. Например, чтобы узнать количество просмотров каждой страницы на вашем веб-сайте, запросу придется просмотреть каждое событие. Поскольку для просмотра каждого события расходуется процессорное время, мы фактически сталкиваемся с ограничением скорости чтения исходных данных с диска и их обработки процессором. Давайте выполним несложные математические операции, чтобы почувствовать масштаб проблемы: для 1 000 000 посещений в день / скорость обработки 10 000 событий в секунду = 100 секунд. Если использовать несколько индексеров или прикупить более скоростные диски, это время можно сократить, но только линейно. Например, если распределить данные по четырем индексерам (без замены дисков на более быстрые), на обработку этого запроса уйдет примерно 25 секунд. Если задействовать механизм summary-индексов, время поиска можно существенно уменьшить. Допустим, у нас подсчитывается количество посещений за каждые пять минут. Тогда: 24 часа * 60 минут в часе / 5-минутные интервалы = 288 summary-событий. Если теперь в запросе использовать эти summary-события, для выполнения запроса потребуется: 288 summary-событий / скорость обработки 10 000 событий в секунду = 0.0288 секунды. Это очень существенное увеличение производительности. В действительности у нас может храниться больше 288 событий. Например, предположим, что нам понадобилось подсчитать события по их HTTP-кодам ответа. Если допус тить, что регулярно наблюдается 10 разных кодов, получаем: 306  Summary-индексы и файлы CSV 24 часа * 60 минут в часе / 5-минутные интервалы * 10 кодов = 2880 событий. И на выполнение запроса уйдет: 2,880 summary-событий / скорость обработки 10 000 событий в секунду = 0.288 секунды. Все еще весьма существенное улучшение в сравнении со 100 секундами. Когда не следует использовать summary-индексы В некоторых случаях summary-индексы не могут использоваться или их применение неэффективно. Ниже перечислены некоторые из них. Когда требуется получить исходные события: в большинстве случаев summary-индексы используются для хранения агрегированных значений. В принципе, в summary-индексе можно хранить копии исходных событий, но обычно так не поступают. Чем больше событий будет храниться в summary-индексе, тем меньше выигрыш вы получите в сравнении с обычными индексами. Когда число категорий данных слишком велико: например, если вам интересно увидеть топ IP-адресов посетителей за день, у вас может возникнуть соблазн просто сохранить счетчики всех наблюдавшихся IPадресов. В результате может получиться огромный массив данных, и вы сэкономите не так много времени, если вообще сэкономите. Аналогично простое сохранение топ-10 адресов за 10-минутные интервалы может дать искаженное представление за более долгий период времени. Мы обсудим этот сценарий в разделе «Подсчет наиболее часто встречающихся данных в больших интервалах времени». Когда непрактично разбивать данные по достаточно большому количеству измерений: если данные имеют большое число измерений или атрибутов и желательно разбить данные по большому числу этих измерений, получившийся в результате summary-индекс может оказаться не намного меньше оригинального индекса. Когда трудно определить приемлемый интервал времени: настраивая несколько summary-индексов, мы должны выбрать временной интервал для агрегирования событий. Если на начальном этапе вам покажется, что 1 час – вполне приемлемый интервал, а потом выяснится, что нужно 10-минутное разрешение, вам будет очень сложно пересчитать старые данные в эти 10-минутные интервалы. Однако вы без труда сможете перейти от 10-минутных интервалов к 1-часовым, потому что отчеты, анализирующие часовые интервалы, с успехом справятся с 10-минутными интервалами. Заполнение summary-индексов через saved search  307 Заполнение summary-индексов через saved search Запросы для заполнения summary-индекса во многом напоминают любые другие хранимые запросы (saved search) (подробнее о создании хранимых запросов рассказывается в главе 2 «Основы поиска»). Разница лишь в том, что такие запросы запускаются через регулярные интервалы времени, а их результаты сохраняются в summary-индексе. Итак, создадим простой запрос для заполнения summary-индекса. 1. Начнем с запроса, возвращающего несколько показателей: source="impl_splunk_gen" | stats count by user 2. Сохраните его с именем search as summary – count by user. 3.Измените настройки на странице Settings  Searches, reports and alerts  summary – count by user (Настройки  Поиск, отчеты и оповещения  summary – count by user). 4.Определите подходящие значения времени. Это довольно сложная задача. Более подробно данный вопрос обсуждается в разделе «Как задержка влияет на запросы, использующие summary-индексы» (см. рис. 10.2). Рис. 10.2  Настройки запроса для заполнения summary-индекса Рассмотрим поближе несколько полей на этой странице: Search (Запрос): source="impl_splunk_gen" | stats count by user. Это текст нашего запроса. Позднее мы заменим инструкцию stats ее специальной версией sistats, поддерживающей summary-индексы. С помощью модификаторов время можно задавать в абсолютных или относительных значениях: Earliest time (Время начала): -62m@m. Значение 62 может показаться странным – почему нельзя просто указать -60m@m? Дело в том, что мы 308  Summary-индексы и файлы CSV должны учесть задержку. Более подробно об этом рассказывается в разделе «Как задержка влияет на запросы, использующие summary-индексы»; Latest time (Время конца): -2m@m. Использование summary-индексов в запросах После того как запрос, заполняющий summary-индекс, поработает на протяжении некоторого времени, мы сможем воспользоваться его результатами в других запросах. Однако если вы спешите или вам нужно получить информацию за периоды времени, предшествовавшие созданию запроса, вам придется добавить в summary-индекс исторические данные. Дополнительные сведения о вычислении значений для summary-индексов по историческим событиям вы найдете в разделе «Как и когда добавлять исторические данные в summary-индексы». Теперь посмотрим, что фактически хранится в summary-индексе: 08/15/2012 10:00:00, search_name="summary - count by user", search_now=1345046520.000, info_min_time=1345042800.000, info_max_time=1345046400.000, info_search_time=1345050512.340, count=17, user=mary Разобьем этот результат на составные части. 08/15/2012 10:00:00: это время начала текущего блока данных. В данном случае такое поведение summary-индексов полностью согласуется с поведением timechart и bucket. search_name="summary - count by user": имя запроса. Обычно поиск по имени – самый простой способ отыскать нужные результаты. search_now ... info_search_time: это поля с информацией о данной записи в summary-индексе; обычно они не представляют интереса для простых пользователей. count=17, user=mary: остальная часть записи включает поля, созданные запросом. Каждая запись, возвращаемая заполняющим запросом, соответствует одному summary-событию. Теперь сконструируем запрос, опираясь на эти данные. В начале запроса нужно указать имя индекса и имя запроса: index="summary_impl_splunk" search_name="summary - count by user" На моем компьютере (как вы понимаете, на основе разных данных будут получены разные результаты) этот запрос загрузил 48 событий. Сравните это с 22 477 исходными событиями. С помощью stats можно быстро получить статистики по пользователям: index="summary_impl_splunk" | stats sum(count) count by user Этот запрос выведет простую таблицу, как показано на рис. 10.3. Использование summary-индексов в запросах  309 Рис. 10.3  Статистики по пользователям из summary-индекса В этом запросе мы определяем sum(count) и count. Они могут иметь одно и то же значение, но представляют суть разные вещи. sum(count): в исходном событии count содержит число появлений пользователя за данный отрезок времени. Исходное значение мы сохраняем в этом поле count. В разделе «Использование sistats, sitop и sitimechart» вы познакомитесь с совершенно иным подходом. count: представляет фактическое число событий в summary-индексе. Генератор, сгенерировавший эти события, имеет не совсем случайный характер, поэтому для всех пользователей в каждом часе он создал хотя бы одно событие. Создать временную диаграмму timechart ничуть не сложнее: index="summary_impl_splunk" | timechart span=1h sum(count) by user Этот запрос вернет график, изображенный на рис. 10.4. Рис. 10.4  Временная диаграмма Главное, что вы должны запомнить, – нельзя получить график более детальный, чем расписание работы заполняющего запроса. В данном случае заполняющий запрос накапливает данные за часовые интервалы. Такого уровня детализации достаточно для ежедневных отчетов и, разумеется, для отчетов еженедельных и ежемесячных, но может быть недостаточно для дашбордов, отображающих оперативную информацию. 310  Summary-индексы и файлы CSV Далее приводится несколько интересных запросов, которые можно использовать для работы с этим простым набором данных: index="summary_impl_splunk" search_name="summary - count by user" | stats avg(count) as "Average events per hour" Этот запрос возвращает среднее число событий в единичном интервале времени, в данном случае – час. Добавив bucket и еще одну команду stats, можно организовать вычисление статистик с другим единичным интервалом времени: index="summary_impl_splunk" search_name="summary - count by user" | bucket span=4h _time | stats sum(count) as count by _time | stats avg(count) as "Average events per 4 hours" Следующий запрос вернет имя пользователя с максимальным числом в час, и сам час, в котором это случилось: index="summary_impl_splunk" search_name="summary - count by user" | stats first(_time) as _time max(count) as max by user | sort -max | head 1 | rename max as "Maximum events per hour" Использование sistats, sitop и sitimechart Для начала дадим определение некоторым новым функциям: sistats: это версия команды stats с поддержкой summary-индекса, которая вычисляет агрегированные статистики по набору данных; sitop: это версия команды top с поддержкой summary-индекса, которая возвращает значение, наиболее часто встречающееся в поле или в комбинации полей; sitimechart: это версия команды timechart с поддержкой summary-индек са, которая создает временные последовательности для визуализации в виде графиков с соответствующими таблицами статистик. До сих пор для заполнения summary-индекса мы использовали команду stats. Она вполне справляется с этой задачей, но ее аналог si* имеет пару преимуществ. Не требует переписывать оставшуюся часть запроса. Например, команда stats count все еще будет успешно работать, как если бы она подсчитывала исходные события. Функции stats, требующие больше данных, чем имеется в данном интервале времени, все еще будут работать. Например, если каждый интервал представляет один час, у вас не получится вычислить среднее за день, используя только средние показатели за каждый час. Функция sistats хранит достаточно информации, чтобы сделать такие вычисления возможными. Существует также несколько серьезных недостатков, о которых вы должны знать. Использование sistats, sitop и sitimechart  311 Запрос, применяющий summary-индекс, должен использовать подмножество функций и поля, указанные в исходном заполняющем запросе. Если последующий запрос отклонится от исходных данных sistats, результаты могут оказаться непредсказуемыми, такие ошибки трудно будет найти. Например, взгляните на следующий код: source="impl_splunk_gen" | sitimechart span=1h avg(req_time) by user | stats avg(req_time) Следующий код вернет непредсказуемые, ошибочные значения: source="impl_splunk_gen" | sitimechart span=1h avg(req_time) by user | stats max(req_time) Обратите внимание, что avg получает исходные данные от sistats, а max производит вычисления по полученным результатам. Команда distinct count (dc) в комбинации с sistats может вернуть огромное число событий. Это объясняется тем, что для определения уникальности значений по интервалам времени требуется сохранять все исходные значения. Типичный случай применения такой команды – выявление IPадресов, оказывающих наибольшую нагрузку на общедоступный сервер. Альтернативное решение этой задачи вы найдете в разделе «Подсчет наиболее часто встречающихся данных в больших интервалах времени». Содержимое summary-индекса имеет неудобочитаемый вид, так как не предназначено для чтения человеком. Чтобы посмотреть, как все это работает на практике, определим несколько запросов. Начнем с простого запроса stats: sourcetype=impl_splunk_gen | stats count max(req_time) avg(req_time) min(req_time) by user Он произведет результаты, как показано на рис. 10.5. Рис. 10.5  Результаты простого запроса stats 312  Summary-индексы и файлы CSV Теперь эти результаты можно отправить прямо в summary-индекс, но пользоваться этими результатами не очень удобно и определение среднего по средним значениям будет страдать неточностью. Чтобы решить эту проблему, можно задействовать вариант sistats: sourcetype=impl_splunk_gen | sistats count max(req_time) avg(req_time) min(req_time) by user В этом случае в результаты будет добавлена дополнительная информация, в которой не очень просто разобраться, как показано на рис. 10.6. Рис. 10.6  sistats добавит в результаты дополнительную информацию Splunk знает, как обрабатывать эти данные, и может использовать их в сочетании с функциями stats, как если бы они были исходными данными. Увидеть, как sistats и stats работают вместе, можно, объединив их, как показано ниже: sourcetype=impl_splunk_gen | sistats count max(req_time) avg(req_time) min(req_time) by user | stats count max(req_time) avg(req_time) min(req_time) by user Даже притом что функция stats не получает исходных событий, она знает, как работать с этими summary-событиями, созданными командой sistats. Благодаря этому мы получим те же результаты, что и в случае с первоначальным запросом, как показано на рис. 10.7. sitop и sitimechart действуют аналогично. Рассмотрим подробнее процедуру подготовки поиска в summary-индексе. 1. Сохранить запрос, использующий sistats: sourcetype=impl_splunk_gen | sistats count max(req_time) avg(req_time) min(req_time) by user 2.Настроить интервалы времени, как было показано выше, в разделе «Заполнение summary-индексов в хранимых запросах». За дополнительной информацией обращайтесь к разделу «Как задержка влияет на запросы, использующие summary-индексы». Как задержка влияет на запросы, использующие summary-индексы  313 3.Создать запрос, обращающийся к summary-индексу, как было показано выше, в разделе «Использование summary-индексов в запросах». Допустим, что мы сохранили этот запрос с именем testing sistats, тогда мы сможем обратиться к нему, как показано ниже: index="summary_impl_splunk" search_name="testing sistats". 4. Применить оригинальную функцию stats к результатам, например: index="summary_impl_splunk" search_name="testing sistats" | stats count max(req_time) avg(req_time) min(req_time) by user Этот запрос должен вернуть те же результаты, что и оригинальный. Рис. 10.7  Функция stats знает, как работать с summary-событиями, созданными командой sistats Мне варианты si* до сих пор кажутся таинственными, но они работают настолько хорошо, что вам определенно стоит взять эти команды на вооружение и довериться их магии. И не забывайте, что ваши функции и поля являются подмножеством оригинала. Как задержка влияет на запросы, использующие summary-индексы Задержка – это разность между временем события (обычно извлекается из текста) и временем записи в индекс. Эти значения времени обычно сохраняются в полях _time и _indextime соответственно. Следующий запрос поможет вам узнать величину задержки: sourcetype=impl_splunk_gen | eval latency = _indextime - _time | stats min(latency) avg(latency) max(latency) 314  Summary-индексы и файлы CSV В моем случае результаты получились, как показано на рис. 10.8. Рис. 10.8  Результат определения величины задержки В этом примере задержка преувеличена, потому что скрипт, лежащий в основе impl_splunk_gen, записывает события в индекс пакетами. На практике же в большинстве случаев задержка составляет всего несколько секунд. Если в системе имеют место какие-то факторы, вызывающие замедление передачи данных, как, например, нестабильная работа сети, задержка может вырасти су щественно, и ее обязательно следует учитывать. Следующий запрос выведет время каждого события: sourcetype=impl_splunk_gen | eval latency = _indextime - _time | eval time=strftime(_time,"%Y-%m-%d %H:%M:%S.%3N") | eval indextime=strftime(_indextime,"%Y-%m-%d %H:%M:%S.%3N") | table time indextime latency в виде таблицы, изображенной на рис. 10.9. Рис. 10.9  Время каждого события Чтобы учесть эту задержку, следует добавить достаточную задержку в запрос, заполняющий summary-индекс. Вот несколько примеров: Confidence Time slice Earliest 2 minutes 1 hour -62m@m 15 minutes 1 hour -1h@h 5 minutes 5 minutes -10m@m 1 hour 15 minutes -75m@m 1 hour 24 hours -1d@d Latest -2m@m -0h@h -5m@m -60m@m -0d@d 0 cron 2 * * * * 15 * * * * */5 * * * * */15 * * * * 1 * * * * Как и когда добавлять исторические данные в summary-индексы  315 Иногда неизвестно, когда индексируются файлы журналов, потому что они обрабатываются пакетами и передаются по ненадежным сетям. Я называю это непредсказуемой задержкой. Одно из возможных решений данной проблемы – воспользоваться приложением indextime search, доступным на http://splunkbase.com. Как и когда добавлять исторические данные в summary-индексы Для нормальной работы отчета, использующего summary-данные, в summaryиндексе должен иметься достаточный объем информации. Если отчет представляет данные за один-два дня, можно просто подождать, пока в индексе накопится достаточно информации. Если нужно, чтобы отчет мог отображать более ранние данные или если диапазон времени длиннее, тогда можно принудительно записать исторические данные в индекс. Использование fill_summary_index.py для заполнения Скрипт fill_summary_index.py позволяет записать в summary-индекс данные за любой период времени. Для этого следует выполнить хранимый запрос, который был определен для заполнения summary-индексов, но только для требуемого интервала времени. Вот как выглядит порядок использования скрипта. 1.Создать запрос, запускаемый по расписанию, как описано выше в разделе «Заполнение summary-индексов в хранимых запросах». 2.Зайти в командную оболочку на сервере Splunk. В распределенной архитектуре вход следует выполнить на головном сервере поиска. 3. Перейти в каталог bin в каталоге установки Splunk: cd $SPLUNK_HOME/bin $SPLUNK_HOME – это каталог установки Splunk. В операционных системах Unix система Splunk по умолчанию устанавливается в каталог /opt/splunk, а в Windows – в каталог c:\ProgramFiles\Splunk. 4. Выполнить команду fill_summary_index, например: ./splunk cmd python fill_summary_index.py -app is_app_one -name "summary - count by user" -et -30d -lt now -j 8 -dedup true -auth admin:changeme Рассмотрим аргументы по порядку: ./splunk cmd: фактически производит настройку окружения, чтобы все последующие команды смогли отыскать библиотеки Splunk и модули Python; python fill_summary_index.py: запускает сам скрипт, передавая его интерпретатору Python, и модули, подключаемые из дистрибутива Splunk; -app is_app_one: имя приложения, содержащего требуемые заполняющие запросы; 316  Summary-индексы и файлы CSV -name "summary - count by user": имя запроса для выполнения. Если вместо имени указать звездочку (*), будут запущены все запросы, заполняющие summary-индексы, объявленные в приложении; -et -30d: время начала для выборки событий, которые следует поместить в summary-индекс; -lt now: время конца; -j 8: определяет максимальное число запросов, выполняемых одновременно; -dedup true: этот флаг определяет режим обработки интервалов времени, в которых нет результатов. Без этого флага в summary-индекс будут записываться повторяющиеся записи. Для некоторых статистик это обстоя тельство не имеет значения, но для большинства оно играет важную роль. Если вас волнует вероятность записи в summary-индекс неполных данных – например, потому что summary-события оказались сгенерированы в тот момент, когда индексер был недоступен, – воспользуйтесь командой delete, чтобы предварительно удалить такие события. Но имейте в виду, что команда delete очень неэффективна и должна использоваться с большой осторожностью, а лучше вообще не использоваться; -auth admin:changeme: учетные данные (имя пользователя и пароль) для запуска запроса (по умолчанию используется пользователь admin, но вы можете задать любые другие учетные данные). Этот скрипт выполнит запрос с соответствующими значениями времени, как если бы он был выполнен системой автоматически в прошлом. Для выполнения запросу может потребоваться много времени, особенно если число интервалов времени велико. Например, для 5-минутных интервалов в выборке данных за месяц запрос будет выполнен 30 * 24 * (60/5) = 8640 раз. Создание нестандартных summary-индексов с помощью collect Если события в summary-индексе предназначены для использования в единственном отчете, можно воспользоваться функцией collect и с ее помощью создать свой summary-индекс. При таком подходе индекс можно заполнить единственным запросом и намного быстрее, чем с помощью скрипта принудительного заполнения, который выполняет запрос для каждого интервала в отдельности. Например, если вам нужно вычислить статистики по 15-минутным интервалам за месяц, скрипт выполнит запрос 2880 раз. Заглянув в код, который фактически заполняет summary-индексы, вы увидите, что для сохранения событий в заданный индекс он использует команду collect. Команда collect доступна нам, и мы можем использовать ее непосредственно. Для этого прежде всего нужно сконструировать запрос, нарезающий данные на интервалы времени: source="impl_splunk_gen" | bucket span=1h _time | stats count by _time user Как и когда добавлять исторические данные в summary-индексы  317 Он вернет простую таблицу, как показано на рис. 10.10. Рис. 10.10  Результаты запроса, распределяющего данные по интервалам времени Обратите внимание, что каждому интервалу и пользователю, сгенерировавшему события в этом интервале, соответствует отдельная строка в таблице. Добавим еще несколько полей, чтобы сделать пример интереснее: source="impl_splunk_gen" | bucket span=1h _time | eval error=if(loglevel="ERROR",1,0) | stats count avg(req_time) dc(ip) sum(error) by _time user В результате получится таблица, изображенная на рис. 10.11. Рис. 10.11  Добавим еще несколько полей 318  Summary-индексы и файлы CSV Теперь все готово к созданию summary-индекса. Переключимся на команду sistats и добавим поле search_name, как это делалось в хранимом запросе. Используем testmode, чтобы гарантировать нормальную работу: source="impl_splunk_gen" | bucket span=1h _time | eval error=if(loglevel="ERROR",1,0) | sistats count avg(req_time) dc(ip) sum(error) by _time user | eval search_name="summary - user stats" | collect index=summary_impl_splunk testmode=true Результаты этого запроса покажут, что фактически будет записано в sum mary-индекс, но, так как этот индекс имеет неудобочитаемый формат, для эксперимента добавим в конец оригинальную инструкцию stats: source="impl_splunk_gen" | bucket span=1h _time | eval error=if(loglevel="ERROR",1,0) | sistats count avg(req_time) dc(ip) sum(error) by _time user | eval search_name="summary - hourly user stats - collect test" | collect index=summary_impl_splunk testmode=true | stats count avg(req_time) dc(ip) sum(error) by _time user Если у себя вы все сделали правильно, то должны получить результаты, похожие на те, что изображены на рис. 10.12. Рис. 10.12  Если вы все сделали правильно, то должны получить похожие результаты Чтобы фактически выполнить запрос, просто удалите testmode из collect: source="impl_splunk_gen" | bucket span=1h _time | eval error=if(loglevel="ERROR",1,0) | sistats count avg(req_time) dc(ip) sum(error) by _time user | eval search_name="summary - user stats" | collect index=summary_impl_splunk Уменьшение размера summary-индекса  319 Обратите внимание: если применить команду collect к периоду времени, для которого в summary-индексе уже имеются данные, вы получите повторяю щиеся результаты. Чтобы избежать этой проблемы, используйте другой интервал времени или команду delete, которая, как упоминалось выше, действует очень неэффективно и вообще не рекомендуется к использованию. Результаты будут доступны только после завершения запроса и создания файла индекса. На моем сервере запросу, выбирающему данные за 1 месяц, потребовалось просмотреть 2.2 миллиона событий, на что ушло 173 секунды, и в результате было создано 2619 summary-событий. Теперь попробуем воспользоваться summary-данными: index=summary_impl_splunk search_name="summary - hourly user stats - collect test" | timechart sum(error) by user В результате получится диаграмма, изображенная на рис. 10.13. Рис. 10.13  Диаграмма, полученная на основе summary-индекса Поскольку диаграмма отображает данные из summary-индекса, на ее создание потребовалось не три минуты, а всего 1.5 секунды. В этом конкретном случае команда collect сгенерировала summary-индекс в четыре раза быстрее, чем скрипт fill_summary_index.py. Но имейте в виду, что при работе с этой командой легко ошибиться, поэтому будьте очень внимательны. Выполняйте пробные запросы с collect testmode=true и завершающей командой stats или timechart. Уменьшение размера summary-индекса Если хранимый запрос, заполняющий summary-индекс, генерирует слишком много результатов, это приведет к снижению эффективности индекса и скорости поиска. Такое может случиться, если одно или несколько полей, используемых для группировки, имеют больше уникальных значений, чем ожидалось. Примером поля с большим количеством уникальных значений может служить URL в журнале веб-сервера. Число уникальных значений URL для сервера может увеличиваться из-за: 320  Summary-индексы и файлы CSV добавления в URL идентификаторов сеанса; добавления в URL критериев поиска; хакерских атак, когда атакующие перебирают все возможные URL, пытаясь найти уязвимость; сканирования всех возможных URL отделом безопасности в попытках убедиться в отсутствии уязвимости. Кроме того, один и тот же ресурс может быть представлен несколькими разными URL, например: /home/index.html; /home/; /home/index.html?a=b; /home/?a=b. Мы рассмотрим несколько решений, позволяющих привести подобные отличающиеся значения к общему виду. Это лишь несколько примеров, и в вашей конкретной ситуации могут потребоваться какие-то иные решения. Определение полей для группировки с помощью eval и rex Один из способов решить проблему – сконструировать новое поле для представления URL с помощью rex. Если вас интересуют только обращения к каталогам, вы можете обобщить URL с помощью одной или нескольких инструкций rex. Рассмотрим фиктивный тип источника impl_splunk_web, которому соответствуют следующие записи в журнале: 2012-08-25T20:18:01 user=bobby GET /products/x/?q=10471480 uid=Mzg2NDc0OA 2012-08-25T20:18:03 user=user3 GET /bar?q=923891 uid=MjY1NDI5MA 2012-08-25T20:18:05 user=user3 GET /products/index.html?q=9029891 uid=MjY1NDI5MA 2012-08-25T20:18:08 user=user2 GET /about/?q=9376559 uid=MzA4MTc5OA Адреса URL имеют сложную структуру. Они могут включать или не включать некоторые компоненты. Например, URL может содержать или не содержать строку запроса, номер страницы или завершающий символ слеша. Чтобы справиться с задачей, вместо попытки создать всеохватывающее регулярное выражение мы воспользуемся инструкцией rex, которая оставляет событие как есть, если в нем не обнаружится совпадений с шаблоном. Взгляните на следующий запрос: sourcetype="impl_splunk_web" | rex "s[A-Z]+s(?P<url>.*?)s" | rex field=url "(?P<url>.*)?" | rex field=url "(?P<url>.*/)" | stats count by url В данном случае он выведет отчет, как показано на рис. 10.14. Уменьшение размера summary-индекса  321 Рис. 10.14  Результат обобщения адресов URL Рассмотрим поближе инструкции rex в этом запросе. rex "s[A-Z]+s(?P<url>.*?)s": этому шаблону соответствует пробел, за которым следуют буквы в верхнем регистре, еще один пробел и, наконец, любые символы до третьего пробела. Атрибут field не определен, поэтому с шаблоном будет сопоставляться поле _raw. Вот как будут выглядеть значения, извлеченные этой инструкцией: – /products/x/?q=10471480; – /bar?q=923891; – /products/index.html?q=9029891; – /about/?q=9376559. rex field=url "(?P<url>.*)?": выполнит сопоставление с полем url. Данному шаблону соответствуют все символы, предшествующие знаку вопроса. Если совпадение найдено, инструкция заместит содержимое поля url результатом совпадения. Иначе поле url останется как есть. Теперь поле url будет содержать следующие значения: – /products/x/; – /bar; – /products/index.html; – /about/. rex field=url "(?P<url>.*/)": и снова сопоставление шаблона будет выполнено с полем url. Данному шаблону соответствуют все символы, пред шествующие последнему найденному символу слеша (включая его). Теперь поле url будет содержать следующие значения: – /products/x/; – /; – /products/; – /about/. Это решение должно уменьшить число возможных URL и тем самым сделать summary-индекс более компактным и эффективным. Вполне возможно, что вам для ваших целей достаточно охватить три уровня вложенности каталогов в URL. Добиться желаемого вам поможет следующая инструкция rex: rex field=url "(?P<url>/(?:[^/]/){,3})" 322  Summary-индексы и файлы CSV Возможности почти бесконечны. Конструируя свои summary-индексы, всегда проверяйте, какой объем данных отбирается заполняющим запросом. Подстановка с метасимволами Splunk поддерживает возможность подстановки с использованием метасимволов, и мы можем воспользоваться ею. Одно из преимуществ этого решения состоит в возможности определить произвольные поля для группировки, не зависящие от значений url. Прежде всего нужно подготовить поле url и определить подстановку. 1.Извлечь поле url. В данном случае с успехом можно использовать шаб лон rex из предыдущего примера: s[AZ]+s(?P<url>.*?)s Подробную информацию об извлечении полей вы найдете в главе 3 «Таблицы, диаграммы и поля». Не забудьте правильно установить разрешения. 2.Создать файл подстановки. Назовем его flatten_summary_lookup.csv. В данном случае добавим следующие строки в файл: url,section /about/*,about /contact/*,contact /*/*,unknown_non_root /*,root *,nomatch Если вы создаете файл подстановки в Excel в Mac OS, обязательно сохраните его в формате Windows comma-separated values (.csv). 3.Загрузить файл на сервер, создать определение подстановки и настроить ее как автоматическую. Подробности вы найдете в разделе «Использование подстановки для обогащения данных» в главе 7 «Расширенный поиск». Определение автоматической подстановки должно выглядеть, как показано на рис. 10.15 (значение в поле Name (Имя) не имеет значения). 4.Настроить разрешения для всех объектов. Обычно для файлов с таблицами подстановки и определений подстановки я выбираю All apps (Все приложения), а для автоматических подстановок – This app only (Только это приложение). Подробности смотрите в главе 7 «Расширенный поиск». 5.Отредактировать transforms.conf. В этой версии Splunk (в действительности начиная с версии 4.3) в веб-интерфейсе доступны не все настройки подстановок. Чтобы изменить нужные нам, приходится редактировать файлы конфигурации. Уменьшение размера summary-индекса  323 Рис. 10.15  Определение автоматической подстановки Более подробно о файлах конфигурации рассказывается в главе 11 «Настройка Splunk», а пока просто добавим две строки в один из файлов. 1.Откройте в редакторе файл $SPLUNK_HOME/etc/apps/is_app_one/local/transforms.conf. Имя каталога is_app_one у вас может отличаться в зависимости от того, в каком приложении создавалось определение подстановки. Если вы не сможете найти этот файл, проверьте разрешения и приложение в административном интерфейсе. 2.В файле найдите две следующие строки или похожие на них, в зависимости от имени, выбранного для файла с таблицей подстановки и определения подстановки: [flatten_summary_lookup] filename = flatten_summary_lookup.csv Если в вашем файле эти строки отсутствуют, проверьте еще раз установленные разрешения. 3. Добавьте еще две строки после строки с именем файла: match_type = WILDCARD(url) max_matches = 1 Фактически эти строки говорят следующее: match_type = WILDCARD(url): вычисляя значение для поля с URL, учитывать метасимволы; без этой настройки сопоставление всегда будет выполняться буквально; 324  Summary-индексы и файлы CSV max_matches = 1: прекращать поиск после первого совпадения. По умолчанию возможно выполнить поиск до 10 совпадений. Нам достаточно первого совпадения – в этом случае подстановка будет действовать на манер инструкции case. Если все было сделано правильно, вы теперь сможете выполнить запрос: sourcetype=impl_splunk_web | stats count by section и получить отчет, изображенный на рис. 10.16. Рис. 10.16  Отчет с автоматической подстановкой Чтобы увидеть происходящее во всех подробностях, выполните такой запрос: sourcetype=impl_splunk_web | rex field=url "(?P<url>.*)?" | stats count by section url Инструкция rex в этом запросе удаляет строку запроса из поля url, созданного механизмом извлечения полей с нашими настройками. В результате мы получим отчет, изображенный на рис. 10.17. Рис. 10.17  Отчет с автоматической подстановкой и инструкцией rex Ниже показано, каким записям в нашем файле с таблицей подстановки соответствуют адреса URL из журнала: Группировка результатов по типам событий  325 url pattern section /about/ /about/* about /contact/ /contact/* contact /bar /* root /foo /* root /products/ /*/* unknown_non_root /products/x/ /*/* unknown_non_root /products/y/ /*/* unknown_non_root Таблица в файле просматривается сверху вниз, и возвращается первое найденное совпадение. Группировка результатов по типам событий Другой подход к группировке результатов для уменьшения размера summa ry-индекса – использование типов событий (event types) не совсем обычным способом. Подробнее о типах событий рассказывается в главе 7 «Расширенный поиск». Этот подход имеет следующие преимущества: все определения создаются в веб-интерфейсе; определения могут быть любой сложности; легко можно ограничить поиск только типами событий, для которых определено имя секции; при желании события можно объединить в множество групп. Недостатки этого подхода: это не самое очевидное решение; неудобно использовать без разделения событий на группы при совпадении с несколькими типами событий. Например, вам сложно будет отличить совпадения с /product/x/* от /product/*. Вот как выглядит процедура создания подобных типов событий: 1. Для каждой секции создайте тип события, как показано на рис. 10.18. 2.Настройте разрешения как This app only или Global, в зависимости от области видимости. 3.Повторите пункты 1 и 2 для каждой секции, по которой предполагается производить объединение. Ссылка Clone (Копировать) в окне диспетчера поможет вам ускорить процесс. После создания типов событий можно приступать к запросу. Значение, указанное в поле Tag (Тег), поможет нам отобрать только события, соответствующие имени секции: tag::eventtype="summary_url" | top eventtype Этот запрос выведет таблицу, изображенную на рис. 10.19. 326  Summary-индексы и файлы CSV Рис. 10.18  Создание нового типа события Рис. 10.19  Результаты поиска по типам событий В результатах теперь отображаются события созданных нами новых типов, а также нежелательное событие с типом bogus. Как вы наверняка помните, в результаты включаются все события, соответствующие определению типа. Это очень мощная возможность, но иногда результаты не соответствуют нашим ожиданиям. Так получилось с типом события bogus, который определен как *, то есть этому типу соответствуют все события. Тип bogus добавлен исключительно для иллюстрации и не имеет практического значения. Подсчет наиболее часто встречающихся данных в больших интервалах времени  327 Давайте создадим новое поле из имени типа события и организуем объединение по этому полю: tag::eventtype="summary_url" | rex field=eventtype "url_(?P<section>.*)" | stats count by section Этот запрос вернет результаты, изображенные на рис. 10.20. Рис. 10.20  Результаты после объединения по новому полю Запрос отобрал только события с определенными типами – именно то, что нам нужно. Чтобы сгруппировать все остальные события в группу other, нужно отыскать все остальные события: sourcetype=impl_splunk_web | rex field=eventtype "url_(?P<section>.*)" | fillnull value="other" section | stats count by section Этот запрос выведет отчет, изображенный на рис. 10.21. Рис. 10.21  Результаты после добавления объединения в группу other Надеюсь, эти примеры послужат вам пищей для размышлений, когда вам понадобится преобразовать результаты поиска в более компактную обобщенную форму. Подсчет наиболее часто встречающихся данных в больших интервалах времени На практике часто возникает необходимость отыскать наиболее часто встречаю щиеся значения в огромном наборе уникальных значений. Например, если 328  Summary-индексы и файлы CSV вы пожелаете узнать, какие IP-адреса расходуют большую часть пропускной способности вашего шлюза в данный день или в неделю, вам может понадобиться проверить миллионы уникальных адресов, чтобы получить ответ. Если для этой цели использовать summary-индекс, вам придется сохранить в нем миллионы событий, вследствие чего индекс быстро потеряет свою эффективность. Исключительно для иллюстрации рассмотрим следующий простой набор данных: Time 1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4 5.5.5.5 6.6.6.6 12:00 99 100 100 100 13:00 99 100 100 100 14:00 99 100 101 100 15:00 99 99 100 100 16:00 99 100 100 100 total 495 300 299 401 400 100 Если сохранять в индексе только топ-3 IP-адресов в час, набор данных будет выглядеть примерно так: Time 1.1.1.1 2.2.2.2 3.3.3.3 4.4.4.4 5.5.5.5 6.6.6.6 12:00 100 100 100 13:00 100 100 100 14:00 100 101 100 15:00 99 100 100 16:00 100 100 100 total 300 299 401 400 100 Судя по этому набору данных, топ-3 включает IP-адреса: 4.4.4.4, 5.5.5.5 и 2.2.2.2. Тогда как фактически первое место принадлежит адресу 1.1.1.1, но он отсутствует в результатах, потому что никогда не входил в топ-3. Чтобы решить эту проблему, в каждом интервале нужно сохранить больше точек данных. Но сколько? Используя генератор данных, подсчитаем случайные числа и посмотрим, что получится. Я применил следующий запрос к своему набору данных: source="impl_splunk_gen" | top req_time Выполняя поиск на недельном интервале, этот запрос вернул результаты, изображенные на рис. 10.22. Сколько всего уникальных значений? Ответ на этот вопрос дает следующий запрос: source="impl_splunk_gen" | stats dc(req_time) Выполнив поиск в моих данных, он сообщил, что в наборе всего 12 239 уникальных значений req_time. А сколько уникальных значений встречается в каждом часе? Следующий запрос подсчитает среднее значение уникальных значений за час: Подсчет наиболее часто встречающихся данных в больших интервалах времени  329 source="impl_splunk_gen" | bucket span=1h _time | stats dc(req_time) as dc by _time | stats avg(dc) Рис. 10.22  Результаты поиска на недельном интервале У меня получилось, что в среднем в каждом часе встречается 3367 уникальных значений req_time. То есть если сохранить все значения req_time за неделю, в индекс будет записано 3 367 * 24 * 7 = 565 656 значений. Сколько значений достаточно сохранить в каждом часе, чтобы получить тот же ответ, что был получен выше? Ответ на этот вопрос может дать следующий запрос: source="impl_splunk_gen" | bucket span=1h _time | stats count by _time req_time | sort 0 _time -count | streamstats count as place by _time | where place<50 | stats sum(count) as count by req_time | sort 0 -count | head 10 Разберем этот запрос. source="impl_splunk_gen": отыскивает все события. | bucket span=1h _time: приводит значение поля _time к началу часа. Мы будем использовать этот прием для имитации почасовых summaryзапросов. | stats count by _time req_time: подсчитывает число уникальных значений req_time в часе. 330  Summary-индексы и файлы CSV | sort 0 _time -count: сортирует все выбранные события (именно это озна чает число 0), сначала в порядке возрастания _time, а затем в порядке убывания count. | streamstats count as place by _time: перебирает события в цикле, постепенно наращивая place и начиная счет count заново при изменении _time. Напомню, что значение _time предварительно приводится к началу часа. | where place<50: сохраняет первые 50 событий в каждом часе. Это будут события с 50 наибольшими значениями count, потому что выше мы уже отсортировали события по полю count в порядке убывания. | stats sum(count) as count by req_time: суммирует все, что осталось в каждом часе. | sort 0 -count: сортирует события по count в порядке убывания. | head 10: возвращает первые 10 результатов. И что же у нас получилось? Сохраняя топ-50 результатов в каждом часе, я получил результаты, изображенные на рис. 10.23. Рис. 10.23  Результаты сохранения топ-50 результатов Как видите, полученные результаты довольно далеки от истины. Повторим попытку. На этот раз попробуем where place<1000. Полученные результаты показаны на рис. 10.24. Так намного лучше, но все еще есть отклонения. После нескольких экспериментов я выяснил, что place<2000 вполне достаточно, чтобы получить ожидаемую десятку топ-10. Это лучше, чем сохранять по 3367 записей за каждый час. Разница может показаться недостаточно большой, чтобы проявлять беспокойство, но если число событий увеличится в 10 или в 100 раз, разница может оказаться гигантской. Чтобы использовать эти результаты в summary-индексе, можно просто исключить результаты, направляемые в набор данных. Вот один из способов, как это можно реализовать: Подсчет наиболее часто встречающихся данных в больших интервалах времени  331 source="impl_splunk_gen" | sitop req_time | streamstats count as place | where place<2001 Рис. 10.24  Результаты сохранения топ-1000 результатов Первая запись, возвращаемая командой sitop, содержит суммарное значение. Другой подход – использовать комбинацию eventstats и sistats, как показано ниже: source="impl_splunk_gen" | eventstats count by req_time | sort 0 -req_time | streamstats count as place | where place<2001 | sistats count by req_time К счастью, это не самая распространенная задача, поэтому большинства сложностей, связанных с ней, можно избежать. Описание еще одного варианта вы найдете в разделе «Определение вычислений, выполняющихся в течение дня». Поиск в summary-индексе Готовые summary-индексы можно заполнять с помощью практически любых хранимых запросов и отчетов. В веб-интерфейсе Splunk summary-индексы доступны для отчетов как оповещения. Чтобы задействовать summary-индекс в хранимом отчете: 1)перейдите на страницу Settings  Searches, Reports, and alerts (Настройки  Поиск, отчеты и оповещения); 2) выберите отчет по имени; 3)в списке Schedule and alert (Расписание и оповещение) выберите Sche dule (Расписание); 332  Summary-индексы и файлы CSV 4)определите расписание для запуска отчета (в документации на Splunk. com отмечается, что «для достижения статистической точности отчетов запросы, заполняющие summary-индексы, должны выполняться достаточно часто»); 5)в разделе Alert (Оповещение) выберите в списке Condition (Условие) значение Always (Всегда); 6)в Alert mode (Режим оповещения) выберите Once per search (Один раз на запрос); 7)в summary indexing (запись в summary-индекс) выберите Enable (Включить); 8)в списке Select the summary index (Выберите summary-индекс) выберите summary-индекс, который будет заполняться отчетом. Вот и все! Теперь запрос или отчет будет использовать summary-индекс. Использование файлов CSV для хранения промежуточных данных Иногда небольшие объемы данных удобно хранить за пределами индексов Splunk. Используя команды inputcsv и outputcsv, можно организовать хранение табличных данных в файлах CSV. Предварительное заполнение раскрывающегося списка Если дашборд содержит динамический раскрывающийся список, для его заполнения приходится выполнять поиск. С увеличением объемов данных запрос, заполняющий этот список, будет работать все медленнее и медленнее, даже при использовании summary-индекса. Однако для хранения требуемой информации можно использовать файл CSV, добавляя в него новые значения по мере их обнаружения. Для этого сначала нужно определить запрос, генерирующий файл CSV. Этот запрос должен просмотреть как можно больше данных: source="impl_splunk_gen" | stats count by user | outputcsv user_list.csv Затем нужно определить запрос, который будет выполняться периодически и добавлять в файл новые записи. Этот отчет нужно сохранить и определить расписание для его запуска: source="impl_splunk_gen" | stats count by user | append [inputcsv user_list.csv] | stats sum(count) as count by user | outputcsv user_list.csv Использование файлов CSV для хранения промежуточных данных  333 После этого, чтобы воспользоваться полученным файлом CSV, достаточно добавить в дашборд простой заполняющий запрос: |inputcsv user_list.csv Вот пример дашборда на упрощенном XML, использующего этот запрос: <input type="dropdown" token="sourcetype"> <label>User</label> <populatingSearch fieldForValue="user" fieldForLabel="user"> |inputcsv user_list.csv </populatingSearch> </input> Создание вычислений, выполняющихся в течение дня Если в течение дня накапливаются миллионы или десятки миллионов событий, выполнение запросов, просматривающих все события за день, может оказаться слишком дорогим удовольствием. По этой причине имеет смысл выполнять некоторые вычисления частями, по небольшим интервалам времени. Использовать summary-индекс для хранения промежуточных результатов не всегда целесообразно, особенно если эти значения нужны лишь в течение ограниченного времени. В разделе «Подсчет наиболее часто встречающихся данных в больших интервалах времени» обсуждение закончилось решением, сохраняющим тысячи значений каждые несколько минут. Для случая, когда нужно всего лишь узнать топ-10 за день, такое решение можно рассматривать как чересчур избыточное. Чтобы уменьшить объем информации в summaryиндексе, в качестве недорогого хранилища промежуточных данных можно использовать файл CSV. Для этого требуется совсем немного: 1)периодически запрашивать новые порции данных и обновлять содержимое CSV; 2) в конце дня сохранить топ значений в summary-индексе; 3) очистить файл CSV. Вот как мог бы выглядеть периодически выполняемый запрос: source="impl_splunk_gen" | stats count by req_time | append [inputcsv top_req_time.csv] | stats sum(count) as count by req_time | sort 10000 -count | outputcsv top_req_time.csv Разберем его строку за строкой. source="impl_splunk_gen": этот запрос отыскивает события, принадлежащие данному интервалу времени. | stats count by req_time: помогает вычислить количество уникальных значений req_time. 334  Summary-индексы и файлы CSV | append [inputcsv top_req_time.csv]: загружает из файла CSV уже имеющие ся результаты и добавляет в конец события из текущих результатов. | stats sum(count) as count by req_time: использует stats для объединения прошлых и текущих результатов. | sort 10000 -count: сортирует результаты в порядке убывания count. Второй член, 10000, указывает, что сохранить требуется только первые 10 000 результатов. | outputcsv top_req_time.csv: записывает обновленные данные обратно в файл CSV. Теперь можно организовать выполнение этого запроса по расписанию, например каждые 15 минут, следуя тем же правилам, касающимся задержки, что были перечислены в разделе «Как задержка влияет на запросы, использующие summary-индексы». Для извлечения накопленных данных, например в каждую полночь, запланируйте запуск еще двух запросов с интервалом в несколько минут: | inputcsv top_req_time.csv | head 100: этот запрос добавляет новую порцию информации в summary-индекс; сохраните его, как описано в разделе «Заполнение summary-индексов в хранимых запросах»; | stats count |outputcsv top_req_time.csv: этот запрос просто очищает файл CSV, записывая в него единственную строку. Итоги В данной главе мы рассмотрели приемы использования summary-индексов и соответствующих команд. Хотя summary-индексы не всегда являются правильным выбором, они могут очень пригодиться для решения определенного круга задач. Мы также исследовали альтернативные подходы, используя файлы CSV для хранения промежуточных данных. В следующей главе мы погрузимся в конфигурационные файлы, управляющие работой Splunk. Глава 11 Настройка Splunk Все управление системой Splunk сосредоточено в конфигурационных файлах, хранящихся в файловой системе каждого сервера Splunk. Эти обычные текстовые файлы в открытом, удобочитаемом формате, которые легко можно править с помощью любого текстового редактора. До настоящего момента мы работали в основном в веб-интерфейсе, но все изменения, которые мы вносили, в конечном итоге оказывались в этих конфигурационных файлах. Несмотря на широту возможностей веб-интерфейса, кое-что возможно только путем прямого редактирования конфигурационных файлов. Эта глава охватывает следующие темы: местоположение конфигурационных файлов; слияние конфигураций; отладка конфигураций; часто используемые конфигурационные файлы и параметры в них. Местоположение конфигурационных файлов Splunk Конфигурационные файлы Splunk располагаются в каталоге $SPLUNK_HOME/etc. Он напоминает каталог /etc в Unix, но находится внутри каталога установки Splunk. Благодаря такой организации конфигурационные файлы не должны принадлежать суперпользователю root. В действительности сервер Splunk может работать с правами любого непривилегированного пользователя (если не предполагается открывать порты с номерами ниже 1024 или читать файлы, доступные для чтения только другим пользователям). Ниже перечислены подкаталоги с конфигурационными файлами. $SPLUNK_HOME/etc/system/default: здесь хранятся конфигурационные файлы с настройками по умолчанию, которые поставляются в составе дистрибутива Splunk. Никогда не редактируйте эти файлы, потому что они затираются при каждом обновлении версии. $SPLUNK_HOME/etc/system/local: здесь хранятся глобальные настройки для данного хоста, переопределяющие настройки по умолчанию. Те немногие конфигурационные файлы, что находятся здесь, создаются в основ- 336  Настройка Splunk ном самой системой Splunk. Если вам понадобится изменить какие-то настройки для своих приложений, практически всегда предпочтительнее делать это в конфигурационных файлах самих приложений. $SPLUNK_HOME/etc/apps/$app_name/default: место хранения конфигурационных файлов для приложения с именем app_name, которые должны распространяться вместе с приложением, через Splunkbase или любым другим способом. $SPLUNK_HOME/etc/apps/$app_name/local: здесь хранится большинство конфигурационных файлов, в том числе общедоступные файлы, создаваемые посредством веб-интерфейса. $SPLUNK_HOME/etc/users/$user_name/$app_name/local: когда в веб-интерфей се создается новый запрос, он получает разрешение по умолчанию Private, и соответствующие настройки сохраняются в каталоге для пользователя или приложения. После изменения разрешений конфигурационный файл переместится в соответствующий каталог с именем $app_name/local. Существует еще несколько каталогов с файлами без расширения .conf. Мы поговорим о них далее в этой главе, в разделе «Ресурсы пользовательского интерфейса». Структура конфигурационных файлов Splunk Файлы .conf, используемые системой Splunk, близко напоминают файлы .ini. Вот пример простого конфигурационного файла: #settings for foo [foo] bar=1 la = 2 Дадим пару определений: stanza (раздел): используются для группировки атрибутов. В примере выше определен один раздел [foo]. Часто разделы называют просто станзами. Запомните следующие важные ограничения: – имя раздела должно быть уникальным в пределах файла; – порядок разделов не имеет значения; атрибут: атрибут – это пара имя/значение. В примере выше определены атрибуты bar и la. Часто атрибуты называют также параметрами. Запомните следующие важные ограничения: – имена атрибутов не должны содержать пробелов и знака «равно» (=); – каждый атрибут принадлежит разделу, объявленному выше; если атрибут объявлен до определения любых разделов, он принадлежит разделу [default]; – имя атрибута должно быть уникальным в пределах раздела, но это ограничение не распространяется на весь файл; Логика слияния конфигураций  337 – каждый атрибут должен определяться в отдельной строке и может занимать только одну строку. Наличие или отсутствие пробелов вокруг знака «равно» (=) не имеет значения. Вот еще несколько правил, которые могут не поддерживаться в других реализациях: имена разделов и атрибутов чувствительны к регистру символов; комментарии начинаются с символа #; атрибуты, объявленные перед любыми разделами, включаются в раздел [default]; любые атрибуты в разделе [default] добавляются во все остальные разделы, не имеющие атрибутов с такими именами. Логика слияния конфигураций Конфигурации, хранящиеся в разных каталогах, за кулисами объединяются в одну суперконфигурацию. Слияние происходит вполне предсказуемым способом, правила которого легко запомнить. В вашем распоряжении имеется также инструмент для предварительного просмотра результата слияния. Порядок слияния Порядок слияния может меняться в зависимости от того, где используется конфигурация – в механизме поиска или в какой-то другой части Splunk. Разница определяется наличием активного пользователя и приложения. Порядок слияния за пределами уровня поиска Порядок слияния конфигураций за пределами механизма поиска очень прост. К конфигурациям в данном случае относятся файлы для чтения, индексированные поля для создания, существующие индексы, конфигурации deployment сервера и deployment клиента и другие настройки. Слияние всех этих конфигураций происходит в следующем порядке. 1.$SPLUNK_HOME/etc/system/default: этот каталог содержит конфигурации по умолчанию, распространяемые вместе с дистрибутивом Splunk. Никогда не изменяйте файлы конфигурации в данном каталоге, так как все ваши изменения будут утрачены после обновления версии Splunk. 2.$SPLUNK_HOME/etc/apps/*/default: настройки из файлов конфигурации в этом каталоге накладываются на суперконфигурацию в обратном порядке сортировки имен каталогов приложений, то есть a бьет z. 3. $SPLUNK_HOME/etc/apps/*/local. 4. $SPLUNK_HOME/etc/system/local: конфигурации из этого каталога применяются последними; за пределами механизма поиска эти конфигурации не переопределяются конфигурациями приложений. Приложения дают очень удобный способ разделения управления и распространения конфигураций. Это особенно важно в архитектурах, где имеется deploy 338  Настройка Splunk ment-сервер, о котором мы поговорим в главе 12 «Продвинутая настройка». Никогда не редактируйте конфигурации в $SPLUNK_HOME/etc/system/local, даже если вам кажется, что для этого есть все основания. Практически всегда править конфигурации лучше в каталогах приложений. Вот небольшой фрагмент псевдокода, поясняющий правила выше: $conf = new Configuration('$SPLUNK_HOME/etc/') $conf.merge( 'system/default/$conf_name' ) for $this_app in reverse(sort(@all_apps)): $conf.merge( 'apps/$this_app/default/$conf_name' ) for $this_app in reverse(sort(@all_apps)): $conf.merge( 'apps/$this_app/local/$conf_name' ) $conf.merge( 'system/local/$conf_name' ) Порядок слияния на уровне поиска При обработке поисковых запросов используется более сложный порядок слияния конфигураций. Когда запускается поиск, практически всегда есть активный пользователь и приложение, и это обстоятельство обязательно учитывается при определении объединенной конфигурации. В общем случае слияние происходит в следующем порядке: 1. $SPLUNK_HOME/etc/system/default. 2. $SPLUNK_HOME/etc/system/local. 3. $SPLUNK_HOME/etc/apps/<не текущее приложение>. выполняется обход всех приложений, отличных от текущего, в алфавитном порядке имен их каталогов (не отображаемых имен приложений). В отличие от слияния за пределами поискового механизма, здесь z бьет a; применяются все конфигурационные атрибуты с глобальной областью видимости, сначала из default, а затем из local. 4.$SPLUNK_HOME/etc/apps/app: применяются все конфигурационные атрибуты, сначала из default, а затем из local. 5. $SPLUNK_HOME/etc/users/user/app/local: Следующий псевдокод, возможно, лучше пояснит эти правила: $conf = new Configuration('$SPLUNK_HOME/etc/') $conf.merge( 'system/default/$conf_name' ) $conf.merge( 'system/local/$conf_name' ) for $this_app in sort(@all_apps): if $this_app != $current_app: $conf.merge_shared( 'apps/$this_app/default/$conf_name' ) $conf.merge_shared( 'apps/$this_app/local/$conf_name' ) $conf.merge( 'apps/$current_app/default/$conf_name' ) $conf.merge( 'apps/$current_app/local/$conf_name' ) $conf.merge( 'users/$current_user/$current_app/local/$conf_name' ) Логика слияния конфигураций  339 Логика слияния конфигураций Теперь, узнав порядок слияния конфигураций, познакомимся с фактической логикой слияния. В действительности она очень проста: имя конфигурационного файла, имя раздела и имя атрибута должны совпадать точно; в силу вступает последнее примененное значение атрибута. Чтобы лучше понять логику слияния конфигураций, разберем несколько практических примеров. Слияние конфигураций – пример 1 Допустим, у нас есть базовая конфигурация в default/sample1.conf: [foo] bar=10 la=20 и уточненная конфигурация в local/sample1.conf: [foo] bar=15 Объединенная конфигурация будет иметь вид: [foo] bar=15 la=20 Обратите внимание на следующее: вторая конфигурация не просто замещает первую; атрибут bar получил значение из второй конфигурации; отсутствие атрибута la во второй конфигурации не влечет его удаления из объединенной конфигурации. Слияние конфигураций – пример 2 Допустим, у нас есть базовая конфигурация default/sample2.conf: [foo] bar = 10 la=20 [pets] cat = red Dog=rex и уточненная конфигурация в local/sample2.conf: [pets] cat=blue dog=fido fish = bubbles [foo] bar= 15 [cars] ferrari =0 340  Настройка Splunk Объединенная конфигурация будет иметь вид: [foo] bar=15 la=20 [pets] cat=blue dog=rex Dog=fido fish=bubbles [cars] ferrari=0 Обратите внимание на следующее: порядок следования разделов не имеет значения; пробелы вокруг знака «равно» (=) не имеют значения; атрибут Dog не переопределяется атрибутом dog, потому что все имена разделов и атрибутов чувствительны к регистру символов; раздел cars добавлен в окончательную конфигурацию целиком. Слияние конфигураций – пример 3 Усложним задачу и рассмотрим слияние четырех конфигураций из разных каталогов. В данном случае будем считать, что конфигурации используются за пределами механизма поиска, поэтому будем использовать правила из раздела «Порядок слияния за пределами механизма поиска». В $SPLUNK_HOME/etc/apps/d/default/props.conf определены следующие парамет ры настройки: [web_access] MAX_TIMESTAMP_LOOKAHEAD = 25 TIME_PREFIX = ^[ [source::*.log] BREAK_ONLY_BEFORE_DATE = true В $SPLUNK_HOME/etc/system/local/props.conf: BREAK_ONLY_BEFORE_DATE = false [web_access] TZ = CST В $SPLUNK_HOME/etc/apps/d/local/props.conf: [web_access] TZ = UTC [security_log] EXTRACT-<name> = [(?P<user>.*?)] В $SPLUNK_HOME/etc/apps/b/default/props.conf: [web_access] MAX_TIMESTAMP_LOOKAHEAD = 20 TIME_FORMAT = %Y-%m-%d $H:%M:%S [source::*/access.log] BREAK_ONLY_BEFORE_DATE = false Логика слияния конфигураций  341 Я нарочно перечислил файлы не в порядке их слияния. В действительности слияние произойдет в следующем порядке: $SPLUNK_HOME/etc/apps/d/default/props.conf $SPLUNK_HOME/etc/apps/b/default/props.conf $SPLUNK_HOME/etc/apps/d/local/props.conf $SPLUNK_HOME/etc/system/local/props.conf Рассмотрим каждый этап слияния и получающуюся в его конце конфигу рацию. 1.Первым в объединенную конфигурацию добавляется файл $SPLUNK_HOME/ etc/apps/d/default/props.conf: [web_access] MAX_TIMESTAMP_LOOKAHEAD = 25 TIME_PREFIX = ^[ [source::*.log] BREAK_ONLY_BEFORE_DATE = true 2. Затем добавляется файл $SPLUNK_HOME/etc/apps/b/default/props.conf: [web_access] MAX_TIMESTAMP_LOOKAHEAD = 30 TIME_PREFIX = ^[ TIME_FORMAT = %Y-%m-%d $H:%M:%S [source::*.log] BREAK_ONLY_BEFORE_DATE = true [source::*/access.log] BREAK_ONLY_BEFORE_DATE = false Даже притом что оба имени – [source::*.log] и [source::*/access.log] – соответствуют имени файла access.log, эти два раздела не объединяются, потому что их имена не совпадают точно друг с другом. Более подробно мы рассмотрим эту логику в подразделе «Типы разделов» раздела props.conf. 3. Далее добавляется файл $SPLUNK_HOME/etc/apps/d/local/props.conf: [web_access] MAX_TIMESTAMP_LOOKAHEAD = 30 TIME_PREFIX = ^[ TIME_FORMAT = %Y-%m-%d $H:%M:%S TZ = UTC [source::*.log] BREAK_ONLY_BEFORE_DATE = true [source::*/access.log] BREAK_ONLY_BEFORE_DATE = false [security_log] EXTRACT-<name> = [(?P<user>.*?)] 4.И наконец, добавляется файл $SPLUNK_HOME/etc/system/local/props.conf, переопределяющий глобальные настройки: [default] BREAK_ONLY_BEFORE_DATE = false [web_access] 342  Настройка Splunk MAX_TIMESTAMP_LOOKAHEAD = 25 TIME_PREFIX = ^[ TIME_FORMAT = %Y-%m-%d $H:%M:%S TZ = CST BREAK_ONLY_BEFORE_DATE = false [source::*.log] BREAK_ONLY_BEFORE_DATE = true [source::*/access.log] BREAK_ONLY_BEFORE_DATE = false [security_log] EXTRACT-<name> = [(?P<user>.*?)] BREAK_ONLY_BEFORE_DATE = false Наибольший интерес здесь представляет атрибут BREAK_ONLY_BEFORE_DATE = false. Сначала он добавляется в раздел [default], а затем во все остальные разделы, не имеющие этого атрибута. Старайтесь не размещать атрибуты за пределами каких-либо разделов или в разделе [default]. Окончательный результат может оказаться совсем не таким, какого вы ожидаете. Слияние конфигураций – пример 4, поиск Теперь рассмотрим пример слияния конфигураций внутри механизма поиска, с более сложным порядком. Допустим, что в текущий момент мы работаем в приложении d, и объединим те же конфигурации, что были показаны в разделе «Слияние конфигураций – пример 3». Для простоты предположим, что все атрибуты имеют глобальную область видимости. Для текущего приложения d слияние конфигураций будет выполнено в следующем порядке: $SPLUNK_HOME/etc/system/local/props.conf $SPLUNK_HOME/etc/apps/b/default/props.conf $SPLUNK_HOME/etc/apps/d/default/props.conf $SPLUNK_HOME/etc/apps/d/local/props.conf Рассмотрим каждый этап слияния и получающуюся в его конце конфигу рацию. 1.Первым в объединенную конфигурацию добавляется файл $SPLUNK_HOME/ etc/system/local/props.conf: BREAK_ONLY_BEFORE_DATE = false [web_access] TZ = CST 2.Затем добавляются конфигурации по умолчанию для приложений, отличных от текущего (в данном случае имеется одна такая конфигурация) $SPLUNK_HOME/etc/apps/b/default/props.conf: BREAK_ONLY_BEFORE_DATE = false [web_access] Логика слияния конфигураций  343 MAX_TIMESTAMP_LOOKAHEAD = 20 TIME_FORMAT = %Y-%m-%d $H:%M:%S TZ = CST [source::*/access.log] BREAK_ONLY_BEFORE_DATE = false 3.Далее добавляются конфигурации по умолчанию для текущего приложения $SPLUNK_HOME/etc/apps/d/default/props.conf: BREAK_ONLY_BEFORE_DATE = false [web_access] MAX_TIMESTAMP_LOOKAHEAD = 25 TIME_PREFIX = ^[ TIME_FORMAT = %Y-%m-%d $H:%M:%S TZ = CST [source::*/access.log] BREAK_ONLY_BEFORE_DATE = false [source::*.log] BREAK_ONLY_BEFORE_DATE = true 4.После этого добавляются конфигурации из local для текущего приложения $SPLUNK_HOME/etc/apps/d/local/props.conf: BREAK_ONLY_BEFORE_DATE = false [web_access] MAX_TIMESTAMP_LOOKAHEAD = 25 TIME_PREFIX = ^[ TIME_FORMAT = %Y-%m-%d $H:%M:%S TZ = UTC [source::*/access.log] BREAK_ONLY_BEFORE_DATE = false [source::*.log] BREAK_ONLY_BEFORE_DATE = true [security_log] EXTRACT-<name> = [(?P<user>.*?)] 5.И наконец, из раздела default копируются атрибуты в другие разделы, если они отсутствуют в тех разделах: BREAK_ONLY_BEFORE_DATE = false [web_access] MAX_TIMESTAMP_LOOKAHEAD = 25 TIME_PREFIX = ^[ TIME_FORMAT = %Y-%m-%d $H:%M:%S TZ = UTC BREAK_ONLY_BEFORE_DATE = false [source::*/access.log] BREAK_ONLY_BEFORE_DATE = false [source::*.log] BREAK_ONLY_BEFORE_DATE = true [security_log] EXTRACT-<name> = [(?P<user>.*?)] BREAK_ONLY_BEFORE_DATE = false Powered by TCPDF (www.tcpdf.org) 344  Настройка Splunk Я знаю, что многим из вас сейчас все это кажется сложным и запутанным, но не огорчайтесь, понимание обязательно придет с практикой. К счастью, есть инструмент btool, рассматривающийся в следующем разделе, который упрощает изучение объединенных конфигураций. Инструмент btool Чтобы увидеть объединенную конфигурацию, можно воспользоваться инструментом командной строки btool. В документации на сайте Splunk можно найти одно из моих любимых примечаний: «btool не тестировался разработчиками Splunk, официально не поддерживается, и правильность его работы не гарантируется. Тем не менее он используется командой технической поддержки при разрешении проблем, возникающих у пользователей». Несмотря на это грозное предупреждение, btool никогда не подводил меня. Этот инструмент поддерживает несколько функций, но я пользовался только одной из них – функцией list: $SPLUNK_HOME/bin/splunk cmd btool props list Эта команда выведет 5277 строк, которые я не буду приводить здесь. Вместо этого поинтересуемся содержимым раздела impl_splunk_gen, добавив это имя в конец команды: /opt/splunk/bin/splunk cmd btool props list impl_splunk_gen В результате мы получим следующее: [impl_splunk_gen] ANNOTATE_PUNCT = True BREAK_ONLY_BEFORE = BREAK_ONLY_BEFORE_DATE = True ... вырезано ... LINE_BREAKER_LOOKBEHIND = 100 LOOKUP-lookupusers = userslookup user AS user OUTPUTNEW MAX_DAYS_AGO = 2000 ... вырезано ... TRUNCATE = 10000 TZ = UTC maxDist = 100 Конфигурационный файл $SPLUNK_HOME/etc/apps/ImplementingSplunkDataGenerator/local/props.conf содержит лишь такие строки: [impl_splunk_web] LOOKUP-web_section = flatten_summary_lookup url AS url OUTPUTNEW EXTRACT-url = s[A-Z]+s(?P<url_from_app_local>.*?)s EXTRACT-foo = s[A-Z]+s(?P<url_from_app>.*?)s Обзор конфигурационных файлов Splunk  345 Так откуда взялись все остальные настройки? Добавив флаг -debug, мы получим ответ на вопрос: /opt/splunk/bin/splunk cmd btool props list impl_splunk_gen -debug Эта команда сгенерирует следующий запрос: Implementi [impl_splunk_gen] system ANNOTATE_PUNCT = True system BREAK_ONLY_BEFORE = system BREAK_ONLY_BEFORE_DATE = True ... вырезано ... system LINE_BREAKER_LOOKBEHIND = 100 Implementi LOOKUP-lookupusers = userslookup user AS user OUTPUTNEW system MAX_DAYS_AGO = 2000 ... вырезано ... system TRUNCATE = 10000 Implementi TZ = UTC system maxDist = 100 Первый столбец, хоть и усеченный, содержит все, что нам нужно знать. Подавляющее число параметров определено в каталоге system, скорее всего, в файле system/default/props.conf. Настройки из нашего файла отмечены меткой Implementi, включающей первые символы из имени каталога приложения, ImplementingSplunkDataGenerator. Если вам когда-нибудь потребуется узнать, откуда получен тот или иной параметр настройки, инструмент btool поможет вам сэкономить массу времени на поисках. Также обратите внимание на приложение Splunk on Splunk в Splunkbase, открывающее доступ к btool из веб-интерфейса Splunk. Обзор конфигурационных файлов Splunk Потратив некоторое время на изучение содержимого каталогов Splunk, можно заметить, что в них имеется множество файлов с расширением .conf. В этом разделе мы кратко познакомимся с наиболее типичными их представителями. Полный перечень файлов и атрибутов вы найдете в официальной документации. Самый быстрый способ найти описание в официальной документации – выполнить запрос Splunk filename.conf в своей любимой поисковой системе. Например, в ответ на запрос Splunk props.conf все поисковые системы, проверенные мною, в первых же результатах выводят ссылку на описание props.conf в официальной документации Splunk. props.conf Разделы в props.conf определяют события, соответствующие хостам, источникам и типам источников. Эти разделы объединяются в основную конфигурацию в соответствии с уникальностью имен разделов и атрибутов, как и любые 346  Настройка Splunk другие конфигурации, но существуют определенные правила, когда каждый раздел применяется к событию и в каком порядке. Проще говоря, атрибуты сортируются по типу, затем по уровню приоритета, а потом по алфавиту. Подробнее эти правила рассматриваются в разделе «Типы разделов». Для начала познакомимся с общими атрибутами. Общие атрибуты Полный набор атрибутов, которые можно увидеть в props.conf, обширен. Давайте рассмотрим наиболее типичные из них и попробуем разбить их по случаям применения. Атрибуты времени поиска Наиболее распространенные атрибуты в props.conf, которые используются пользователями, – это настройки, отвечающие за извлечение полей. Когда пользователь определяет в веб-интерфейсе извлекаемое поле, соответствующий атрибут сохраняется в файле props.conf, например: [my_source_type] EXTRACT-foo = s(?<bar>d+)ms EXTRACT-cat = s(?<dog>d+)s Эта конфигурация определяет поля bar и dog с типом источника my_source_ type. Определения извлекаемых полей – самые распространенные настройки времени поиска. Их можно помещать в секции любых типов, описанных в разделе «Типы разделов», но чаще используются разделы с именами типов источников. К числу других типичных атрибутов времени поиска можно отнести: REPORT-foo = bar: этот атрибут является своеобразной ссылкой на раздел в transforms.conf, но применяется во время поиска, а не индексации. Этот подход использовался до появления EXTRACT, но все еще находит применение в некоторых особых случаях. Более подробно мы поговорим о таких случаях в разделе transforms.conf; KV_MODE = auto: этот атрибут позволяет указать, должна ли система Splunk автоматически извлекать поля из событий. По умолчанию атрибуту присваивается значение auto. Часто этому атрибуту присваивается значение none, чтобы отключить автоматическое извлечение полей из соображений производительности. Также поддерживаются значения multi, JSON и XML; LOOKUP-foo = mylookup barfield: этот атрибут позволяет включить автоматическую подстановку для набора событий. Сама подстановка должна быть определена в файле transforms.conf. Атрибуты времени индексирования Как обсуждалось в главе 3 «Таблицы, диаграммы и поля», в разделе «Индексируемые и извлекаемые поля», существует возможность добавлять поля в метаданные событий. Это достигается добавлением преобразований в файл transforms.conf и атрибутов в props.conf, связы вающих преобразования с событиями. Обзор конфигурационных файлов Splunk  347 Атрибут в props.conf выглядит так: TRANSFORMS-foo = bar1,bar2 Этот атрибут ссылается на разделы в transforms.conf по их именам, в данном случае bar1 и bar2. Настройки из разделов в transforms.conf, указанных в атрибуте в props.conf, затем применяются к перечисленным событиям. Атрибуты времени парсинга Большинство атрибутов в props.conf на самом деле управляет парсингом событий. Для успешного парсинга событий требуется ответить на несколько вопросов. Как найти начало нового события? Являются ли события многострочными? Конечно, Splunk постарается самостоятельно найти ответы на эти вопросы, но лучше явно указать точные настройки, в том числе: – SHOULD_LINEMERGE = false: если известно, что событие никогда не будет содержать символа перевода строки, присвойте этому атрибуту значение false, чтобы исключить ненужную обработку; – BREAK_ONLY_BEFORE = ^dddd-dd-dd: если известно, что событие всегда начинается с определенного шаблона, вы сможете указать этот шаблон в данном атрибуте; – TRUNCATE = 1024: если интерес представляют только n первых символов в событии, вы можете указать, после какого символа усекать каждую строку; что именно считать строкой, определяет следующий атрибут; – LINE_BREAKER = ([rn]+)(?=d{4}-dd-dd): самый эффективный способ обработки многострочных событий – явно определить признак разрыва строк. В данном примере строка заканчивается одним или несколькими символами перевода строки, за которыми следует дата в формате 1111-11-11. Самый большой недостаток такого подхода: если формат записей в журнале изменится, ваш индекс начнет заполняться ошибочными элементами, пока вы не измените настройки в конфигурации. Чтобы получить дополнительную помощь с этой настройкой, можно воспользоваться приложением props helper, доступным на Splunkbase. Где находится дата? Если дата в событии не указывается, см. пункт с описанием атрибута DATETIME_CONFIG ниже. Для ответа на этот вопрос используются следующие атрибуты: – TIME_PREFIX = ^[: по умолчанию предполагается, что дата находится в начале строки. Если это не так, помогите Splunk найти позицию в строке, предшествующую дате. Этот шаблон применяется к каждой строке, но, если вы переопределили LINE_BREAKER, можете быть уверены, что в многострочных событиях проверка будет применяться только к первой строке; – MAX_TIMESTAMP_LOOKAHEAD = 30: эту настройку желательно изменить, даже если вы не меняли других настроек. Данный параметр говорит, как далеко следует заглядывать за TIME_PREFIX в поисках дат. Если этот атрибут не определен, Splunk будет просматривать первые 150 в каждой строке и пытаться с помощью регулярных выражений отыскать что-нибудь, 348  Настройка Splunk похожее на дату. По умолчанию используются довольно нестрогие регулярные выражения, которые скорее отыскивают некоторое подобие даты, а не саму дату. Если известно, что дата никогда не будет длиннее n символов, присвойте этому атрибуту значение n или n + 2. Не забывайте, что символы извлекаются после TIME_PREFIX. Как выглядит дата? Подсказать ответ на этот вопрос помогут следующие атрибуты: – TIME_FORMAT = %Y-%m-%d %H:%M:%S.%3N %:z: если этот атрибут определен, Splunk будет применять strptime к символам, непосредственно следующим за TIME_PREFIX. Это самый эффективный и надежный способ. Без этого атрибута Splunk попытается применить несколько регулярных выражений, одно за другим, пока не найдет что-нибудь, похожее на дату; – DATETIME_CONFIG = /etc/apps/a/custom_datetime.xml: как уже упоминалось, для поиска даты Splunk использует несколько регулярных выражений. Если атрибут TIME_FORMAT не определен или по какой-то необъяснимой причине не работает, можно указать свой набор регулярных выражений или вообще запретить извлекать время, присвоив этому атрибуту значение CURRENT (соответствует текущему времени на индексере) или NONE (соответствует времени последнего изменения файла или, если нет файла, текущему времени). Лично мне никогда не приходилось определять свой файл custom_datetime.xml, хотя слышал, что этот прием используется на практике. При добавлении дат через веб-интерфейс есть возможность воспользоваться функцией предварительного просмотра, конструирующей разделы с настройками для конфигурации. В сгенерированных конфигурациях не используется атрибут LINE_BREAKER, что определенно надежнее, но менее эффективно. Вот пример раздела с добавлением атрибута LINE_BREAKER для эффективности: [mysourcetype] TIME_FORMAT = %Y-%m-%d %H:%M:%S.%3N %:z MAX_TIMESTAMP_LOOKAHEAD = 32 TIME_PREFIX = ^[ SHOULD_LINEMERGE = False LINE_BREAKER = ([rn]+)(?=[d{4}-d{1,2}-d{1,2}s+ d{1,2}:d{1,2}:d{1,2}) TRUNCATE = 1024000 Предполагается, что эта конфигурация будет применяться к таким сообщениям в журнале: [2011-10-13 13:55:36.132 -07:00] ERROR Interesting message. Дополнительная информация. Еще одна строка. [2011-10-13 13:55:36.138 -07:00] INFO All better. [2011-10-13 13:55:37.010 -07:00] INFO More data и еще строка. Разберем подробнее, как будут применяться эти настройки к первой строке в примере. Обзор конфигурационных файлов Splunk  349 LINE_BREAKER указывает, что новое событие начинается с одного или нескольких символов перевода строки, за которыми следует квадратная скобка и последовательность цифр и дефисов, согласно шаблону [111111-11 11:11:11]. SHOULD_LINEMERGE=False сообщает, что каждое событие занимает только одну строку. TIME_PREFIX переносит позицию парсинга за символ [. TIME_FORMAT проверяет символы, начиная с текущей позиции, на соответствие указанному шаблону. Если сопоставление увенчалось успехом, обработка времени на этом заканчивается. Если попытка применить шаблон из TIME_FORMAT потерпела неудачу, из текущей позиции (после TIME_PREFIX) извлекается MAX_TIMESTAMP_LOOKAHEAD символов и применяются регулярные выражения из DATE_CONFIG. Если попытка применить регулярные выражения также не увенчалась успехом, используется последнее успешно полученное время из предыдущего события. Если такого времени нет, используется время последнего изменения файла, если это время недоступно, используется текущее время. Это самый эффективный и точный способ парсинга событий в Splunk, но и самый ненадежный. Если формат представления дат в журнале изменится, в вашем индексе почти наверняка появятся поврежденные данные. Используйте такой подход, только если абсолютно уверены, что формат записей в журнале не изменится без вашего ведома. Атрибуты для загрузки данных В файле props.conf есть несколько атрибутов, используемых на стадии загрузки данных, но их редко приходится настраивать. CHARSET = UTF-16LE: при чтении данных система Splunk должна знать, какой набор символов используется в журнале. В большинстве случаев в журналах используется набор символов 8859-1 или UTF-8. Некоторые приложения для Windows используют 2-байтные символы с обратным порядком следования байтов, что может привести к записи мусора в индекс. Настройка CHARSET = UTF-16LE решает эту проблему. Полный список поддерживаемых кодировок вы найдете в официальной документации. NO_BINARY_CHECK = true: если Splunk решит, что имеет дело с двоичным файлом, она вообще не будет индексировать его. Обнаружив подобное поведение, измените значение этого атрибута, чтобы заставить Splunk читать ваши файлы. Такое возможно, если файл содержит символы в неожиданной кодировке, поэтому перед изменением этого атрибута можно попробовать изменить параметр CHARSET. Типы разделов Теперь, после знакомства с часто используемыми атрибутами, поговорим о разных типах разделов в props.conf. Поддерживается три формы определения разделов: 350  Настройка Splunk [foo] – Это точное имя типа источника (souyrcetype) и наиболее распространенная форма определения раздела; типы источников событий обычно определяются в inputs.conf. – Метасимволы недопустимы. [source::/logs/.../*.log] – Соответствует атрибуту source, в котором обычно содержится путь к файлу журнала, откуда получено событие. – Звездочка (*) соответствует имени файла или каталога. – Троеточие (...) соответствует любой части пути. [host::*nyc*] – Соответствует атрибуту host, который обычно содержит имя хоста, на котором работает Splunk Forwarder. – Допускается использовать звездочку (*). Ниже эти типы перечислены в порядке уменьшения приоритета: 1) источник; 2) хост; 3) тип источника. Например, допустим, что у нас есть событие со следующими полями: sourcetype=foo_type source=/logs/abc/def/gh.log host=dns4.nyc.mycompany.com и определены следующие настройки: [foo_type] TZ = UTC [source::/logs/.../*.log] TZ = MST [host::*nyc*] TZ = EDT Тогда, учитывая приоритеты типов разделов, к данному событию будет применена настройка TZ = MST. Усложним пример и допустим, что у нас определены такие настройки: [foo_type] TZ = UTC TRANSFORMS-a = from_sourcetype [source::/logs/.../*.log] TZ = MST BREAK_ONLY_BEFORE_DATE = True TRANSFORMS-b = from_source [host::*nyc*] TZ = EDT BREAK_ONLY_BEFORE_DATE = False TRANSFORMS-c = from_host В этом случае к нашему событию будут применены атрибуты: Обзор конфигурационных файлов Splunk  351 TZ = MST BREAK_ONLY_BEFORE_DATE = True TRANSFORMS-a = from_sourcetype TRANSFORMS-b = from_source TRANSFORMS-c = from_host Приоритеты в пределах одного типа Если некоторому событию соответствует несколько разделов с типом источника или хоста, в действие вступают дополнительные правила определения приоритета. Раздел с именем, содержащим метасимволы, получает приоритет 0, а раздел с точным именем – приоритет 100. Используется раздел с наивысшим приоритетом. Например, допустим, у нас есть разделы: [source::/logs/abc/def/gh.log] TZ = UTC [source::/logs/.../*.log] TZ = CDT Тогда к событию будет применен атрибут TZ со значением UTC, потому что точное совпадение source::/logs/abc/def/gh.log с именем файла журнала обес печивает наивысший приоритет. Если имеется несколько разделов с одинаковыми приоритетами, они применяются в алфавитном порядке. Например, в случае с конфигурацией [source::/logs/abc/.../*.log] TZ = MST [source::/logs/.../*.log] TZ = CDT будет применен атрибут TZ=CDT, потому что /logs/.../*.log предшествует /logs/ abc/.../*.log в алфавитном порядке. Такое поведение может показаться противоречащим здравому смыслу, потому что /logs/abc/.../*.log – определенно более точный путь. Однако, встав на путь определения логики выбора лучшего пути, можно далеко зайти и окончательно запутаться, поэтому было принято вполне разумное решение использовать алфавитный порядок сортировки. Также есть возможность определить свои уровни приоритетов, но, к счастью, необходимость в этом редко возникает на практике. Атрибуты с классом Углубляясь в изучение конфигураций, вы неизбежно встретите имена атрибутов в форме FOO-bar. Слово после дефиса часто называют классом. Такие атрибуты отличаются следующими особенностями: слияние атрибутов из разных файлов происходит по тем же правилам, которые действуют в отношении любых других атрибутов; согласно правилам, описанным выше, к событию будет применен только один экземпляр каждого класса; 352  Настройка Splunk окончательный набор атрибутов, полученный после слияния, применяется в алфавитном порядке следования имен классов. Допустим, что у нас имеется событие со следующими полями: sourcetype=foo_type source=/logs/abc/def/gh.log host=dns4.nyc.mycompany.com и определена такая конфигурация: [foo_type] TRANSFORMS-a = from_sourcetype1, from_sourcetype2 [source::/logs/.../*.log] TRANSFORMS-c = from_source_b [source::/logs/abc/.../*.log] TRANSFORMS-b = from_source_c [host::*nyc*] TRANSFORMS-c = from_host В этом случае к событию будут применены следующие настройки: TRANSFORMS-c = from_source_b TRANSFORMS-b = from_source_c TRANSFORMS-a = from_sourcetype1, from_sourcetype2 Чтобы определить порядок применения преобразований, отсортируем разделы по именам классов, в данном случае c, b и a: TRANSFORMS-a = from_sourcetype1, from_sourcetype2 TRANSFORMS-b = from_source_c TRANSFORMS-c = from_source_b После упорядочения преобразования будут объединены в один список и применены в таком порядке: from_sourcetype1, from_sourcetype2, from_source_c, from_source_b Обычно порядок преобразований не имеет значения, но точное его знание поможет вам в случаях, когда потребуется составить цепочку преобразований и создать одно поле из другого. Мы рассмотрим такую возможность ниже, в разделе transforms.conf. inputs.conf Этот конфигурационный файл, как нетрудно догадаться, управляет загрузкой данных в Splunk. К моменту, когда данные покидают этап ввода, они являются не фактическими событиями, а лишь метаданными, связанными с ними: host, source, sourcetype и необязательное поле index. Эти метаданные затем используются на этапе парсинга для создания событий в соответствии с правилами, определенными в props.conf. Типы загрузки можно разбить на следующие категории: файлы, сетевые порты и скрипты. В первую очередь мы рассмотрим атрибуты, общие для всех типов ввода. Обзор конфигурационных файлов Splunk  353 Атрибуты, общие для всех типов ввода Существует группа общих метаданных, используемых на этапе парсинга для выбора соответствующих разделов в props.conf: host: по умолчанию в поле host записывается имя хоста, где произошло событие. Обычно это истинное значение, но при необходимости его можно скорректировать; source: обычно в это поле записывается путь к файлу или номер сетевого порта, откуда получено событие, но при необходимости его можно переопределить; sourcetype: значение для этого поля почти всегда определяется в inputs. conf и является основой для выбора набора правил парсинга в props.conf; Очень важно присвоить значение полю sourcetype. В отсутствие значения Splunk будет генерировать его автоматически, опираясь на поле source, что легко может привести к взрывному росту числа уникальных значений sourcetype. index: это поле определяет индекс для записи событий. Если поле отсутствует, используется индекс по умолчанию. Все эти значения можно изменять с помощью преобразований, но при этом следует помнить, что преобразования применяются после этапа парсинга. Это означает, что нельзя применить разные правила парсинга к событиям из одного и того же файла, например применять разные форматы времени к разным строкам. Загрузка из файлов Подавляющее большинство событий попадает в Splunk из файлов. Обычно события читаются на машине, где они возникли, и записываются в файлы журналов. Очень часто разделы в inputs.conf выглядят довольно просто: [monitor:///logs/interesting.log*] sourcetype=interesting В большинстве случаев этого вполне достаточно. Данный раздел предпи сывает: прочитать все файлы журналов, соответствующие шаблону /logs/interes ting.log*, и установить наблюдение за ними, в ожидании новых данных; дать типу источника имя interesting; в поле source записать имя файла журнала; в поле host записать имя машины, откуда получен файл журнала; сохранить события в индексе по умолчанию. Это вполне разумные настройки по умолчанию. Если атрибут sourcetype отсутствует, Splunk выберет тип источника, опираясь на имя файла, что не всегда желательно, потому что в этом случае перечень типов источников очень быст ро разбухнет до невероятных размеров. Использование шаблонов для выбора файлов журналов Возможно, вы обратили внимание на символ звездочки (*) в имени раздела в предыдущем примере. 354  Настройка Splunk Это важно, потому что дает системе Splunk шанс отыскать события, записанные в файлы журнала, которые обрабатываются механизмом ротации. Если просто указать имя /logs/interesting.log, есть вероятность потерять события в конце журнала, записанные незадолго до его обработки механизмом ротации, особенно на высоконагруженном сервере. Есть несколько редких ситуаций, когда может возникнуть путаница, но в подавляющем большинстве случаев механизмы по умолчанию делают именно то, что мы от них ожидаем. Подробнее об упомянутых редких случаях рассказывается в разделе «Когда использовать crcSalt». Черные и белые списки Для создания более сложных правил загрузки можно также использовать поддержку черных и белых списков. Обычно черные спис ки используются для перечисления файлов, которые не должны индексироваться, таких как файлы gz и zip. Сделать это можно, как показано ниже: [monitor:///opt/B/logs/access.log*] sourcetype=access blacklist=.*.gz Этот раздел будет соответствовать файлу access.log.2012-08-30, но если в системе используется скрипт сжатия старых файлов журналов, Splunk не будет пытаться прочитать access.log.2012-07-30.gz. Белые списки, напротив, используются для применения какого-то особенного шаблона, например: [monitor:///opt/applicationserver/logs] sourcetype=application_logs whitelist=(app|application|legacy|foo).log(.d{4})? blacklist=.*.gz Этому белому списку, например, соответствуют файлы app.log, application. log, legacy.log.2012-08-13, foo.log и др. Атрибут blacklist отбросит любые файлы gz. Так как logs – это каталог, по умолчанию будут проверены все вложенные подкаталоги. Рекурсивный выбор файлов Организация журналов или приложений может требовать рекурсивного обхода. Например, допустим, у нас есть такие разделы: [monitor:///opt/*/logs/access.log*] sourcetype=access [monitor:///opt/.../important.log*] sourcetype=important Символ звездочки (*) будет соответствовать единственному файлу или каталогу, тогда как троеточие (...) будет соответствовать дереву каталогов произвольной глубины. Таким способом можно найти все необходимые файлы, но имейте в виду, что при этом будет постоянно сканироваться весь каталог /opt. Обзор конфигурационных файлов Splunk  355 То есть Splunk будет снова и снова сканировать каталоги от первого метасимвола в пути monitor. Если каталог /opt содержит много файлов и каталогов, что почти всегда верно, Splunk будет впустую расходовать ресурсы на сканирование всех каталогов в поисках подходящих файлов, потребляя процессорное время и память. Я был свидетелем, как единственный процесс Splunk «сожрал» 2 гигабайта памяти, сканируя глубокое дерево каталогов. Чтобы избежать подобного развития событий, обычно достаточно проявить немного смекалки. Проще говоря, если известны возможные значения для *, лучше определить несколько разделов. Например, допустим, в каталоге /opt нам интересны два подкаталога, A и B, тогда следующие разделы обеспечат большую эффективность: [monitor:///opt/A/logs/access.log*] sourcetype=access [monitor:///opt/B/logs/access.log*] sourcetype=access Кроме того, ничего страшного не произойдет, если разделы будут соответствовать несуществующим файлам и каталогам. Это не вызовет никаких ошибок, но будьте внимательны и не определяйте шаблоны, широкие настолько, что им могут соответствовать нежелательные файлы. Переходы по символическим ссылкам При сканировании каталогов по умолчанию Splunk производит переходы по символическим ссылкам. Часто это очень удобно, но иногда может стать источником проблем, если символическая ссылка ведет в большую и медленную файловую систему. Чтобы изменить поведение по умолчанию, можно добавить такой атрибут: followSymlink = false Возможно, стоит добавлять этот атрибут во все разделы monitor, пока вы не будете уверены, что следование по символическим ссылкам совершенно необходимо. Определение значения поля host из поля source По умолчанию в поле host записывается имя хоста форвардера, от которого получен файл журнала, и такое поведение по умолчанию почти всегда соответствует желаемому. Но если журналы поступают от нескольких хостов, есть возможность получить имя хоста из поля source, используя атрибуты host_regex и host_segment. Например, допустим, у нас имеется такой путь: /nfs/logs/webserver1/access.log Тогда записать значение webserver1 в поле host можно так: [monitor:///nfs/logs/*/access.log*] sourcetype=access host_segment=3 или так: 356  Настройка Splunk [monitor:///nfs/logs/*/access.log*] sourcetype=access host_regex=/(.*?)/access.log Атрибут host_regex также можно использовать для получения значения для поля host из имени файла. Кроме того, переопределить значение host можно с помощью преобразования, но имейте в виду, что преобразования выполняются после парсинга, то есть когда любые настройки из props.conf уже будут применены. Игнорирование устаревших данных Часто бывает, что к моменту установки Splunk в каталоге, откуда должны извлекаться файлы журналов, уже имеются журналы, накопившиеся за месяцы и годы работы. Журналы, обновляющиеся нечасто, тоже могут содержать устаревшие события, не представляющие интереса, которые будут занимать место в индексе без всякой пользы. В таких ситуациях лучше всего настроить сжатие любых старых журналов, старше нескольких дней, но в разветвленных архитектурах сделать это бывает очень непросто. Splunk поддерживает два параметра настройки, которые помогут игнорировать устаревшие данные, но будьте внимательны: настроив игнорирование файлов, будет довольно сложно изменить свое мнение. Если вместо этого вы сожмете устаревшие журналы, добавите сжатые файлы в черный список, как было описано выше, в разделе «Черные и белые списки», позднее вы сможете просто разархивировать любые файлы, которые, по вашему мнению, должны попасть в индекс. Рассмотрим простой пример: [monitor:///opt/B/logs/access.log*] sourcetype = access ignoreOlderThan = 14d В этом случае атрибут ignoreOlderThan требует игнорировать все события в любых файлах, дата последнего изменения которых находится в прошлом далее, чем 14 дней от текущего момента. Если файл обновится в будущем, вновь добавленные в него события будут помещены в индекс. Атрибут followTail позволяет игнорировать все события, записанные к текущему моменту. Поясним это на примере: [monitor:///opt/B/logs/access.log*] sourcetype = access followTail = 1 Splunk запомнит длину файлов, соответствующих шаблону, и, как того требует параметр followTail, будет игнорировать такие файлы, пока их длина не изменится. Любые новые события, добавленные в файлы, будут записаны в индекс. Помните, что не существует простого пути изменить положение дел пос ле применения этих настроек, если впоследствии вы измените свое мнение. В настоящее время нет возможности потребовать игнорировать события старше некоторого времени, но, учитывая, что обычно ротация файлов журналов выполняется ежедневно, это не является проблемой. Обзор конфигурационных файлов Splunk  357 Когда использовать crcSalt Для нужд слежения за имеющимися файлами для каждого из них Splunk сохраняет контрольную сумму первых 256 байт. Обычно этого достаточно, так как большинство файлов журналов начинается с сообщения, которое почти гарантированно будет уникальным. Однако этот механизм перестает работать, когда первые 256 байтов не уникальны для одного и того же сервера. В своей практике я дважды встречался с такой ситуацией. 1.Первый случай, когда журнал начинался с описательного заголовка, содержащего информацию о версии продукта, например: ================================================================ == Great product version 1.2 brought to you by Great company == == Server kernel version 3.2.1 == 2.Второй случай, когда сервер записывает многие тысячи файлов с низким разрешением времени, например: 12:13:12 Session created 12:13:12 Starting session В таких ситуациях можно организовать добавление в контрольную сумму пути к файлу, или crcsalt, как показано ниже: [monitor:///opt/B/logs/application.log*] sourcetype = access crcSalt = <SOURCE> Атрибут crcSalt в этом примере требует добавить в контрольную сумму полный путь к файлу журнала. Данный метод работает, только если файлы журналов имеют уникальные имена. С этой целью при создании файлов журналов можно добавлять текущую дату в их имена. В таком случае вам может понадобиться изменить шаб лон имен файлов журналов, чтобы они всегда включали дату, и исключить возможность переименования файлов. Не используйте crcSalt, если у вас файлы журналов могут переименовы ваться! Если вы добавили crcSalt в input.conf, где прежде эта настройка отсутствовала, все данные будут переиндексированы! Перед добавлением этого парамет ра в существующую конфигурацию переместите все старые файлы журналов в другое место или добавьте их в черный список. Деструктивное индексирование файлов Если файлы журналов поступают пакетами, есть возможность организовать их прием и автоматическое удаление, воспользовавшись типом ввода batch. Этот прием должен использоваться только применительно к копиям файлов журналов. Взгляните на следующий пример: [batch:///var/batch/logs/*/access.log*] sourcetype=access 358  Настройка Splunk host_segment=4 move_policy = sinkhole Настройки в этом разделе требуют выполнить индексирование файлов в указанном каталоге и затем удалить их. Убедитесь, что это именно то, что вам нужно! Ввод из сети Splunk может не только читать файлы, но и принимать данные из сети. Для этого определяются такие разделы: [protocol://<remote host>:<local port>] Часть определения remote host редко используется на практике, и здесь она приводится, только чтобы показать, что для хостов можно определять отдельные конфигурации. Далее перечисляются типичные примеры заголовков раздела: [tcp://1234]: сообщает, что Splunk должна прослушивать порт 1234 и принимать входящие TCP-соединения. Любой хост сможет подключиться к этому порту и послать свои данные; [tcp-ssl://importanthost:1234]: включает прием TCP-соединений через SSL от хоста importanthost. На первом запуске Splunk сгенерирует самоподписанные сертификаты; [udp://514]: разделы этого типа обычно применяются для приема событий от демона syslog. Однако для подобных случаев предпочтительнее использовать выделенный приемник событий syslog, такой как rsyslog или syslog-ng. Подробнее эта тема обсуждается в главе 12 «Продвинутая настройка»; [splunktcp://9997] или [splunktcp-ssl://9997]: применяется в распределенных окружениях для приема событий индексерами. Этот нестандартный протокол используется только для обмена данными между серверами Splunk. Данный раздел будет создан автоматически, когда вы откроете страницу Settings  Forwarding and receiving  Receive data (Настройки  Отправка и прием  Прием данных) и настроите сервер Splunk на прием данных, отправляемых другими серверами Splunk. Для протоколов TCP и UDP поддерживаются следующие атрибуты: source: если не указан, в поле source по умолчанию будет записываться protocol:port, например udp:514; sourcetype: если не указан, в поле sourcetype по умолчанию также будет записываться protocol:port, но обычно это не то, что требуется. Лучше прямо указать тип источника и создать соответствующий раздел в props. conf; connection_host: этот аргумент определяет, откуда будет браться значение для поля host при получении данных из сети. На выбор доступны следующие варианты: – connection_host = dns: использует обратный DNS для определения имени хоста из параметров входящего соединения. Обычно это лучший Обзор конфигурационных файлов Splunk  359 вариант при правильной настройке обратного DNS. Используется по умолчанию; – connection_host = ip: записывает в поле host IP-адрес удаленного компьютера. Это лучший вариант, когда обратный DNS работает ненадежно; – connection_host = none: использует имя хоста сервера Splunk, получившего данные. Этот вариант имеет смысл, когда весь трафик передается промежуточному хосту; – connection_host = foo: задает статическое имя хоста. В практике нередко используется возможность изменения имени хоста с помощью преобразования, например для событий syslog. Однако преобразования выполняются после этапа парсинга, когда уже слишком поздно менять такие параметры, как часовой пояс, опираясь на имя хоста; queueSize: определяет объем памяти, который можно выделить для входной очереди. Очереди обычно используются для хранения данных, пока индексеры не извлекут их; persistentQueueSize: определяет размер хранимой очереди, используемой для сохранения данных на диске после заполнения очереди в памяти. Если вы обнаружите, что ваша конфигурация сетевого ввода начинает обрастать все большим количеством сложностей, я советую обратиться в службу поддержки Splunk, потому что для вашего конкретного случая вполне может иметься более простое решение. Настройки ввода для Windows Одна из замечательных особенностей Windows – сама эта система, и многие приложения для нее записывают сообщения в одно и то же место. К сожалению, это место не является файлом, поэтому для извлечения событий необходимо использовать механизмы, характерные для Windows. В Splunk для этой цели предусмотрены разделы с именами в форме [WinEventLog:LogName]. Например, раздел с настройками для журнала Security выглядит так: [WinEventLog:Security] Для этих разделов предусмотрено множество разных атрибутов, но все они имеют вполне разумные значения по умолчанию. Единственный атрибут, который мне лично приходилось настраивать, – current_only. Это аналог атрибута followTail в разделах monitor. Например, следующий раздел требует следить за журналом Application, но начинать чтение событий только с текущего момента: [WinEventLog:Application] current_only = 1 Это удобно, когда на сервере имеется большой объем исторических событий. Еще один источник данных в Windows – инструментарий управления Windows (Windows Management Instrumentation, WMI). WMI позволяет: 360  Настройка Splunk получать параметры работы, которые можно увидеть в мониторе быст родействия Windows Performance Monitor; следить за обращениями к Windows Event Log API; выполнять запросы к базе данных в WMI; посылать запросы удаленным машинам. Теоретически можно организовать мониторинг большого количества серверов Windows, используя WMI и несколько форвардеров Splunk, но я не рекомендую поступать так. Конфигурация получается сложной, данная методика плохо масштабируется, имеет множество проблем с безопасностью и пока протестирована недостаточно тщательно. Кроме того, при чтении из журналов Windows через WMI события возвращаются в ином формате, отличном от исходного, из-за чего большинство приложений, ожидающих событий из Windows, будет действовать не так, как предполагалось. Самый простой способ сгенерировать конфигурации inputs.conf и wmi.conf, необходимые для чтения событий из журналов Windows через WMI, – установить Splunk для Windows в системе Windows и настроить ввод через веб-интерфейс. Дополнительные примеры ищите в официальной документации Splunk. Скрипты загрузки данных Периодически Splunk запускает процессы и перехватывает их вывод. Например, вот как выглядит раздел с настройками для ввода данных из приложения ImplementingSplunkDataGenerator: [script://./bin/implSplunkGen.py 2] interval=60 sourcetype=impl_splunk_gen_sourcetype2 source=impl_splunk_gen_src2 host=host2 index=implSplunk Обратите внимание на следующее: роль рабочего каталога будет играть корневой каталог приложения, содержащего inputs.conf; файлы с расширением .py будут выполняться интерпретатором Python, входящим в состав Splunk. Это означает, что скрипту будут доступны модули для Python, поставляемые вместе с системой Splunk. Чтобы получить возможность использовать другие модули Python, в разделе нужно указать путь к Python; любые аргументы, указанные в разделе, будут обрабатываться, как если бы они передавались скрипту в командной строке; атрибут interval определяет, как часто (в секундах) должен вызываться этот скрипт: – если скрипт к моменту очередного запуска еще выполняется, он не будет запущен повторно; – допускается использовать скрипты, выполняющиеся продолжительное время. Поскольку в каждый момент времени может выполняться Обзор конфигурационных файлов Splunk  361 только одна копия скрипта, атрибут interval фактически определяет интервал проверки возможности запуска скрипта; – значение для этого атрибута можно указывать в формате cron. Скрипты могут быть написаны на любом языке программирования, при условии что их можно запустить из командной строки. Splunk просто перехватывает вывод запущенного скрипта. В состав Splunk для Windows входят скрипты, опрашивающие WMI. Вот пример раздела для такого скрипта: [script://$SPLUNK_HOMEbinscriptssplunk-wmi.path] Важно отметить, что: вместо слешей пути в Windows используют символы обратных слешей; $SPLUNK_HOME интерпретируется правильно. transforms.conf В конфигурационном файле transforms.conf определяются преобразования и подстановки (lookup), применяемые к событиям. Эти преобразования и подстановки используются в props.conf по их именам. В последующих подразделах для демонстрации примеров будет использоваться такое событие: 2012-09-24T00:21:35.925+0000 DEBUG [MBX] Password reset called. [old=1234, new=secret, req_time=5346] Мы будем использовать его со следующими метаданными: sourcetype=myapp source=/logs/myapp.session_foo-jA5MDkyMjEwMTIK.log host=vlbmba.local Создание индексируемых полей Конфигурационный файл transforms.conf часто используется для создания индексируемых полей. Индексируемые поля отличаются от извлекаемых тем, что они должны создаваться на этапе индексирования и поддерживают возможность поиска по ним независимо от наличия в исходном тексте событий. Обычно вместо индексируемых полей предпочтительнее создавать извлекаемые поля. Обсуждение случаев, когда индексируемые поля могут оказаться предпочтительнее извлекаемых, вы найдете в главе 3 «Таблицы, диаграммы и поля», в разделе «Индексируемые и извлекаемые поля». Индексируемые поля не применяются к уже заиндексированным событиям. В настоящее время не существует возможности восполнить недостающие поля без полного повторного индексирования. Создание поля loglevel [myapp_loglevel] REGEX = s([A-Z]+)s FORMAT = loglevel::$1 WRITE_META = True Вот как выглядит типичный раздел в transforms.conf: 362  Настройка Splunk Это преобразование добавит в события поле loglevel=DEBUG. Это хорошая идея, если значениями loglevel являются широко распространенные слова, например ERROR. Рассмотрим данный раздел подробнее: [myapp_loglevel]: имя раздела может быть любым, главное требование – уникальность, но в ваших же интересах, чтобы оно было еще и осмысленным. Это имя используется в props.conf; REGEX = s([A-Z]+)s: шаблон, с помощью которого событие проверяется на необходимость применения данного преобразования. Если событие не соответствует этому шаблону, преобразование не применяется; FORMAT = loglevel::$1: создает поле loglevel. Внутри Splunk все индексируемые поля хранятся с использованием разделителя ::, мы тоже должны следовать этому формату; WRITE_META = True: без этого атрибута преобразование не будет создавать индексируемое поле и сохранять его с событием. Создание поля session из поля source Используя пример события, представленный выше, создадим еще одно поле – поле session, – которое появляется только в значении поля source: [myapp_session] SOURCE_KEY = MetaData:Source REGEX = session_(.*?).log FORMAT = session::$1 WRITE_META = True Обратите внимание на атрибут SOURCE_KEY. Его значением может быть любое поле метаданных или другое уже созданное индексируемое поле. Обсуждение порядка выполнения преобразований вы найдете в подразделе «Атрибуты с классом» раздела props.conf. Подробнее эти поля мы рассмотрим в подразделе «Изменение полей метаданных». Создание поля тега Это еще одна возможность создавать поля исключительно для маркировки событий, которые сложно отыскать каким-то иным способом. Например, для поиска всех слишком медленных событий мы могли бы использовать запрос: sourcetype=myapp req_time>999 Без индексируемого поля этому запросу пришлось бы проверить каждое событие, соответствующее критерию sourcetype=myapp. После этого запрос отбросил бы события со значениями req_time, меньшими или равными 999. Если заранее известно, что значение req_time>999 – это плохо, и есть возможность определить регулярное выражение, отличающее такие события, мы можем маркировать подобные события для более быстрого извлечения. Представьте, что в transforms.conf имеется такой раздел: [myapp_slow] REGEX = req_time=d{4,} Обзор конфигурационных файлов Splunk  363 FORMAT = slow_request::1 WRITE_META = True Регулярному выражению REGEX соответствуют любые события, содержащие последовательность символов req_time=, за которыми следует четыре или более цифр. После добавления slow_request в fields.conf (см. раздел fields.conf) у нас появится возможность искать по критерию slow_request=1 и находить все медленные события намного эффективнее. Это не относится к событиям, индексированным до определения данного преобразования. Если медленные события являются большой редкостью, этот запрос будет выполняться намного быстрее. Создание полей для классификации хостов В некоторых архитектурах части имени хоста означают что-то конкретное. Если этот шаблон хорошо известен и предсказуем, возможно, стоит выделить такие части имен хостов в отдельные поля. Возьмем для примера вымышленное имя хоста vlbmba.local (вообщето, не совсем вымышленное – это имя хоста моего ноутбука). Мы могли создать поля, определяющие тип и владельца хоста. Вот как мог бы выглядеть соответствующий раздел в конфигурации: [host_parts] SOURCE_KEY = MetaData:Host REGEX = (...)(...). FORMAT = host_owner::$1 host_type::$2 WRITE_META = True С помощью новых полей мы легко сможем классифицировать ошибки по информации, содержащейся в именах хостов. Другое возможное применение – использование lookup, преимуществом которого является возможность обратного преобразования. Такой прием гарантирует ускорение поиска по конкретным полям. Изменение полей метаданных Иногда возникает необходимость изменить основные поля с метаданными. Мы рассмотрим одну из возможных причин для переопределения каждого из основных значений метаданных. Как уже не раз говорилось, преобразования применяются после этапа парсинга, поэтому изменение полей метаданных с помощью преобразований не влияет на применение разделов из props.conf при парсинге данных. Например, для событий из syslog, содержащих имя хоста, нельзя изменить часовой пояс, потому что дата была получена до применения преобразований. Среди прочих Splunk поддерживает следующие атрибуты: _raw (значение по умолчанию для SOURCE_KEY); MetaData:Source; MetaData:Sourcetype; MetaData:Host; _MetaData:Index. 364  Настройка Splunk Переопределение значения в поле host Если имена хостов отличаются от других источников, как, например, syslog от форвардеров Splunk, их можно нормализовать с помощью преобразований. Например, допустим, что от имени хоста vlbmba.local нужно оставить только левую половину, предшествующую первой точке. Реализовать это можно с помощью следующего раздела: [normalize_host] SOURCE_KEY = MetaData:Host DEST_KEY = MetaData:Host REGEX = (.*?). FORMAT = host::$1 Согласно этим настройкам, имя хоста будет заменено на vlbmba. Обратите внимание на два аспекта: здесь отсутствует атрибут WRITE_META, потому что мы не добавляем новое, а переопределяем значение имеющегося поля с метаданными; в начало значения атрибута FORMAT обязательно должна включаться подстрока host::. Переопределение значения в поле source Некоторые приложения фиксируют в журнале каждый сеанс, диалог или транзакцию. В результате возникает проб лема взрывного роста числа уникальных значений в поле source. Эти значения в конечном итоге записываются в файл $SPLUNK_HOME/var/lib/splunk/*/db/Sources.data – каждое уникальное значение в отдельной строке. С течением времени этот файл может вырасти до гигантских размеров, и Splunk будет тратить массу времени на его обновление, вызывая задержки в работе. Эту проблему также можно решить с помощью нового параметра disableGlobalMetadata в indexes. conf. Вот как можно нормализовать это значение: [myapp_flatten_source] SOURCE_KEY = MetaData:Source DEST_KEY = MetaData:Source REGEX = (.*session_).*.log FORMAT = source::$1x.log Это преобразование запишет в поле source значение /logs/myapp.session_x.log и таким способом ликвидирует проблему бесконтрольного увеличения числа уникальных источников. Если желательно сохранить идентификатор сеанса, перед этим преобразованием можно выполнить преобразование из раздела «Создание поля session из поля source», чтобы сохранить идентификатор в отдельном поле. Аналогично можно определить преобразование, переписывающее все значения поля source в другое поле с метаданными. Наличие большого числа файлов журналов в файловой системе порождает еще несколько проблем, включая нехватку памяти для слежения за всеми файлами. Чтобы избежать чего-то подобного, обязательно следует предусмотреть процедуру чистки, которая будет архивировать старые файлы журналов. Обзор конфигурационных файлов Splunk  365 Переопределение значения в поле sourcetype В практике нередко возникает потребность изменить значение поля sourcetype, исходя из содержимого события. Допустим, что нам потребовалось изменить тип источника для событий, содержащих [MBX] после поля loglevel, чтобы для таких событий использовать отдельную процедуру извлечения полей. Вот как это можно организовать: [mbx_sourcetype] DEST_KEY = MetaData:Sourcetype REGEX = d+s[A-Z]+s([MBX]) FORMAT = sourcetype::mbx Используйте данную возможность с большой осторожностью, потому что легко можно допустить логическую ошибку, которую потом будет сложно исправить. Запись событий в разные индексы Иногда бывает нужно посылать события в разные индексы, например потому, что одни события должны храниться дольше других, или из-за того, что содержат конфиденциальную информацию, которая должна быть доступна не всем пользователям. Эта потребность может возникнуть для событий любых типов и из любых источников, будь то файл, сеть или скрипт. Чтобы добиться желаемого, достаточно просто классифицировать событие и назначить индекс. [contains_password_1] DEST_KEY = _MetaData:Index REGEX = Password reset called FORMAT = sensitive Обратите внимание на следующее: в этом случае вам наверняка придется предусмотреть несколько преобразований, поэтому позаботьтесь об уникальности имен индексов; значение DEST_KEY начинается с символа подчеркивания; значение FORMAT не начинается с index::; индекс sensitive должен существовать на машине, выполняющей индексирование, иначе событие, соответствующее условию в REGEX, будет потеряно. Определения подстановок (lookup) Для определения простой подстановки достаточно указать имя файла: [testlookup] filename = test.csv Допустим, что test.csv содержит столбцы user и group, а события имеют поле user, тогда мы сможем воспользоваться этой подстановкой, добавив команду lookup в запрос: * | lookup testlookup user 366  Настройка Splunk Также можно организовать автоматический вызов этой подстановки из props.conf: [mysourcetype] LOOKUP-testlookup = testlookup user Собственно, это все, что нужно знать для начала, и этого достаточно для подавляющего большинства случаев. Инструкции по созданию подстановок через веб-интерфейс вы найдете в разделе «Использование lookups для обогащения данных» главы 7 «Расширенный поиск». Подстановки (lookup) с метасимволами В главе 10 «Summary-индексы и файлы CSV» мы уже правили файл transforms.conf, но при этом я не объяснял, к чему это приводит. Давайте вернемся к тому примеру и взглянем на него с другой стороны: [flatten_summary_lookup] filename = flatten_summary_lookup.csv match_type = WILDCARD(url) max_matches = 1 Рассмотрим подробнее добавленные нами строки: match_type = WILDCARD(url): этот атрибут сообщает, что значение поля url в файле подстановки может содержать метасимволы. Например, адрес URL в файле CSV может выглядеть так: /contact/*; max_matches = 1: по умолчанию в событие может быть добавлено до 10 запи сей из lookup – файла подстановки в виде поля с несколькими значениями. В данном случае мы указали, что в событие следует добавить только первое встретившееся совпадение. Подстановки (lookup) с метасимволами CIDR Подстановки с метасимволами CIDR очень похожи на обычные текстовые подстановки с метасимволами, но используют правила бесклассовой междоменной маршрутизации (Classless Inter-Domain Routing, CIDR) для поиска подстановок, соответствующих IP-адресам. Рассмотрим этот прием на примере. Допустим, у нас есть такой файл подстановки: ip_range,network,datacenter 10.1.0.0/16,qa,east 10.2.0.0/16,prod,east 10.128.0.0/16,qa,west 10.129.0.0/16,prod,west Cоответствующее определение в transforms.conf: [ip_address_lookup] filename = ip_address_lookup.csv match_type = CIDR(ip_range) max_matches = 1 Обзор конфигурационных файлов Splunk  367 И несколько событий: src_ip=10.2.1.3 user=mary src_ip=10.128.88.33 user=bob src_ip=10.1.35.248 user=bob Мы могли бы воспользоваться командой lookup для обогащения этих событий, как показано ниже: src_ip="*" | lookup ip_address_lookup ip_range as src_ip | table src_ip user datacenter network Этот запрос выполнит поиск IP-адресов и вернет таблицу, изображенную на рис. 11.1. Рис. 11.1  Пример обогащения данных с применением подстановки CIDR Этот запрос также демонстрирует возможность использовать одну и ту же подстановку для разных полей с помощью ключевого слова as в вызове lookup. Использование времени в подстановках (lookup) Подстановку, зависящую от времени, можно использовать для обогащения событий, опираясь на время их возникновения. Для этого нужно указать начало интервала времени в определении подстановки и формат времени в конфигурации. При использовании этого механизма значения подстановки можно изменять с течением времени, даже задним числом. Вот очень простой пример добавления поля version, значение которого зависит от времени. Допустим, у нас есть такой файл CSV: sourcetype,version,time impl_splunk_gen,1.0,2012-09-19 02:56:30 UTC impl_splunk_gen,1.1,2012-09-22 12:01:45 UTC impl_splunk_gen,1.2,2012-09-23 18:12:12 UTC В этом случае можно определить настройки подстановки в transforms.conf, указывающие, какое поле в событиях должно сравниваться со временем и какой формат имеет это поле: [versions] filename = versions.csv time_field = time time_format = %Y-%m-%d %H:%M:%S %Z 368  Настройка Splunk Использовать такую подстановку можно, как показано ниже: sourcetype=impl_splunk_gen error | lookup versions sourcetype | timechart count by version Этот запрос выведет диаграмму появления ошибок (по версиям) с течением времени, как показано на рис. 11.2. Рис. 11.2  Диаграмма появления ошибок с течением времени Этот подход можно также использовать для слежения за развертыванием версий в окружениях и активностью отключенных учетных записей. REPORT Атрибуты с именами в формате REPORT-foo в props.conf используют разделы с настройками в transforms.conf на этапе поиска, то есть они не оказывают влияния на поля с метаданными. Определения EXTRACT писать намного проще, потому что они целиком находятся в одном атрибуте в props.conf, но есть пара задач, которые можно решить только с использованием атрибута REPORT в паре с преобразованием, объявленным в transforms.conf. Создание полей с несколькими значениями Допустим, некоторое поле в событии может иметь несколько значений. Определение EXTRACT обнаружит только первое такое значение. Например, представьте, что у нас имеется такое событие: 2012-08-25T20:18:09 action=send a@b.com c@d.com e@f.com Мы могли бы получить первый адрес электронной почты с помощью такого определения: EXTRACT-email = (?i)(?P<email>[a-zA-Z0-9._]+@[a-zA-Z0-9._]+) Оно запишет в поле email значение a@b.com. С помощью атрибута REPORT и преобразования можно извлечь все адреса электронной почты, задействовав атрибут MV_ADD. Вот как для этого случая мог бы выглядеть атрибут в props.conf: Обзор конфигурационных файлов Splunk  369 REPORT-mvemail = mvemail и раздел в transforms.conf: [mvemail] REGEX = (?i)([a-zA-Z0-9._]+@[a-zA-Z0-9._]+) FORMAT = email::$1 MV_ADD = true Если какая-то другая конфигурация уже создала поле email, тогда атрибут MV_ADD добавит в него все значения, соответствующие заданному регулярному выражению. Создание динамических полей Иногда возникает необходимость создать поля динамически. Например, пусть у нас есть событие: 2012-08-25T20:18:09 action=send from_335353("a@b.com") to_223523("c@d.com") cc_39393("e@f.com") cc_39394("g@h.com") и нам хотелось бы извлечь поля from, to и cc, но мы не знаем всех возможных вариантов написания их имен. Следующий раздел в transforms.conf создаст нужные нам поля динамически: [dynamic_address_fields] REGEX=s(S+)_S+("(.*?)") FORMAT = $1::$2 MV_ADD=true И, пока мы не ушли далеко, добавим числовые значения из имен полей в их значения: [dynamic_address_ids] REGEX=s(S+)_(S+)(" FORMAT = $1::$2 MV_ADD=true В результате мы получим поля с несколькими значениями, как показано на рис. 11.3. Рис. 11.3  Динамические поля с несколькими значениями Единственное, чего мы не можем сделать, – добавить дополнительный текст в атрибут FORMAT. Например, во втором случае было бы хорошо иметь возможность определить атрибут FORMAT, как показано ниже: FORMAT = $1_id::$2 370  Настройка Splunk Но, к сожалению, такой атрибут будет работать не так, как хотелось бы, – он просто создаст поле id. Объединение преобразований в цепочки Как рассказывалось в разделе «Атрибуты с классом», преобразования выполняются в определенном порядке. В большинстве случаев порядок не имеет значения, но иногда хотелось бы иметь возможность объединять преобразования в цепочки, где последующие преобразования полагаются на наличие полей, созданных предыдущими преобразованиями. Хорошим примером может служить нормализация поля source, о которой рассказывалось в разделе «Переопределение значения в поле source». Если это преобразование выполнится до преобразования, описанного в разделе «Создание поля session из поля source», наше поле session всегда будет получать значение x. Возьмем эти два преобразования, создадим еще одно и объединим их в цепочку так, чтобы первая часть поля session помещалась в другое поле. Допус тим, у нас есть следующие преобразования: [myapp_session] SOURCE_KEY = MetaData:Source REGEX = session_(.*?).log FORMAT = session::$1 WRITE_META = True [myapp_flatten_source] SOURCE_KEY = MetaData:Source DEST_KEY = MetaData:Source REGEX = (.*session_).*.log FORMAT = source::$1x.log [session_type] SOURCE_KEY = session REGEX = (.*?)FORMAT = session_type::$1 WRITE_META = True Чтобы обеспечить выполнение преобразований в определенном порядке, просто перечислим их в одном атрибуте TRANSFORMS в props.conf: [source:*session_*.log] TRANSFORMS-s = myapp_session,myapp_flatten_source,session_type Для примера используем поле source из события: source=/logs/myapp.session_foo-jA5MDkyMjEwMTIK.log Рассмотрим поближе, что делают эти преобразования: myapp_session: читает поле с метаданными source, создает индексируемое поле session со значением foo-jA5MDkyMjEwMTIK; myapp_flatten_source: записывает в поле с метаданными source новое значение /logs/myapp.session_x.log; Обзор конфигурационных файлов Splunk  371 session_type: читает новое индексируемое поле session, создает поле session_type со значением foo. Данный прием упорядочения также можно применить на этапе поиска с помощью разделов EXTRACT и REPORT. В этом конкретном случае требуется, чтобы результаты вычислений сохранялись в индексируемых полях, если вы хотите отыскать эти значения, потому что значения являются частью поля с метаданными. Фильтрация событий Некоторые события не имеет смысла индексировать. Самое сложное – определить такие события и убедиться, что определение выполняется безошибочно. Если отфильтровать слишком много событий, в критический момент вы можете оказаться без важной информации, способной помочь в поиске проблем, что может вызвать еще больше проблем, чем настройка Splunk для обработки больших объемов данных. Помня об этом, определите события, какие вам точно не понадобятся, а сама процедура их фильтрации реализуется очень просто. Допустим, у нас имеется такое событие: 2012-02-02 12:24:23 UTC TRACE Database call 1 of 1,000. [...] Я абсолютно уверен, что данные события с таким типом источника и уровнем TRACE мне в индексе не нужны. Чтобы отфильтровать такие события, в конфигурации props.conf создадим раздел с описанием типа источника mysourcetype, как показано ниже: [mysourcetype] TRANSFORMS-droptrace=droptrace Затем определим преобразование в transforms.conf: [droptrace] REGEX=^d{4}-d{2}-d{2}s+d{1,2}:d{2}:d{1,2}s+[A-Z]+sTRACE DEST_KEY=queue FORMAT=nullQueue Splunk сравнит nullQueue с nulldevice, который (согласно документации) требует от Splunk не передавать и не индексировать отфильтрованные данные. Атрибуту REGEX намеренно присвоено максимально строгое регулярное выражение, какое я только смог придумать, потому что очень важно по ошибке не отфильтровать другие события, и для этого шаблона лучше, если он ошибется и пропустит события TRACE, чем отфильтрует какие-то важные события. fields.conf В конфигурацию fields.conf мы должны добавить все созданные нами индексируемые поля, иначе поиск по этим полям будет выполняться неэффективно, если вообще будет выполняться. Для наших примеров из раздела transforms. conf конфигурация fields.conf должна выглядеть так: 372  Настройка Splunk [session_type] INDEXED = true [session] INDEXED = true [host_owner] INDEXED = true [host_type] INDEXED = true [slow_request] INDEXED = true [loglevel] INDEXED = true Эти настройки требуют от Splunk не просматривать тело событий в поисках запрашиваемых значений. Рассмотрим, например, следующий запрос: host_owner=vlb Фактический запрос будет иметь такой вид: vlb | search host_owner=vlb Предполагая, что значение vlb находится в теле события, этот запрос прос то не будет работать. Добавление соответствующего раздела в fields.conf исправляет эту проблему. В случае с уровнем логирования, поскольку значение присутствует в теле события, запрос будет работать, но без использования индексированного поля, и задействует его только для фильтрации найденных событий по самому слову. outputs.conf Эта конфигурация управляет передачей событий между серверами Splunk. В подавляющем числе случаев этот конфигурационный файл находится на форвардерах Splunk, которые передают события индексерам. Вот пример такого файла: [tcpout] defaultGroup = nyc [tcpout:nyc] autoLB = true server = 1.2.3.4:9997,1.2.3.6:9997 Допускается использовать преобразования для маршрутизации событий между разными группами серверов, но этот прием используется редко, потому что зачастую вносит ненужные сложности. indexes.conf Если говорить простым языком, indexes.conf определяет, где на диске будут храниться данные, сколько данных будет храниться и как долго. Индекс – это обычный каталог с определенной структурой. Внутри каталога имеется несколько файлов с метаданными и подкаталогов; эти подкаталоги называются корзинами (bucket) и хранят фактические индексированные данные. Обзор конфигурационных файлов Splunk  373 Вот как выглядит простой раздел в indexes.conf: [implSplunk] homePath = $SPLUNK_DB/implSplunk/db coldPath = $SPLUNK_DB/implSplunk/colddb thawedPath = $SPLUNK_DB/implSplunk/thaweddb Рассмотрим эти атрибуты поближе: homePath: место хранения свежих данных; coldPath: место хранения старых данных; thawedPath: каталог, в котором можно восстановить корзины. Данный атрибут должен определяться всегда, но мне лично никогда не приходилось пользоваться им. Возможно, имеет смысл чуть подробнее остановиться на терминологии корзин: hot: корзина, в настоящий момент открытая для записи. Она находится в homePath; warm: корзина, созданная относительно недавно, но в настоящий момент закрытая для записи. Она также находится в homePath; cold: старая корзина, перемещенная в coldPath. Перемещение происходит после превышения значения параметра maxWarmDBCount; frozen: в большинстве случаев просто означает «удаленный». Пользователи, желающие архивировать корзины, могут определить параметры coldToFrozenScript или coldToFrozenDir, управляющие архивированием корзин; thawed: оттаявшей (thawed) называют корзину, прежде замороженную (frozen), но возвращенную обратно. Особенность оттаявших корзин в том, что они не управляются и не всегда используются в поиске. Когда задан параметр coldToFrozenDir, обычно сохраняются только исходные данные, поэтому Splunk должен перестроить индексы, чтобы вновь получить возможность использовать эти корзины для поиска. Срок хранения индекса определяется следующими атрибутами: frozenTimePeriodInSecs: этот параметр определяет продолжительность хранения данных в индексе. Корзина будет удалена, когда самое свежее событие в нем окажется старше этого значения. Значение по умолчанию примерно равно 6 годам; maxTotalDataSizeMB: этот параметр определяет максимальный размер индекса. Общий объем горячих (hot), теплых (warm) и холодных (cold) корзин не должен превышать этого значения. Первым удаляется всегда самая старая корзина. Значение по умолчанию равно 500 Гбайт. В общем случае желательно устанавливать оба этих атрибута. frozenTimePeriodInSecs должен соответствовать ожиданиям пользователя. Цель maxTotalDataSizeMB – защитить систему от исчерпания дискового пространства. Реже используются следующие атрибуты: coldToFrozenDir: если определен, замораживаемые корзины будут перемещаться в этот каталог вместо удаления. Данный каталог не управляет- 374  Настройка Splunk ся системой Splunk, поэтому администратор должен сам следить за ним и предотвращать вероятность переполнения диска; maxHotBuckets: корзина представляет некоторый отрезок времени и в идеа ле должна охватывать как можно меньший интервал. Я никогда не устанавливал в этом атрибуте значение меньше 3 и наиболее практичным считаю значение 10; maxDataSize: максимальный размер одной корзины. Значение по умолчанию зависит от типа процессора и обычно всегда имеет вполне разумную величину. Чем больше сегменты, тем меньше их приходится открывать в процессе поиска, но тем больший объем дискового пространства они займут перед удалением (заморозкой). Значение по умолчанию определяется автоматически и никогда не превышает 750 Мбайт. Значение auto_high_volume соответствует 1 Гбайт в 32-разрядной системе и 10 Гбайт в 64-разрядной; его следует использовать только в индексерах, получающих больше 10 Гбайт в день. Подробнее об управлении размерами нескольких индексов мы поговорим в главе 12 «Продвинутая настройка». authorize.conf Данный конфигурационный файл хранит настройки, управляющие разрешениями и ролями. Эти настройки влияют на процедуру поиска и доступность разного рода функций через веб-интерфейс. Обычно управление разрешениями осуществляется на странице Settings  Access controls (Настройки  Управление доступом), тем не менее хотя бы краткое знакомство с устройством конфигурационного файла может оказаться полезным. Раздел с настройками роли выглядит примерно так: [role_power] importRoles = user schedule_search = enabled rtsearch = enabled srchIndexesAllowed = * srchIndexesDefault = main srchDiskQuota = 500 srchJobsQuota = 10 rtSrchJobsQuota = 20 Познакомимся с этими атрибутами поближе: importRoles: список ролей для наследования разрешений. Наследованные разрешения добавляются к разрешениям данной роли; schedule_search и rtsearch: эти два разрешения доступны для роли power; srchIndexesAllowed: определяет индексы, доступные для поиска с этой ролью. В данном случае разрешается использовать все индексы; srchIndexesDefault: определяет индексы по умолчанию, доступные для поиска. Этот атрибут влияет также на выбор данных для отображения Ресурсы пользовательского интерфейса  375 в Search  Summary (Поиск  Сводка). Если вы установили приложение ImplementingSplunkDataGenerator, то на этой странице увидите типы источников impl_splunk_*, даже притом что эти данные фактически хранятся в индексе implsplunk; srchDiskQuota: всякий раз, когда запускается процедура поиска, результаты сохраняются на диске и хранятся до истечения определенного времени. Время хранения можно задать явно, при создании хранимых запросов, но для интерактивного поиска оно определяется автоматически. Пользователи могут удалять устаревшие результаты, зайдя в представление Jobs (Задания); srchJobsQuota: каждый пользователь может одновременно запустить не более некоторого ограниченного числа запросов. По умолчанию – не более трех. Пользователи с повышенными привилегиями (с ролью power) могут одновременно запустить до 10 запросов, а пользователи с ролью admin – до 50; rtSrchJobsQuota: этот параметр определяет максимальное число одновременно обрабатываемых запросов в режиме реального времени. По умолчанию таких запросов не может быть больше шести. savedsearches.conf Эта конфигурация содержит параметры хранимых запросов и редко изменяется вручную. times.conf Хранит определения интервалов времени, доступные в виджете выбора времени. commands.conf Хранит определения команд, поддерживаемых приложением. Мы будем использовать эту конфигурацию в главе 13 «Расширение Splunk». web.conf Основные настройки в этой конфигурации, которые обычно приходится изменять, – это номер порта веб-сервера, сертификаты SSL и признак необходимости запускать веб-сервер. Ресурсы пользовательского интерфейса Большинство приложений для Splunk состоит в основном из ресурсов для вебприложения. Организация этих ресурсов полностью отличается от организации всех остальных конфигураций. 376  Настройка Splunk Представления и навигация По аналогии с файлами .conf, документы, описывающие представления и навигацию, обрабатываются в следующем порядке: $SPLUNK_HOME/etc/users/$username/$appname/local: когда создается новый дашборд, он помещается в этот каталог и остается здесь, пока разрешения на доступ к нему не изменятся на App или Global; $SPLUNK_HOME/etc/apps/$appname/local: как только документ будет открыт для совместного использования, он переместится в этот каталог; $SPLUNK_HOME/etc/apps/$appname/default: допускается вручную перемещать документы в этот каталог. Это необходимо, если вы собираетесь открыть другим доступ к своему приложению. В отличие от файлов .conf, эти документы не объединяются. Внутри каждого из этих каталогов представления и настройки навигации помещаются в каталоги data/ui/views и data/ui/nav соответственно. Поэтому если представить, что пользователь bob создал представление foo для приложения app1, соответствующий документ будет сохранен как: $SPLUNK_HOME/etc/users/bob/app1/local/data/ui/views/foo.xml Как только пользователь откроет другим доступ к своему приложению, документ переместится в: $SPLUNK_HOME/etc/apps/app1/local/data/ui/views/foo.xml Для определений навигации поддерживается аналогичная структура, с той лишь разницей, что соответствующий документ всегда будет иметь имя default.xml, например: $SPLUNK_HOME/etc/apps/app1/local/data/ui/nav/default.xml Эти файлы можно править не только через веб-интерфейс, но и с помощью любого текстового редактора, но в последнем случае изменения вступят в силу только после перезапуска Splunk, если не использовать обходное решение. Чтобы повторно загрузить изменившееся представление или определение навигации, откройте URL http://mysplunkserver:8000/debug/refresh, заменив mysplunkserver именем своего сервера. Если что-то пойдет не так, перезапустите Splunk. Ресурсы сервера приложений Помимо представлений и навигации, существует много других ресурсов, используемых веб-приложением. Например, приложения и дашборды могут ссылаться на файлы CSS и изображения, как рассказывалось в главе 8 «Работа с приложениями». Эти ресурсы хранятся в каталоге $SPLUNK_HOME/etc/ apps/$appname/appserver/. В этом каталоге имеется несколько подкаталогов: static: здесь хранятся все статические файлы, используемые вашим приложением. Тут также хранятся файлы, автоматически используемые системой Splunk: appIcon.png, screenshot.png, application.css и application.js. Ресурсы пользовательского интерфейса  377 На другие файлы можно ссылаться динамически. Примеры можно найти в разделе «Включение файлов в сложные дашборды на стороне сервера» главы 8 «Работа с приложениями»; event_renderers: визуализаторы событий позволяют определить свой код для отображения событий определенных типов. Мы увидим, как писать свои визуализаторы событий, в главе 13 «Расширение Splunk»; templates: есть возможность определять свои шаблоны на языке шаблонов mako, однако она редко используется на практике; modules: здесь хранятся новые модули, предоставляемые приложениями. Примерами таких модулей могут служить Google Maps и Sideview Utils. Дополнительную информацию о создании своих модулей вы найдете на сайте https://dev.splunk.com, или используйте существующие модули как примеры. Метаданные Разрешения для доступа к объектам хранятся в файлах, в каталоге $SPLUNK_HOME/ etc/apps/$appname/metadata/. Здесь можно найти два таких файла: default.meta и local.meta. Эти файлы: применяются только к ресурсам в приложении, в котором содержатся; правила в этих файлах объединяются перед применением, и предпочтение отдается настройкам в local.meta; управляются с использованием интерфейса администратора; могут содержать правила, влияющие на все конфигурации определенного типа, но такие правила должны добавляться вручную. Если эти файлы отсутствуют (этот каталог присутствует не во всех приложениях), ресурсы ограничиваются текущим приложением. Давайте заглянем в файл default.meta, созданный системой Splunk для приложения is_app_one: # Разрешения на уровне приложения [] access = read : [ * ], write : [ admin, power ] ### ТИПЫ СОБЫТИЙ [eventtypes] export = system ### СВОЙСТВА [props] export = system ### ПРЕОБРАЗОВАНИЯ [transforms] export = system ### ПОДСТАНОВКИ [lookups] 378  Настройка Splunk export = system ### СОСТОЯНИЕ ПРЕДСТАВЛЕНИЙ: даже простые пользователи должны ### иметь возможность создавать общие состояния представлений [viewstates] access = read : [ * ], write : [ * ] export = system Рассмотрим этот фрагмент поближе. Заголовок [] раздела указывает, что все пользователи должны иметь право на чтение для всего в этом приложении, но только пользователи с ролями admin или power имеют право на запись. Разделы [eventtypes], [props], [transforms] и [lookups] указывают, что настройки всех типов для этого приложения по умолчанию должны быть доступны всем пользователям во всех приложениях. Атрибут export=system равноценен установке разрешения Global в пользовательском интерфейсе. Раздел [viewstates] дает всем пользователям право делиться viewstates глобально. Состояние представления (viewstate) содержит информацию о настройках дашборда, установленных через веб-приложение, например настройки диаграммы. Без этого настройки диаграммы, применяемые к дашборду или хранимому запросу, оказались бы недоступны. Заглянув в local.meta, можно увидеть настройки, определенные нами в вебприложении для этого приложения: [indexes/summary_impl_splunk] access = read : [ * ], write : [ admin, power ] [views/errors] access = read : [ * ], write : [ admin, power ] export = system owner = admin version = 4.3 modtime = 1339296668.151105000 [savedsearches/top%20user%20errors%20pie%20chart] export = none owner = admin version = 4.3 modtime = 1338420710.720786000 [viewstates/flashtimeline%3Ah2v14xkb] owner = nobody version = 4.3 modtime = 1338420715.753642000 [props/impl_splunk_web/LOOKUP-web_section] access = read : [ * ] export = none owner = admin version = 4.3 modtime = 1346013505.279379000 Итоги  379 Надеюсь, идея вам понятна. Веб-приложение создает конкретные записи для каждого созданного объекта. При распространении приложений обычно проще определить общие разрешения в metadata/default.meta для доступа к ресурсам в вашем приложении. Для приложений, просто экспортирующих дашборды, метаданные не требуются, так как для всех ресурсов (приложений) устанавливаются вполне приемлемые значения по умолчанию. Если приложение экспортирует ресурсы для использования в других приложениях, например подстановки или извлекаемые поля, ваш файл default.meta мог бы выглядеть примерно так: ### СВОЙСТВА [props] export = system ### ПРЕОБРАЗОВАНИЯ [transforms] export = system ### ПОДСТАНОВКИ [lookups] export = system Эти метаданные указывают, что все настройки в ваших файлах props.conf и transforms.conf, а также определения подстановок должны объединяться в логическую конфигурацию для каждого поиска. Итоги В этой главе мы познакомились с особенностями работы механизма конфигурирования в Splunk и наиболее часто используемыми настройками. Это далеко не полный справочник по доступным настройкам, поэтому за более исчерпывающей информацией я рекомендую обращаться к официальной документации. Самый простой, на мой взгляд, способ получить доступ к официальной документации с описанием конкретного конфигурационного файла – выполнить поиск в интернете по запросу splunk имя_файла.conf. В главе 12 «Продвинутая настройка» мы рассмотрим приемы развертывания распределенных архитектур и их эффективную настройку. Все, что вы узнали в этой главе, безусловно, пригодится для понимания более продвинутых приемов. Глава 12 Продвинутая настройка Начиная работу с системой Splunk, вы, вероятно, установили ее на одной машине, импортировали несколько журналов и приступили к поиску. Это замечательно, что есть такая простая возможность попробовать продукт, но как только вы перейдете к тестированию и эксплуатации, все может стать намного сложнее, и тогда, потратив немного времени на планирование, вы сможете избежать многих неприятностей. В этой главе мы обсудим следующие темы: получение данных; разные компоненты распределенной архитектуры; управление конфигурациями в распределенной архитектуре; организация распределенной архитектуры; проблемы безопасности; стратегии резервного копирования. Планирование архитектуры системы Ниже перечислено несколько вопросов, на которые вам нужно ответить, чтобы определить, сколько серверов Splunk будет задействовано в вашей архитектуре. Как много данных будет индексироваться каждый день? Как много данных будет храниться? Существует эмпирическое правило: 100 Гбайт в день на индексер Splunk, при условии что у вас быстрые диски. Дополнительные сведения вы найдете в разделе «Организация индексирования». Как много запросов будет обрабатываться одновременно? Скорее всего, это число меньше, чем вы думаете. Это не число пользователей, имеющих доступ к Splunk, а число запросов, обрабатываемых одновременно. Оно зависит от типов запросов, запускаемых в группе. Откуда поступают исходные данные? От того, откуда поступают данные, может зависеть архитектура системы. Предусмотрев получение данных из всех возможных у вас источников, вы избавите себя от многих проб лем в будущем. Примеры вы найдете в разделе «Типичные источники данных». Типы серверов Splunk  381 Как много дата-центров вам придется контролировать? Обслуживание серверов, находящихся в разных местах, увеличивает уровень сложности. Несколько примеров настройки разных архитектур для разных ситуаций вы найдете в разделе «Развертывание серверов Splunk». Как будут настраиваться серверы Splunk? Как будут распределяться конфигурации? В этой главе мы рассмотрим все эти и некоторые другие темы. Типы серверов Splunk В распределенной архитектуре разные серверы Splunk служат разным целям. Существует четыре этапа обработки данных, которые обычно распределяются между двумя–четырьмя уровнями. К этим этапам относятся: ввод: на этом этапе исходные данные извлекаются из файлов журналов, портов или скриптов; парсинг: на этом этапе выполняется преобразование исходных данных в события, определяется их время, создаются базовые метаданные, выполняются преобразования и т. д.; индексирование: на этом этапе данные сохраняются в индексах в оптимизированном для поиска виде; поиск: на этом этапе пользователи запускают запросы и получают результаты. Все эти этапы могут выполняться на одном сервере, но, если распределить их между несколькими серверами, можно добиться очень высокой производительности, даже когда объем исходных данных очень велик. Форвардеры Splunk На каждом компьютере, содержащем файлы журналов, обычно устанавливается форвардер (forwarder) Splunk. Его задача – читать файлы журналов на этом компьютере или выполнять скрипты для сбора данных. Инсталляция может быть выполнена на: полноценном сервере Splunk, установленном на компьютере и настроенном только для передачи данных, без их индексирования; форвардере Splunk (Universal Forwarder, UF), по сути, том же сервере Splunk, но без функций индексирования и поиска. В случае установки полноценного сервера Splunk его можно настроить на работу в одном из двух режимов. Как форвардер, не производящий парсинга событий, а просто пересылающий поток исходных данных индексерам. В этом режиме форвардер Splunk потребляет минимум ресурсов машины, на которой выполняется (если только количество файлов, которые он должен сканировать, не слишком велико), и легко настраивается. Однако в подобном случае на плечи индексеров ложится больше работы. Если вас устроит этот режим, лучше устанавливайте универсальный форвардер Splunk (UF). 382  Продвинутая настройка Как многофункциональный форвардер (Heavy Forwarder), осуществляющий парсинг событий и пересылающий индексерам результаты парсинга – готовые события. В таком случае индексерам остается меньше работы, но возникает дополнительная сложность – необходимость передачи настроек форвардерам. Кроме того, в этом режиме форвардер потребляет почти в два раза больше процессорного времени и памяти, чем обычный форвардер. Для большинства клиентов правильным оказывается выбор универсального форвардера Splunk (UF). Наибольшую важность для форвардера представляют следующие конфигурационные файлы: inputs.conf: определяет файлы для чтения, сетевые порты для прослушивания или скрипты для запуска; outputs.conf: определяет индексеры, которым следует передавать данные; props.conf: как обсуждалось в главе 11 «Настройка Splunk», лишь малая часть этой конфигурации так или иначе связана с этапом ввода, но многие настройки в ней имеют прямое отношение к парсингу. Самый прос той способ обращения с этой конфигурацией – рассылать props.conf целиком, чтобы требуемые разделы с настройками были доступны всем и везде. Мы обсудим эту проблему в разделе «Использование приложения для организации конфигурации» далее в этой главе; default-mode.conf: используется для отключения ненужных модулей. В форвардере большинство модулей не нужно и потому отключено; limits.conf: главным параметром в этом файле конфигурации является maxKBps, определяющий максимальную пропускную способность, которую может использовать форвардер. Этот параметр для форвардера (UF) по умолчанию получает очень низкое значение, чтобы уменьшить нагрузку на сеть и на обслуживаемую машину. Часто это значение можно увеличить, не опасаясь вредных последствий. Нередко его увеличивают до предельных возможностей имеющегося сетевого оборудования. Подробнее о развертывании форвардеров мы поговорим в разделе «Развертывание серверов Splunk». Индексеры Splunk В большинстве архитектур индексеры занимаются парсингом и индексированием событий. Если в системе имеется только один индексер Splunk, он же обычно занимается обработкой запросов. Как нетрудно догадаться из названия, индексер индексирует данные. Индексер должен иметь доступ к быстрым дискам, будь то локальные диски, сеть хранения данных (SAN) или сетевые тома. По своему опыту могу отметить, что сетевая файловая система (Network File System, NFS) недостаточно надежна и плохо подходит для хранения индексов и файлов Splunk. Сервер Splunk предполагает, что его диски будут действовать Типичные источники данных  383 подобно локальным дискам, чего NFS иногда не может обеспечить. Файлы журналов вполне можно читать из NFS. Для индексеров хорошо подойдут дис ки iSCSI, а также сетевые хранилища данных (SAN). Наибольшую важность для индексера представляют следующие конфигурационные файлы. inputs.conf: обычно определяет только один источник ввода, [splunktcp://9997]. Этот раздел настраивает индексер на прослушивание порта 9997 и прием на нем запросов на соединение от форвардеров. indexes.conf: определяет местоположение индексов и срок хранения данных. По умолчанию: – все данные записываются в каталог $SPLUNK_HOME/var/lib/splunk; – индекс продолжает расти до максимального размера 500 Гбайт, после чего из него начинают удаляться самые старые события; – индекс хранит события до шести лет, после чего из него начинают удаляться самые старые события; – события удаляются из индекса по достижении любого из пределов. Мы обсудим изменение этих пределов в разделе «Организация индексирования». props.conf и transforms.conf: если индексер осуществляет парсинг, он будет использовать настройки, управляющие разбиением потока данных на события, парсингом данных и индексированием полей, из эти конфигурационных файлов; server.conf: содержит адрес сервера лицензий. Ответ на вопрос «Сколько индексеров понадобится?» вы найдете в разделе «Организация индексирования». Поиск в Splunk При наличии только одного сервера Splunk поиск выполняется одновременно с индексированием. Это нормально, пока объем информации из журналов не увеличится до такой степени, что один сервер не сможет легко обрабатывать ее. На самом деле установка отдельного Search Head-сервера может снизить производительность, так как выполнение распределенного поиска сопряжено с большими затратами. Большинство настроек, управляющих поиском, выполняется через вебинтерфейс. Настройки, касающиеся конкретно поиска в распределенной архитектуре, находятся в разделе Settings  Distributed Environment  Distributed search (Настройки  Распределенное окружение  Распределенный поиск). Типичные источники данных Данные могут поступать из источников разных типов – файлов, сетевых портов или скриптов. Давайте рассмотрим наиболее типичные сценарии. 384  Продвинутая настройка Мониторинг файлов журналов на сервере В этом сценарии сервер записывает информацию о событиях в свои файлы журналов на локальном диске, а процесс форвардера следит за ними. Это один из типичных примеров использования Splunk. Ниже перечислены основные преимущества такого подхода. Возможность существенной оптимизации процесса. Если индексеры не перегружены работой, события часто становятся доступными для поиска в течение нескольких секунд. Корректная обработка задержек, вызванных проблемами в сети или перегрузкой индексеров. После исчезновения причин, порождающих задержки, процесс форвардера продолжит передачу данных с того места, на котором возникла задержка. Использование форвардера (UF), обычно потребляющего меньше 100 Мбайт оперативной памяти и несколько процентов процессорного времени. Объем потребляемых ресурсов увеличивается с ростом объема новых данных и количества отслеживаемых файлов. Подробности вы найдете в разделе inputs.conf главы 11 «Настройка Splunk». Журналы без указанного часового пояса наследуют часовой пояс машины, на которой работает форвардер. Это почти всегда совпадает с нашими требованиями. Имя хоста выбирается автоматически и зависит от хоста, где находятся файлы журналов. Это почти всегда совпадает с нашими требованиями. К недостаткам можно отнести: необходимость установки форвардера на каждый сервер. Если у вас уже настроена система распределения программного обеспечения между серверами, этот аспект не является проблемой. Доступные стратегии мы обсудим в разделе «Развертывание серверов Splunk»; форвардер должен иметь право на чтение всех индексируемых им файлов журналов. Обычно реализация такого сценария не является большой проблемой, но требует некоторой предусмотрительности. Типичная организация системы в подобном случае выглядит примерно так, как показано на рис. 12.1. Splunk Indexer Splunk Forwarder Splunk Forwarder Splunk Forwarder Рис. 12.1  Типичная организация системы Splunk для мониторинга файлов журналов на серверах Типичные источники данных  385 Если объем информации, извлекаемой ежедневно из файлов журналов, превышает 100 Гбайт, вам определенно стоит подумать об архитектуре с несколькими индексерами. Мы подробнее поговорим об этом в разделе «Организация индексирования». Мониторинг файлов журналов на общих дисках (file share) Некоторые клиенты настраивают свои серверы так, что все их файлы журналов располагаются на общем сетевом диске, доступном через NFS или как-то иначе. Такая реализация вполне работоспособна, но далека от идеала. Ниже перечислены основные преимущества такого подхода. Отсутствует необходимость устанавливать форвардер на каждый сервер, записывающий события в файлы журналов на общем диске. Доступ на чтение к этим файлам должен иметь только один сервер Splunk, читающий эти файлы. К недостаткам можно отнести: использование общего сетевого диска может стать причиной большой нагрузки на сеть и сделать ее узким местом; если один файл содержит больше пары мегабайт неидексированных данных, процесс Splunk будет читать этот файл до тех пор, пока не проиндексирует его до конца. Если в системе имеется несколько индексеров, в этот период только один из них будет получать данные от форвардера, обслуживающего общий диск. В высоконагруженной системе форвардер может не успевать обрабатывать вновь поступающие данные; процессы форвардеров Splunk не сообщают друг другу о том, какие файлы были прочитаны. Это усложняет управление отказами форвардеров, если не использовать сеть хранения данных (SAN); факт появления новых записей в файле журнала Splunk определяется по времени последнего изменения файла. На сетевых дисках метаданные, связанные с файлом, могут обновляться не так быстро, как хотелось бы; наличие большого количества файлов журналов, которые требуется прочитать, вызывает увеличение потребления памяти и процессорного времени форвардером Splunk. По этой причине рекомендуется периодически удалять старые файлы журналов, чтобы минимизировать число файлов, за которыми должен следить форвардер Splunk. Типичная организация системы в такой ситуации выглядит, как показано на рис. 12.2. На первый взгляд такая организация выглядит просто, но, к сожалению, она плохо масштабируется. 386  Продвинутая настройка Splunk Indexer Splunk Forwarder Share Рис. 12.2  Типичная организация системы Splunk для мониторинга файлов журналов на разделяемом диске Периодическая (Batch) обработка файлов журналов Реже используется подход периодического сбора файлов журналов после их ротации. Он очень напоминает сценарий мониторинга файлов журналов на разделяемом диске, кроме того что проблема масштабирования может вставать еще острее. Ниже перечислены основные преимущества такого подхода: отсутствует необходимость устанавливать форвардер на каждый сервер, записывающий события в файлы журналов на общем диске. К недостаткам можно отнести: когда происходит ротация файла журнала и если этот файл имеет большой размер, процесс Splunk слишком долго будет занят чтением только этого файла; хорошо, если каталог находится на индексере, но если форвардеру приходится рассылать события нескольким индексерам, в каждый момент времени события будут посылаться только одному индексеру; события не будут читаться из журнала до его ротации и копирования; активный журнал не может копироваться, потому что при копировании события могут усекаться или сервер Splunk может запутаться и посчитать дополненный файл журнала новым и повторно проиндексировать его целиком. Однако иногда это единственный возможный сценарий. В таких ситуациях следует руководствоваться следующими правилами. Копируйте файлы журналов в каталог для их анализа только после того, как произойдет их ротация. Если возможно, в inputs.conf вместо разделов monitor используйте разделы batch, чтобы разрешить Splunk удалять файлы после индексирования. Если возможно, копируйте файлы журналов на разные серверы Splunk или на разные форвардеры, которые затем будут распределять события между несколькими индексерами или, может быть, копировать файлы непосредственно в каталоги для наблюдения на индексерах. При этом вы должны гарантировать, чтобы один и тот же файл журнала не копиро- Типичные источники данных  387 вался сразу на несколько машин, так как в Splunk отсутствует механизм разделения позиций внутри файла между экземплярами. Прием событий от syslog Другим распространенным источником данных является syslog, обычно от устройств, не имеющих файловой системы или не поддерживающих установку дополнительного программного обеспечения. Часто источниками этого типа являются приборы и устройства, посылающие свои события в виде пакетов UDP. Настройка syslog заслуживает отдельной книги, поэтому мы лишь в общих чертах обсудим интеграцию syslog и Splunk. Прием событий непосредственно на стороне индексера Splunk Для очень небольших архитектур вполне может подойти сценарий, когда сервер Splunk непосредственно принимает события syslog через сетевой порт. Типичная организация системы в такой ситуации выглядит, как показано на рис. 12.3. Splunk Indexer device Рис. 12.3  Типичная организация системы Splunk для приема событий syslog непосредственно через сетевой порт На стороне индексера Splunk следует настроить прием по syslog для получения данных через udp или tcp. Соответствующий раздел в inputs.conf может выглядеть примерно так: [udp://514] sourcetype = syslog Преимущество такого подхода заключается в его простоте, а главный недостаток состоит в том, что если процесс Splunk не запущен или занят чемто еще, вы потеряете события, поступившие в этот момент. В числе причин, вызывающих потерю событий, можно назвать: высокую нагрузку на систему, большое число обрабатываемых запросов, медленный диск, проблемы с сетью или приостановку системы для обслуживания либо обновления. Если события syslog важны для вас, есть смысл задействовать syslog коллектор на том же оборудовании, но в идеале желательно использовать отдельное оборудование. Использование syslog-коллектора Для приема событий syslog и записи их на диск рекомендуется использовать автономный коллектор syslog. Примерами таких приемников могут служить 388  Продвинутая настройка rsyslog и syslog-ng. В этом случае можно настроить Splunk для мониторинга каталогов, куда коллектор syslog будет записывать получаемые события. Идеально коллектор syslog следует настроить для записи событий в один файл или каталог для каждого хоста. В этом случае для каждого хоста можно добавить в inputs.conf настройки host_segment или host_regex. Преимущество этой конфигурации состоит в том, что разделы в props.conf могут применяться к хостам, например устанавливать TZ по шаблону имени хоста. Это невозможно, если хост определяется по сообщениям в журнале, как обычно имеет место в случае с syslog. Ниже перечислены основные преимущества использования коллектора syslog. Коллектор syslog не будет решать никаких других задач, поэтому он всегда будет иметь возможность извлечь события из буферов ядра, прежде чем они будут удалены. Промежуточные файлы будут действовать как буфер, поэтому в случае задержек или простоев события не будут теряться. Данные syslog хранятся на диске, поэтому их можно архивировать независимо или запрашивать с помощью других скриптов. Если файлы записываются отдельно для каждого хоста, имя хоста можно извлекать из пути к файлу и применять различные правила парсинга (например, для определения часового пояса). Типичная организация системы для небольших архитектур в такой ситуации выглядит, как показано на рис. 12.4. Splunk Indexer disk syslog-ng device Рис. 12.4  Типичная организация системы Splunk для приема событий с использованием «родного» коллектора syslog Типичные источники данных  389 Поскольку настройка процесса syslog проста и вряд ли изменится с течением времени, простое использование еще одного процесса на том же сервере Splunk повысит уровень защиты от потери сообщений. Медленный диск, высокая нагрузка на центральный процессор или нехватка памяти по-прежнему могут вызывать проблемы, но вам, по крайней мере, не придется беспокоиться о перезапуске процесса Splunk. Следующий уровень защиты – использование отдельного сервера для получения событий syslog и форвардера Splunk для отправки событий одному или нескольким индексерам. Такая конфигурация выглядит, как показано на рис. 12.5. Splunk Indexer Splunk Forwarder disk syslog-ng device Рис. 12.5  Типичная организация системы Splunk для приема событий с использованием коллектора syslog на отдельном сервере Этот единственный сервер все еще является единственной точкой отказа, но у данной конфигурации есть преимущество – сервер Splunk, хранящий индексы, можно перезапустить, не опасаясь негативного влияния на сервер, получающий события syslog. Еще более высокой степени защиты можно добиться, используя балансировщик нагрузки или схему с динамическим DNS для распределения данных syslog между несколькими серверами, осуществляющими прием событий и пересылающими эти события одному или нескольким индексерам Splunk. Такая конфигурация выглядит, как показано на рис. 12.6. Эта конфигурация сложнее в настройке, но очень устойчива, потому что потерю событий может вызвать только глобальный сбой сети. 390  Продвинутая настройка Splunk Indexer Splunk Forwarder disk syslog-ng load balancer device Рис. 12.6  Типичная организация системы Splunk для приема событий с использованием коллектора syslog на отдельном сервере и балансировкой нагрузки Загрузка событий syslog форвардером Splunk Также есть возможность использовать серверы Splunk для непосредственного получения событий syslog и затем передавать их индексерам Splunk. Такая конфигурация выглядит, как показано на рис. 12.7. Splunk Indexer Splunk Forwarder load balancer device Рис. 12.7  Типичная организация системы Splunk для непосредственного приема событий syslog форвардером Splunk Промежуточные процессы форвардеров Splunk можно настроить, определив для них большие входные буферы с помощью параметров queueSize и persistentQueueSize в inputs.conf. Обратите внимание, что в этом случае промежуточ- Типичные источники данных  391 ные форвардеры будут иметь тип Heavy Forwarder. Есть несколько преимуществ такой организации, которые я могу назвать: если процессы форвардеров вместе с устройствами, генерирующими события, находятся в одном дата-центре, тогда форвардер будет автоматически устанавливать часовой пояс событий. Это может быть очень полезно, если у вас имеется несколько дата-центров с устройствами в разных часовых поясах; парсинг событий можно осуществлять на этом этапе и таким способом разгрузить индексеры. Один из недостатков связан с тем, что любые правила парсинга событий, анализируемых этими промежуточными форвардерами, должны определяться на этом уровне, что может потребовать перезапуска при внесении изменений. Извлечение событий из базы данных Некоторые приложения сохраняют события в базе данных. Преимущество этого решения состоит в том, что все журналы хранятся централизованно, а недостаток – в сложности масштабирования из-за ограничений сервера баз данных. Если эти данные загрузить в Splunk, можно воспользоваться преимуществами Splunk для взаимной увязки событий из разных журналов. Процесс извлечения событий из базы данных в общих чертах можно описать так. 1.Сконструировать запрос для извлечения соответствующих событий; например: select date, id, log from log_table 2.Определить поле, которое будет служить указателем. Обычно эту роль играет поле идентификатора или даты события. 3. Изменить запрос, задействовав поле указателя, например: select date,id,log from log_table where id>4567 4.Использовать скрипт ввода для запуска этого запроса, запомнить поле указателя и вывести результаты. На https://splunkbase.splunk.com вы найде те много примеров приложений на разных языках, но вы можете использовать любые языки программирования и инструменты по своему выбору. Лично мне лучше знаком прием использования скрипта ввода с поддержкой JDBC на языке Java. Исключительно ради иллюстрации ниже перечислены шаги, выполнив которые, вы сможете достичь желаемой цели: 1) установите Java 1.5 (или выше); 2) загрузите приложение; 3) скопируйте JAR-файл драйвера JDBC в каталог bin/lib; 4) скопируйте содержимое bin/example в bin/myapp; 392  Продвинутая настройка 5) измените bin/myapp/query.properties, как показано ниже: driverClass=com.mysql.jdbc.Driver connectionString=jdbc:mysql://mydb:3306/myapp?user=u&passwo rd=p iteratorField=id query=select date,id,log from entries where id>${id} order by id 6) добавьте соответствующий раздел в inputs.conf. [script://./bin/run.sh myapp] interval = 60 sourcetype = myapp source = jdbc Этого должно быть достаточно. iteratorField можно опустить, если запрос предусматривает устранение дубликатов каким-то иным способом. Другим популярным решением является использование расширения Splunk DB Connect 3.0. Splunk DB Connect помогает установить надежную связь между Splunk и миром структурированных данных SQL и JDBC. Подробнее об этом расширении вы сможете узнать на странице: https://www.splunk.com/blog/2017/02/20/splunk-db-connect-3-released.html. Использование скриптов для сбора данных Scripted Input в Splunk – это скрипты, которые выдают результаты их отработки в текстовом виде для дальнейшего индексирования Splunk. Splunk будет периодически запускать скрипт, настроенный в inputs.conf. Рассмотрим простой пример. Представьте, что конфигурация inputs.conf внутри приложения содержит следующий раздел: [script://./bin/user_count.sh] interval = 60 sourcetype = user_count И скрипт bin/user_count.sh содержит следующий код: #!/bin/sh DATE=$(date "+%Y-%m-%d %H:%M:%S") COUNT=$(wc -l /etc/passwd | awk '{print "users="$1}') echo $DATE $COUNT Он выводит данные в виде: 2012-10-15 19:57:02 users=84 Отличные примеры таких скриптов можно найти на сайте https://splunkbase. splunk.com. Обратите внимание, что: интервал может определяться в формате задания cron; Powered by TCPDF (www.tcpdf.org) Организация индексирования  393 если имя скрипта оканчивается на .py, для его запуска Splunk будет использовать свою копию Python; не забывайте, что Python не входит в состав универсального форвардера; для управления разбивкой потока текстовых данных на события можно использовать props.conf, как при чтении из обычного файла; если вывод не содержит даты, атрибуту DATETIME_CONFIG следует присвоить значение CURRENT; если события занимают несколько строк (то есть содержат символ перевода строки), атрибуту BREAK_ONLY_BEFORE следует присвоить соответствующий шаблон; если события занимают одну строку (то есть не содержат символа перевода строки), атрибуту SHOULD_LINEMERGE следует присвоить значение False; каждый момент времени может выполняться только одна копия скрипта; если скрипт должен действовать непрерывно, присвойте атрибуту interval значение -1. Организация индексирования Есть целый ряд факторов, влияющих на выбор количества индексеров Splunk, но на начальном этапе моделирования системы обычно руководствуются правилом: «100 Гбайт исходных данных в день на один индексер». В подавляющем большинстве случаев узким местом является производительность дисковой подсистемы, исключая системы с очень медленными процессорами. Расчеты, описываемые ниже, предполагают, что вы будете равномерно распределять события между индексерами с использованием опции autoLB форвардера Splunk. Подробнее о нем мы поговорим, когда будем обсуждать проб лему балансировки нагрузки на индексеры. Модель системы, которую мы возьмем за основу, имеет следующие характеристики. 8 Гбайт ОЗУ (оперативной памяти). Если объем доступной памяти больше, весь остаток после выделения пространства для дискового кеша Splunk будет отдан операционной системе. Восемь быстрых физических процессоров. В высоконагруженном индексере почти постоянно решением задач индексации будут заняты как минимум два ядра. Стоит также отметить следующее: – увеличение числа процессоров не повредит, но, скорее всего, не даст особенного выигрыша, потому что диски, хранящие индексы, едва ли будут поспевать за увеличенной скоростью обработки. Чем больше отдельных индексеров со своими дисками, тем больший объем информации они смогут обработать; – виртуализация практически бесполезна, потому что процессор активно используется во время поиска для парсинга исходных данных; 394  Продвинутая настройка – медленные ядра, спроектированные для выполнения многопоточных приложений, не дадут существенного выигрыша. Например, избегайте использования аппаратных архитектур на процессорах Sun SPARC и AIX. Диски с производительностью 800 IOPS (произвольных операций ввода/вывода в секунду). Такие диски считаются достаточно быстрыми для Splunk. Поищите в своей любимой поисковой системе по фразе «Splunk bonnie++», чтобы узнать, как определить эту величину. Самое главное, о чем следует помнить при тестировании дисков, – объем операций чтения/записи должен быть достаточно велик, чтобы исключить влияние кеша диска на измерения. Также помните, что при использовании общих дисков их производительность будет делиться между всеми индексерами. Одновременно обрабатывается не более четырех запросов. Обратите внимание на следующее: – большинство запросов обрабатывается очень быстро; – это число охватывает интерактивные и хранимые запросы; – для уменьшения нагрузки, создаваемой типичными запросами, можно использовать summary-индексы; – summary-запросы – это обычные сохраняемые поиски. Для проверки существующей системы выполните следующий запрос: index=_audit search_id action=search | transaction maxpause=1h search_id | concurrency duration=duration | timechart span="1h" avg(concurrency) max(concurrency) Ниже приводится формула для грубой оценки (предполагается, что каждый индексер имеет восемь быстрых процессоров и 8 Гбайт ОЗУ): число требуемых индексеров = [измеренное число операций ввода/вывода в секунду] / 800 * [число гигабайтов исходных данных, поступающих за сутки] / 100 * [среднее число конкурирующих запросов] / 4 Непредсказуемость поведения систем, сети и пользователей не позволяет надежно спрогнозировать производительность без тщательного тестирования. Эти числа являются лишь грубой оценкой. Предположим, вы работаете в компании среднего размера, генерирующей около 80 Гбайт данных в день. У вас есть несколько очень активных пользователей, поэтому можно ожидать, что в среднем одновременно будет выполняться четыре запроса. У вас есть хорошие диски, для которых тест bonnie++ показал устойчивый уровень производительности в 950 IOPS. Также иногда запускаются довольно тяжелые запросы для добавления данных в summary-индексы, и ожидается, что в любой момент времени будет обрабатываться хотя бы один такой запрос. Это дает нам следующие оценки: Планирование отказоустойчивости  395 950/800 IOPS * 80/100 Гбайт * (1 summary-запрос + 4 пользовательских запроса) / 4 = 1.1875 индексера Конечно, мы не можем развернуть 1.1875 индексера, поэтому для начала можно запустить один индексер и посмотреть, как он справляется с нагрузкой, или сразу запустить два индексера. Я бы посоветовал начать с двух индексеров, если это возможно. Это даст вам некоторую отказоустойчивость и запас производительности, потому что система мониторинга имеет свойство быстро разрастаться по мере выявления в компании новых источников данных. В идеале, при пересечении отметки в 100 Гбайт, имеет смысл начать с трех индексеров и распределить диски между ними. Дополнительная емкость даст вам возможность остановить один индексер и при этом иметь достаточную емкость, чтобы покрыть нормальную нагрузку. Дополнительную информацию по этому вопросу вы найдете в разделе «Планирование избыточности». Если мы увеличим число средних параллельных запросов, увеличим объем данных, индексируемых в день, или уменьшим число операций ввода-вывода в секунду, необходимое число индексеров должно увеличиваться более или менее линейно. С увеличением среднего числа одновременно обрабатываемых запросов, объема исходных данных, поступающих за сутки, или уменьшением производительности диска число индексеров увеличивается более или менее линейно. С увеличением нагрузки, скажем до 120 Гбайт исходных данных в сутки, 5 пользовательских и 2 summary-запросов, выполняемых одновременно, число индексеров увеличится до: 950/800 IOPS * 120/100 Гбайт * (2 summary-запроса + 5 пользовательских запросов) / 4 = 2.5 индексера Трех индексеров будет достаточно, чтобы покрыть эту нагрузку, но если один индексер остановится, оставшиеся не будут успевать обрабатывать данные, поступающие от форвардеров. В идеале в такой ситуации хорошо бы иметь четыре или более индексеров. Планирование отказоустойчивости Термин «избыточность» может иметь разные значения в зависимости от проб лемы. В Splunk имеются механизмы, помогающие решить некоторые из этих проблем. Начиная с версии 5 в Splunk появился механизм репликации данных, способный устранить большинство из этих проблем. Давайте кратко рассмот рим данную тему. 396  Продвинутая настройка Коэффициент репликации При настройке кластера индексеров Splunk необходимо указать, какое коли чество копий данных должен поддерживать кластер. Отдельные узлы хранят входящие данные в корзинах (bucket), а кластер в целом хранит несколько копий каждой корзины. Все копии корзин сохраняются на разных узлах. Число копий каждой корзины называется коэффициентом репликации Splunk (replication factor). Рассмотрим эту идею на очень простом примере. Имейте в виду, что кластер (индексов) устойчив к отказам, если их число на 1 меньше коэффициента репликации. То есть если вы запустили 3 индексера и задали коэффициент репликации 3, ваша система сможет сохранить работоспособность после отказа 2 индексеров. Добавляя дополнительные узлы, вы можете потребовать от Splunk сохранять копии каждого сегмента (индексированных данных) на отдельных узлах и таким способом повысить отказоустойчивость (то есть число вышедших из строя узлов, не влекущих отказа всей системы). По большей части это выглядит логично и просто; больше узлов – выше отказоустойчивость. Проблема, однако, в том, что вам придется хранить и обрабатывать все эти копии. На веб-сайте Splunk можно найти такое замечание: «Даже притом что на репликацию уходит не очень много вычислительных ресурсов, с увеличением коэффициента репликации требуется запускать больше индексеров и предусматривать больше места для индексированных данных». В действительности системы Splunk почти никогда не бывают такими прос тыми. В большинстве случаев приходится учитывать следующее: в большинстве кластеров каждый узел будет действовать как источник и приемник, получая внешние данные от форвардера и реплицированные данные от других узлов; для лучшего горизонтального масштабирования кластер с коэффициентом репликации 3 может состоять из гораздо большего числа узлов, чем 3. В любой момент времени каждый узел-источник будет передавать копии своих данных двум узлам-приемникам, но каждый раз, когда он начинает заполнять новую «горячую» корзину, его набор узлов-приемников может измениться. Настройка коэффициента репликации Как отмечалось в предыдущем разделе, на практике редко приходится иметь дело с единственным коэффициентом репликации Splunk. Чаще используется модель мультисайтовой кластеризации индексов, поэтому вам потребуется вычислить коэффициент репликации для всего кластера сайтов. Он должен использоваться взамен ранее описанного коэффициента репликации, характерного для односайтового окружения. Планирование отказоустойчивости  397 Параметры настройки определяются на ведущем узле как часть основной конфигурации кластера. Они определяют местоположение копий сегментов в пределах сайта (global) и общее число копий во всем кластере. Для настройки коэффициента репликации на уровне сайта необходимо установить параметр multisite=true. В следующем разделе подробнее рассказывается о коэффициенте репликации для всего кластера. Синтаксис Коэффициент репликации для отдельного сайта настраивается с помощью атрибута site_replication_factor в файле server.conf на ведущем узле. Этот атрибут находится в разделе [clustering] и замещает атрибут replication_factor, используемый в односайтовых окружениях. Например: [clustering] mode = master multisite=true available_sites=site1,site2 site_replication_factor = origin:2,total:3 site_search_factor = origin:1,total:2 Вот синтаксис определения этого атрибута в общем виде: site_replication_factor = origin:<n>, [site1:<n>,] [site2:<n>,] ..., total:<n> где: <n> – положительное целое число, определяющее количество копий корзин; origin:<n> – определяет минимальное число копий корзин, которые должны храниться в пределах сайта (стороны), где создана эта корзина; site1:<n>, site2:<n>, ..., – определяет минимальное число копий, хранимых в пределах каждого сайта; total:<n> – общее число копий каждого сегмента на всех сайтах кластера. Есть разные формулы вычисления site_replication_factor (отличные от формулы, используемой для односайтового окружения). Как обычно, я советую начинать изучение этого вопроса с официальной документации, доступной по адресу: http://docs.splunk.com/Documentation/Splunk/7.0. 2/Indexer/Sitereplicationfactoris. Балансировка нагрузки на индексеры За балансировку нагрузки на индексеры отвечают форвардеры. В самом прос том случае балансировка организуется определением списка индексеров в outputs.conf: [tcpout:nyc] server=nyc-splunk-index01:9997,nyc-splunk-index02:9997 Если текущий индексер недоступен, форвардер просто выберет другой индексер из списка. Эта схема хорошо работает в большинстве случаев. Если 398  Продвинутая настройка запись DNS возвращает несколько адресов, Splunk будет осуществлять балансировку между указанными адресами. По умолчанию форвардер автоматически начинает балансировать нагрузку, если определить параметр autoLB=true. Фактически форвардер будет переключаться между индексерами по таймеру. Это единственный вариант, доступный для форвардеров. В случае с heavy-форвардером, если определить параметр autoLB=false, балансировка будет выполняться по событиям. Это менее эффективно и может привести к непредсказуемым результатам, потому что оригинальный порядок событий не поддерживается при использовании нескольких индексеров. Основные последствия остановки индексеров В случае с единственным индексером его остановка – например, для обновления системы – приведет к накоплению событий в очередях форвардеров. Если в системе имеется несколько индексеров, форвардеры продолжат посылать события оставшимся индексерам. Давайте рассмотрим простой сценарий. Допустим, у нас имеется четыре машины, и форвардеры настроены на балансирование нагрузки между двумя индексерами, как показано на рис. 12.8. Indexer Indexer Forwarder Forwarder Рис. 12.8  Система Splunk с четырьмя машинами Пока все работает, каждый форвардер посылает половину своих событий каждому индексеру. Если один индексер остановится, остается только один индексер, как показано на рис. 12.9. Indexer Indexer Forwarder Forwarder Рис. 12.9  Система Splunk с одним остановленным индексером Работа с несколькими индексами  399 В этом случае: все события будут посылаться единственному оставшемуся индексеру; все события, хранящиеся на остановленном индексере, станут недоступны и не будут включаться в результаты поиска. Splunk может решить эту проблему ценой потребления дополнительного дискового пространства; запросы, целью которых являются самые свежие события, будут обрабатываться как обычно, потому что необходимые события будут сохраняться на оставшемся индексере (здесь предполагается, что один индексер в состоянии покрыть рабочую нагрузку). Если объем поступающих данных превышает пропускную способность одного индексера, он не будет успевать их обрабатывать своевременно; в результате мы можем не увидеть новых событий, пока второй индексер не включится в работу. С увеличением числа индексеров отрицательный эффект от отключения одного из них будет становиться все меньше, как показано на рис. 12.10. Search Indexer Indexer Indexer Indexer Forwarder Рис. 12.10  С увеличением числа индексеров отрицательный эффект от отключения одного из них уменьшается В этом случае мы потеряем только 25 процентов пропускной способности индексеров, и недоступными станут лишь 25 % исторических данных. До тех пор, пока три индексера будут успевать обрабатывать поток входных данных, мы будем иметь своевременный доступ к новым событиям. С увеличением числа индексеров отрицательный эффект от отключения одного из них будет становиться все меньше. Работа с несколькими индексами Индекс в Splunk – это набор событий, ограниченный определенным размером, интервалом времени или обоими параметрами сразу. По умолчанию все события передаются в индекс, определяемый атрибутом defaultDatabase, который называется main и располагается в каталоге defaultdb. 400  Продвинутая настройка Структура каталогов индекса Каждый индекс располагается в нескольких каталогах на диске. По умолчанию это дерево каталогов находится в $SPLUNK_DB, или, по умолчанию, в $SPLUNK_HOME/ var/lib/splunk. Взгляните на следующий раздел с настройками главного индекса: [main] homePath = $SPLUNK_DB/defaultdb/db coldPath = $SPLUNK_DB/defaultdb/colddb thawedPath = $SPLUNK_DB/defaultdb/thaweddb maxHotIdleSecs = 86400 maxHotBuckets = 10 maxDataSize = auto_high_volume Если система Splunk установлена в /opt/splunk, тогда корневым каталогом индекса будет каталог /opt/splunk/var/lib/splunk/defaultdb. Чтобы изменить местоположение индекса, нужно изменить значение SPLUNK_DB в $SPLUNK_HOME/etc/splunk-launch.conf или задать абсолютный путь в indexes.conf. splunk-launch.conf не контролируется из приложений, а значит, о нем легко забыть при добавлении индексеров. По этой причине, и для большей удобочитаемости, я советую использовать абсолютные пути в indexes.conf. Каталоги homePath хранят метаданные уровня индекса, а также горячие и теп лые корзины. coldPath хранит холодные корзины, которые являются всего лишь устаревшими теплыми корзинами. Более подробно об этом рассказывается в разделах «Жизненный цикл корзины» и «Определение размера индекса». Когда следует создавать дополнительные индексы Есть несколько причин для создания дополнительных индексов. Если ни одна из них не соответствует вашим потребностям, значит, нет причин создавать другие индексы. На самом деле добавление индексов ухудшает общую производительность, потому что в такой ситуации для обработки одного запроса приходится открывать несколько индексов. Для нужд тестирования Если у вас нет тестового окружения, вы можете размещать новые данные в тес товых индексах. В этом случае вы легко сможете восстановить работоспособность системы после ошибки, просто удалив тестовый индекс. Так как Splunk может работать на настольном компьютере, старайтесь тестировать новые конфигурации локально, если это возможно. Иной срок хранения Нередко для одних типов источников иногда требуется хранить больше исторических данных, чем для других. Классический пример – журналы системы безопасности, которые желательно хранить более долгий срок, чем журналы веб-доступа. Журналы системы безопасности может понадобиться хранить Работа с несколькими индексами  401 год или более, тогда как журналы веб-доступа достаточно хранить лишь пару недель. Если данные из таких двух источников помещать в один индекс, события, порожденные системой безопасности, будут храниться в тех же сегментах, что и события веб-доступа, и устаревать одновременно. Чтобы разделить эти события, нужно выполнить следующие шаги. 1. Создать новый индекс, например с именем security. 2. Определить для этого индекса свои настройки. 3.Обновить inputs.conf, чтобы организовать сохранение событий из источников определенных типов в новом индексе. Чтобы организовать хранение событий в индексе в течение года, можно добавить в indexes.conf такие настройки: [security] homePath = $SPLUNK_DB/security/db coldPath = $SPLUNK_DB/security/colddb thawedPath = $SPLUNK_DB/security/thaweddb # один год в секундах frozenTimePeriodInSecs = 31536000 Для дополнительной защиты следует также установить параметры maxTotalDataSizeMB и, может быть, coldToFrozenDir. При наличии нескольких индексов, которые должны устаревать одновременно, или размещении homePath и coldPath на разных устройствах используйте тома. Подробнее об этом рассказывается в разделе «Использование томов для управления несколькими индексами». После этого останется лишь добавить в inputs.conf индекс в соответствующий раздел, например: [monitor:///path/to/security/logs/logins.log] sourcetype=logins index=security Иные разрешения Если какие-то данные должны быть доступны ограниченному кругу пользователей, самый эффективный способ реализовать такое ограничение – помес тить данные в отдельный индекс и ограничить доступ к нему определенной ролью. Ниже перечислены основные шаги, которые необходимо выполнить для этого. 1. Определить новый индекс. 2.Настроить inputs.conf или transforms.conf, организовав передачу событий в новый индекс. 3. Убедиться, что роль user не имеет доступа к этому индексу. 4. Создать новую роль с правом доступа к новому индексу. 5.Добавить в новую роль требуемый круг пользователей. При использовании аутентификации LDAP необходимо отобразить роль в группу LDAP и добавить пользователей в эту группу LDAP. 402  Продвинутая настройка Для отправки конкретных событий в этот новый индекс, например с именем sensitive, можно определить такое преобразование: [contains_password] REGEX = (?i)password[=:] DEST_KEY = _MetaData:Index FORMAT = sensitive Далее это преобразование можно связать с конкретным значением sourcetype или source в props.conf. Примеры, как это делается, вы найдете в главе 11 «Настройка Splunk». Увеличение производительности Помещая события с разными типами источников в разных индексах, можно добиться увеличения производительности, если события с этими типами источников извлекаются порознь. В этом случае будет тратиться меньше времени на позиционирование головок диска. При наличии нескольких устройств хранения размещение индексов на разных устройствах может помочь увеличить производительность даже больше, чем использование разных физических серверов для обработки разных запросов. Аналогично размещение homePath и coldPath на разных устройствах также способствует увеличению производительности. Однако при регулярном выполнении запросов, использующих сразу несколько типов источников, распределение таких событий по разным индексам фактически может отрицательно сказаться на производительности. Например, представьте, что у нас имеются два типа источников: web_access и web_error. Представьте также, что в web_access имеется строка: 2012-10-19 12:53:20 code=500 session=abcdefg url=/path/to/app и в web_error имеется строка: 2012-10-19 12:53:20 session=abcdefg class=LoginClass Чтобы объединить эти результаты, можно выполнить такой запрос: (sourcetype=web_access code=500) OR sourcetype=web_error | transaction maxspan=2s session | top url class Если события с типами источников web_access и web_error хранить в разных индексах, этому запросу потребуется дважды обратиться к сегментам индекса, и фактически он будет обрабатываться в два раза дольше. Жизненный цикл корзины (bucket) Индекс состоит из корзин, каждая из которых имеет свой жизненный цикл. Каждая корзина содержит события за определенный период времени. Как упоминалось в главе 11 «Настройка Splunk», жизненный цикл делится на этапы: hot (горячий), warm (теплый), cold (холодный), frozen (заморожен- Работа с несколькими индексами  403 ный) и thawed (размороженный). Единственная практическая разница между горячей и другими корзинами – горячая корзина постоянно пополняется и не обязательно оптимизирована. Корзины, соответствующие этим этапам, располагаются в разных местах на диске и управляются разными настройками в indexes.conf. homePath содержит горячие корзины по числу в maxHotBuckets и теплые корзины по числу в maxWarmDBCount. Когда завершается заполнение горячей корзины, она становится теплой. Когда теплых корзин становится слишком много, самая старая из них становится холодной. Не устанавливайте слишком маленькое значение в maxHotBuckets. Если парсинг данных происходит не идеально, ошибочный парсинг дат приведет к появлению слишком больших интервалов времени. Старые и вновь создаваемые корзины будут перекрываться во времени, а значит, запросам придется просматривать больше корзин, что приведет к ухудшению производительности. Значение 5 можно считать вполне безопасным. coldPath содержит холодные корзины, которые перед ротацией были теплыми и хранились в homePath. Ротация теплых корзин в холодные происходит, когда число теплых корзин превысит значение maxWarmDBCount. Если coldPath находится на том же устройстве, ротация будет выполняться очень быстро, простым переименованием/перемещением файла; в противном случае будет выполняться более долгая операция копирования. По достижении значения в параметре frozenTimePeriodInSecs, maxTotalDataSizeMB или maxVolumeDataSizeMB самая старый холодная корзина будет заморожена. По умолчанию под заморозкой понимается удаление. Это поведение можно изменить, определив любой из следующих параметров: – coldToFrozenDir: определяет каталог для перемещения замороженных корзин. Splunk удалит файлы индекса и сохранит сжатые копии исходных данных. Это позволяет сократить потребление дискового пространства почти вдвое. Данный каталог не управляется системой Splunk, поэтому вам самим придется позаботиться о его своевременной очистке, чтобы избежать переполнения диска; – coldToFrozenScript: определяет скрипт, выполняющий некоторые действия при заморозке корзины. Скрипт должен выбрать каталог для сохранения замороженной корзины; – thawedPath: определяет каталог для восстановленных (размороженных) корзин. Эти корзины не управляются системой Splunk и по умолчанию не используются при выполнении поиска по всему диапазону времени. Чтобы задействовать эти корзины в поиске, нужно явно включить в запрос охватываемый ими диапазон времени. Лично мне никогда не доводилось использовать этот каталог. Если вам понадобится дополнительная информация, попробуйте поискать на сайте https:// splunk.com по фразе «restore archived». 404  Продвинутая настройка Определение размера индекса Чтобы оценить, сколько дискового пространства потребуется для хранения индекса, можно воспользоваться следующей формулой: (гигабайт в сутки) * .5 * (дней хранения) Аналогично, чтобы узнать, сколько за какой период в днях можно хранить события в индексе, можно воспользоваться следующей формулой: (емкость устройства в гигабайтах) / ( (гигабайт в сутки) * .5 ) Число .5 – это коэффициент сжатия. Обычно после сжатия исходных данных их объем уменьшается почти в 10 раз. Файлы сегментов индекса, необходимые для ускорения поиска, имеют размер примерно в два раза меньше оригинального, хотя нередко существенно меньше. Если вы планируете разнести сегменты по разным устройствам, формулы будут выглядеть сложнее, если не использовать тома. Без томов фактические формулы выглядят так: homePath = (maxWarmDBCount + maxHotBuckets) * maxDataSize coldPath = maxTotalDataSizeMB - homePath Например, допустим, что мы определили следующие настройки: [myindex] homePath = /splunkdata_home/myindex/db coldPath = /splunkdata_cold/myindex/colddb thawedPath = /splunkdata_cold/myindex/thaweddb maxWarmDBCount = 50 maxHotBuckets = 6 maxDataSize = auto_high_volume #10 Гбайт в 64-разраядных системах maxTotalDataSizeMB = 2000000 Подставив эти значения в формулы выше, получим: homePath = (50 warm + 6 hot) * 10240 MB = 573440 MB coldPath = 2000000 MB - homePath = 1426560 MB При использовании томов вычисления упрощаются – мы можем просто задать размеры томов и переложить все вычисления на плечи Splunk. Использование томов для управления индексами Тома объединяют пулы хранения разных индексов и обеспечивают их одновременное устаревание. Рассмотрим ситуацию, когда имеется пять индексов и три устройства хранения. Индексы: Имя web security app chat web_summary Данных в сутки 50 Гбайт 1 Гбайт 10 Гбайт 2 Гбайт 1 Гбайт Хранить не требуется 2 года не требуется 2 года 1 год Требуемый объем ? 730 Гбайт * 50% ? 1460 Гбайт * 50% 365 Гбайт * 50% Работа с несколькими индексами  405 Устройства: Имя small_fast big_fast big_slow Размер 500 Гбайт 1000 Гбайт 5000 Гбайт Опираясь на требуемое время хранения, мы можем создать тома. Индексы security и chat имеют общие требования к продолжительности хранения, по этому поместим их в один том. Горячие сегменты желательно хранить на самых быстрых устройствах, поэтому для начала определим такую конфигурацию: [volume:two_year_home] # место хранения для security и chat path = /small_fast/two_year_home maxVolumeDataSizeMB = 300000 [volume:one_year_home] # место хранения для web_summary path = /small_fast/one_year_home maxVolumeDataSizeMB = 150000 Для хранения остальных сегментов этих индексов определим сопутствующий том, размещенный на устройстве big_slow: [volume:two_year_cold] # место хранения холодных корзин security и chat path = /big_slow/two_year_cold maxVolumeDataSizeMB = 850000 #([security]+[chat])*1024 - 300000 [volume:one_year_cold] # место хранения холодных корзин web_summary path = /big_slow/one_year_cold maxVolumeDataSizeMB = 230000 #[web_summary]*1024 - 150000 Для хранения остальных индексов, срок хранения которых не важен, используем big_fast и остаток на big_slow: [volume:large_home] # место хранения для web и app path = /big_fast/large_home maxVolumeDataSizeMB = 900000 # оставить 10% на непредвиденные обстоятельства [volume:large_cold] # место хранения для холодных корзин web и app path = /big_slow/large_cold maxVolumeDataSizeMB = 3700000 #(big_slow - two_year_cold - one_year_cold)*.9 Учитывая, что сумма large_home и large_cold составляет 4 600 000 Мбайт и совокупный ежесуточный объем новых данных для индексов web и app составляет 60 000 Мбайт, получаем предельный срок хранения web и app с 50%-ным сжатием около 153 дней. В действительности число дней будет несколько больше. Определив тома, мы можем ссылаться на них в определениях индексов: 406  Продвинутая настройка [web] homePath = volume:large_home/web coldPath = volume:large_cold/web thawedPath = /big_slow/thawed/web [security] homePath = volume:two_year_home/security coldPath = volume:two_year_cold/security thawedPath = /big_slow/thawed/security coldToFrozenDir = /big_slow/frozen/security [app] homePath = volume:large_home/app coldPath = volume:large_cold/app thawedPath = /big_slow/thawed/app [chat] homePath = volume:two_year_home/chat coldPath = volume:two_year_cold/chat thawedPath = /big_slow/thawed/chat coldToFrozenDir = /big_slow/frozen/chat [web_summary] homePath = volume:one_year_home/web_summary coldPath = volume:one_year_cold/web_summary thawedPath = /big_slow/thawed/web_summary Параметр thawedPath нельзя определить с использованием синтаксиса томов, и его следует задавать явно. Для дополнительной защиты мы определили coldToFrozenDir, куда должны переписываться корзины индексов security и chat перед удалением, но помните, что вы должны сами своевременно чистить этот каталог, чтобы избежать переполнения диска. Если диск переполнится, Splunk прекратит заполнение корзин в этом томе. Это был лишь один из подходов к использованию томов. Вы можете организовывать тома любым способом, но не забывайте, что первым замораживаться будет самый старый сегмент в томе, независимо от того, к какому индексу он принадлежит. Развертывание серверов Splunk Splunk предлагает готовые скомпилированные дистрибутивы для Windows и разных версий Unix. Дистрибутивы для Unix распространяются в виде сжатых архивов .tar. Для некоторых платформ имеются также свои пакеты. Если в вашей организации применяются пакеты, такие как deb или rpm, вы сможете использовать предлагаемые пакеты и привычную процедуру их установки. Во всех остальных случаях установка начинается с распаковывания архива tar в некоторый выбранный вами каталог. Процесс установки полноценной версии Splunk и форвардера один и тот же. Развертывание серверов Splunk  407 Типичная процедура установки включает следующие этапы: 1) установка двоичных файлов; 2) добавление базовой конфигурации; 3) настройка запуска Splunk на этапе загрузки операционной системы; 4) перезапуск Splunk. Имея многолетний опыт работы со многими компаниями, могу честно сказать, что ни в одной из них не использовался похожий продукт или даже методология развертывания программного обеспечения. Splunk реализует подход автоматической установки, чтобы максимально легко вписаться в рабочие процессы клиентов. Развертывание из файла tar Порядок развертывания сервера из файла tar зависит от используемой версии tar. При наличии современной версии tar можно выполнить следующую команду: tar xvzf splunk-7.0.x-xxx-Linux-xxx.tgz Более старые версии могут не поддерживать сжатие gzip. В таком случае то же самое можно сделать следующей командой: gunzip -c splunk-7.0.x-xxx-Linux-xxx.tgz | tar xvf - Эти команды распакуют содержимое архива в текущий каталог. Чтобы распаковать архив в другой каталог, добавьте ключ -C в команду tar: tar -C /opt/ -xvzf splunk-7.0.x-xxx-Linux-xxx.tgz Развертывание из дистрибутива msiexec Развернуть Splunk в Windows можно с помощью msiexec. Этот прием позволяет легко развернуть серверы Splunk на большом количестве компьютеров. Чтобы установка протекала без лишних вопросов, можно передать комбинацию ключей AGREETOLICENSE и /quiet: msiexec.exe /i splunk-xxx.msi AGREETOLICENSE=Yes /quiet Если планируется использовать сервер развертывания, можно указать следующие значения: msiexec.exe /i splunk-xxx.msi AGREETOLICENSE=Yes DEPLOYMENT_SERVER="deployment_server_name:8089" /quiet Или, если планируется наложить приложение, содержащее deploymentclient. conf, можно отложить запуск Splunk до копирования этого приложения на место: msiexec.exe /i splunk-xxx.msi AGREETOLICENSE=Yes LAUNCHSPLUNK=0 /quiet Есть возможность добавить ключи установки, позволяющие немедленно начать чтение данных, но я бы не советовал использовать их, а явно определять конфигурации загрузки данных. 408  Продвинутая настройка Добавление базовой конфигурации Если вы используете сервер развертывания (Deployment Server), сейчас самое время настроить файл deploymentclient.conf. Сделать это можно несколькими способами. Выполнив команду в командной строке: $SPLUNK_HOME/bin/splunk set deploy-poll deployment_server_name:8089 Напрямую скопировав файл deploymentclient.conf в: $SPLUNK_HOME/etc/system/local/ Скопировав приложение с файлом deploymentclient.conf в: $SPLUNK_HOME/etc/apps/ Я бы рекомендовал третий вариант, потому что он позволяет переопределить эту конфигурацию позднее через сервер развертывания. Пример такого подхода мы рассмотрим в разделе «Использование сервера развертывания Splunk». Если вы собираетесь настраивать конфигурацию каким-то другим способом, например с помощью puppet, не забудьте перезапустить процессы форвардеров Splunk после развертывания новой конфигурации. Настройка запуска Splunk на этапе загрузки операционной системы На компьютерах с ОС Windows Splunk устанавливается как служба, которая автоматически запускается после установки и перезагрузки. В системах Unix наличие команды splunk дает возможность создать и использовать сценарий запуска в соответствии с операционной системой. Вот как это выглядит: $SPLUNK_HOME/bin/splunk enable boot-start Чтобы запустить Splunk от имени другого пользователя, нужно добавить флаг -user: $SPLUNK_HOME/bin/splunk enable boot-start -user splunkuser Команда splunk все еще должна запускаться с привилегиями пользователя root, но сценарий запуска изменится и будет запускаться с привилегиями указанного пользователя. Если система Splunk должна работать с привилегиями обычного пользователя (что желательно в большинстве случаев), убедитесь, что каталог установки и каталоги с данными принадлежат пользователю, указанному в команде enab le boot-start. Изменить принадлежность каталогов можно с помощью команды chmod, например chmod -R splunkuser $SPLUNK_HOME. В некоторых дистрибутивах Linux после этого нужно выполнить команду service splunk start. Использование приложений для организации конфигурации  409 Использование приложений для организации конфигурации Организовать конфигурации в распределенной архитектуре можно несколькими способами. Наиболее очевидным является подход к организации по типу машины. Например, можно поместить все конфигурационные файлы для вебсерверов в одно приложение, а все конфигурационные файлы для серверов баз данных – в другое. Проблема этого подхода – в том, что любые изменения, затрагивающие оба типа машин, придется сделать в обоих приложениях, а это чревато ошибками. Более надежный и вместе с тем более сложный подход заключается в нормализации конфигураций. Он гарантирует наличие только одной копии каждой конфигурации, распределенной по нескольким приложениям. Распределение конфигураций по целям Обычно в типичной процедуре установки используются конфигурационные приложения с именами: inputs-sometype: группа приложений с настройками загрузки данных. Настройки можно группировать по назначению машины, типу источника, местоположению, операционной системе или любым другим способом, имеющим смысл в вашей ситуации. Обычно я выполняю группировку по назначению машин или типам источников; props-sometype: эта группа приложений должна примерно соответствовать группе с настройками загрузки данных. Приложения с настройками props могут учитывать не только тип, но, например, тип машины и ее местоположение; outputs-datacenter: при развертывании в нескольких дата-центрах час то в каждом из них настраиваются свои индексеры Splunk. В этом случае вам понадобятся приложения для дата-центров; indexerbase: если все индексеры имеют схожие настройки, логично было бы поместить их в приложение и развертывать его как любое другое приложение. Все эти конфигурации полностью отделены от задач поиска, которые должны реализовываться в отдельных приложениях, создаваемых и поддерживаемых через веб-интерфейс Splunk. Представьте, что у нас есть распределенная архитектура в двух дата-цент рах – восточном (east) и западном (west). В каждом дата-центре размещены веб-серверы, серверы приложений и серверы баз данных. В каждом дата-центре имеется два индексера Splunk. Для этой архитектуры можно было бы определить следующие приложения: inputs-web, inputs-app и inputs-db: – inputs.conf определяет файлы журналов для мониторинга; 410  Продвинутая настройка каждое приложение должно быть развернуто на каждой машине, предназначенной для этой цели. Если некоторые машины служат нескольким целям, на них должны развертываться все соответствующие приложения; props-web, props-app и props-db: – props.conf определяет порядок парсинга файлов журналов; – transforms.conf включает необходимые преобразования; – разные части props.conf используются на разных этапах обработки. Поскольку трудно сказать, где и какой этап будет выполняться, обычно проще развернуть все эти приложения на всех машинах; props-west и props-east: – иногда возникает необходимость внести изменения в конфигурацию в зависимости от местоположения, например настроить часовой пояс. Для этого можно использовать атрибут TZ в props.conf и развертывать приложения в соответствующих дата-центрах; outputs-west и outputs-east: – эти приложения могут содержать только конфигурации outputs.conf для соответствующих дата-центров; indexerbase: – если предположить, что все индексеры настраиваются одинаково, это приложение могло бы содержать стандартную конфигурацию indexes. conf, конфигурацию inputs.conf с определением номера порта для приема соединений от форвардеров и конфигурацию server.conf с адресом сервера лицензий Splunk. Рассмотрим содержимое всех этих файлов: следующие приложения мы должны развернуть на форвардерах: inputs-web local/inputs.conf [monitor:///path/to/web/logs/access*.log] sourcetype = web_access index = web [monitor:///path/to/web/logs/error*.log] sourcetype = web_error index = web inputs-app local/inputs.conf [monitor:///path/to/app1/logs/app*.log] sourcetype = app1 index = app [monitor:///path/to/app2/logs/app*.log] sourcetype = app2 index = app inputs-db local/inputs.conf Использование приложений для организации конфигурации  411 [monitor:///path/to/db/logs/error*.log] sourcetype = db_error outputs-west local/outputs.conf [tcpout:west] server=spl-idx-west01.foo.com:9997,spl-idx-west02.foo.com:9997 #autoLB=true -- значение по умолчанию outputs-east local/outputs.conf [tcpout:east] server=spl-idx-east01.foo.com:9997,spl-idx-east02.foo.com:9997 следующие приложения нужно развернуть на всех серверах: props-web local/props.conf [web_access] TIME_FORMAT = %Y-%m-%d %H:%M:%S.%3N %:z MAX_TIMESTAMP_LOOKAHEAD = 32 SHOULD_LINEMERGE = False TRANSFORMS-squashpassword = squashpassword [web_error] TIME_FORMAT = %Y-%m-%d %H:%M:%S.%3N %:z MAX_TIMESTAMP_LOOKAHEAD = 32 TRANSFORMS-squashpassword = squashpassword local/transforms.conf [squashpassword] REGEX = (?mi)^(.*)password[=:][^,&]+$ FORMAT = $1password=########$2 DEST_KEY = _raw props-app local/props.conf [app1] TIME_FORMAT = %Y-%m-%d %H:%M:%S.%3N MAX_TIMESTAMP_LOOKAHEAD = 25 BREAK_ONLY_BEFORE = ^d{4}-d{1,2}-d{1,2}s+d{1,2}:d{1,2} [app2] TIME_FORMAT = %Y-%m-%d %H:%M:%S.%3N MAX_TIMESTAMP_LOOKAHEAD = 25 BREAK_ONLY_BEFORE = ^d{4}-d{1,2}-d{1,2}s+d{1,2}:d{1,2} props-db local/props.conf [db_error] MAX_TIMESTAMP_LOOKAHEAD = 25 props-west 412  Продвинутая настройка local/props.conf [db_error] TZ = PST [web_error] TZ = PST props-east local/props.conf [db_error] TZ = EST [web_error] TZ = EST наконец, следующее приложение нужно развернуть на индексерах: indexerbase local/indexes.conf [volume:two_year_home] path = /small_fast/two_year_home maxVolumeDataSizeMB = 300000 [volume:one_year_home] path = /small_fast/one_year_home maxVolumeDataSizeMB = 150000 [volume:two_year_cold] path = /big_slow/two_year_cold maxVolumeDataSizeMB = 1200000 [volume:one_year_cold] path = /big_slow/one_year_cold maxVolumeDataSizeMB = 600000 [volume:large_home] path = /big_fast/large_home maxVolumeDataSizeMB = 900000 [volume:large_cold] path = /big_slow/large_cold maxVolumeDataSizeMB = 3000000 [web] homePath = volume:large_home/web coldPath = volume:large_cold/web thawedPath = /big_slow/thawed/web [app] homePath = volume:large_home/app coldPath = volume:large_cold/app thawedPath = /big_slow/thawed/app [main] homePath = volume:large_home/main coldPath = volume:large_cold/main Установка конфигурации  413 thawedPath = /big_slow/thawed/main local/inputs.conf [splunktcp://9997] local/server.conf [license] master_uri = https://spl-license.foo.com:8089 Это минимальный набор приложений, но он позволяет получить достаточно хорошее представление о настройке распределенной архитектуры. Далее мы проиллюстрируем, куда должны устанавливаться приложения. Установка конфигурации Как мы уже знаем, конфигурация в Splunk – это просто дерево каталогов с текстовыми файлами. Установка конфигурации, по сути, заключается в копировании этих файлов на соответствующие машины и перезапуске серверов Splunk. Для установки можно использовать собственную систему, например на основе puppet или простого набора сценариев, или задействовать сервер развертывания (Deployment Server), входящий в состав Splunk. Использование собственной системы развертывания Преимущество использования собственной системы заключается в том, что вы уже знаете, как ее использовать. При наличии нормализованных приложений, о которых рассказывалось в разделе «Использование приложений для организации конфигурации», для их развертывания на форвардерах и индексерах достаточно выполнить следующие шаги. 1. Оставить на месте приложения, уже имеющиеся в $SPLUNK_HOME/etc/apps/. 2.Скопировать приложения, предназначенные для развертывания, в $SPLUNK_HOME/etc/apps/. 3.Перезапустить форвардер Splunk. Обратите внимание, что перезапуск следует выполнять с привилегиями пользователя, от имени которого был запущен форвардер Splunk, либо вызовом сценария запуска службы, либо с использованием команды su. В Windows следует перезапустить службу splunkd. Собственно, это все, если у вас уже имеется действующая система управления конфигурациями. Развертывать конфигурации на индексерах следует, только когда их остановка допустима, так как для загрузки новых конфигураций индексеры придется перезапустить. Не развертывайте конфигураций, пока вы не будете готовы выполнить перезапуск, потому что некоторые (но не все) конфигурации вступают в действие немедленно. 414  Продвинутая настройка Использование Splunk Deployment Server В отсутствие своей системы управления конфигурациями вы можете воспользоваться сервером развертывания, входящим в состав Splunk. Вот некоторые преимущества подхода с использованием сервера развертывания Splunk: включит в установку Splunk все необходимое; корректно перезапустит форвардеры после развертывания новых версий приложений; не будет выполнять перезапуск, если в этом нет необходимости; удалит приложения, которые больше не нужны на машине; оставит нетронутыми приложения, которыми не управляет; журналы с событиями развертывания клиента и сервера доступны в Splunk. И недостатки: начиная с версии Splunk 4.3 наблюдаются проблемы с масштабированием при развертывании более чем нескольких сотен клиентов – в какойто момент необходимо прибегнуть к дополнительным настройкам (одно из решений заключается в использовании нескольких серверов развертывания); конфигурация сложна, и при ее наборе легко допустить опечатки. А теперь, памятуя о недостатках, настроим сервер развертывания для установки приложений, описанных выше. Шаг 1 – выбор машины для сервера развертывания Для небольших архитектур, включающих не более нескольких десятков форвардеров, сервер развертывания можно запустить на главном сервере Splunk. При большем количестве форвардеров для сервера развертывания желательно выделить отдельную машину. В идеале этот сервер должен работать на собственной машине. Требования к машине невелики, достаточно 4 Гбайт оперативной памяти и двух процессоров. Подойдет и виртуальная машина. По возможности определите DNS-запись для сервера развертывания. Позже это упростит перемещение сервера развертывания на другую машину. Если у вас нет отдельной машины, можете запустить еще один сервер Splunk на той же машине, где выполняются другие серверы Splunk. Для этого выполните следующие действия: 1.Установите копию Splunk в другой каталог, например /opt/splunk-deploy/ splunk/. 2.Запустите эту копию сервера Splunk командой /opt/splunkdeploy/splunk/ bin/splunk start. В ответ на запрос укажите другие номера портов, отличные от номеров по умолчанию, и запомните их. Я в таких случаях использую номера на единицу выше: 8090 и 8001. 3.К сожалению, если выполнить команду splunk enable boot-start для этой новой копии, она затрет существующий сценарий запуска. Чтобы орга- Установка конфигурации  415 низовать автоматический запуск обоих экземпляров, нужно или отредактировать имеющийся сценарий запуска, или переименовать сущест вующий сценарий, чтобы он не был затерт. Шаг 2 – настройка конфигурации deploymentclient.conf Используя адрес нового сервера развертывания, в идеале DNS-запись, создадим приложение с именем deploymentclient-yourcompanyname. Первоначально это приложение следует установить вручную на форвардерах, но потом оно может управляться сервером развертывания. Вот как примерно должно выглядеть это приложение: deploymentclient-yourcompanyname local/deploymentclient.conf [deployment-client] [target-broker:deploymentServer] targetUri=deploymentserver.foo.com:8089 Шаг 3 – определение типов и местоположений машин Как мы определили в разделе «Распределение конфигураций по целям», в датацентрах «восточный» и «западный» у нас имеются машины следующих типов: индексеры Splunk; серверы баз данных; веб-серверы; серверы приложений. Шаг 4 – нормализация конфигураций в соответствующие приложения Для простоты примера используем приложения, созданные в разделе «Распределение конфигураций по целям», а также приложение развертывания клиента, созданное в разделе «Шаг 2 – настройка конфигурации deploymentclient.conf». Эти приложения должны находиться в каталоге $SPLUNK_HOME/etc/deploymentapps/ на сервере развертывания. Шаг 5 – сопоставление приложений с клиентами в serverclass.conf В подобных случаях я всегда начинаю со второго примера в SPLUNK_HOME/etc/ system/README/serverclass.conf: [global] [serverClass:AppsForOps] whitelist.0=*.ops.yourcompany.com [serverClass:AppsForOps:app:unix] [serverClass:AppsForOps:app:SplunkLightForwarder] Допустим, у нас имеются машины, перечисленные ниже. Организации очень редко проявляют последовательность в выборе имен хостов, поэтому я добавил в конец списка пару хостов, имена которых выбиваются из общего строя: 416  Продвинутая настройка spl-idx-west01 spl-idx-west02 spl-idx-east01 spl-idx-east02 app-east01 app-east02 app-west01 app-west02 web-east01 web-east02 web-west01 web-west02 db-east01 db-east02 db-west01 db-west02 qa01 homer-simpson Файл serverclass.conf имеет следующую структуру: [serverClass:<className>] # параметры, применяемые ко всем приложениям в этом классе [serverClass:<className>:app:<appName>] # параметры, применяемые к конкретному приложению в этом классе Обратите внимание, что: <className> – произвольное имя, выбранное вами; <appName> – имя каталога в $SPLUNK_HOME/etc/deploymentapps/; порядок следования разделов не имеет значения. Не забудьте обновить <className>, копируя разделы :app:. Делая это, легко ошибиться. Важно отметить, что изменения в конфигурации не вызывают перезапуск индексеров. Применим вышесказанное к нашим хостам: [global] restartSplunkd = True # перезапускать splunk при изменении конфигурации #### ИНДЕКСЕРЫ ## индексеры обрабатываются особо, они не должны перезапускаться [serverClass:indexers] whitelist.0=spl-idx-* restartSplunkd = False [serverClass:indexers:app:indexerbase] [serverClass:indexers:app:deploymentclient-yourcompanyname] [serverClass:indexers:app:props-web] [serverClass:indexers:app:props-app] [serverClass:indexers:app:props-db] # передать props-west только индексерам в дата-центре "западный" [serverClass:indexers-west] Установка конфигурации  417 whitelist.0=spl-idx-west* restartSplunkd = False [serverClass:indexers-west:app:props-west] # передать props-east только индексерам в дата-центре "восточный" [serverClass:indexers-east] whitelist.0=spl-idx-east* restartSplunkd = False [serverClass:indexers-east:app:props-east] #### ФОРВАРДЕРЫ # передать настройки парсинга событий всем форвардерам # добавить индексеры в черный список, # чтобы предотвратить нежелетельный перезапуск [serverClass:props] whitelist.0=* blacklist.0=spl-idx-* [serverClass:props:app:props-web] [serverClass:props:app:props-app] [serverClass:props:app:props-db] # передать props-west только индексерам в дата-центре "западный" # добавить индексеры в черный список, # чтобы предотвратить нежелательный перезапуск [serverClass:west] whitelist.0=*-west* whitelist.1=qa01 blacklist.0=spl-idx-* [serverClass:west:app:props-west] [serverClass:west:app:deploymentclient-yourcompanyname] # передать props-east только индексерам в дата-центре "восточный" # добавить индексеры в черный список, # чтобы предотвратить нежелательный перезапуск [serverClass:east] whitelist.0=*-east* whitelist.1=homer-simpson blacklist.0=spl-idx-* [serverClass:east:app:props-east] [serverClass:east:app:deploymentclient-yourcompanyname] # определить настройки ввода для сервера приложений [serverClass:appservers] whitelist.0=app-* whitelist.1=qa01 whitelist.2=homer-simpson [serverClass:appservers:app:inputs-app] # определить настройки ввода для веб-сервера [serverClass:webservers] whitelist.0=web-* whitelist.1=qa01 418  Продвинутая настройка whitelist.2=homer-simpson [serverClass:webservers:app:inputs-web] # определить настройки ввода для сервера баз данных [serverClass:dbservers] whitelist.0=db-* whitelist.1=qa01 [serverClass:dbservers:app:inputs-db] # определить список форвардеров в дата-центре "западный" [serverClass:fwd-west] whitelist.0=app-west* whitelist.1=web-west* whitelist.2=db-west* whitelist.3=qa01 [serverClass:fwd-west:app:outputs-west] # определить список форвардеров в дата-центре "восточный" [serverClass:fwd-east] whitelist.0=app-east* whitelist.1=web-east* whitelist.2=db-east* whitelist.3=homer-simpson [serverClass:fwd-east:app:outputs-east] Вы должны организовать шаблоны и классы так, чтобы это имело смысл для вас и ваших дата-центров, но я бы советовал стремиться к максимально простой организации. Уверяю вас, большое число строк в конфигурационном файле – меньшее зло, чем сложная логика. Вот еще несколько замечаний о формате serverclass.conf: числа, следующие за whitelist и blacklist, должны начинаться с нуля и увеличиваться последовательно, без пропусков. Так в следующем примере параметр whitelist.3 не будет обрабатываться, потому что параметр whitelist.2 закомментирован: [serverClass:foo] whitelist.0=a* whitelist.1=b* # whitelist.2=c* whitelist.3=d* проверка whitelist.x и blacklist.x происходит в следующем порядке: – clientName, как определено в deploymentclient.conf: эта возможность редко применяется на практике, но может оказаться полезной, когда на одной физической машине действует несколько серверов Splunk или когда DNS работает крайне ненадежно; – IP-адрес: сопоставление CIDR не поддерживается, но можно использовать строковые шаблоны; – обратный DNS: это имя, возвращаемое системой DNS для указанного IP-адреса. Установка конфигурации  419 Если записи в обратном DNS давно не обновлялись, это может вызывать проблемы, потому что данное значение проверяется перед проверкой имени хоста, определяемого самим хостом. В случае подозрений попробуйте воспользоваться командой ping <ip-адрес машины> или чем-то подобным, чтобы увидеть, какое имя возвращает DNS; имя хоста, определяемое самим форвардером. Это имя всегда проверяется только после проверки имени DNS, поэтому старайтесь свое временно обновлять записи в DNS; копируя строки с :app:, не забывайте изменять <className>! Это действительно одна из самых распространенных ошибок, которые встречаются в serverclass.conf. Шаг 6 – перезапуск сервера развертывания Если serverclass.conf отсутствует, для активации сервера развертывания нужно перезапустить соответствующий сервер Splunk. После загрузки сервера развертывания можно выполнить команду: $SPLUNK_HOME/bin/splunk reload deploy-server Этого достаточно, чтобы вступили в силу любые изменения в etc/deploymentapps/serverclass.conf. Шаг 7 – установка deploymentclient.conf После запуска сервера развертывания нужно настроить клиентов на работу с ним. На каждом компьютере, где будет выполняться клиент развертывания, нужно выполнить следующие шаги. 1.Скопировать приложение deploymentclient-yourcompanyname в $SPLUNK_HOME/ etc/apps/. 2. Перезапустить Splunk. Если все настройки выполнены правильно, вы должны заметить, как в течение нескольких минут соответствующие приложения появятся в $SPLUNK_HOME/ etc/apps/. Чтобы увидеть, что при этом происходит, загляните в $SPLUNK_HOME/ var/log/splunk/splunkd.log. Если обнаружатся какие-то проблемы, включите режим отладки на клиенте и/или сервере, отредактировав $SPLUNK_HOME/etc/log.cfg, и выполните перезапуск. Взгляните на следующие строки: category.DeploymentServer=WARN category.DeploymentClient=WARN Отыскав эти строки, измените их, как показано ниже, и перезапустите Splunk: category.DeploymentServer=DEBUG category.DeploymentClient=DEBUG После перезапуска вы увидите полное содержание диалога сервера с клиентом в $SPLUNK_HOME/var/log/splunk/splunkd.log. Устранив проблему, не забудьте вернуть настройки обратно! 420  Продвинутая настройка Использование LDAP для аутентификации По умолчанию Splunk использует свою систему аутентификации, которая хранит информацию о пользователях и ролях в простых текстовых файлах. Однако есть возможность использовать для аутентификации LDAP и скрипты. Бесплатные версии Splunk не поддерживают эти механизмы аутентификации. Чтобы включить аутентификацию через LDAP, выполните следующие шаги. 1.Перейдите на страницу Settings  Access controls  Authentication method (Настройки  Управление доступом  Метод аутентификации). 2. Установите флажок LDAP. 3.Щелкните на ссылке Configure Splunk (Настроить Splunk), чтобы настроить использование LDAP и определить соответствия для групп. 4. Щелкните на кнопке New (Новый). Вам необходимо знать некоторые значения, чтобы настроить доступ к серверу LDAP. В каждой организации сервер LDAP настраивается немного по-своему, поэтому мне никогда не удавалось правильно настроить аутентификацию через LDAP с первого раза. Для этого лучше всего скопировать значения из другого приложения, которое уже настроено в вашей организации. После настройки соединения с сервером LDAP можно определить соответствия между ролями Splunk и группами LDAP. Использовать ли существующие или создать особые группы для Splunk – зависит от вашей организации, но в большинстве компаний, с которыми я работал, предпочитали создавать отдельные группы для ролей в Splunk. Обычно создавались группы: splunkuser, splunkpoweruser, splunksecurity и splunkadmin. Разрешения определяются методом сложения, поэтому пользователь может быть членом любого количества групп. В Splunk 4.3 появились возможность использовать сразу несколько серверов LDAP, поддержка динамических и вложенных групп и многое другое. Офи циальную документацию можно найти по адресу: https://docs.splunk.com/Documentation/Splunk/latest/Security/SetUpUserAuthenticationWithLDAP. Использование единой точки входа Организация единой точки входа (Single sign-on, SSO) позволяет использовать некоторый другой веб-сервер для аутентификации в Splunk. Для этого необходимо, чтобы: ваша система SSO могла действовать как прямой HTTP-прокси, пересылающий HTTP-запросы в Splunk; ваша система SSO добавляла идентификатор аутентифицированного пользователя в HTTP-заголовок; IP-адрес сервера, пересылающего запросы, был статическим; Балансировщики нагрузки и Splunk  421 получив конкретное имя пользователя, система Splunk могла определить роли, присвоенные этому пользователю. Обычно это реализуется с помощью using LDAP, но также можно организовать, определяя пользователей непосредственно в интерфейсе Splunk или посредством своего плагина аутентификации. Допустим, все перечисленные требования выполняются, тогда типичное решение выглядит примерно так: 1. Настроить аутентификацию в Splunk через LDAP. 2.Настроить веб-сервер для передачи проксируемых запросов в Splunk: если все настройки выполнены правильно, работа с прокси-сервером внешне не должна отличаться от прямого взаимодействия с веб-прило жением Splunk. 3.Настроить аутентификацию на веб-сервере: веб-сервер должен соединяться с сервером Splunk и возвращать вам запрос на аутентификацию. 4.Проверить HTTP-заголовок, содержащий имя удаленного пользователя: реализуя проксирование через ваш веб-сервер, измените URL на http:// yourproxyserver/debug/sso. Вы должны увидеть имя пользователя в Remote user HTTP header или Other HTTP headers. 5.Настроить SSO в $SPLUNK_HOME/etc/system/local/web.conf: добавьте три ат рибута в раздел [settings], как показано ниже: [settings] SSOMode = strict remoteUser = REMOTE-USER trustedIP = 192.168.1.1,192.168.1.2 Вот и все. Обычно самое сложное – настроить веб-сервер для аутентификации и проксирования. Для диагностики происходящего используйте страницу /debug/sso. Также могут возникать проблемы с пунктуацией в имени поля заголовка. Устранение любых знаков пунктуации из имени заголовка часто помогает избавиться от неожиданных проблем. Балансировщики нагрузки и Splunk Некоторые организации, вложившие значительные средства в подсистемы балансировки нагрузки, предпочитают использовать их по возможности для централизованного управления сетью. Splunk предлагает три службы, описанные в следующих разделах. Веб-серверы Обычно прослушивающий порт 8000 веб-сервер Splunk может балансировать нагрузку при работе с пулом поисковых серверов. Балансировщик нагрузки должен быть настроен в режиме постоянной привязки, так как веб-сервер бу- 422  Продвинутая настройка дет по-прежнему полагаться на сеансы пользователей, привязанные к тому веб-серверу, с которым пользователь начинал работу. Подробнее об этом рассказывается в разделе «Несколько поисковых серверов». splunktcp Служба splunktcp, обычно прослушивающая порт 9997, сама не хранит информации о состоянии. Автоматическая балансировка в Splunk хорошо протестирована и обеспечивает очень высокую эффективность, но не поддерживает сложной логики. Например, она отдает предпочтение индексерам, находящимся в том же дата-центре, и использует индексеры в других дата-центрах лишь в крайнем случае. Проблема заключается в том, что при настройке только одного адреса для форвардера Splunk откроется лишь одно соединение и будет удерживаться открытым бесконечно. То есть при перезапуске индексера он не получит нового соединения до перезапуска форвардеров. Самое простое решение – настроить два адреса в балансировщике в outputs. conf. Эти два адреса должны иметь два разных порта или два разных IP-адреса. Два разных CNAME с одним номером порта не дадут желаемого эффекта, так как Splunk осуществляет разрешение адресов и выполняет свертку списка IP-адресов. Сервер развертывания Обычно прослушивающий порт 8089 сервер развертывания по умолчанию принимает соединения SSL и использует самоподписанный сертификат. При использовании балансировщика нагрузки с серверами развертывания можно столкнуться с двумя проблемами: в действительности используется протокол REST через HTTP, но не совсем, поэтому вместо балансировщика нагрузки, понимающего протокол HTTP, используйте балансировщик нагрузки TCP; несмотря на теоретическую возможность балансировки нагрузки на серверы развертывания, может возникнуть проблема, если серверы развертывания не синхронизированы, из-за чего клиенты развертывания могут загружать то один, то другой набор приложений. Лучшее решение, пожалуй, заключается в том, чтобы запустить несколько серверов развертывания и с помощью DNS или балансировщиков нагрузки обеспечить соединение определенных групп хостов с определенными серверами развертывания. Несколько Search Head Путем организации пулов поисковых серверов можно запустить несколько Search Head. Эта возможность требует, чтобы они имели что-то общее, то есть фактически они должны находиться в одном дата-центре. Соответствующая архитектура выглядит, как показано на рис. 12.11. Итоги  423 LB Search nfs Indexer Рис. 12.11  Архитектура с несколькими поисковыми серверами Далее кратко перечислены шаги настройки поиска. 1. Смонтировать том NFS на каждом Search Head. 2. На каждом сервере включить поддержку объединения в пул. 3. Скопировать существующие конфигурации на том NFS. 4. Проверить работу серверов. 5. Включить балансировку нагрузки. Официальную документацию можно найти по адресу: http://docs.splunk.com/ Documentation/Splunk/7.0.2/DistSearch/Configuresearchheadpooling. Итоги В этой главе мы затронули широкий круг вопросов, каждый из которых, возможно, заслуживает отдельной главы. Может быть, мы сделаем это в следующей книге (или следующем издании!). Мы поговорили о разных функциях, выполняемых серверами Splunk, как собирать данные из разных источников, как установить Splunk, как организовать индексирование, как управлять конфигурацией нескольких серверов, и, наконец, затронули несколько продвинутых вопросов, касающихся развертывания. Далее мы посмотрим, как писать свои расширения для Splunk. Глава 13 Расширение Splunk Несмотря на то что ядро Splunk закрыто, есть ряд мест, где можно использовать скрипты или внешний программный код для расширения возможностей системы. В этой главе мы рассмотрим несколько примеров таких мест, где можно добавить внешний код. Большинство примеров написано на Python, поэтому, если вы незнакомы с Python, вам может пригодиться какой-нибудь справочник по этому языку программирования. В этой главе мы обсудим следующие темы: реализация скриптов для создания событий; использование Splunk из командной строки; отправка запросов в Splunk через REST-интерфейс; реализация своих команд поиска; реализация визуализаторов событий нестандартных типов; реализация скриптов нестандартных операций поиска. Примеры, представленные в этой главе, включены в состав приложения ImplementingSplunkExtendingExamples, которое доступно для загрузки на веб-сайтах издательств Packt (https://www.packtpub.com/support) и «ДМК Пресс» (www.dmkpress.com и www.дмк.рф, в разделе Читателям – Файлы к книгам). В конце главы также будет представлена платформа Hunk и дан краткий обзор ее возможностей. Разработка скриптов ввода для сбора данных Скрипты сбора данных позволяют запускать фрагменты программного кода по расписанию и передавать выходные данные в систему Splunk, как если бы они были прочитаны из файлов. Не важно, на каком языке написан скрипт и где он располагается, достаточно, чтобы он был выполняемым. Мы уже затрагивали эту тему в разделе «Использование скриптов для сбора данных» в главе 12 «Продвинутая настройка». Теперь мы рассмотрим данный вопрос с точки зрения практической реализации. Прием данных без дат Одна из распространенных проблем, возникающих при приеме данных от скриптов, –непредсказуемый формат даты или вообще ее отсутствие. В такой Разработка скриптов ввода для сбора данных  425 ситуации проще настроить систему Splunk, чтобы она вообще не анализировала дату и использовала текущее время. Давайте напишем скрипт, перечисляющий открытые сетевые подключения: from subprocess import Popen from subprocess import PIPE from collections import defaultdict import re def add_to_key(fieldname, fields): return " " + fieldname + "=" + fields[fieldname] output = Popen("netstat -n -p tcp", stdout=PIPE, shell=True).stdout.read() counts = defaultdict(int) for l in output.splitlines(): if "ESTABLISHED" in l: pattern = r"(?P<protocol>\S+)\s+\d+\s+\d+\s+" pattern += r"(?P<local_addr>.*?)[^\d](?P<local_port>\d+)\s+" pattern += r"(?P<remote_addr>.*)[^\d](?P<remote_port>\d+)" m = re.match(pattern, l) fields = m.groupdict() if "local_port" in fields and "remote_port" in fields: if fields["local_addr"] == fields["remote_addr"]: continue try: if int(fields["local_port"]) < 1024: key = "type=incoming" key += add_to_key("local_addr", fields) key += add_to_key("local_port", fields) key += add_to_key("remote_addr", fields) else: key = "type=outgoing" key += add_to_key("remote_addr", fields) key += add_to_key("remote_port", fields) key += add_to_key("local_addr", fields) except: print "Unexpected error:", sys.exc_info()[0] counts[key] += 1 for k, v in sorted(counts.items()): print k + " count=" + str(v) Перед тем как связать скрипт с системой, протестируем его с помощью интерпретатора Python, входящего в состав Splunk: $SPLUNK_HOME/bin/splunk cmd python connections.py Если ваш скрипт использует какие-либо модули Splunk для Python, вы должны применить интерпретатор Python из Splunk, потому что другие интер претаторы Python, установленные в вашей системе, не смогут отыскать эти модули. 426  Расширение Splunk На моей тестовой машине я получил такой вывод: type=outgoing remote_addr=17.149.36.120 remote_port=5223 local_addr=192.168.0.20 count=1 type=outgoing remote_addr=17.158.10.104 remote_port=443 local_addr=192.168.0.20 count=2 type=outgoing remote_addr=17.158.10.42 remote_port=443 local_addr=192.168.0.20 count=5 type=outgoing remote_addr=17.158.8.23 remote_port=993 local_addr=192.168.0.20 count=4 type=outgoing remote_addr=173.194.64.109 remote_port=993 local_addr=192.168.0.20 count=8 type=outgoing remote_addr=199.47.216.173 remote_port=443 local_addr=192.168.0.20 count=1 type=outgoing remote_addr=199.47.217.178 remote_port=443 local_addr=192.168.0.20 count=1 type=outgoing remote_addr=50.18.31.239 remote_port=443 local_addr=192.168.0.20 count=1 Теперь, получив действующий скрипт, нужно выполнить настройки в двух файлах – inputs.conf и props.conf. Как рассказывалось в главе 12 «Продвинутая настройка», мы должны поместить эти файлы в разные приложения, если собираемся использовать их в распределенной архитектуре. В конфигурационный файл inputs.conf следует добавить примерно такие строки: [script://./bin/connections.py] interval=60 sourcetype=connections Если имя скрипта заканчивается на .py, Splunk автоматически будет использовать свой интерпретатор Python для его выполнения. Иначе файл скрипта должен иметь разрешение на выполнение. Если вам потребуется задействовать другой интерпретатор Python, укажите полный путь к нему и передайте скрипт как аргумент: В конфигурационный файл props.conf следует добавить примерно такие строки: [connections] SHOULD_LINEMERGE = false DATETIME_CONFIG = CURRENT Эти настройки требуют, чтобы каждая строка, получаемая от скрипта, интерпретировалась как событие, и в этом событии не следует искать ничего, похожего на дату. Теперь напишем запрос, выполняющий поиск по данным, полученным от этих скриптов ввода, и извлекающий номера портов и доменные имена из установленных соединений. Этот запрос использует dnslookup и подставляет в поле remote_host либо доменное имя, либо адрес подсети: index=implsplunk sourcetype=connections | fillnull value="-" remote_addr remote_port local_addr local_port Разработка скриптов ввода для сбора данных  427 | dedup remote_addr remote_port local_addr local_port | lookup dnslookup clientip as remote_addr | rex field=clienthost ".*.(?<domain>[^.]+.[^.]+)" | eval remote_host=coalesce(domain,remote_addr) | eval remote_host=replace(remote_host,"(.*).d+$","1.0") | stats sum(count) as count values(remote_port) as remote_ports by remote_host local_addr local_port | eval remote_ports=mvjoin(remote_ports, ", ") На моей тестовой машине я получил результаты, изображенные на рис. 13.1. Рис. 13.1  Результаты выполнения запроса на моей тестовой машине Прием данных, представляющих единственное событие Если весь вывод скрипта должен интерпретироваться как единственное событие, нужно указать в LINE_BREAKER несуществующий и невозможный разделитель строк. Напишем скрипт на языке командной оболочки, который будет возвращать разные части вывода команды uname в виде полей с говорящими именами. Исходный код скрипта вы найдете в файле ImplementingSplunkExtendingExamples/bin/uname.sh: #!/bin/sh date "+%Y-%m-%d %H:%M:%S" echo hardware="$(uname -m)" echo node="$(uname -n)" echo proc="$(uname -p)" echo os_release="$(uname -r)" echo os_name="$(uname -s)" echo os_version="$(uname -v)" Этот скрипт выводит примерно такие данные: 2012-10-30 19:28:05 hardware="x86_64" node="mymachine.local" proc="i386" 428  Расширение Splunk os_release="12.2.0" os_name="Darwin" os_version="Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64" Обратите внимание на последнюю строку: она определенно содержит дату. Если явно не сообщить Splunk, что весь вывод представляет единственное событие, она преобразует эту последнюю строку в отдельное событие. Чтобы избежать этого, в inputs.conf следует добавить: [script://./bin/uname.sh] interval = 0 0 * * * sourcetype=uname Обратите внимание, что для определения значения в поле interval использован синтаксис cron. Согласно этому атрибуту, скрипт будет запускаться каждый день в полночь. Как вариант этому параметру можно присвоить значение 86 400, чтобы Splunk вызывала этот скрипт через каждые 24 часа. В конфигурационный файл props.conf следует добавить примерно такие строки: [uname] TIME_FORMAT = %Y-%m-%d %H:%M:%S # интерпретировать каждую "строку" как событие: SHOULD_LINEMERGE = false # определить невозможный шаблон, определяющий начало строки, # чтобы весь вывод интерпретировался как одна "строка": LINE_BREAKER = ((?!)) # ограничить длину "строки" одним мегабайтом, на всякий случай: TRUNCATE=1048576 После установки скрипта и настроек вы сможете отыскать эти события по sourcetype=uname и получить результат, изображенный на рис. 13.2. Рис. 13.2  Результат поиска событий по sourcetype=uname Так как мы использовали синтаксис имя_поля="значение_поля", заключили значения в кавычки и определили невозможный разделитель строк, эти поля и их значения будут автоматически извлечены и сохранены в индексе. Затем мы сможем использовать имена полей в запросах, как показано ниже: earliest=-24h sourcetype=uname | eventstats count by os_release os_name | search count<10 Этот запрос отыщет редкие комбинации os_release и os_name. Разработка скриптов ввода для сбора данных  429 Прием данных от скриптов, выполняющихся продолжительное время Иногда обработка данных занимает много времени, например при извлечении информации из внешних источников, таких как базы данных. Вот простой пример такого скрипта: import time import random import sys for i in range(1, 1000): print "%s Hello." % time.strftime('%Y-%m-%dT%H:%M:%S') # заставить python фактически вывести данные sys.stdout.flush() time.sleep(random.randint(1, 5)) Этот скрипт будет выполняться примерно от 1000 до 5000 секунд. Так как для выполнения этому скрипту требуется значительное время, мы можем интерпретировать каждую строку как отдельное событие (подобно скрипту в разделе «Прием данных без дат») или, если известно, что вывод скрипта содержит даты, настроить ввод по аналогии с обычным файлом журнала. В данном случае дата присутствует всегда, поэтому выберем второй вариант. Вывод скрипта не содержит ничего необычного: 2012-10-30T20:13:29 Hello. 2012-10-30T20:13:33 Hello. 2012-10-30T20:13:36 Hello. В конфигурационный файл inputs.conf следует добавить примерно такие строки: [script://./bin/long_running.py] interval = 1 sourcetype=long_running С атрибутом interval = 1 Splunk будет пытаться запустить скрипт каждую секунду, но так, чтобы в каждый конкретный момент выполнялось не более одной копии скрипта. В конфигурационный файл props.conf добавить примерно такие строки: [long_running] TIME_FORMAT = %Y-%m-%dT%H:%M:%S MAX_TIMESTAMP_LOOKAHEAD = 21 BREAK_ONLY_BEFORE = ^d{4}-d{1,2}-d{1,2}Td{1,2}: С этими настройками Splunk будет запускать продолжительный процесс, который сможет выполнить все необходимые операции. Несмотря на то что система Splunk способна запускать скрипты и принимать от них выходные данные, если эта информация очень важна, безопаснее запланировать вызов скрипта из cron, перенаправить его вывод в файл и настроить Splunk на чтение этого файла. Такое решение даст возможность ис- 430  Расширение Splunk пользовать файл другими способами, например сохранять в файле не только стандартный вывод, но и стандартный вывод ошибок скрипта, а кроме того, данные будут неизменно поступать в файл, даже в периоды остановки Splunk. Однако этот подход имеет и свой недостаток – вам придется самим очищать такие файлы. Использование Splunk из командной строки Практически все, что можно сделать в веб-интерфейсе, так же можно сделать из командной строки. Чтобы получить общее представление о доступных возможностях, выполните команду /opt/splunk/bin/splunk help. Чтобы получить справку по конкретной команде, выполните /opt/splunk/bin/splunk help [commandname]. На практике в командной строке чаще всего выполняется команда search. Например: $ /opt/splunk/bin/splunk search 'foo' 2012-08-25T20:17:54 user=user2 GET /foo?q=7148356 uid=MzA4MTc5OA 2012-08-25T20:17:54 user=user2 GET /foo?q=7148356 uid=MzA4MTc5OA 2012-08-25T20:17:54 user=user2 GET /foo?q=7148356 uid=MzA4MTc5OA Обратите внимание на следующие аспекты: по умолчанию поиск выполняется за все время. Чтобы избежать этого, включите в запрос earliest=-1d или другой подходящий интервал времени; по умолчанию Splunk выведет только 100 строк результатов. Если вам потребуется больше, используйте флаг -maxout; поиск доступен лишь для аутентифицированных пользователей, поэтому Splunk потребует ввести имя и пароль пользователя, если не указать эти данные в аргументе -auth. Часто доступ из командной строки используется для подсчета числа событий, полученных из других систем. Попробуем для примера выполнить прос тую команду stats и подсчитать по хостам число вхождений слова error за последний час: $ /opt/splunk/bin/splunk search 'earliest=-1h error | stats count by host' Эта команда выведет следующие результаты: ------------ ----host2 3114 vlb.local 3063 Обратите внимание на такие аспекты: для ограничения периода поиска последним часом добавлен параметр earliest=-1h; по умолчанию данные выводятся в табличной форме, которую легко читать, но трудно интерпретировать в скриптах. Управлять форматом вывода можно с помощью ключа -output; Отправка запросов в Splunk через REST-интерфейс  431 по умолчанию Splunk непрерывно выводит промежуточные результаты по мере их извлечения. Это замедляет выполнение запроса. Запретить вывод промежуточных результатов можно с помощью ключа -preview as false. Промежуточные данные не выводятся, когда скрипт вызывается не из интерактивного терминала, например когда вызов происходит из cron. Чтобы получить вывод в формате CSV, попробуйте такую команду: $ /opt/splunk/bin/splunk search 'earliest=-1h error | stats count by host' -output csv -preview false Она выведет следующее: count,host 3120,host2 3078,"vlb.local" Отметьте также, что в отсутствие результатов команда ничего не выведет. Отправка запросов в Splunk через REST-интерфейс Splunk поддерживает богатый интерфейс HTTP REST, позволяющий выполнять поиск, добавлять данные, добавлять входы, управлять пользователями и многое другое. Документацию и библиотеку SDK можно найти по адресу: http://dev.splunk.com/. Чтобы получить представление о том, как взаимодействовать с интерфейсом REST, рассмотрим простой диалог, в ходе которого запускается запрос и выводятся результаты. Суть этого диалога заключается в выполнении следующих шагов: 1) запустить запрос (POST); 2) получить статус (GET); 3) извлечь результаты (GET). Для иллюстрации этих шагов воспользуемся утилитой командной строки curl. Использование SDK могло бы значительно упростить взаимодействия. Вот как выглядит команда запуска запроса: curl -u user:pass -k https://yourserver:8089/services/search/jobs d"search=search query" По сути, она посылает POST-запрос search=search query. Знакомые с протоколом HTTP могут заметить, что это стандартный POST-запрос, какой посылается HTML-формами. Чтобы выполнить запрос earliest=-1h index="_internal" warn | stats count by host, нужно экранировать символы, считающиеся специальными в адресах URL. Соответствующая команда будет выглядеть так: $ curl -u admin:changeme -k https://localhost:8089/services/search/jobs d"search=search%20earliest%3D-1h%20index%3D%22_internal%22%20 warn%20%7C%20stats%20count%20by%20host" 432  Расширение Splunk Если запрос принят к исполнению, Splunk вернет ответ в формате XML с идентификатором запроса: <?xml version='1.0' encoding='UTF-8'?> <response><sid>1352061658.136</sid></response> Далее нужно использовать содержимое <sid> для ссылки на задание. Проверить статус этого задания можно с помощью такой команды: curl -u admin:changeme -k https://localhost:8089/services/search/jobs/1352061658.136 Она вернет большой объем информации о задании, как показано ниже: <entry ...> <title>search earliest=-1h index="_internal" warn | stats count by host</title> <id>https://localhost:8089/services/search/jobs/1352061658.136</id> ... <link href="/services/search/jobs/1352061658.136/events" rel="events"/> <link href="/services/search/jobs/1352061658.136/results" rel="results"/> ... <content type="text/xml"> <s:dict> ... <s:key name="doneProgress">1.00000</s:key> ... <s:key name="eventCount">67</s:key> ... <s:key name="isDone">1</s:key> ... <s:key name="resultCount">1</s:key> Наиболее интересными полями для нас являются doneProgress, eventCount, resultCount, но наибольший интерес представляет поле isDone. Если isDone содержит значение 0, мы должны подождать и повторить запрос статуса. И только получив значение isDone=1, мы сможем извлечь результаты, обратившись по URL, указанному в <link rel="results">. В данном случае, чтобы извлечь результаты, нужно выполнить такую команду: curl -u admin:changeme -k https://localhost:8089/services/search/jobs/1352061658.136/results Она вернет следующий код XML: <?xml version='1.0' encoding='UTF-8'?> <results preview='0'> <meta> <fieldOrder> <field>host</field> Отправка запросов в Splunk через REST-интерфейс  433 <field>count</field> </fieldOrder> </meta> <result offset='0'> <field k='host'> <value><text>vlb.local</text></value> </field> <field k='count'> <value><text>67</text></value> </field> </result> </results> Первым следует список имен полей в meta/fieldOrder. Далее идут результаты. Хотя это и необязательно (потому что результаты заданий удаляются автоматически по истечении некоторого времени), но мы можем сэкономить немного дискового пространства на серверах Splunk, принудительно удалив ненужные больше результаты. Для этого достаточно отправить HTTP-запрос DELETE по URL задания: curl -u admin:changeme -k -X DELETE https://localhost:8089/services/search/jobs/1352061658.136 Только чтобы показать возможность использования Python API, ниже приводится скрипт на Python: import splunk.search as search import splunk.auth as auth import sys import time username = sys.argv[1] password = sys.argv[2] q = sys.argv[3] sk = auth.getSessionKey(username, password) job = search.dispatch("search " + q, sessionKey=sk) while not job.isDone: print "Job is still running." time.sleep(.5) for r in job.results: for f in r.keys(): print "%s=%s" % (f, r[f]) print "----------" job.cancel() Этот скрипт использует модули для Python, входящие в состав Splunk, поэтому должен запускаться с применением встроенного интерпретатора Python: $ /opt/splunk/bin/splunk cmd python simplesearch.py admin changeme 'earliest=-7d index="_internal" warn | timechart count by source' 434  Расширение Splunk Он выведет следующие строки: _time=2012-10-31T00:00:00-0500 /opt/splunk/var/log/splunk/btool.log=0 /opt/splunk/var/log/splunk/searches.log=0 /opt/splunk/var/log/splunk/splunkd.log=31 /opt/splunk/var/log/splunk/web_service.log=0 _span=86400 _spandays=1 ---------_time=2012-11-01T00:00:00-0500 /opt/splunk/var/log/splunk/btool.log=56 /opt/splunk/var/log/splunk/searches.log=0 /opt/splunk/var/log/splunk/splunkd.log=87 /opt/splunk/var/log/splunk/web_service.log=2 _span=86400 _spandays=1 ---------... За дополнительными примерами и исчерпывающей документацией обращайтесь на сайт http://dev.splunk.com. Реализация своих команд поиска В дополнение к набору встроенных команд Splunk предоставляет возможность писать свои команды на Python и Perl. Вы можете писать команды, изменяющие, замещающие и даже генерирующие новые события. Когда не стоит писать свои команды Внешние команды могут очень пригодиться, но если число событий, которые будут обрабатываться такими командами, очень велико или если важна высокая производительность, реализацию собственных команд следует рассматривать как последнее средство. Приложите все силы, чтобы решить поставленную задачу с использованием языка запросов или других функций, встроенных в Splunk. Например, решая задачи, перечисленные ниже, посмотрите – нет ли стандартного пути решения: перед использованием регулярных выражений познакомьтесь с командами rex, regex и извлекаемыми полями; перед вычислением новых или изменением существующих полей обратите внимание на eval (поищите в интернете по фразе «функции eval в Splunk»); перед обогащением результатов внешними данными познакомьтесь с возможностью lookup, которую тоже можно реализовать с применением скриптов; перед чтением периодически изменяющихся внешних данных подумайте – можно ли использовать inputcsv. Реализация своих команд поиска  435 Проблема производительности, которой страдают внешние команды, обусловлена двумя основными причинами: во-первых, для выполнения команды требуется запустить процесс интерпретатора Python, передать скрипту на Python события в формате CSV и затем импортировать результат обратно в процесс Splunk; во-вторых, низкая производительность может быть обусловлена логикой работы кода самой команды. На скорость работы команды, обращающейся к внешнему источнику, такому как база данных, будет влиять скорость работы этого источника. В своей практике мне ни разу не удалось добиться снижения производительности своих команд меньше чем на 50 % от производительности встроенных команд. Чтобы убедиться в правоте моих слов, попробуйте выполнить пару запросов: * | head 100000 | eval t=_time+1 | stats dc(t) На моем ноутбуке при запуске из командной строки и с отключенным выводом промежуточных результатов (как можно видеть ниже) этот запрос выполнялся примерно 4 секунды: # time /opt/splunk/bin/splunk search '* | head 100000 | eval t=_time+1 | stats dc(t)' -preview false А теперь попробуйте выполнить запрос, использующий внешнюю команду, входящую в состав примера: * | head 100000 | echo | eval t=_time+1 | stats dc(t) У меня время поиска увеличилось до 6 секунд с хвостиком, то есть на 50 %. В состав примеров входят три разновидности команды echo разной слож ности: echo: просто копирует данные из стандартного ввода в стандартный вывод; echo_csv: использует csvreader и csvwriter; echo_splunk: использует для сбора событий и вывода результатов модули на Python, входящие в состав Splunk. Мы будем применять эти модули в наших примерах команд. Производительность всех трех команд примерно одинаковая, а значит, основные потери времени обусловлены передачей событий в/из Splunk. Добавление required_fields=_time в commands.conf в данном примере уменьшает отставание с 2.5× до 1.5×. Если заранее известно, какие поля понадобятся команде, эта настройка сможет существенно улучшить производительность. Когда стоит писать свои команды С учетом предупреждения, касающегося снижения производительности, в некоторых случаях создание внешних команд дает неоспоримые, на мой взгляд, преимущества: 436  Расширение Splunk когда требуется выполнить специфическую операцию, которую невозможно выразить с использованием внутренних команд; когда требуется взаимодействовать с внешней системой (впрочем, использование механизма lookup может оказаться более эффективным); когда требуется создавать события, что называется, из воздуха, например для нужд тестирования. Уверен, вы наверняка сможете назвать еще множество своих причин. А теперь приступим к исследованию разных аспектов, связанных с созданием своих команд. Конфигурирование команд Прежде чем начать писать команды, следует познакомиться с некоторыми настройками, необходимыми для всех команд. Во-первых, для каждой команды в файле commands.conf должна иметься своя запись. Взгляните на следующее определение раздела: [commandname] filename = scriptname.py streaming = false enableheader = true run_in_preview = true local = false retainsevents = false Познакомимся поближе с этим разделом и атрибутами в нем: [commandname]: в заголовке раздела указывается имя, под которым команда будет доступна в запросах, в данном случае commandname; filename = scriptname.py: скрипт для запуска. Скрипт должен находиться в каталоге bin приложения; streaming = false: по умолчанию для получения всего набора результатов будет запускаться только один экземпляр команды. Предполагается, что для работы скрипту необходимы все события. Если ваш скрипт обрабатывает события по одному, присвойте этому атрибуту значение true. Это устранит ограничение на количество событий, которое по умолчанию равно 50 000, согласно параметру maxresultrows в limits.conf; enableheader = true: по умолчанию скрипт получит заголовок, который можно обработать с помощью модулей на Python, входящих в состав Splunk. Если присвоить этому атрибуту значение false, ваша команда будет получать простой текст со значениями, перечисленными через запятую; run_in_preview = true: по умолчанию команда будет вызываться многократно в процессе извлечения событий с целью обновления промежуточных результатов в пользовательском интерфейсе. Этот атрибут не влияет на хранимые запросы, но если присвоить ему значение false, скорость выполнения интерактивных запросов может существенно увеличиться. Это особенно важно, если команда использует внешний ресурс; Реализация своих команд поиска  437 local = false: в распределенной архитектуре ваша команда по умолчанию будет скопирована на все индексеры и выполнена там. Если команда должна выполняться на одной машине, установите local=true, в этом случае она будет выполнена только на Search Head; retainsevents = false: по умолчанию Splunk предполагает, что команда возвращает преобразованные события, подобно командам stats или timechart. Если присвоить этому атрибуту значение true, результаты будут интерпретироваться как обычные события. Чтобы сделать команды доступными для других приложений, например для Search, нужно изменить метаданные в нашем приложении. Добавьте следующие строки в файл metadata/default.meta: [commands] export = system Наконец, чтобы получить возможность использовать только что настроенную команду, необходимо перезапустить Splunk или открыть страницу http:// yourserver/debug/refresh в браузере. То же самое следует сделать после изменения параметров в commands.conf, но после внесения изменений в сам скрипт делать этого не нужно. Добавление полей Начнем с простой команды, всего лишь добавляющей новое поле в каждое событие. Соответствующий код вы найдете в файле ImplementingSplunkExtending Examples/bin/addfield.py: # импортировать модуль, входящий в состав Splunk import splunk.Intersplunk as si # прочитать результаты в переменную results, dummyresults, settings = si.getOrganizedResults() # выполнить обход результатов. results -- это список словарей. for r in results: # r -- это словарь. Доступ к полям осуществляется по их именам. r['foo'] = 'bar' # вернуть результаты в Splunk si.outputResults(results) Далее приводятся настройки для этой команды в commands.conf: [addfield] filename = addfield.py streaming = true retainsevents = true Используется команда следующим образом: * | head 10 | addfield | top foo Этот запрос вернет нам результат, изображенный на рис. 13.3. 438  Расширение Splunk Рис. 13.3  Результат применения команды addfield Тот же результат, но более эффективно, можно получить с помощью eval foo="bar", но данный пример наглядно иллюстрирует организацию простой команды. Манипулирование данными Иногда полезно изменить значение поля, например _raw. Просто ради забавы перевернем текст каждого события. Также добавим параметр, требующий переворачивать только слова, не меняя порядка их следования. Этот пример вы найдете в файле ImplementingSplunkExtendingExamples/bin/reverseraw.py: import splunk.Intersplunk as si import re # объявим сначала функцию, используемую далее def reverse(s): return s[::-1] # фактическое начало сценария results, dummyresults, settings = si.getOrganizedResults() # получить параметры команды keywords, options = si.getKeywordsAndOptions() # получить значение words, используя значение по умолчанию false words = options.get('words', False) # проверить значение words if words and words.lower().strip() in ['t', 'true', '1', 'yes']: words = True else: words = False # цикл по результатам for r in results: # если параметр words имеет значение true, перевернуть каждое слово if words: newRaw = [] parts = re.split('([^a-zA-Z\']+)', r['_raw']) for n in range(0, len(parts) - 2, 2): newRaw.append(reverse(parts[n])) newRaw.append(parts[n + 1]) newRaw.append(reverse(parts[-1])) r['_raw'] = ''.join(newRaw) # иначе просто поменять порядок слов в _raw на обратный else: r['_raw'] = reverse(r['_raw']) si.outputResults(results) Реализация своих команд поиска  439 Раздел в commands.conf: [reverseraw] filename = reverseraw.py retainsevents = true streaming = true Допустим, у нас имеется следующее событие: 2012-10-27T22:10:21.616+0000 DEBUG Don't worry, be happy. [user=linda, ip=1.2.3., req_time=843, user=extrauser] Используем нашу новую команду в следующем запросе: * | head 10 | reverseraw Для предыдущего события этот запрос вернет: ]resuartxe=resu ,348=emit_qer ,.3.2.1=pi ,adnil=resu[ .yppah eb ,yrrow t'noD GUBED 0000+616.12:01:22T72-01-2102 Добавим аргумент words: * | head 10 | reverseraw words=true В результате будут перевернуты только слова, без изменения их порядка: 2012-10-27T22:10:21.616+0000 GUBED t'noD yrrow, eb yppah. [resu=adnil, pi=1.2.3., qer_emit=843, resu=resuartxe] Теперь для интереса перевернем событие еще раз: * | head 10 | reverseraw words=true | reverseraw В результате получится: ]extrauser=user ,348=time_req ,.3.2.1=ip ,linda=user[ .happy be, worry Don't DEBUG 0000+616.12:01:22T72-01-2102 happy be, worry Don't – мастер Йода не мог бы сказать лучше!1 Преобразование данных До сих пор наши команды возвращали исходные события, изменяя поля. Однако команды могут также преобразовывать данные, подобно встроенным функциям top и stats. Для примера напишем функцию подсчета слов в событиях. Этот пример вы найдете в ImplementingSplunkExtendingExamples/bin/countwords.py: import splunk.Intersplunk as si import re import operator from collections import defaultdict class WordCounter: 1 Исходный текст «Don't worry, be happy» переводится как «Не волнуйтесь, будьте счастливы», а после двойного переворачивания получается «happy be, worry Don't» – «счастливы будьте, волнуйтесь не». – Прим. перев. 440  Расширение Splunk word_counts = defaultdict(int) unique_word_counts = defaultdict(int) rowcount = 0 casesensitive = False mincount = 50 minwordlength = 3 def process_event(self, input): self.rowcount += 1 words_in_event = re.findall('\W*([a-zA-Z]+)\W*', input) unique_words_in_event = set() for word in words_in_event: if len(word) < self.minwordlength: continue # skip this word, it's too short if not self.casesensitive: word = word.lower() self.word_counts[word] += 1 unique_words_in_event.add(word) for word in unique_words_in_event: self.unique_word_counts[word] += 1 def build_sorted_counts(self): # создать массив кортежей, # упорядоченных по количеству слов sorted_counts = sorted(self.word_counts.iteritems(), key=operator.itemgetter(1)) # перевернуть его sorted_counts.reverse() return sorted_counts def build_rows(self): # сконструировать результаты - массив словарей count_rows = [] for word, count in self.build_sorted_counts(): if self.mincount < 1 or count >= self.mincount: unique = self.unique_word_counts.get(word, 0) percent = round(100.0 * unique / self.rowcount, 2) newrow = {'word': word, 'count': str(count), 'Events with word': str(unique), 'Event count': str(self.rowcount), 'Percent of events with word': str(percent)} count_rows.append(newrow) return count_rows # вернуть целое число из options или возбудить исключение def getInt(options, field, default): try: return int(options.get(field, default)) except Exception, e: Реализация своих команд поиска  441 # возбудить исключение с описательным сообщением raise Exception("%s must be an integer" % field) if __name__ == '__main__': try: # получить результаты results, dummyresults, settings = si.getOrganizedResults() keywords, options = si.getKeywordsAndOptions() word_counter = WordCounter() word_counter.mincount = getInt(options, 'mincount', 50) word_counter.minwordlength = getInt(options, 'minwordlength', 3) # определить необходимость учета регистра символов casesensitive = options.get('casesensitive', False) if casesensitive: casesensitive = (casesensitive.lower().strip() in ['t', 'true', '1', 'y', 'yes']) word_counter.casesensitive = casesensitive # выполнить обход исходных результатов for r in results: word_counter.process_event(r['_raw']) output = word_counter.build_rows() si.outputResults(output) # перехватить исключение и вывести сообщение except Exception, e: import traceback stack = traceback.format_exc() si.generateErrorResults("Error '%s'. %s" % (e, stack)) Скрипт получился довольно длинным, но все происходящее в нем должно быть вам понятно. Отмечу лишь несколько важных моментов в этом примере: большая часть логики сосредоточена в определении класса. Это помогает достичь лучшего отделения бизнес-логики от логики, связанной с системой Splunk; проверка __main__ – обычное дело в Python; здесь также предусмотрена обработка исключений; исключение возникает при неудачной попытке выполнить парсинг целочисленных аргументов; имена полей перечисляются через пробел. Настройки в commands.conf запрещают потоковую обработку и сохранение событий: [countwords] filename = countwords.py retainsevents = false streaming = false Powered by TCPDF (www.tcpdf.org) 442  Расширение Splunk Вот как можно использовать эту команду: * | countwords Этот запрос вернет результаты, изображенные на рис. 13.4. Рис. 13.4  Результат применения команды countwords Для своих тестовых данных я получил 132 строки, представляющие 132 уникальных слова с длиной не менее трех символов. В столбце count (количест во) выводится число вхождений каждого слова в наборе данных, а в столбце Events with word (Событий со словом) – число событий, содержащих данное слово. Обратите внимание на число 50000 в столбце Event count (Число событий). Даже притом что у меня запрос нашел более 300 000 событий, команде было передано только 50 000. Это ограничение можно увеличить, изменив атрибут maxresultrows в limits.conf, но будьте осторожны! Это ограничение существует для вашей же защиты. Реализация своих команд поиска  443 Попробуем передать аргументы: * | head 1000 | countwords casesensitive=true mincount=250 minwordlength=0 Этот запрос вернет результаты, изображенные на рис. 13.5. Рис. 13.5  Результат применения команды countwords с аргументами Обратите внимание, что теперь в подсчете участвуют одно- и двухсимвольные слова, число вхождений определяется с учетом регистров символов и подсчет прекращается по достижении значения mincount. Исключительно ради полноты обсуждения решение той же задачи с использованием встроенных команд можно записать так: * | rex max_match=1000 "W*(?<word>[a-zA-Z]+)W*" | eval id=1 | accum id | fields word id | eventstats count | mvexpand word | eval word=lower(word) | stats max(count) as event_count dc(id) as events_with_word count as word_count by word | sort -events_with_word | eval percent_events_containing = round(events_with_word/event_count*100.0,2) | rename word_count as count 444  Расширение Splunk events_with_word as "Events with word" event_count as "Event count" percent_events_containing as "Percent of events with word" | table count "Events with word" word "Event count" "Percent of events with word" Возможно, есть более эффективное решение на основе встроенных команд, но это то, что мне первым пришло на ум. Генерирование данных Иногда желательно иметь возможность создавать события, что называется, из воздуха. Эти события могут возвращаться запросом к базе данных, вебслужбой или просто генерироваться программным кодом на основе данных, указанных в запросе. Для иллюстрации механики реализуем генератор случайных чисел. Этот пример можно найти в ImplementingSplunkExtendingExamples/bin/random_ generator.py: import splunk.Intersplunk as si from random import randint keywords, options = si.getKeywordsAndOptions() def getInt(options, field, default): try: return int(options.get(field, default)) except Exception, e: # возбудить исключение с информативным сообщением raise Exception("%s must be an integer" % field) try: min = getInt(options, 'min', 0) max = getInt(options, 'max', 1000000) eventcount = getInt(options, 'eventcount', 100) results = [] for r in range(0, eventcount): results.append({'r': randint(min, max)}) si.outputResults(results) except Exception, e: import traceback stack = traceback.format_exc() si.generateErrorResults("Error '%s'. %s" % (e, stack)) Настройки для этой команды в commands.conf: [randomgenerator] filename = random_generator.py generating = true Вот как можно использовать эту команду: |randomgenerator Реализация скриптов для обогащения данных  445 Обратите внимание на символ вертикальной черты (|) в начале. Он указывает, что вместо поиска нужно просто запустить указанную команду. Проверим способность кода на Python генерировать случайные числа: |randomgenerator eventcount=100000 min=100 max=899 | bucket r | chart count by r В результате появится диаграмма, изображенная на рис. 13.6. Рис. 13.6  Диаграмма, иллюстрирующая распределение случайных чисел, сгенерированных командой randomgenerator Я думаю, что это неплохое распределение для 100 000 образцов. То же самое можно реализовать с использованием встроенных команд Splunk: index=_internal | head 100000 | eval r=random()/2147483647*100000 | bucket r | chart count by r Это был очень краткий обзор имеющихся возможностей на примере забавных демонстрационных команд, цель которого состояла в том, чтобы проиллюстрировать механику выполнения кода. Несколько дополнительных примеров вы найдете в составе Splunk, в каталоге $SPLUNK_HOME/etc/apps/ search/bin. Реализация скриптов для обогащения данных Мы довольно подробно рассмотрели механизм lookup из CSV-файлов в главе 7 «Расширенный поиск», затем снова коснулись его в главе 10 «Summary-индексы и файлы CSV» и в главе 11 «Настройка Splunk». Встроенных возможностей Splunk обычно достаточно для решения большинства практических задач, но иногда, чтобы получить значения для lookup, требуется использовать внешний источник данных или динамическую логику. Lookup с использованием 446  Расширение Splunk скриптов имеет следующие преимущества перед командами и подстановкой из CSV-файлов: вызов скрипта для получения значения подстановки происходит только один раз для каждого уникального замещаемого значения, тогда как команды выполняются для каждого события; потребление памяти при использовании lookup из CSV-файлов возрастает с увеличением размера файла; часто изменяющиеся значения можно хранить во внешней системе и запрашивать с помощью скрипта вместо частого экспортирования файла CSV. В разделе «Подстановка с метасимволами» главы 10 «Summary-индексы и файлы CSV» мы фактически реализовали оператор case через конфигурацию. Теперь давайте реализуем то же самое в виде скрипта, чтобы показать, как это можно сделать на Python. Прежде всего добавим следующие строки в transforms.conf: [urllookup] external_cmd = url_lookup.py fields_list = url section call_count Вот несколько замечаний, касающихся этой конфигурации: fields_list – это список полей, которые должны передаваться скрипту и возвращаться им; fields_list должен содержать не менее двух полей, иначе скрипт будет завершаться с ошибкой. Далее приводится исходный код скрипта: import sys import re from csv import DictReader from csv import DictWriter patterns = [] def add_pattern(pattern, section): patterns.append((re.compile(pattern), section)) add_pattern('^/about/.*', 'about') add_pattern('^/contact/.*', 'contact') add_pattern('^/.*/.*', 'unknown_non_root') add_pattern('^/.*', 'root') add_pattern('.*', 'nomatch') # возвращает раздел для данного url def lookup(url): try: for (pattern, section) in patterns: if pattern.match(url): return section return '' Реализация скриптов для обогащения данных  447 except: return '' # подготовить объект чтения reader = DictReader(sys.stdin) fields = reader.fieldnames # подготовить объект записи writer = DictWriter(sys.stdout, fields) writer.writeheader() # начать вывод call_count = 0 for row in reader: call_count = call_count + 1 if len(row['url']): row['section'] = lookup(row['url']) row['call_count'] = call_count writer.writerow(row) Этот скрипт принимает адрес URL, последовательно применяет к нему заданные регулярные выражения одно за другим, пока не найдет совпадения, и устанавливает значение поля section. Вот несколько замечаний к предыдущем скрипту: скрипт принимает исходный текст в формате CSV с полями, заданными в transforms.conf, но значения должны содержаться только в полях, требующих подстановки. В данном случае таковым является поле url; поле url должно присутствовать в данных или определяться командой lookup с помощью as; параметр call_count добавлен, чтобы показать, что подстановка на основе скрипта работает эффективнее, чем внешняя команда, потому что команда lookup получает только по одной входной строке для каждого уникального значения url. А теперь попробуем выполнить запрос: index=implsplunk sourcetype="impl_splunk_web" | rex "s[A-Z]+s(?<url>.*?)?" | lookup urllookup url | stats count values(call_count) by url section Он вернет результат, изображенный на рис. 13.7. Столбец values(call_count) доказывает, что скрипт подстановки получил всего восемь строк, по одной для каждого уникального значения url. Это намного лучше, чем 12 743 строки, которые получила бы эквивалентная команда. Дополнительные примеры подстановки с использованием скриптов вы найдете в: $SPLUNK_HOME/etc/system/bin/external_lookup.py Также загляните в приложение MAXMIND, доступное на сайте Splunkbase. 448  Расширение Splunk Рис. 13.7  Результат применения подстановки на основе скрипта Реализация визуализаторов событий Визуализаторы событий дают возможность определить свой шаблон для отображения событий определенного типа. Дополнительную информацию о создании своих типов событий вы найдете в главе 7 «Расширенный поиск». Визуализаторы событий используют язык шаблонов mako (http://www.makotemplates.org/). Типичный визуализатор событий включает: шаблон, хранящийся в $SPLUNK_HOME/etc/apps/[yourapp]/appserver/event_ renderers/[template].html; раздел с настройками в event_renderers.conf; необязательное определение типа события в eventtypes.conf; необязательные определения классов CSS в application.css. Создадим несколько небольших примеров. Все упоминаемые здесь файлы вы найдете в $SPLUNK_HOME/etc/apps/ImplementingSplunkExtendingExamples. Эти примеры не экспортируются за пределы приложения, поэтому, чтобы опробовать их, вы должны выполнять запросы внутри данного приложения. Для этого откройте в браузере страницу http://[yourserver]/app/ImplementingSplunkExtendingExamples/flashtimeline. Визуализация определенных полей Для отображения полей с известными именами достаточно написать простой шаблон. Рассмотрим тип событий template_example. Соответствующий шаблон находится в файле appserver/event_renderers/template_example.html: <%page args="job, event, request, options"> <ul class="template_example"> <li> <b>time:</b> ${i18n.format_datetime_microseconds(event.get('_time', event. time))} Реализация визуализаторов событий  449 </li> <li> <b>ip:</b> ${event.get('ip', '')} </li> <li> <b>logger:</b> ${event.get('logger', '')} </li> <li> <b>message:</b> ${event.get('message', '')} </li> <li> <b>req_time:</b> ${event.get('req_time', '')} </li> <li> <b>session_id:</b> ${event.get('session_id', '')} </li> <li> <b>user:</b> ${event.get('user', '')} </li> <li> <b>_raw:</b> ${event.get('_raw', '')} </li> </ul> </%page> Этот шаблон выводит каждое событие в отдельном блоке <ul>, перечисляя определенные поля. Чтобы связать этот шаблон с конкретным типом событий, нужно добавить в default/event_renderers.conf следующий раздел: [template_example] eventtype = template_example template = template_example.html Наконец, чтобы придать результату определенное оформление, можно добавить следующий код CSS в appserver/static/application.css: ul.template_example { list-style-type: none; } ul.template_example > li { background-color: #dddddd; padding: 4px; margin: 1px; } 450  Расширение Splunk Для проверки нового визуализатора событий нужно загрузить конфигурацию. Для этого можно просто перезапустить Splunk или открыть в браузере страницу http://[yourserver]/debug/refresh. Прямо сейчас можно выполнить запрос и применить тип события вручную: index="implsplunk" sourcetype="template_example" | eval eventtype="template_example" Наш визуализатор отобразит каждое событие, как показано на рис. 13.8. Рис. 13.8  Вид события, отображенного нашим визуализатором Чтобы обеспечить автоматическое применение визуализатора, добавьте в eventtypes.conf определение типа событий: [template_example] search = sourcetype=template_example Теперь результаты любого запроса, отыскивающего события sourcetype =template_example, будут отображаться с использованием нашего шаблона. Таблица полей на основе их значений Шаблон имеет доступ ко всему событию, поэтому вы можете использовать поля, как вам заблагорассудится. Следующий пример создает горизонтальную таблицу полей и позволяет пользователю определить перечень полей для отображения в специальном поле. Соответствующий шаблон хранится в appserver/event_renderers/tabular.html: <%inherit file="//results/EventsViewer_default_renderer.html" /> <%def name="event_raw(job, event, request, options, xslt)"> <% import sys _fields = str(event.fields.get('tabular', 'host,source,sourcetype,linecount')).split(',') head = '' Реализация визуализаторов событий  451 row = '' for f in _fields: head += "<th>" + f + "</th>" row += "<td>" + str(event.fields.get(f, '-')) + "</td>" %> <table class="tabular_eventtype"> <tr> ${head} </tr> <tr> ${row} </tr> </table> </%def> Обратите внимание, что он наследует шаблон визуализации событий, используемый по умолчанию, а это значит, что мы изменим только отображение поля _raw. Добавьте следующий раздел в event_renderers.conf: [tabular] eventtype = tabular template = tabular.html и код CSS в application.css: th.tabular_eventtype { background-color: #dddddd; border: 1px solid white; padding: 4px; } td.tabular_eventtype { background-color: #eeeeee; border: 1px solid white; padding: 4px; } Мы не будем добавлять новое определение типа событий, а просто добавим eventtype в запрос. Посмотрим, что у нас получилось, выполнив следующий запрос: index="implsplunk" | eval eventtype="tabular" Результат, в котором отображаются поля по умолчанию, показан на рис. 13.9. Рис. 13.9  Результат отображения событий с использованием шаблона tabular 452  Расширение Splunk Обратите внимание, что в выводе все так же можно видеть номер события, меню сценариев реагирования, локальное время, отображаемое системой Splunk, и поля, заданные в шаблоне. Фактически мы переопределили только отображение поля _raw. Если указать конкретные поля для отображения в таблице, шаблон выведет только их: index="implsplunk" sourcetype="template_example" | eval tabular="level,logger,message,foo,network" | eval eventtype="tabular" Результат выполнения этого запроса показан на рис. 13.10. Рис. 13.10  Результат попытки отобразить определенные поля с использованием шаблона tabular В соответствии со следующим кодом в шаблоне все поля без значений будут отображаться как дефис (-): str(event.fields.get(f, '-')) Намного проще было бы воспользоваться командой table, чем писать визуализатор событий. Поэтому данный подход оправдан, только когда нужно Реализация визуализаторов событий  453 отобразить событие каким-то особым способом или сохранить доступность меню сценариев реагирования (workflow actions). Альтернативное решение заключается в использовании модулей Table и Multiplexer, доступных в приложении Sideview Utils. Форматированный вывод XML В этом примере мы используем модуль minidom для Python для парсинга и форматирования разметки XML. Шаблон будет пытаться найти поле xml и в случае неудачи применяться к полю _raw. Теперь пройдемся по файлам в ImplementingSplunkExtendingExamples. Файл шаб лона находится в appserver/event_renderers/xml.html: <%inherit file="//results/EventsViewer_default_renderer.html" /> <%def name="event_raw(job, event, request, options, xslt)"> <% from xml.dom import minidom import sys def escape(i): return i.replace("<", "<").replace(">", ">") _xml = str( event.fields.get('xml', event.fields['_raw']) ) try: pretty = minidom.parseString(_xml).toprettyxml(indent=' '*4) pretty = escape( pretty ) except Exception as inst: pretty = escape(_xml) pretty += "n(couldn't format: " + str( inst ) + ")" %> <pre class="xml_eventtype">${pretty}</pre> </%def> Раздел в event_renderers.conf: [xml] eventtype = xml template = xml.html Раздел в eventtypes.conf: [xml] search = sourcetype="xml_example" Теперь можно просто выполнить запрос, показанный ниже: index="implsplunk" sourcetype="xml_example" Он вернет результат, изображенный на рис. 13.11. Первое событие содержит недопустимый код XML, поэтому в исходное значение было добавлено сообщение об ошибке. 454  Расширение Splunk Рис. 13.11  Форматированный вывод разметки XML Реализация скриптов для обработки уведомлений (alert) Другой вариант организации взаимодействий с внешними системами – запуск скрипта в ответ на alert, с использованием результатов выполнения хранимого запроса. В Splunk можно найти простой пример такого скрипта в $SPLUNK_HOME/ bin/scripts/echo.sh. Давайте опробуем его, выполнив следующие шаги: 1)создайте хранимый запрос. Для опробования нам достаточно простого запроса, например: index=_internal | head 100 | stats count by sourcetype Реализация скриптов для обработки уведомлений (alert)  455 2)запланируйте выполнение запроса в некоторый момент в будущем. Я настроил его выполнение через каждые 5 минут; 3)установите флажок Run a script (Запустить скрипт) и введите имя файла echo.sh, как показано на рис. 13.12. Рис. 13.12  Установите флажок Run a script (Запустить скрипт) и введите имя файла echo.sh Скрипт сохраняет вывод в файл $SPLUNK_HOME/bin/scripts/echo_output.txt. У меня он вывел следующие строки: '/opt/splunk/bin/scripts/echo.sh' '4' 'index=_internal | head 100 | stats count by sourcetype' 'index=_internal | head 100 | stats count by sourcetype' 'testingAction' 'Saved Search [testingAction] always(4)' 'http://vlbmba.local:8000/app/search/@go?sid=scheduler__ admin__search__testingAction_at_1352667600_2efa1666cc496da4' '' '/ opt/splunk/var/run/splunk/dispatch/scheduler__admin__search__ testingAction_at_1352667600_2efa1666cc496da4/results.csv.gz' 'sessionK ey=7701c0e6449bf5a5f271c0abdbae6f7c' Проанализируем каждый аргумент в этом выводе по порядку: $0: путь к скрипту – '/opt/splunk/bin/scripts/echo.sh'; $1: число возвращенных событий – '4'; $2: критерии поиска – index=_internal | head 100 | stats count by sourcetype'; $3: полная строка запроса – index=_internal | head 100 | stats count by sourcetype'; $4: имя хранимого запроса – 'testingAction'; $5: причина уведомления – 'Saved Search [testingAction] always(4)'; $6: ссылка на результаты поиска: 'http://vlbmba.local:8000/app/search/@go?sid=scheduler__admin__sear ch__testingAction_at_1352667600_2efa1666cc496da4' 456  Расширение Splunk $7: устарел, в настоящее время не используется – ''; $8: путь к необработанным результатам, которые всегда хранятся в сжатом виде: '/opt/splunk/var/run/splunk/dispatch/scheduler__admin__search__test ingAction_at_1352667600_2efa1666cc496da4/results.csv.gz' $9: ключ сеанса, в котором был выполнен запрос: 'sessionKey=7701c0e6449bf5a5f271c0abdbae6f7c' Обычно скрипты, обрабатывающие уведомления, используются для отправки событий в систему мониторинга. Также можно организовать архивирование полученных результатов или отправку их в другую систему. Давайте реализуем простенький скрипт, который копирует результаты в файл и затем выполняет команду curl. Вот как выглядит этот скрипт: #!/bin/sh DIRPATH='dirname "$8"' DIRNAME='basename "$DIRPATH"' DESTFILE="$DIRNAME.csv.gz" cp "$8" /mnt/archive/alert_action_example_output/$DESTFILE URL="http://mymonitoringsystem.mygreatcompany/open_ticket.cgi" URL="$URL?name=$4&count=$1&filename=$DESTFILE" echo Calling $URL curl $URL Его можно поместить в каталог $SPLUNK_HOME/bin/scripts на сервере, где он должен выполняться, и сослаться на него в настройках уведомления. В распределенной архитектуре Splunk сервером, выполняющим скрипт, будет Search Head. Чтобы выполнить какое-либо действие для каждой строки результатов, скрипт должен открыть эти результаты. Ниже приводится скрипт на Python, который циклически обрабатывает содержимое GZIP-файла и отправляет результаты в систему слежения за проблемами, включая само событие в формате JSON: #!/usr/bin/env python import sys from csv import DictReader import gzip import urllib import urllib2 import json # адрес URL системы заявок open_ticket_url = "http://ticketsystem.mygreatcompany/ticket" # открыть архив gzip как файл f = gzip.open(sys.argv[8], 'rb') Hunk  457 # создать объект чтения csv reader = DictReader(f) for event in reader: fields = {'json': json.dumps(event), 'name': sys.argv[4], 'count': sys.argv[1]} # добавить данные в запрос POST data = urllib.urlencode(fields) # послать запрос resp = urllib2.urlopen(open_ticket_url, data) print resp.read() f.close() Надеюсь, эти примеры послужат вам хорошей отправной точкой. Hunk Платформа Hunk, расширяющая возможности Splunk, была разработана с целью дать большому числу пользователей возможность доступа к данным, хранящимся в хранилищах Hadoop и NoSQL (и других, похожих на них), без необходимости тратить время, силы и средства на моделирование и разработку. Например, Hadoop может собирать большие объемы данных из многих источников, преобразовывать их в читаемые файлы журналов, которые затем быст ро и эффективно можно получить в Splunk с помощью Hunk. Вот некоторые интересные особенности Hunk: возможность создания виртуального индекса Splunk: позволяет беспрепятственно использовать язык обработки запросов Splunk (Splunk Search Processing Language, SPL) для интерактивного исследования, анализа и визуализации данных, как если бы они хранились в индексе Splunk; простота освоения: по аналогии с доступом к данным, индексированным в Splunk, от вас не требуется заранее знать, как хранятся данные в Hadoop; вы можете просто указать на источник Hadoop и сразу приступить к исследованиям; интерактивность: Hunk можно использовать для анализа терабайтов и даже петабайтов данных, а также обогащать данные из Hadoop дополнительными данными из внешних реляционных баз данных с помощью Splunk DB Connect; возможности визуализации данных и создания отчетов: пользователи могут оперативно создавать графики и диаграммы, а также использовать представления и отчеты для создания дашбордов, которые можно просматривать и редактировать на компьютерах, планшетах или мобильных устройствах. В настоящее время Hunk поддерживает 64-разрядные версии Linux. Доку ментацию и учебное руководство Hunk можно найти по адресу: http://docs. 458  Расширение Splunk splunk.com/Documentation/Hunk/latest/Hunktutorial/Tutorialoverview. Обратите внимание, что в настоящее время Hunk официально поддерживает Splunk до версии 6.4.9 и проходит проверку с новыми версиями. Итоги Как было показано в этой главе, есть несколько способов расширить загрузку данных, преобразование и вывод событий в Splunk. Механизм поиска Splunk – это лишь самое начало. Проявив изобретательность и смекалку, с помощью Splunk можно расширять существующие системы, реализуя поддержку новых источников данных и используя ее в качестве инструмента запуска действий. В следующей главе мы рассмотрим Splunk Machine Learning Toolkit. Глава 14 Machine Learning Toolkit В Splunk 7.0 вошла обновленная версия приложения Splunk Machine Learning Toolkit, добавляющая новые специализированные команды в язык запросов SPL, настраиваемые визуализации, вспомогательные механизмы и множество демонстрационных примеров, помогающих исследовать разные понятия машинного обучения. В этой главе мы сосредоточимся на организации машинного обучения с использованием одной из новейших возможностей Splunk – приложения Splunk Machine Learning Toolkit. Здесь мы обсудим следующие темы: что такое машинное обучение? обзор инструментария; рабочее пространство; ассистенты; расширения языка запросов SPL; конструирование моделей. В этой главе вы узнаете, что означает термин «машинное обучение» и как с помощью Splunk Machine Learning Toolkit создавать модели машинного обучения, даже не будучи опытным специалистом по анализу данных с богатым опытом в математической статистике и машинном обучении! Что такое машинное обучение? Судя по многочисленным высказываниям, машинное обучение, вероятно, коренным образом изменит нашу жизнь и наши представления о ней. В числе ярких примеров областей, которые, скорее всего, выиграют от внедрения машинного обучения, можно назвать торговлю и маркетинг, планирование мероприятий по техническому обслуживанию и прогнозирование рисков для здоровья (и многие другие). Машинное обучение дает более глубокое понимание, опираясь на шаблоны, выявленные или наблюдаемые в машинных данных. Итак, как понятнее определить машинное обучение? Покопавшись в интернете, можно найти такие описания машинного обучения: раздел информатики; следующий этап развития распознавания шаблонов, паттернов; 460  Machine Learning Toolkit область исследований, целью которых является реализация возможности самообучения компьютеров без программирования; один из методов реализации искусственного интеллекта (ИИ) на основе вероятностно-статистических и эволюционных методов; дает возможность программному обеспечению делать более точные прогнозы без явного программирования и так далее... Целью машинного обучения является формирование процедуры (или алгоритма), получающей входные данные и использующей статистическую логику и рассуждения для предсказания наиболее вероятного результата. Процедуры машинного обучения часто делятся на две категории: обучаемые с учителем и без учителя. Процедуры, обучаемые с учителем, требуют, чтобы кто-то представил не только входные данные, но и указал, каким должен быть результат (взаимодействие с человеком). Кроме того, в обучении с учителем оцениваются и регистрируются отзывы о точности или успешности результатов обработки. Процесс ввода, обучения и оценки результатов повторяется многократно в течение периода, известного как обучение процедур (которые также называют моделями). По завершении периода обучения появляется возможность применить обученную процедуру к новым данным. Процедуры, обучаемые без учителя, не нуждаются в процессе обучения, описанном выше. Вместо этого они используют итеративный метод (называемый глубоким обучением) просмотра данных и получения приемлемых результатов. Процедуры, обучаемые без учителя, обычно используются для решения более сложных задач обработки данных (к этой категории часто относятся сценарии обработки больших данных). Процессы в машинном обучении аналогичны процессам интеллектуального анализа данных (и те, и другие выполняют поиск в данных, выявляют шаблоны, а затем корректируют процесс на основе результатов или полученных знаний). Механизмы рекомендаций по содержимому Распространенным примером повседневного использования машинного обучения могут служить механизмы рекомендаций по содержимому. В действительности они являются алгоритмами, которые идентифицируют и возвращают информацию людям, опираясь на их поведение. Другими словами, получая информацию об онлайн-покупках, механизм рекомендаций по содержимому может служить средством доставки рекламы и другой информации (в режиме реального времени), релевантной для данного покупателя. Примерно так действует механизм рекомендаций Facebook News Feeds, поставляющий персонализированную информацию пользователям. Обработка естественного языка Еще одна сфера применения машинного обучения, нашедшая реальное воплощение, – обработка естественного языка (Natural Language Processing, NLP). Обзор инструментария  461 С помощью методов NLP можно обработать произвольные текстовые данные, такие как неструктурированные клинические заметки, статьи в академических журналах, отзывы пациентов или другие описательные тексты. Как отмечает Дженнифер Бресник (Jennifer Bresnick, «Top 4 Machine Learning Use Cases for Healthcare Providers», март 2017): «В одном проекте, запущенном в Соединенном Королевстве, исследователи применили инструменты обработки естественного языка к оценкам врачей своих коллег и обнаружили, что результаты, полученные с их помощью, согласуются с человеческими оценками в 98 % случаев. Как объясняют исследователи, произвольная текстовая информация имеет сложную структуру, а это означает, что, в отличие от оценок, полученных по результатам аттестации и опроса пациентов, слова нельзя просто сложить, чтобы получить что-то осмысленное. Поэтому издавна задача осмысления таких данных выполнялась вручную квалифицированными аналитиками...» Оперативные исследования Наконец, применение методов машинного обучения к данным о событиях может помочь организациям выявить причины проблем на ранних этапах и сократить время их разрешения, а также определить наиболее эффективные схемы работы. Я советую читателям найти время и ознакомиться со статьей Кристин Холл (Christine Hall), Splunk Brings Machine Learning to Data Analytics, опубликованной 27 сентяб ря 2017 года: http://www.datacenterknowledge.com/machine-learning/splunk-brings-machine-learning-data-analytics. Обзор инструментария Splunk предлагает следующую трехуровневую архитектуру для поддержки машинного обучения, включающую: уровень 1: базовая платформа с функциями поиска; уровень 2: готовые решения и приложения, доступные на Splunkbase; уровень 3: набор инструментов машинного обучения Splunk Machine Learning Toolkit. Уровни 1 и 2 не требуют пояснений, их назначение уже должно быть понятно вам на данном этапе, поэтому остановимся на уровне 3. Обзор инструментов мы начнем знакомством с типичным проектом машинного обучения, чтобы понять, какие работы выполняет большинство специалистов по анализу данных. Вот краткий перечень этих работ: сбор (данных); фильтрация и преобразование (данных); исследование и визуализация (данных); 462  Machine Learning Toolkit моделирование (данных); оценка (результатов моделирования); внедрение (как использовать полученные предсказания?). Время, потраченное не зря Из задач, перечисленных выше, до 60 % времени, по мнению специалистов в области обработки данных, уходит на фильтрацию и преобразование и почти 20 % – на сбор данных. Приложение Splunk MLT разрабатывалось для расширения возможностей платформы Splunk и организации управляемой среды моделирования для разработчиков и специалистов по обработке данных. В этой связи в литературе, посвященной Splunk, часто перечисляются следующие преимущества использования Splunk и Splunk MLT для реализации проектов машинного обучения. Сбор данных: Splunk, по своей сути, является отличным инструментом сбора и индексирования данных и может значительно упростить сбор данных – даже больших или неформатированных. После установки Splunk автоматически начинает собирать данные в режиме реального времени. Это освобождает время для моделирования и оценки. Фильтрация и преобразование. Splunk предлагает различные варианты фильтрации и преобразования данных, например props.conf (для применения логики в процессе сбора данных), tansforms.conf (для определения логики и правил обработки данных), определения моделей данных (для представления предметных знаний в данных) и приложения, которые можно найти на Splunkbase. И снова, освобождая исследователей от этой рутинной работы, Splunk позволяет выделить больше времени на моделирование и оценку. Исследование и визуализация: еще одна сильная сторона Splunk, представленная поддержкой сводных таблиц, диаграмм, пользовательского интерфейса и языка запросов SPL. Моделирование: эту возможность дает приложение MLT. Оценка: обеспечивается поддержкой уведомлений, дашбордов и от четов. Внедрение: применение результатов в соответствующих целях. Основываясь на этом списке и некоторых статистических данных, можно предположить, что общее время, потраченное на реализацию проекта машинного обучения, может оставаться почти таким же, но использование Splunk и Splunk MLT поможет перераспределить его между задачами. Другими словами, меньше времени будет потрачено на выполнение менее ценной и более рутинной работы (получение и подготовка данных), и больше времени уйдет на более ценную и интересную работу (оценка получившейся модели, уточнение используемых алгоритмов и получение более точного результата), как показано на рис. 14.1. Обзор инструментария  463 Без использования Splink Построение выборки обучающих данных Сбор данных Фильтрация и преобразование данных Анализ данных Идентификация шаблонов Оценка и уточнение С использованием Splink Построение выборки обучающих данных Сбор данных Фильтрация и преобразование данных Анализ данных Идентификация шаблонов Оценка и уточнение Рис. 14.1  Распределение времени для решения разных задач Приложение Splunk Machine Learning Toolkit предлагает так называемое управляемое рабочее пространство (помогающее перспективному ученому по данным создавать модели машинного обучения), множество интерактивных демонстрационных примеров, а также несколько новых расширений SPL, предназначенных для поддержки создания и оперативной настройки моделей и алгоритмов машинного обучения. Это, в свою очередь, влияет на продвижение проекта машинного обучения. У вас есть возможность использовать в своих моделях более чем 300 алгоритмов, реализованных в библиотеках на Python, таких как scikit-learn, pandas, statsmodel, NumPy и SciPy, доступных через расширение Splunk Python for Scientific Computing. Подробности ищите на сайте https://www.splunk.com/. Получение приложения Приложение Splunk Machine Learning Toolkit (MLT) можно получить на сайте Splunkbase после регистрации и получения учетной записи. Splunkbase – это сайт сообщества, поддерживаемый Splunk, где пользователи могут найти приложения и расширения для Splunk, увеличивающие функциональные возможности и практическую ценность Splunk, а также обеспечивающие простой и удобный интерфейс для конкретных ситуаций. На момент написания этих строк самую последнюю версию Machine Learning Toolkit можно было получить по адресу https://splunkbase.splunk.com/app/2890/. На рис. 14.2 изображена страница на Splunkbase, где можно получить приложение MLT. На этой же странице вы найдете вводный видеоролик. 464  Machine Learning Toolkit Рис. 14.2  Страница на Splunkbase, где можно получить приложение MLT Предварительные требования Для использования Splunk Machine Learning Toolkit у вас должна быть установлена версия Splunk Enterprise 6.4 или выше, или Splunk Cloud. Прежде чем приступить к работе с Splunk Machine Learning Toolkit, необходимо загрузить и установить (соответствующую версию) расширение Splunk Python for Scientific Computing. Сделать это необходимо перед установкой Splunk Machine Learning Toolkit: для Mac: https://splunkbase.splunk.com/app/288/; для 64-разрядной версии Linux: https://splunkbase.splunk.com/app/2882/; для 32-разрядной версии Linux: https://splunkbase.splunk.com/app/2884/; для 64-разрядной версии Windows: https://splunkbase.splunk.com/app/2883/. Установка Чтобы после загрузки установить приложение Splunk Machine Learning Toolkit Splunk Enterprise (как и любое другое приложение), выполните следующие шаги: 1) войдите в Splunk Enterprise; 2) в меню Apps (Приложения) щелкните на значке Apps (Приложения); 3)щелкните на ссылке Install app from file (Установить приложение из файла); 4)в диалоге Upload app (Загрузить приложение) щелкните на кнопке Choose File (Выбрать файл); 5)найдите только что загруженный файл .tar.gz или .tar (с таким именем, как splunk-machine-learning-toolkit_310). Затем щелкните на кнопке Open (Открыть) или Choose (Выбрать); 6) щелкните на кнопке Upload (Загрузить); 7) после установки вам будет предложено перезапустить Splunk. Рабочее пространство  465 Будьте внимательны! Вы не должны распаковывать загруженный файл архива перед установкой. После завершения установки должно появиться сообщение App Splunk Machine Learning Toolkit was installed successfully (Приложение Splunk Machine Learning Toolkit успешно установлено), указывающее, что ML Toolkit успешно установлено и готово к использованию, как показано на рис. 14.3. Рис. 14.3  Приложение MLT успешно установлено и готово к использованию Теперь можно приступать к практическому использованию Splunk Machine Learning Toolkit! Для обсуждения тем, связанных с приложением Splunk Machine Learning Toolkit, посетите сайт Splunk Answers: http://answers.splunk.com/answers/app/2890. Рабочее пространство Напомню, что цель Splunk Machine Learning Toolkit – упростить и оптимизировать процесс применения методов машинного обучения к данным, собранным в Splunk. Текущая версия 3.1.0 приложения включает демонстрационные примеры, организованные по типу использования: классификация (предсказания типа «да» или «нет»); регрессия; выявление аномалий; выявление выбросов; другие типы использования. Демонстрационные примеры показывают, как применить перечисленные методы машинного обучения к образцовым выборкам данных (также входящим в состав приложения). Их можно использовать в качестве отправной точки для реализации своих методов анализа. После запуска приложения Splunk Machine Learning Toolkit откроется страница Showcase (Демонстрационные примеры), как показано на рис. 14.4. 466  Machine Learning Toolkit Рис. 14.4  Страница Showcase (Демонстрационные примеры) На этой странице можно щелкнуть на любом из примеров, после чего откроется соответствующий ассистент, который проведет вас через процесс применения демонстрируемой модели к данным. Так, если щелкнуть на примере Predict Numeric Fields (Прогнозирование числовых значений полей), откроется страница помощника, который поможет вам применить эту модель к образцам данных, как показано на рис. 14.5. Рис. 14.5  Страница помощника для модели Predict Numeric Fields (Прогнозирование числовых значений полей) На рис. 14.6 изображена полоса меню приложения. Ассистенты  467 Рис. 14.6  Полоса меню приложения В меню присутствуют следующие пункты: Search (Поиск): ведет на стандартную страницу поиска (в данных ML); Showcase (Демонстрационный пример): ведет на страницу со списком демонстрационных примеров (см. рис. 14.4); Models (Модели): ведет на страницу Models (Модели), где доступны ранее созданные модели; Assistants (Ассистенты): раскрывающийся список с доступными ассис тентами (описываются в следующем разделе); Scheduled Jobs (Планировщик заданий): открывает доступ к планировщику ранее созданных обучающих заданий и отчетов; Docs (Документация): ведет к актуальной документации с описанием Splunk Machine Learning Toolkit; Video Tutorials (Видеоруководства): ведет на страницу со списком ссылок на видеоруководства, касающиеся использования механизмов машинного обучения в Splunk. Мы еще вернемся к демонстрационным примерам в разделе «Создание модели». Ассистенты Splunk Machine Learning Toolkit предлагает (на момент написания этих строк) шесть ассистентов, как можно видеть на рис. 14.7. Рис. 14.7  Список доступных ассистентов в Splunk Machine Learning Toolkit Они предлагают пошаговые инструкции по созданию моделей машинного обучения с определенной целью. Вот как описывается назначение ассистентов на сайте Splunk: 468  Machine Learning Toolkit «Каждый ассистент содержит комплекс примеров с наборами данных и дает возможность применить разные способы визуализации и команды SPL к собственным данным...» Эти шесть ассистентов опираются на шесть наиболее распространенных моделей, которые может построить специалист по данным. В их числе: Predict Numeric Fields (линейная регрессия): например, для предсказания медианной стоимости; Predict Categorical Fields (линейная регрессия): например, для предсказания оттока клиентов; Detect Numeric Outliers (анализ распределения): например, для обнаружения выбросов в наблюдаемых данных; Detect Categorical Outliers (оценка вероятности): например, для обнаружения отклонений в анализах пациентов, страдающих сахарным диабетом; Forecast Time Series: например, для прогнозирования расширения дата-центра и необходимых для этого мощностей; Cluster Numeric Events: например, для анализа работы кластера жестких дисков с технологией SMART. Мы еще вернемся к ассистентам в разделе «Создание модели». Расширенный язык запросов SPL Splunk Machine Learning Toolkit содержит множество дополнительных команд, называемых командами ML-SPL, которые реализуют стандартные задачи машинного обучения. Эти команды можно использовать на любом сервере Splunk, где установлено приложение Splunk Machine Learning Toolkit. Их всего шесть – fit, apply, summary, listmodels, deletemodel и sample: fit: используется для обучения модели на результатах поиска в Splunk; apply: используется для прогнозирования по текущим результатам поиска с применением модели, обученной командой fit; summary: выводит сводную информацию о модели, обученной командой fit; listmodels: создает список моделей, обученных командой fit; deletemodel: удаляет модель, обученную командой fit; sample: эту команду можно использовать для случайной выборки событий. Приложение ML-SPL Performance Существует приложение для Splunk, набирающее популярность, которое часто называют сопутствующим приложением для Splunk Machine Learning Toolkit. Это приложение – ML-SPL Performance – предназначено для совместного использования с Machine Learning Toolkit и доступно для загрузки на Splunkbase: https://splunkbase.splunk.com/app/3289. Создание модели  469 Оно позволит вам измерить производительность каждого алгоритма, который вы реализуете с использованием ML-SPL в среде Splunk и просмотреть результаты в специальном дашборде. Эти результаты можно использовать для выявления и устранения узких мест в производительности вашего приложения. Это приложение обладает богатыми возможностями. Его главная страница показана на рис. 14.8. Рис. 14.8  Главная страница приложения ML-SPL Performance А теперь, после знакомства с основами, перейдем к следующему разделу и попробуем создать свою модель с помощью ML Toolkit. Создание модели Добравшись до этого раздела, вы наверняка познакомились с базовой информацией в предыдущих разделах этой главы и получили, по крайней мере, общее представление о машинном обучении. Теперь вы знаете, что Splunk может помочь в создании моделей машинного обучения, предлагая последнюю версию ML Toolkit; а также нашли, загрузили и установили Splunk Machine Language Toolkit в свое окружение Splunk. Все верно? Отлично! Тогда давайте посмотрим, как на практике создать модель машинного обучения. Прогнозирование временных рядов Фактически цель машинного обучения – обобщить предоставленные примеры. Результаты такого обобщения (то, что мы называем прогнозными моделями) затем можно использовать для прогнозирования, или предсказания. Необходимость качественных прогнозов в деловом мире очевидна. Прогноз временных рядов – это тип прогнозных моделей, широко используемых для прогнозирования будущих показателей на основе прошлых событий. В част- 470  Machine Learning Toolkit ности, основная задача прогнозирования временных рядов заключается в наблюдении исторических тенденций, изменяющихся с течением времени, и использовании выявленных закономерностей для прогнозирования будущего (будущих показателей). Существует множество методов создания моделей прогнозирования временных рядов (AR, MA, ARIMA, SARIMA, AAN и SVM). Для понимания логики процедур и различий между ними требуются очень глубокие познания. К счастью, Splunk ML Toolkit существенно упрощает процесс создания моделей прогнозирования временных рядов (вам не придется получать ученую степень в статистике!). Использование Splunk Как отмечалось выше в этой главе, Splunk предлагает следующую трехуровневую архитектуру для поддержки машинного обучения, включающую: уровень 1: базовая платформа с функциями поиска; уровень 2: готовые решения и приложения, доступные на Splunkbase; уровень 3: набор инструментов машинного обучения Splunk Machine Learning Toolkit. Поскольку главной темой этой главы является знакомство с приложением Splunk Machine Learning Toolkit, мы можем пропустить первые два уровня и сразу перейти на третий. Запуск приложения Первый шаг – запуск приложения MLT. После входа в Splunk его можно найти слева на главной странице, как показано на рис. 14.9. После щелчка на значке запуска приложения Splunk Machine Learning Toolkit откроется страница с Showcase (Демонстрационные примеры). Мы собираемся заняться прогнозированием временных рядов, поэтому нужно прокрутить страницу вниз, чтобы добраться до нужного примера, как показано на рис. 14.10. Здесь вы увидите главную ссылку Forecast Time Series (Прогнозирование временных рядов) и список дополнительных ссылок, ведущих к примерам моделей этого типа. Давайте выберем прогнозирование объема продаж на месяц, для этого щелкните на ссылке Forecast Monthly Sales (Прогнозирование месячного объема продаж), после чего откроется страница прогнозирования временных рядов, включающая несколько разделов, или панелей. Splunk Machine Learning Toolkit предоставляет демонстрационный пример Forecast Monthly Sales (Прогнозирование месячного объема продаж) вместе с образцом файла данных, как можно видеть на рис. 14.11. Создание модели  471 Рис. 14.9  Значок запуска приложения Splunk Machine Learning Toolkit Рис. 14.10  Демонстрационный пример модели прогнозирования временных рядов Рис. 14.11  Демонстрационный пример прогнозирования месячного объема продаж включает файл данных 472  Machine Learning Toolkit Раздел/панель вверху имеет две вкладки, Create New Forecast (Новый прог ноз) и Load Existing Settings (Загрузить имеющиеся данные), как показано на рис. 14.12. Рис. 14.12  Вкладка Create New Forecast (Новый прогноз) На этой панели можно заметить знакомое поле ввода Enter a search (Введите запрос) с предварительно подготовленным запросом, ссылающимся на образец файла данных, который содержит информацию о продажах, и несколько раскрывающихся списков для выбора параметров нашей будущей модели машинного обучения для прогнозирования временных рядов. Вот эти параметры: Algorithm (Алгоритм): позволяет выбрать методологию для конструирования модели. Здесь предлагаются варианты, подходящие для типа временных рядов, выбранного нами (прогнозирование месячного объема продаж); Field to forecast (Поле для прогнозирования): здесь нужно выбрать поле, значение которого модель должна предсказать (спрогнозировать) по имеющимся исходным данным. В образцовом файле с данными есть только два поля: Month (месяц) и Sales (продажи); Method (Метод): здесь выбирается метод, который должен реализовать алгоритм. На основе выбранного метода будут показаны и предложены дополнительные поля ввода настроек. Прогнозирование тенденций имеет научное обоснование, но его результаты могут оказаться неоднозначными. Чем дальше в будущее простирается прогноз, тем неопределеннее могут быть результаты. В реальной жизни могут происходить неожиданные события, ломающие любые закономерности или тренды. Кроме того, чем сложнее модель, тем более неопределенным получается прогноз. Вы можете настроить вышеупомянутые параметры модели, как вам заблагорассудится. Благодаря Splunk Machine Learning Toolkit вы с легкостью сможете изменить метод для модели, повторно обучить ее, выполнить прогноз и оценить и сравнить результаты. Создание модели  473 Имейте в виду, что если вы незнакомы с особенностями методов алгоритма, стоит потратить некоторое время на поиски в Google, чтобы получить некоторое представление о каждом. Впрочем, можно пойти другим путем – путем экспериментов, который всегда рекомендуется при знакомстве с разными настройками модели. В модели прогноза временных рядов часто разумнее выбрать метод LLP5, как показано на рис. 14.13, сочетающий в себе методы LLP и LLT (поскольку исторические данные о продажах в течение периода времени, скорее всего, будут включать сезонные и другие закономерности). Рис. 14.13  Выбор метода LLP5 В число других параметров настройки входят: Future Timespan (Интервал времени в будущем), то есть интервал времени, на который простирается прогноз, и Confidence interval (Доверительный интервал). Доверительные интервалы – очень распространенный способ представления достоверности прогноза. Эти интервалы задаются в процентах случаев, охватывающих вероятные результаты, например 67 %, 90 % или 95 %. И снова разумнее выбрать значение 95 %. Используя предоставленные данные, сопровождающие демонстрационный пример, первым шагом на пути настройки прогнозной модели можно изменить (или ввести) запрос и просмотреть данные. Например, если нас не устраивает интервал временной шкалы, мы можем выбрать относительный интервал времени для поиска Previous year (Предыдущий год), как показано на рис. 14.14. Рис. 14.14  Выбор относительного интервала времени для поиска Previous year (Предыдущий год) После изменения запроса можно щелкнуть на кнопке Forecast (Прогноз), чтобы повторно обучить модель и увидеть эффект изменения временного интервала, как показано на рис. 14.15. 474  Machine Learning Toolkit Рис. 14.15  Результат прогнозирования после повторного обучения модели Следующий раздел/панель на странице – панель Forecast (Прогноз), изображенная на рис. 14.16. Рис. 14.16  Панель Forecast (Прогноз) В этой панели приложение Machine Learning Toolkit автоматически создает график, отображающий входные данные, сгенерированный прогноз и соответствующие доверительные интервалы, чтобы помочь оценить качество результатов текущей модели. Наводя указатель мыши на заголовки панелей, всегда можно получить полезные советы. Если вы удовлетворены всеми параметрами настройки, можете щелкнуть на кнопке, соответствующей дальнейшему желаемому действию. Например, мож- Проверка  475 но просмотреть базовый запрос на языке SPL или настроить запуск уведомления при выходе прогнозируемого значения за пределы определенного диапазона. Splunk Machine Learning Toolkit дает возможность просматривать и/или редактировать (и сохранять версии) запросы SPL в каждой панели на странице. Например, можно щелкнуть на кнопке Show SPL (Показать SPL), чтобы получить доступ к командам, используемым для создания графика, как показано на рис. 14.17. Рис. 14.17  Исходный код запроса на языке SPL Последняя панель, расположенная в нижней части страницы (см. рис. 14.18), отображает различные статистические данные, которые можно использовать для оценки качества прогнозной модели, в том числе: R2 Statistic (Коэффициент R2): квадрат коэффициента корреляции между предсказанными и фактическими значениями; Root Mean Squared Error (RSME) (Среднеквадратичная ошибка): среднее квадратичное ошибок прогноза; Forecast Outliers (Выбросы в прогнозе): число значений в контрольном периоде, вышедших за доверительный интервал. Рис. 14.18  Панель со статистическими данными для оценки качества прогнозной модели Проверка Проверка прогнозной модели включает обучение модели на части данных (которые называют обучающими данными) и ее проверку на другой части данных (которые называют контрольными данными). В задачах прогнозирования обучающие данные находятся в начале интервала, а контрольные данные – в конце и служат для сопоставления с прогнозом. Проверку обученной модели с помощью контрольного набора можно выполнять разными способами, в зависимости от типа модели. Каждый ассистент 476  Machine Learning Toolkit предоставляет доступные методы в разделе Validation (Проверка), который появляется после обучения модели. Эксплуатация Если в ходе проверки выяснилось, что модель удовлетворяет требованиям, ее можно ввести в эксплуатацию. Обычно в ходе эксплуатации выполняются следующие действия: генерируется прогноз, который можно использовать непосредственно или передать на вход другой аналитической системы; выявляются выбросы и аномалии, чтобы помочь усовершенствовать весь процесс; запускаются действия или уведомления о принятом решении. Splunk Machine Learning Toolkit обеспечивает простоту эксплуатации и передачи полученных результатов благодаря имеющимся в Splunk возможностям создания дашбордов, уведомлений и отчетов. Кроме того, после создания прогноза сгенерированные данные можно экспортировать. Сохранение в виде отчета В панели Visualization (Визуализация) можно выбрать способ визуализации полученных результатов, как показано на рис. 14.19. Рис. 14.19  Выбор способа визуализации полученных результатов Проверка  477 После выбора способа визуализации можно использовать функцию Save As (Сохранить как), чтобы сохранить визуализацию в виде отчета Splunk или дашборда, как показано на рис. 14.20. Рис. 14.20  Сохранение выбранной визуализации в виде отчета Вы также можете использовать любые способы визуализации, созданные вами, и сохранить результат на любом сервере Splunk, где установлено приложение Splunk Machine Learning Toolkit. Исследование данных Как отмечалось выше, данные, созданные моделью машинного обучения, можно также экспортировать. Для этого на панели визуализации: 1)щелкните на кнопке Open in Search (Открыть в приложении поиска), как показано на рис. 14.21; Рис. 14.21  Кнопка Open in Search (Открыть в приложении поиска) 478  Machine Learning Toolkit 2) щелкните на кнопке Export (Экспортировать), как показано на рис. 14.22; Рис. 14.22  Кнопка Export (Экспортировать) 3)заполните поля в диалоге Export Results (Экспорт результатов) и щелк ните на кнопке Export (Экспортировать), как показано на рис. 14.23; Рис. 14.23  Диалог Export Results (Экспорт результатов) 4)после этого будет создан файл, который можно использовать непосредственно и/или передать в другую аналитическую систему. Итоги В этой главе мы узнали, что такое машинное обучение, познакомились с основами приложения Splunk Machine Learning Toolkit и увидели, как его можно использовать для создания модели машинного обучения. Предметный указатель Символы _indextime и _time, 66 |, символ вертикальной черты, 84 A addterm, 283 authorize.conf, 374 атрибуты importRoles, 374 rtsearch, 374 rtSrchJobsQuota, 375 schedule_search, 374 srchDiskQuota, 375 srchIndexesAllowed, 374 srchIndexesDefault, 374 srchJobsQuota, 375 B btool, инструмент, использование, 344 C chart, команда, представление данных, 91 chart, параметры команды Chart Overlay, 93 General, 92 Legend, 93 X-Axis, 93 Y-Axis, 93 collectId, 206 commands.conf, 375 crcSalt, 357 CSV, файлы вычисления в течение дня, 333 для хранения промежуточных результатов, 332 заполнение раскрывающегося списка, 332 cтруктура каталога приложения, 261 appserver, 261 bin, 262 default, 262 local, 262 lookups, 262 metadata, 262 nav, 262 views, 262 D distinct count (dc), команда, 311 E eval, команда группировка полей, 320 создание полей, 99 F fields.conf, 371 fill_summary_index.py, скрипт, использование для заполнения, 315 G Geo Location Lookup Script, установка, 244 Google Maps использование, 246 расширение, 291 google, команда, 238 H HiddenPostProcess, создание нестандартных детализаций в нескольких панелях, 288 Hunk, платформа, 457 документация, 457 обзор, 457 особенности, 457 480  Предметный указатель I indexes.conf, 372 indextime search, приложение URL, 315 inputs.conf атрибуты, 352 host, 353 index, 353 source, 353 sourcetype, 353 атрибуты для протоколов TCP/UDP connection_host, 358 persistentQueueSize, 358 queueSize, 358 source, 358 sourcetype, 358 ввод из сети, 358 ввод из файлов, 353 выбор журнала с использованием шаблонов, 353 индексирование файлов, 357 использование srcSalt, 357 настройки ввода для Windows, 359 определение значения host из поля source, 355 переходы по символическим ссылкам, 355 рекурсивный выбор файлов, 354 скрипты как источники ввода, 360 устаревшие данные, игнорирование, 356 черные и белые списки, 354 intentions, 282 addterm, 283 stringreplace, 282 IOPS (операций ввода/вывода в секунду), 394 L layoutPanel, атрибут знакомство, 279 размещение панелей, 280 M mako, язык шаблонов, 448 ML-SPL Performance URL, 468 обзор, 468 O outputs.conf, 372 P «Perl Compatible Regular Expressions» (PCRE), ссылка, 98 Pivot Editor, редактор, 131 объекты поиска, 131 объекты событий, 131 объекты транзакций, 131 props.conf атрибуты времени ввода, 349 времени индексирования, 346 времени парсинга, 347 времени поиска, 345 с классом, 351 типы разделов, 349 приоритеты, 351 R REST, интерфейс, отправка запросов в Splunk, 431 rex, команда группировка полей, 320 создание полей, 99 S savedsearches.conf, 375 Search & Reporting, приложение, 27 генератор данных, 28 действия, 31 поиск, 30 представление Summary, 28 результаты поиска, 35 параметры, 37 представление событий, 37 хронологическая последовательность, виджет выбора полей, 33 Sideview Utils, 293 URL, 293 модуль HTML, 296 Предметный указатель  481 модуль Redirector, 296 модуль search, 294 модуль Search, 296 модуль SideviewUtils, 296 модуль URLLoader, 295, 296 связывание дашбордов, 294 формы, 297 Sideview Utils (LGPL), приложение, 269 sistats, использование, 310 sitimechart, использование, 310 sitop, использование, 310 Splunk балансировка нагрузки, 421 верхняя полоса меню, 23 добавление базовой конфигурации, 408 домашнее приложение, 19 индексеры, 382 интерфейс, 18 использование из командной строки, 430 конфигурационные файлы authorize.conf, 374 commands.conf, 375 fields.conf, 371 indexes.conf, 372 inputs.conf, 352, 358 outputs.conf, 372 props.conf, 345 savedsearches.conf, 375 times.conf, 375 transforms.conf, 361 web.conf, 375 обзор, 345 коэффициент репликации, 396 логирование, 18 настройка, 335 настройка запуска на этапе загрузки, 408 несколько поисковых серверов, 422 отправка запросов через REST-интерфейс, 431 поиск, 383 продвинутая настройка, 380, 424 развертывание из архива tar, 407 развертывание из дистрибутива msiexec, 407 развертывание серверов, 406 сервер развертывания, 414 создание моделей машинного обучения, 469 форвардеры, 381 форвардеры, настройка, 382 форвардеры, универсальные, 381 Splunk 6.2, устаревшие функции, 166 Splunkbase, установка приложений из, 243 Splunkbase, сайт, 463 Splunk Cloud, 44 eventgen, 50 HTTP Event Collector (HEC), 45 Splunk reference App – PAS, 50 Universal forwarder, 50 URL, 44 краткий тур по облаку, 46 опробование перед покупкой, 45 полоса меню, 48 последствия, 44 Splunk Machine Learning Toolkit (MLT) URL, 463 ассистенты, 467 демонстрационные примеры, 465 достоинства, 462 запуск, 470 обзор, 462 полоса меню, 466 получение, 463 предварительные требования, 464 рабочее пространство, 465 расширенный язык запросов SPL, 468 установка, 464 Splunk Web Framework, 241 Splunk, сервер развертывания выбор машины, 414 достоинства, 414 использование, 414 настройка конфигурации deploymentclient.conf, 415 недостатки, 414 нормализация конфигураций в приложения, 415 482  Предметный указатель определение типов и местоположений машин, 415 перезапуск, 419 сопоставление приложений с клиентами в serverclass.conf, 415 установка deploymentclient.conf, 419 StatsD, 206 stats, команда, агрегирование значений, 88 stringreplace, 282 summary-индексы группировка полей с помощью eval, 320 группировка полей с помощью rex, 320 группировка результатов по типам событий, 325 заполнение в хранимых запросах, 307 использование, 305 использование в запросах, 308 когда не следует использовать, 306 общие сведения, 303 отчеты, поиск, 331 подсчет топ данных в больших интервалах времени, 327 создание, 304 создание с помощью collect, 316 уменьшение размера, 319 T timechart,использование, 190 timechart, команда параметры, 95 представление данных, 93 times.conf, 375 top, имитация, 195 top, команда вывод типичных значений полей, 85 дополнительная информация, 88 управление выводом, 87 transforms.conf REPORT, 368 динамические поля, 369 поля с несколькими значениями, 368 атрибуты, 361, 368 изменение полей метаданных, 363 переопределение поля host, 364 переопределение поля source, 364 переопределение поля sourcetype, 365 объединение преобразований в цепочки, 370 подстановки использование времени в, 367 определение, 365 с метасимволами, 366 создание индексируемых полей, 361 создание полей для классификации хостов, 363 создание поля loglevel, 361 создание поля session из поля source, 362 создание поля маркера, 362 фильтрация событий, 371 W web.conf, 375 X xmlkv, команда, 236 xpath, команда, 237 А Автоматическая подстановка определение, 220 Аннотирование событий, 81 Атрибуты, 336 Атрибуты, потомки, 127 добавление, 128 Аутентификация с использованием LDAP, 420 с использованием единой точки входа, 420 Б Балансировка нагрузки, 421 splunktcp, 422 веб-серверов, 421 на индексеры, 397 серверов развертывания, 422 Предметный указатель  483 Верхняя полоса меню, 23 Виджет выбора времени Advanced, 65 Date and time range, 65 Date range, 65 Presets, 62 Real-time, 64 Relative, 63 Виджет выбора полей, 58 Визуализаторы событий визуализация полей по выбору, 448 реализация, 448 форматированный вывод XML, 453 Вложенные подзапросы, 174 Внешние команды, 236 Время, 60 как анализируется, 60 как определяется часовой пояс, 61 как отображается, 61 как хранится, 61 определение в строке запроса, 66 разные способы поиска по времени, 62 Выбора времени, виджет использование, 38 Выбора полей, виджет, 33 использование, 39 поля, 34 переупорядочение панелей, 152 преобразование панелей в отчеты, 152 процесс разработки, 269 редактирование исходного кода, 158 редактирование пользовательского интерфейса, 158 создание форм из, 159 Детализации, нестандартные, 284 определение в отдельных панелях, 286 определение в своих запросах, 284 применение HiddenPostProcess для создания в нескольких панелях, 288 создание, 284 Диаграммы, настройка справочник (ссылка), 110 Диаграммы, расширения charting.axisX2.abbreviation, 114 charting.axisX.abbreviation, 114 charting.axisY2.abbreviation, 114 charting.axisY.abbreviation, 114 charting.data.fieldHideList, 112 charting.fieldDashStyles, 113 charting.legend.mode, 113 charting.lineWidth, 111 в версии 7.0, 110 Домашнее приложение, 19 Г З Глубокое обучение, 460 Д Дашборды, 141 автоматический запуск, 168 выполнение запросов по расписанию, 169 добавление панелей, 145 добавление полей ввода, 157 дополнительные настройки, 157 конструирование с помощью мастеров, 142 меню, 157 назначение, 141 непосредственное редактирование XML, 158 Задания поиска, настройки, 73 Задержка, влияние на запросы, использующие summary-индексы, 313 Запросы, повторное использование, 281 Значения, извлечение из XML, 236 Значок запуска, настройка, 253 И Избыточность коэффициент репликации, 396 планирование, 395 Извлекаемые и индексируемые поля, 107 Индексеры, балансировка нагрузки, 397 Индексеры Splunk, 382 484  Предметный указатель indexes.conf, 383 inputs.conf, 383 props.conf, 383 server.conf, 383 transforms.conf, 383 Индексирование, организация, 393 Индексируемые поля и извлекаемые, 107 медленные запросы, 109 недостатки, 107 поиск распространенных терминов, 108 преимущества, 107 приложение по источнику, 109 разбиение слов, 108 Индексы, 399 для тестирования, 400 для увеличения производительности, 402 жизненный цикл сегмента, 402 использование томов для управления, 404 несколько индексеров, 400 определение размера индекса, 404 создание для метрик, 206 с разными разрешениями, 401 с разным сроком хранения, 400 структура каталогов, 400 Индексы, summary группировка полей с помощью eval, 320 группировка полей с помощью rex, 320 группировка результатов по типам событий, 325 заполнение в хранимых запросах, 307 использование, 305 использование в запросах, 308 когда не следует использовать, 306 общие сведения, 303 отчеты, поиск, 331 подсчет топ данных в больших интервалах времени, 327 создание, 304 создание с помощью collect, 316 уменьшение размера, 319 Инструментарий управления Windows (Windows Management Instrumentation, WMI), 359 Интерфейс извлечения полей, 100 индексируемые и извлекаемые поля, 107 прототипирование с помощью rex, 104 создание с помощью административного интерфейса, 105 Источники данных, 383 использование скриптов для сбора данных, 392 мониторинг файлов журналов на разделяемом диске, 385 мониторинг файлов журналов на сервере, 384 пакетная обработка файлов журналов, 386 прием из базы данных, 391 прием событий от syslog, 387 К Классификация результатов по типам событий, 212 Командная строка, использование Splunk из, 430 Команды генерирование данных, 444 добавление полей, 437 когда не стоит писать свои команды, 434 когда стоит писать свои команды, 435 конфигурирование, 436 манипулирование данными, 438 преобразование данных, 439 реализация, 434 Команды ML-SPL, 468 apply, 468 deletemodel, 468 fit, 468 listmodels, 468 sample, 468 summary, 468 Конкуренция команды transaction и concurrency, 182 Предметный указатель  485 определение уровня с использо ванием предложения by, 184 оценка нагрузки на сервер, 183 Конфигурации использование сервера развертывания, 414 использование собственной системы развертывания, 413 установка, 413 Конфигурационные приложения, 409 indexerbase, 409 inputs-sometype, 409 outputs-datacenter, 409 props-sometype, 409 Конфигурационные файлы каталоги, 335 логика слияния, 337 инструмент btool, 344 порядок слияния, 337 пример, 338, 339, 340, 342 местоположение, 335 структура, 336 Конфигурационные файлы Splunk authorize.conf, 374 commands.conf, 375 fields.conf, 371 indexes.conf, 372 inputs.conf, 352, 358 outputs.conf, 372 props.conf, 345 savedsearches.conf, 375 times.conf, 375 transforms.conf, 361 web.conf, 375 обзор, 345 Коэффициент репликации, 396 настройка, 396 синтаксис, 397 Л Логика многократное использование, макросы, 224 Логика слияния конфигураций, 337 инструмент btool, 344 порядок слияния, 337 пример, 338, 339, 340, 342 Логирование, в Splunk, 18 М Макросы context, пример, 233 многократное использование логики, 224 с аргументами, создание, 225 создание, 224 Машинное обучение механизмы рекомендаций по содержимому, 460 обзор, 459 обработка естественного языка, 460 оперативные исследования, 461 Метаданные, 377 default.meta, файл, 377 local.meta, файл, 377 Метасимволы, использование в подстановке, 322 Метрики в версии 7.0, 205 значение, 205 имя, 205 использование в Splunk, 206 определение, 205 отметка времени, 205 размерности, 205 свой тип индекса, 205 создание индекса, 206 Механизмы рекомендаций по содержимому, 460 Модели, 460 Модели данных, 115 добавление полей (атрибутов), 122 заполнение полей в диалоге, 119 объекты, 116 подстановочные атрибуты, 125 роль в поиске, 116 создание, 118 Модели машинного обучения запуск приложения MLT, 470 использование Splunk, 470 исследование результатов, 477 проверка, 475 486  Предметный указатель прогнозирование временных рядов, 469 создание, 469 сохранение в виде отчета, 476 эксплуатация, 476 Модули ConvertToDrilldownSearch, 278 EnablePreview, 278 ExtendedFieldSearch, 277 HiddenChartFormatter, 278 HiddenFieldPicker, 278 HiddenSearch, 277 JobProgressIndicator, 278 JSChart, 278 SubmitButton, 277 TimeRangePicker, 277 ViewRedirector, 279 ViewRedirectorLink, 279 ViewstateAdapter, 277 поток логики, 277 Н Навигация влияние разрешений на, 259 настройка, 251 Настройка Splunk, 335 продвинутая, 380, 424 Настройка ввода данных через UDP или TCP, 207 Несколько поисковых серверов, 422 О Обзор инструментария, 461 Обработка естественного языка, 460 Обучение процедур, 460 Объекты, моделей данных атрибуты, 117 дерево объекта, 116 объекты корневые, 116 ограничения, 116 Оперативные исследования, 461 Операторы AND, 54 NOT, 54 OR, 54 знак равно (=), 54 использование, 53 кавычки (""), 54 квадратные скобки ( [ ] ), 54 круглые скобки ( ( ) ), 54 Оповещения параметры Action Options, 79 Enable Actions, 79 Sharing, 79 создание на основе поиска, 77 Отчеты доступность для ускорения, 205 ускорение, 202 Отчеты, настройки Acceleration, 71 Embed, 71 Permissions, 70 Schedule, 71 П Панели, создание нестандартных детализаций, 286 Подзапросы, 171 вложенные, 174 в транзакциях, 178 ограничения, 173 поиск дополнительных событий, 171 Подстановка автоматическая, определение, 220 для обогащения данных, 216 настройка определения, 218 определение файла с таблицей подстановки, 216 с метасимволами, 322 Подстановочные атрибуты, 125 настройка, 125 Поиск аннотирование событий, 81 виджет выбора полей, 58 виджеты полей, 55, 58 в реальном времени методом скользящего окна, 64 время, 57 изменение критериев щелчком мыши, 55 несколько поисковых серверов, 422 Предметный указатель  487 определение времени в строке запроса, 66 основы, 52 передача результатов другим, 68 разные способы поиска о времени, 62 расширенный, 208, 240, 268, 303 сегментирование событий, 55 создание оповещений, 77 сохранение для повторного использования, 74 ускорение получения результатов, 67 шаблонные символы в полях, 60 эффективное использование критериев, 52 эффективное использование шаблонных символов, 59 Поиск Splunk, 383 Поля, 96 извлечение с помощью интерфейса, 100 извлечение уровня журналирования, 100 индексируемые и извлекаемые, 107 использование в поиске, 58 и шаблонные символы, 60 команды создания, 99 регулярные выражения, 97 создание командой eval, 99 создание командой rex, 99 Порядок слияния, конфигураций, 337 в механизме поиска, 338 за пределами механизма поиска, 337 Приложение с примерами пользовательского интерфейса, установка, 159 Приложения Google Maps, использование, 246 встроенные, 241 для организации конфигурации, 409 использование своей разметки HTML, 254 использование своих стилей CSS, 254 назначение, 240 настройка внешнего вида, 253 настройка значка запуска, 253 определение, 240 самостоятельное управление, 266 создание, 247 структура каталогов, 261 установка, 242 установка из Splunkbase, 243 установка из файлов, 247 Приложения, свои выгрузка, 265 добавление в Splunkbase, 263 очистка каталогов, 263 подготовка, 263 упаковка, 265 установка разрешений, 263 Проверка, моделей, 475 Продвинутый XML, 268 преобразование упрощенного XML в, 272 причины использования, 268 причины отказаться от, 269 структура, 270 Промежуточные данные сохранение в файлах CSV, 332 Р Раздел с настройками, 40 Data, группа, 42 Distributed environment, группа, 43 KNOWLEDGE, группа, 42 System, группа, 42 Users and authentication, группа, 43 Разрешения влияние на другие объекты, 259 доступа к объектам, 258 App, 258 Global, 258 Private, 258 исправление проблем, 260 Расширения, сторонние, 291 Google Maps, 291 Sideview Utils, 293 Расширенный поиск, 208, 240, 268, 303 Расширенный язык запросов SPL, 468 Регулярные выражения, 97 Результаты адрес URL, 68 488  Предметный указатель передача другим, 68 сохранение в виде оповещения, 72 сохранение в виде отчета, 69 сохранение в виде панели, 71 сохранение в виде типа события, 73 Ресурсы пользовательского интерфейса, 375 представления и навигация, каталоги, 376 Ресурсы сервера приложений, 376 event_renderers, 377 modules, 377 static, 376 templates, 377 С Самостоятельное управление приложениями, 266 Сводные таблицы, 129 Pivot Editor, редактор, 131 короткий пример, 134 работа с элементами, 132 создание, 129 форматирование, 134 элементы, 132 параметры настройки, 132 элементы разбиения на столбцы, 133 элементы разбиения на строки, 133 элементы столбцов значений, 133 элементы фильтрации, 132 Своя разметка HTML включение в сложные дашборды на стороне сервера, 255 в простых дашбордах, 254 Сегменты, жизненный цикл, 402 Символ вертикальной черты (|), 84 Скрипты ввода для сбора данных, 424 прием данных без дат, 424 прием данных от скриптов, выполняющихся продолжительное время, 429 прием данных, представляющих единственное событие, 427 Скрипты подстановки для обогащения данных, 445 Скрипты уведомлений обработка результатов, 454 реализация, 454 События аннотирование, 81 подсчет в интервалах времени, 190 Создание форм, 159 Среднее число запросов в минуту, вычисление, 191 Среднее число событий в минуту, за каждый час, 193 Сценарии реагирования запуск нового поиска со значением из события, 226 пример для отображения контекста поля, 231 создание, 226 ссылки на внешние сайты, 229 Сценарий реагирования, создание, 231 Т Таблицы, диаграммы и поля, 84 Теги для упрощения поиска, 208 Типы событий для группировки результатов, 325 для классификации результатов, 212 добавление тегов, 214 Транзакции, 175 определение продолжительности сеанса, 175 позапросы в, 178 получение укрупненных статистик, 177 У Универсальный форвардер Splunk, 381 Ускорение, 117, 201 большие данные, 202 доступность для отчетов, 205 отчетов, 202 Усовершенствованные параллельные алгоритмы, 118 Установка, планирование, 380 Ф Файлы журналов мониторинг на разделяемом диске, 385 Предметный указатель  489 мониторинг на сервере, 384 пакетная обработка, 386 прием из базы данных, 391 прием событий от syslog, 387 Файлы с данными, разделенными запятыми (Comma-Separated Values, CSV), 216 Форвардеры Splunk, 381 default-mode.conf, 382 inputs.conf, 382 limits.conf, 382 outputs.conf, 382 props.conf, 382 Формы ограничения постобработки, 165 постобработка результатов поиска, 165 создание из дашборда, 159 управление несколькими панелями, 163 Ш Шаблонные символы, эффективное использование в поиске, 59 Э Элементы, сводных таблиц, 132 Этапы обработки ввод, 381 индексирование, 381 парсинг, 381 поиск, 381 Эффективное использование критериев поиска, 52 Книги издательства «ДМК Пресс» можно заказать в торгово-издательском холдинге «Планета Альянс» наложенным платежом, выслав открытку или письмо по почтовому адресу: 115487, г. Москва, 2-й Нагатинский пр-д, д. 6А. При оформлении заказа следует указать адрес (полностью), по которому должны быть высланы книги; фамилию, имя и отчество получателя. Желательно также указать свой телефон и электронный адрес. Эти книги вы можете заказать и в интернет-магазине: www.a-planeta.ru. Оптовые закупки: тел. (499) 782-38-89. Электронный адрес: books@alians-kniga.ru. Джеймс Д. Миллер Внедрение Splunk 7 Главный редактор Мовчан Д. А. Технический редактор Перевод Корректор Верстка Дизайн обложки Кулаков А. С. Киселев А. Н. Синяева Г. И. Чаннова А. А. Мовчан А. Г. dmkpress@gmail.com Формат 70×100 1/16. Гарнитура «PT Serif». Печать офсетная. Усл. печ. л. 39,81. Тираж 500 экз. Веб-сайт издательства: www.dmkpress.com Powered by TCPDF (www.tcpdf.org)

splunk 7

Related documents

Products

Support

splunk 7

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib