проще говоря: если есть 60 метрик с хоста, но в ТС-базе будет хранится еще и имя хоста то 60 надо умножить на количество хостов, а если еще какие-то мета данные у метрик будут, то и это надо тоже учесть

ииии? я что-то не очень догоняю как это влияет. но допустим около 60

вот так влияет - https://docs.influxdata.com/influxdb/v0.12/guides/hardware_sizing/ (на примере influx-а, но они все сейчас, как правило, держат индекс метрик в памяти). 60 это очень мало, можно не запариваться и брать то что удобнее

Привет. Мы выложили в OpenSource Graphouse - компонент, который позволяет использовать ClickHouse как хранилище метрик для Графита. Graphouse содержит: 1. TCP cервер для приема метрик 2. HTTP API для поиска метрик и получения данных (с питонячим модулем для graphite-web) 3. HTTP API для управления деревом метрик. Лежит тут - https://github.com/yandex/graphouse Доступны deb пакеты. Документацию постепенно дополняем. Будем рады любым замечаниям и предложениям.

@AndreevDm а бенчмарков нет?

@AndreevDm а бенчмарков нет?

В ближайшие пару недель сделаем.

@AndreevDm а расскажите про профит который получили? вообще кликхаус впечатляет скоростью и мощью, давно хотелось его как-то для типовых метрик попробовать

Профит - куда большая производительсноть (особенно на вставку) и эфективное хранение. У нас давно был кластер с виспером, он с трудом справлялся с нагрузкой. (Это было давно и цифры я сейчас не найду). Мы попробовали использовать КХ - и всё что работало на одной нескольких машинок в виспером - прекрастно завелось на одной с кх

@AndreevDm а расскажите про профит который получили? вообще кликхаус впечатляет скоростью и мощью, давно хотелось его как-то для типовых метрик попробовать

Я себе внедрял относительно недавно КХ в качестве бэкнда к графиту вместо виспера (месяца 3 назад). Пока ощутил: 1. В 100 раз упала утилизация дисков (с 50% до 0.5%) 2. Репликация данных из коробки - теперь сервера можно рестартить без потерь 3. Можно делать сложные SQL-запросы к данным графита. Админы себе кучу отчетиков по данным из КХ наклепали

ребят какое железо используете под сбор метрик, а то у меня vm нагибается.. хотя вроде не много записываю.. на запись в 3MB/s печалит как-то

Всмысле у меня идёт на graphite, вот он и кладёт vm по io

поможет ли мне кластеризация, если вывести на физ машины.. O_o

Привет. Мы выложили в OpenSource Graphouse - компонент, который позволяет использовать ClickHouse как хранилище метрик для Графита. Graphouse содержит: 1. TCP cервер для приема метрик 2. HTTP API для поиска метрик и получения данных (с питонячим модулем для graphite-web) 3. HTTP API для управления деревом метрик. Лежит тут - https://github.com/yandex/graphouse Доступны deb пакеты. Документацию постепенно дополняем. Будем рады любым замечаниям и предложениям.

а чем он лучше или хуже того что ломик писал?

@AndreevDm спасибо что поделились кодом, буду следить за репозиторием, и бенчмарки хочется поглядеть

я про это в чатике кликхаусовом уже спрашивал )

@AndreevDm а расскажите про профит который получили? вообще кликхаус впечатляет скоростью и мощью, давно хотелось его как-то для типовых метрик попробовать

4. Ну и производительность на вставку действительно очень крутая. Когда я мигрировал данные из виспера, данные стабильно заливались со скоростью 1.5 млн точек в секунду в течении нескольких часов.

У нас сейчас прилетает порядка 2.5 миллиона метрик в минуту. До недавного времени всё это жило на двух машинках (можно и на одной, но нельзя же без репликик). Сейчас пересилили на другой кластер побольше (просто в целях уменьшения количества кластеров)

4. Ну и производительность на вставку действительно очень крутая. Когда я мигрировал данные из виспера, данные стабильно заливались со скоростью 1.5 млн точек в секунду в течении нескольких часов.

ну я неделю 2.4М писал, но в настоящее, а не прошлое, да

У нас сейчас прилетает порядка 2.5 миллиона метрик в минуту. До недавного времени всё это жило на двух машинках (можно и на одной, но нельзя же без репликик). Сейчас пересилили на другой кластер побольше (просто в целях уменьшения количества кластеров)

виспер держит до 300к в секунду

на 1 машинке слабее чем ваши )

@rlomonosov спасибо за детали, а чем визуализируете? grafana? у кого есть хорошая поддержка ClickHouse в качестве источника данных?

КХ с ломиковской проксей 2.4М в секунду держит. 2.5М в минуту это не серьезно

@rlomonosov спасибо за детали, а чем визуализируете? grafana? у кого есть хорошая поддержка ClickHouse в качестве источника данных?

Графитом

КХ с ломиковской проксей 2.4М в секунду держит. 2.5М в минуту это не серьезно

Ну может у них тоже держит. Можешь потестить

Ну может у них тоже держит. Можешь потестить

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

КХ с ломиковской проксей 2.4М в секунду держит. 2.5М в минуту это не серьезно

Я всего лишь говорю, сколько у нас сейчас. Будем делать бенчмарки конечно померием на более крупных объемах

это ж время опять нужно, а твоя уже работает

Я всего лишь говорю, сколько у нас сейчас. Будем делать бенчмарки конечно померием на более крупных объемах

сделайте сравнение с https://github.com/lomik/carbon-clickhouse и https://github.com/lomik/graphite-clickhouse

это ж время опять нужно, а твоя уже работает

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

и в том числе с точки зрения оверхеда на чтение данных

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

я про объемы. У яндекса очень маленькие графиты были

пару лет назад

сделайте сравнение с https://github.com/lomik/carbon-clickhouse и https://github.com/lomik/graphite-clickhouse

Спасибо, записал

@rlomonosov спасибо за детали, а чем визуализируете? grafana? у кого есть хорошая поддержка ClickHouse в качестве источника данных?

А. Еще redash использую для сложных отчетов по графиту

Ещё немного цифр. В КХ на хранение одной точки уходит где-то 7 байт.

@AndreevDm у меня в тестах на синтетике (данные сгенерированные hagger'ом) было 5.6 байт на точку, на реальных данных (копия куска продакшена) 6.4

это с учетом метаданных всяких там

А сколько уникальных метрик?

смотря как точки хранить

у нас близко к 1 байту получилось

Это в чем так?

CH

Конечно сильно зависит от данных. У нас имена метрик достаточно длинные. Хаггером прогоним, сравним с виспером.

Кстати, а есть какой-нибудь ман, как правильно настраивать виспер и карбон

А сколько уникальных метрик?

сейчас посчитаю... это некоторое время займет

А сколько уникальных метрик?

в мини-копии продакшена мало - 8 млн на сервер

Тоже посчитал сколько байт на точку в КХ - 6.85 получилось

А период метрик какой при этом основной?

Конечно сильно зависит от данных. У нас имена метрик достаточно длинные. Хаггером прогоним, сравним с виспером.

хаггером я генерировал посекундные метрики - то есть 2.4 млн уникальных метрик получалось

А период метрик какой при этом основной?

у нас смешанное - я б сказал неьзя точно определить период

преобладают по 10сек и по 60 секунд

А период метрик какой при этом основной?

30 дней по точке в минуту , что старше - точка в час

@AndreevDm vsmirnov@graphite-2287 0:130 clickhouse-server $ wc -l /etc/clickhouse-server/config.d/graphite.xml 1753 /etc/clickhouse-server/config.d/graphite.xml

У нас в проде в основном минутные

Чат, а кто-то снимает промом метрики раз в секунду?

есть подводные камни?

а 2.4 млн метрик это сколько в объеме на хдд получается?

У меня выборочно для AIX сервера есть, где-то 1500-2000 точек в секунду, подводные камни только одни, если сделать выборку больше чем за 5 минут из influxdb, то influx падает

правда дашбор где-то с десяток графиков содержит, точек много получается, а сервер с influxdb всего с 6ГБ ОЗУ

И сколько под такое кол-во Io выходит?

в среднем ~20 io в секунду, в общем ни очём

@AndreevDm про виспер - лучше всего брать альтернативный стек, а именно github.com/lomik/go-carbon, он даже из коробки достаточно адекватен.

С ним может говорить graphite-web и carbonapi

Там презентации нет, чем он лучше :(

Кстати, а кто-нибудт может расказать делали реализации https://github.com/lomik/graphite-clickhouse ?

@rlomonosov ^

ERROR: S client not available

@rlomonosov собственно вопрос, как реализован поиск по глобам?

@rlomonosov собственно вопрос, как реализован поиск по глобам?

насколько я помню, он раньше делал отдельную табличку

и в нее складывал с глубинами разными

и поиск по ней был

Через отдельную табличку в КХ со списком уникальных метрик. Глоб превращаются в регулярку + пара дополнительных оптимизаций: проверка префикса выносится отдельно и еще че-то такое мелкое

Т.е. на каждый поиск сложного глоба - фулскан по таблице?

Да. По отдельной маленькой replacing

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

А сколько у вас уникальных метрик?

20 млн в табличке

У нас тоже есть Replcaing табличка для списка метрик, но мы дерево метрик в памяти держим. Сначала держали всё, но когда дерево стало под 150млн, сделали загрузку в пямять только первых n уровней, а остальное дерево - on-demand загрузка с кешированием.

Примерно вот так работает andreevdm@graph01gt:~$ time curl -s "http://localhost:7000/search?query=o*.D*.{l,m}*.{r,t}*.*" | wc -l 671 real 0m0.020s user 0m0.008s sys 0m0.000s

Я так хотел сделать, а потом посмотрел что с нашими стандартными запросами и КХ справляется отлично. Сейчас по логам проверил - среднее время запроса на поиск - 14ms. Самая жесть 200мс (количество таких запросов в день можно по пальцам пересчитать).

У нас сейчас в проде таблица с деревом - 200 миллионов. Там конечно уже много неактуаьных метрик, но как раз ondeman загрузка спасает

Мы неактуальное чистим чтобы не отсвечивало в дереве. Но на 200 млн мое решение точно всосет. особенно если запрашивать o*.D*.{l,m}*.{r,t}*.*

https://prometheus.io/blog/2017/04/10/promehteus-20-sneak-peak/

ссусь, но почитаю

TLDR выкатили альфу с необкатанным новым стороджом, расходимся

This version does not work with old storage data and should not replace existing production deployments ну альфа же!

Ivan а не поделитесь как вообще нынче influxdb себя ведет на больших данных в целом? стабильнее чем раньше? проблем много?

у меня версия 1.0 до 1.2 пока не обновил. На больших запросах на 6ГБ падает, какие именно "большие", я не скажу

8 млн точке при 6 ГБ выдавал и не падал, задержка в выдаче - секунды примерно

@rlomonosov а мне кажется или у вас была имплементация ручки render со всеми функциями?

@rlomonosov а мне кажется или у вас была имплементация ручки render со всеми функциями?

У нас была - https://github.com/go-graphite/carbonapi

@rlomonosov а мне кажется или у вас была имплементация ручки render со всеми функциями?

Только то, что кинул @Civiloid

виспер держит до 300к в секунду

Кстати эти цифры hdd или ssd?

Кстати эти цифры hdd или ssd?

ssd

Я пожет пропустил, а для https://github.com/lomik/carbon-clickhouse какие цифры были?

Я пожет пропустил, а для https://github.com/lomik/carbon-clickhouse какие цифры были?

2.4M points/sec

примерно на этом моменте у меня нагрузка от hagger'а перестала пролезать в гигабитную сеть