Месяц назад компания Splunk на своей 8-ой ежегодной конференции Splunk Conf 2017 презентовала выпуск нового мажорного релиза Splunk 7.0. В этой статье мы расскажем об основных нововведениях и улучшениях платформы, а также покажем пару примеров.

Метрики


В новом релизе Splunk вводит отдельный тип данных для индексации — метрики. Это в большинстве своем технологические данные, описывающие конкретный процесс или систему, а точнее их состояние. Это всем известные показатели, такие как: величина загрузки процессора, объем свободной оперативной памяти или места на диске, показатели AWS (Amazon Web Service), IoT и многое другое. Полный список доступен здесь. Стоит сказать лишь одно, чтобы загрузить метрики в Splunk у них должно быть три обязательных поля: время, название метрики и значение, остальное опционально, см. картинку ниже.


Также, при создании нового индекса, теперь нужно указывать, что это данные с метриками а не просто логи. Из коробки доступны забор таких sourcetype, как StatsD и collectD, для остального нужно будет конфигурировать transforms.conf и props.conf, но это не сложно.



Новые SPL команды для метрик


Для работы с метриками Splunk сделал новые команды mstats и mcatalog. Правда mcatalog пока официально не поддержиается, поэтому мы покажем только примеры запросов с mstats, которая как вы уже поняли сильно похожа на stats, глбальным отличием от stats является то, что поиск начинается сразу с pipe line |, а не с фильтрации.

Посчитаем среднюю скорость:

| mstats avg(_value) WHERE metric_name="car.speed" AND driver_id="*" span=1m



Добавим разделение по car_ip, для этого используем дополнительно timechart:

| mstats avg(_value) prestats=t WHERE metric_name="car.speed" AND driver_id="*" span=1m BY car_ip
| timechart avg(_value) AS speed span=30m BY car_ip



Зачем все это нужно?

Хороший вопрос, ведь раньше все тоже самое можно было делать с помощью обычной индексации, timechart и stats, и все работало. На самом деле ответ очевиден — это скорость. Для метрик, скорость обработки поисковых запросов, по заявлению разработчиков, возрастает в 20 раз и при этом уменьшается общая нагрузка на систему. Впечатляет, не правда ли?

Улучшение визуализации


Теперь на графики можно добавлять аннотации, Splunk так и назвал эту фичу Event Annotation. Правда стоит сразу отметить, что она работает только с line charts, column charts, и area charts.



Цвет можно выбирать, сообщение в аннотации может быть как статичным, так и формироваться из конкретного поля события, ну и понятно, что аннотация — это отдельный запрос в том же временном интервале что и главный запрос. Все это делается очень просто, стоит только дописать пару строчек в исходный xml дашборда. Ниже пример, ну а подробно об этом здесь.



Обновленный Machine Learning Toolkit


Основным обновлением ML Toolkit является добавление в него нового алгоритма — ARIMA, что очень сильно приближает его к реальному Machine Learning. Помимо этого была расширена ролевая модель, теперь каждый пользователь может сохранить свои наработки отдельно, а также расширен API, о нем подробно здесь.




Итого


Понятно, что в данном релизе есть еще масса различных фич, таких как: обновленная Monitoring Console, Chart Enhancements, Report Action Enhancements, общая оптимизация работы платформы и ускорение поиска и многое другое, но мы старались рассказть про наиболее важные и интересные нововведения.

Дополнительно


Для наиболее глубокого изучения вопроса стоит установить приложение Splunk Enterprise 7.0 Overview, а также посмотреть официальное видео релиза.

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

Комментарии (3)


  1. imanushin
    16.10.2017 11:07

    Подскажите, пожалуйста, а как вы бы порекомендовали организовать настройку Splunk для следующего сценария:


    • Есть один Splunk на несколько команд
    • У каждой команды — один или несколько индексов
    • Иногда одной из команд необходимо сделать изменения в настройках (т.е. inputs.config и пр.), однако прямой доступ к конфигурации выдавать опасно.

    Т.е. с одной стороны команды должны иметь возможность настраивать то, какие логи собираются. С другой стороны, прямой доступ к конфигурации давать опасно. И с третьей стороны — для упрощения процесса, в идеале сделать так, чтобы команда таки сама настраивала маски к собственным файлам для сбора.


    1. UnclShura
      16.10.2017 19:13

      [Я к Splunk никакого отношения не имею]
      А не используйте файлы вообще — коннектитесь к Splunk напрямую. Откройте несколько портов, каждому назначьте свой индекс и дуйте туда напрямую. Мы так log4cxx и log4net настроили (правда с кастомным TCP appender'ом, поскольку только UDP из коробки у них).


    1. igor_job
      17.10.2017 19:04

      1. Если используете форвардеры без Deployment Server или с ним:
      На форвардерах в каталоге local приложений команды смогут сохранять свои конфиги inputs.conf. Эти конфиги имеют приоритет над системными.
      2. Можно использовать HttpEventCollector для сбора логов, тогда вы выдадите командам токены, которые они будут использовать.
      3. Можно забирать у команд фильтры для inputs.conf из заранее огороворенного места (github, bitbucket), где будет храниться не только нужная информация, но и вся история изменений.