его разрабатывают парни из github - это так же достаточно весомый аргумент помоему

"разрабатывают" ? последний коммит Aug 17, 2016 а statsite пилят ребята из hashicorp )

отчет наших тестировщиков звучал примерно так: statsite - по верности результатов агрегирования продержался не намного дольше классического statsd, не смотря на лидерство по производительности. В конце концов так же упирается в один поток цикла обработки событий. brubeck - хорош по производительности, эфективно улилизирует несколько ядер параллельно, и что самое удивительное ВСЕГДА правильно считает значение агрегатов. Начал лажать лишь на запредельных значениях нагрузки. И то только от того, что закончились ресурсы железа: brubeck-у и утилите подающей поток метрик стало тесно на одном сервере. По ощущениям дна у него нет (smile).

Народ зацените, запилил статью на хабре: https://habrahabr.ru/company/avito/blog/335410/

Самое вкусное про clickhouse не рассказали ;) сам в процессе переезда очень интересно узнать с чем столкнулись и как порешали

это во второй статье

я ее только пишу

На данный момент памяти clickhouse требует больше чем на том же объёме метрик go-стек и работает медленнее по части отрисовки, сражаюсь с этим пока

По месту на диске конечно просто сказка 500гб ужались в 50

по отрисовке у него индексы сильно влияют на скорость

И это при использовании sparce файлов

по отрисовке у него индексы сильно влияют на скорость

Ок посмотрю в эту сторону

https://github.com/prometheus/prometheus/releases/2.0.0-beta.1 / 2017-08-11 was tagged

блин, надо URL Encodi'ить еще ссылки, чтобы постились нормально

https://habrastorage.org/web/c14/6ff/080/c146ff080a074023a05e3cb5224191bb.JPG огонь конечно :)

https://github.com/influxdata/kapacitor/releases/v1.3.3 was tagged

Наверное сто раз спрашивали. Буду сто первым. Предположим я для метрик хочу поднять графана + кликхаус. У меня все эти ваши микросервисы на джава. Нагрузка не большая, есть проблемы с местом на дисках (и такое бывает). Хочется собирать метрики по времени откликов api, железные и бизнесовые. Про какие инструменты читать? Кто как в кликхаус метрики кладет?

Наверное сто раз спрашивали. Буду сто первым. Предположим я для метрик хочу поднять графана + кликхаус. У меня все эти ваши микросервисы на джава. Нагрузка не большая, есть проблемы с местом на дисках (и такое бывает). Хочется собирать метрики по времени откликов api, железные и бизнесовые. Про какие инструменты читать? Кто как в кликхаус метрики кладет?

а почему Вы хотите класть метрики именно в КХ? Почему не прометеус?

А зачем выбирать? https://github.com/Percona-Lab/PromHouse

Действительно, с таким ридми это точно хороший продукт, главное понятно для чего он

Действительно, с таким ридми это точно хороший продукт, главное понятно для чего он

У некоторых и такого нет)

К сожалению

Но я правда не понял что это

Это не продукт ещё, потому и README нет. Но после PromCon'а будет

Если кратко, это remote storage для Prometheus 2 поверх ClickHouse

Если кратко, это remote storage для Prometheus 2 поверх ClickHouse

а вы разработчик да ?

видимо да.

хорошая тема.

чот я схему не очень понимаю https://github.com/Percona-Lab/PromHouse/blob/master/storages/clickhouse.go#L32

Я не очень верю в такую схему. Лейблы в виде json текстом - это странно

чот я схему не очень понимаю https://github.com/Percona-Lab/PromHouse/blob/master/storages/clickhouse.go#L32

Там она недоделанная судя по туду

То есть берется имя, инстанс и джоба, а остальные теги дропаются

ну я вот смотрю и не верю

ну я вот смотрю и не верю

Ну недоделанная вещь еще

Доделают - может выйдет что то интересное

1. Такой схемы не будет, конечно. Если посмотрите на код, то поймёте, что там половины нет. :) 2. Не могу обещать, что всё будет – не только от меня и зависит. Но, если интересно, можно подписаться. 3. Раз уж сюда запостил – предлагайте схему. Мой текущий план – GraphiteMergeTree и динамическое создание колонок по частоте лейблов, и json для всего остального. Есть уже такой опыт – предлагайте.

динамическое создание колонок.....

звучит круто

Если лейбл встретился больше, чем X раз, то создать колонку. Или предложить пользователю создать колонку.

а как выглядит процесс эксплуатации ?

переодически поглядываем за _показателем_ и вносим в конфиг информацию о том что нам нужна колонка ?

по перечитыванию конфига получаем решардинг ?

На эти вопросы у меня пока нет ответа

и не совсем понятно формат создаваемого поля с данными

я тестил указание праивльного формата колонки значительно экономит место

там где надо хранить bool не стоит uint64 использовать

1. Такой схемы не будет, конечно. Если посмотрите на код, то поймёте, что там половины нет. :) 2. Не могу обещать, что всё будет – не только от меня и зависит. Но, если интересно, можно подписаться. 3. Раз уж сюда запостил – предлагайте схему. Мой текущий план – GraphiteMergeTree и динамическое создание колонок по частоте лейблов, и json для всего остального. Есть уже такой опыт – предлагайте.

Что будет индексом? Ты не сможешь добавлять колонки в индекс, а без этого graphitemergetree будет схлопывать метрики с разными значениями этих колонок

1. Такой схемы не будет, конечно. Если посмотрите на код, то поймёте, что там половины нет. :) 2. Не могу обещать, что всё будет – не только от меня и зависит. Но, если интересно, можно подписаться. 3. Раз уж сюда запостил – предлагайте схему. Мой текущий план – GraphiteMergeTree и динамическое создание колонок по частоте лейблов, и json для всего остального. Есть уже такой опыт – предлагайте.

AggregatingMergeTree тока, а не GraphtieMergeTree + надо дать возможность людям делать всякие вещи типа replicated + distributed

@alek_si кажется что НЕ надо динамически делать колонки вообще

https://github.com/Percona-Lab/PromHouse/issues

Оставьте замечания там, плиз

@alek_si а почему не так вот? Если ты разработчик

Сейчас я уже не смогу осмысленно ответить, а потом история отматается

Потому что я сейчас на острове посреди ничего :)

Я сейчас понимаю, что смысл в комментариях есть, но по существу уже сложно

Я только issues смог включить с телефона :)

на русском тебе там issues можно оставить или лучше на английском?

на русском тебе там issues можно оставить или лучше на английском?

pishi translitom

Лучше понятно. Если на английском проблем не вызывает, то на английском

Спасибо :)

я думаю, у человека из букинга проблем с английским не будет от слова совсем :))))

Ну я с телефона и глубоко в субботе, делайте скидку :)

я думаю, у человека из букинга проблем с английским не будет от слова совсем :))))

ну на русском всегда проще )

но ок, лучше на английском так на английском

Что будет индексом? Ты не сможешь добавлять колонки в индекс, а без этого graphitemergetree будет схлопывать метрики с разными значениями этих колонок

мне помнится что graphitemergetree вообще не факт что адекватно будет работать с бОльшим количеством колонок, чем он рассчитывает (или если имена их будут иные)

и вот под его задачу надо брать aggregatingmergetree

ERROR: S client not available

@alek_si https://github.com/Percona-Lab/PromHouse/issues/1 что-то такое наверное

На английском коллеги поймут

Спасибо, в понедельник отвечу по-существу

Примерно так, но не совсем

PUTVAL localhost/mean/5seconds interval=60 1502695117.54:0.0361020672187 PUTVAL localhost/max/5seconds interval=60 1502695117.54:0.0361020672187 PUTVAL localhost/q50/5seconds interval=60 1502695117.54:0.0378270149231 PUTVAL localhost/q90/5seconds interval=60 1502695117.54:0.0378270149231 чуваки, это правильный выхлоп для коллектд?

Для exec плагина. Похож.

лан, попытаюсь прикрутить, спасибо

output должен быть unbuffered только

https://collectd.org/wiki/index.php/Plugin:Exec

бля, вот хз, что за буфферы в выхлопе стдауте. ща почитаю, спасибо

Всем привет. Подскажите пожалуйста что можно почитать для выбора системы для сбора статистики. В принципе ничего сложного не надо, но собирать статистику и орать в случае срабатывания триггера - должно уметь. Плюс - графики.. Сейчас пользуюсь zabbix... да, который - говно :) Но там так и не понял есть ли вообще возможность сделать вычисляемый item для уже имеющихся данных и пересчитать его для уже существующих значений согласно новой формулы. Может кто что подсказать? Или я не по адресу? ?

могу посоветовать только prometheus, но в настройке не прост, но зато очень гибок.

да ладно, пром простой очень

Пересчитать вычисляемый айтем для имеющихся данных можно только вручную - прямо в бд

Ну или, как вариант, перезалить эти данные с временнЫми метками

Пересчитать вычисляемый айтем для имеющихся данных можно только вручную - прямо в бд

Эх... это плохо( явно ведь не такая уж и редкая задача думаю... Ну тогда буду думать над тем куда с заббикса уйти)

Вот смотрю я на prometheus, и в принципе он мне нравится, но небольшой вопрос по нему задам. Вот допустим мне надо что бы сработал алёрт если на графике после достижения точки максимума значение упало на N единиц. Это возможно? Или нет? Точка максимума должна быть за последние M минут. Мне не надо само решение, просто возможно или нет :) Хотя и от решения не откажусь :))

Вот смотрю я на prometheus, и в принципе он мне нравится, но небольшой вопрос по нему задам. Вот допустим мне надо что бы сработал алёрт если на графике после достижения точки максимума значение упало на N единиц. Это возможно? Или нет? Точка максимума должна быть за последние M минут. Мне не надо само решение, просто возможно или нет :) Хотя и от решения не откажусь :))

да, возможно

триггер - это тот же запрос.

Понятно, значит завтра буду смотреть на него более внимательно, но я так понимаю в докере его не совсем хорошо будет запускать?

почему нет? том просто выдайте ему

иначе данные потеряете. Это вопрос вкуса

Там просто вроде для обновления(добавления?) консоли надо или перезагрузить приложение или прописать команду в консоли?

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

Только зачем том, можно же просто слинковать папки?

Там просто вроде для обновления(добавления?) консоли надо или перезагрузить приложение или прописать команду в консоли?

консоль рекомендуется делать отдельно. best practice - grafana

но графану подключать придется в том же докер контейнере или она как отдельный фронтенд пойдет?

Ладно, в любом случае спасибо большое, думаю завтра разберусь что да как и запущу на тестовый вариант :)

но графану подключать придется в том же докер контейнере или она как отдельный фронтенд пойдет?

Как бы все уже готово давно https://github.com/vegasbrianc/prometheus

триггер - это тот же запрос.

А можно пример?

да, возможно

Интересно просто, как составить запрос, чтобы он запомнил максимум и потом отнял N едениц