Как стать автором
Обновить

Splunk 7.1. Что нового? Новый веб интерфейс, интеграция с Apache Kafka и многое другое…

Время на прочтение4 мин
Количество просмотров3.7K
Всего голосов 11: ↑9 и ↓2+7
Комментарии12

Комментарии 12

У Slunk есть два главных недостатка: большая цена и большая задержка от поступления данных в систему до времени их доступности к анализу. При большом количестве open source конкурентов исход сравнения явно не в его пользу…
большая цена

Это если сравнивать цену с ценой open source (которая ноль). Но если использовать более менее адекватную модель затрат, включающую затраты на внедрение, железо, зп сотрудников (об этом вообще никто никогда не вспоминает, хотя это ежемесячные расходы, и достаточно большие, если учесть что это квалифицированные сотрудники), затраты на поддержку, затраты на дополнительные платные фичи ( у open source они всегда есть иначе где модель монетизации бизнеса), список можно продолжать.

исход сравнения явно не в его пользу...

Судя по тому как растет его популярность, пока явно наоборот:
www.fool.com/investing/2017/04/05/splunk-in-2-charts.aspx

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

Здесь хотелось бы примеров, потому как не слышал о такой проблеме ранее.
На работе в инвестбанках использовали и ElasticSearch и Splunk. В итоге ElasticSearch был объявлен стратегическим решением в организации, новые проекты на Splunk принимали со «скрипом», да и не каждый готов выделять из бюджета проекта круглые суммы на гигабайты логов так как таррификация по объему ingesting data (попробуй предскажи sizing реального профиля работы приложения, а в нештатных ситуациях объем логов только увеличивается). Безусловно splunk удобнее на начальном этапе — не нужно прописывать regexp для файлов, но когда в организации генерируются терабайты лог файлов, затраты на поддержку нескольких проектов окупаются с лихвой.
Но если использовать более менее адекватную модель затрат

Множество конкурентов на рынке анализа данных. Всегда можно найти решение, которое больше подойдет в данном конкретном случае для конкретной задачи: elasticsearch, logentries, datadog, druid, clickhouse…

Судя по тому как растет его популярность, пока явно наоборот:
www.fool.com/investing/2017/04/05/splunk-in-2-charts.aspx

Впервые вижу этот ресурс с говорящим за себя названием. Маркетинг и не такое расскажет. Повторюсь, что по своему опыту я вряд ли когда-либо порекомендую splunk.

Примеры задержек в Splunk, к моей радости, остались при смене работы с бывшим работодателем. В Network security monitoring software Splunk не конкурент Elasticsearch. Когда надо реагировать на атаку, данные еще не доступны в дашборде…

А если нужно ускорить выполнение запросов, затраты и требования к квалификации специалистов будут не меньше чем в случае с Elasticsearch.
Количество клиентов у Splunk продолжает расти. Они публичная компания, последний раз я видел их отчет, у них было около 13k клиентов, несколько лет назад было меньше 10k.
Вот другой более популярный сайт с рейтингом БД db-engines.com/en/ranking, Splunk растет по их показателям тоже.

Никто не может обезопасить от неправильного сконфигурированного software. Использование Summary Index для real-time анализа как-то не имеет особый смысл.

> В Network security monitoring software Splunk не конкурент Elasticsearch.

Можете посмотреть на список компаний и их обоснования на выбор Splunk для Security Monitoring www.splunk.com/en_us/customers.html#filter/filter2/Security
Вот другой более популярный сайт с рейтингом БД db-engines.com/en/ranking, Splunk растет по их показателям тоже.

Да но на этом же сайте видно что Elasticsearch на 9 месте по популярности, а Splunk на 13

Использование Summary Index для real-time анализа как-то не имеет особый смысл.

Привел исключительно как пример, что Splunk не проще и требует определенного уровня знаний при оптимизациях. Соответственно не будет экономии на заработной плате экспертов, только прийдется искать малочисленных специалистов по этой системе. А стоимость лицензий астрономическая.
Машин выпущенных компанией тайота тоже больше на дорогах, чем мерседесов. Это не показательно. ElasticSearch это изначально БД для Full-Text Search, а Machine Log Analysis они прикрутили потом. Поэтому популярность его меня ни сколько не смущает.

Я не спорю в том, что Splunk тоже можно сконфигурировать не верно. И, скорее всего, нужны некоторые знания в настройке. Но это другое, чем допиливать самому в ElasticSearch.
Например, если нужен ACL — то придется платить за XPack в ElasticSearch, либо писать самому (либо прикручивать кем-то написанный opensource plugin). X-Pack совсем не дешевый, у них ценовая политика другая, но не знаю, что окажется дешевле X-Pack или гигабайты Splunk.
Помимо X-Pack, в случае с Enterprise будет необходим саппорт, он тоже платный.
Если мы говорим про ELK, то я рекомендую посмотреть на ответ сравнение между ELK и Splunk answers.splunk.com/answers/616416/what-is-the-difference-between-splunk-and-elk-stac.html?childToView=617933#answer-617933

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

Поэтому я бы не сказал, что это верное замечание «При большом количестве open source конкурентов исход сравнения явно не в его пользу». It depends.
Если мы говорим про ELK, то я рекомендую посмотреть на ответ сравнение между ELK и Splunk answers.splunk.com/answers/616416/what-is-the-difference-between-splunk-and-elk-stac.html?childToView=617933#answer-617933


наверно одно из наиболее успешных сравнений
Изменения в Контроли доступа вызовет боль для тех, кто автоматизирует установку Splunk.
У Splunk есть отличная документация, как установить изначальный пароль docs.splunk.com/Documentation/Splunk/7.1.0/Security/Secureyouradminaccount

Мы так же написали блог пост о том, как использовать теперь Splunk Docker Image www.outcoldsolutions.com/blog/2018-04-25-docker-splunk-7-1-0 после этих нововведений.
Некоторое время назад все спрашивали про OpenSource конкурентов — чем они лучше Splunk. Сегодня, я смотрю, вопрос задается ровно наоборот — за что платить деньги за лицензию, и можно ли то же сделать на менее дорогих (но, как на вид, не всегда менее хороших) решениях.
По поводу mstats. Несколько показателей в одной команде можно было вычислять и в 7.0. В частности, ваш пример для 7.1 отлично отработал бы и в 7.0.*.

Разница в том, что в 7.0 можно было делать вычисления только по полю _value. Так что если надо было рассчитать статистику по разным метрикам, то приходилось писать что-то вроде такого:

| mstats avg(_value) as value where index=metric_index metric_name=metric1 OR metric_name=metric2 span=1min by metric_name
| timechart span=1min max(value) as value by metric_name


В 7.1 же можно имя метрики сразу писать внутри стат.функции:

| mstats avg(metric1) as metric1, avg(metric2) as metric2 where index=metric_index span=1min

Так что новый функционал тут особо не привнесли, но синтаксически стало приятнее (а использование _value в mstats теперь deprecated).

Главная проблема с метрическими индексами в том, что если повторно отправить в метрический индекс метрику с таким же именем и dimensions, то в индексе будут содержаться оба значения. Очевидно, что это может плохо повлиять на вычисляемые статистики по этим метрикам. Возможными вариантами решения проблемы могли быть либо возможность избирательно удалять данные из метрического индекса (сделать аналог команды delete), либо настройка индекса, которая позволяла бы хранить только последнее значение по имени метрики и dimensions. Но этого пока нет, и приходится очень аккуратно настраивать сбор данных в метрические индексы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий