слишком много /intel

а вот код pysmart читать не хочется

а еще публикация описывается в каждом плагине независимо.

https://github.com/intelsdi-x/snap-plugin-collector-haproxy/tree/master/examples/tasks

два таска

с переопредеенной секций Publish

https://github.com/intelsdi-x/snap-plugin-collector-pysmart/blob/master/snap_pysmart/init.py

404

телега научилась портить линки

https://github.com/intelsdi-x/snap-plugin-collector-pysmart/blob/master/snap_pysmart/__init__.py

kwargs.get("DeviceList")().devices не питонячий немного, ага

https://github.com/intelsdi-x/snap-plugin-collector-disk/tree/master/examples/tasks

диски надо определять раздельными тасками.

а не

о тут есть пример что публиковать можно в два дейстинейшена сразу.

https://github.com/intelsdi-x/snap-plugin-collector-pysmart/blob/master/snap_pysmart/__init__.py

скажу таки: "фу"

ну чот на мой вкус не очень.

Кто то странный писал его

ну. короче ентерпрайзненько

я бы еще не скоро в него посмотрел, спасибо

а я второй раз натыкаюсь

за деньги бы им рефакторинг хотя бы сделать

да не. парни явно пилят потому как альтернатив нет или в случае прома они их не устраивают

https://github.com/influxdata/telegraf/releases/1.4.0-rc3 was tagged

https://github.com/influxdata/telegraf/releases/1.4.0-rc3 was tagged

Я в нем ковырялся. Но пока не перешел

и у меня впечатление что они не очень понимают к чему хотят в конце концов прийти

потому что вон та картинка с процессингом метрик она прикольная но вместо коллектора с плагинами эта система превращается... превращается, в элегантные шорты

Это не очень хорошо, когда ты вместо коллектора получаешь шорты

Вы хотите сказать не Интел, а индусы:)

там индусов в коммитерах нету практически

ну им один из товарищей предлагал чуть более компактный json (в 4 раза более компактный) спрашивая нафига вам вот поле вот это и вот это и почему так а не эдак... ему сказали - патамуфта

это я про плагин который в кафку льет

ему товарищь который плагин в еластик запилил сказал а ты сделай как я - добавь опцию - типа без нее будет вот такими пушистыми дефолтовыми деревьями слать, а с оной - компактно

ну и мне например не нравится ситуация что ты запускаешь скажем 5 плагинов сбора + 2 плагина обработки + 1 плагин посылки и в итоге у тебя на систему сбора метрик под сотню процессов, понятно что оно так то ничего особо не кушает, но после коллектд такую картину в htop наблюдать страннавата

а в остальном подход хороший, центральное ядро, плагины версионируются и т.д.

ну и мне например не нравится ситуация что ты запускаешь скажем 5 плагинов сбора + 2 плагина обработки + 1 плагин посылки и в итоге у тебя на систему сбора метрик под сотню процессов, понятно что оно так то ничего особо не кушает, но после коллектд такую картину в htop наблюдать страннавата

у тебя htop для красоты типо?

посоны, как правильно зарегэкспить

tomcat_threadpool_connectioncount{instance=~"$host:.*", protocol=~”^(http|ajp).*"}

protocol бывает либо http-nio либо ajp-nio

может protocol=~"http|ajp.*"

о, точно

Всем привет. Стоит вопрос выбора хранилища для данных, по которым будет делаться аналитика. Пока что выбор пал на ClickHouse и Elasticsearch. Подскажите, пожалуйста, имеет ли смысл использовать что-либо из них, или стоит посмотреть на что-то совсем другое? Если выбирать из CH и ES, чему отдать предпочтение? Какие плюсы/минусы у каждого из них? Какие подводные камни могут ждать? Буду благодарен за любые советы и рекомендации. Понимаю, что тема возможно сама по себе холиварная, но очень надеюсь получить в ответ конструктив)

@kmarenov никто ж не знает зачем тебе эти базы )

почему твой выбор на них пал

Если нужна аналитика на основе статистики, то clickhouse для вас.

если просто как базу ради базы - рекомендую начать с SQlite :)

если просто как базу ради базы - рекомендую начать с SQlite :)

я бы еще понял с постгреса

если SQlite не подходит - объяснить почему :)

я бы еще понял с постгреса

от простого к сложному )

а то это как монго предлагать :)

sqlite проще

я короче провоцирую человека на "объясни что тебе надо"

Если нужна аналитика на основе статистики, то clickhouse для вас.

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

пока не объяснил - sqlite ему ок в моем понимании

постгрес уже не справляется)

отчеты по минуте строятся

Мы с постгресса ушли на кликхаус, так как постгресс долго обрабатывал статистику.

Мы с постгресса ушли на кликхаус, так как постгресс долго обрабатывал статистику.

и как впечатления?

Производительность возросла в 15-20 раз.

@kmarenov вопрос в том что надо ) clickhouse хорош как аналитика по хорошо и строго структурированным данным

с выверенными индексами

и пониманием какие запросы делаются

мне вот говорят, что вроде у эластика богатые возможности для аналитики, сам язык богат такими возможностями

если все это есть - будет хорошо

эластик в общем помедленее будет, зато ок даже если у тебя нет толком структуры

ERROR: S client not available

я даже рискну предположить что он будет хуже постгреса

по скорости

но лучше по гибкости

но запросы вам виднее

и опять же выверенные индексы порешают, но данные разрастутся

на самом деле провести эксперимент думаю не сложно вам будет - запишите данные и туда и туда

и погоняйте типичные запросы

Если хорошо сбалансировать эластик по индексам, то у постгресса он выиграет, но надо сидеть и настраивать.

у приятеля в компании эластиком делаются отчеты по 14 млрд событий (17 тб данных), всё молниеносно работает

погонять мы можем, но интересно узнать мнение опытных людей

Производительность возросла в 15-20 раз.

а были какие-нибудь проблемы? подводные камни?

ну выше ж написали, запрос расплывчат, уточните

кликхаус и еластик немного про разное все же

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

событий не сказать что прям очень много, но несколько миллионов за месяц набегает

постгрес начинает задыхаться

а были какие-нибудь проблемы? подводные камни?

БД четкая - время-значение, по другому никак: основная колонка обязательно время. Очень он любит память, пришлось размер памяти увеличить в 2 раза, но бережлив к диску. Писать надо большими кусками, только тогда будет профит.

напомню что по КХ есть специальный групчатик

https://t.me/clickhouse_ru

он же официальнй сапорт канал

у тебя htop для красоты типо?

а у тебя?

БД четкая - время-значение, по другому никак: основная колонка обязательно время. Очень он любит память, пришлось размер памяти увеличить в 2 раза, но бережлив к диску. Писать надо большими кусками, только тогда будет профит.

Любит память?

При чтении да

а у тебя?

у меня алерты настроены, а для красоты grafana есть

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

"по сути одна широкая таблица" - распределенная таблица в clickhouse)

хочу спросить, а это щупал кто нибудь?https://github.com/influxdata/telegraf/tree/master/plugins/inputs/docker

хочу спросить, а это щупал кто нибудь?https://github.com/influxdata/telegraf/tree/master/plugins/inputs/docker

Там выше часто обсуждали. Поиск.

извините, спасибо :)

И кажестся еще в DevOps

@freeseacher эт, может стоит шапку сделать с базовыми ссылками? ) А то про КХ применительно к аналитике довольно часто приходят и спрашивают )