Остальное скорее надо но никто не пользуется

У меня просто скоро ещё большие изменения в зиппере поспеют

https://github.com/go-graphite/carbonzipper/commits/grpcNew

У меня просто скоро ещё большие изменения в зиппере поспеют

Он научиться работать с graphite-clickhouse?

Он научиться работать с graphite-clickhouse?

должен и так работать. Если не работает - это бага и ее надо фиксить (либо в graphite-clickhouse либо в зиппере)

а, или ты про балансировку. Если про нее то да, должен появится round robin :)

про балансировку

я вообще пока haproxy обхожусь

но хотелось бы чегно то более нативного

А в чем проблема с балансировкой в graphite-clickhouse и зиппере?

А в чем проблема с балансировкой в graphite-clickhouse и зиппере?

Кликхаусу нужен round robin

Или указывать только 1 сервер

И ему нужно всегда слать запрос как есть

С глобами

А го карбону надо запрос делить на более мелкие запросы

И слать броадкастом

А, зиппер не умеет слать глобы

Ну нельзя по факту смешивать

А, зиппер не умеет слать глобы

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

так вроде параметр "sendGlobsAsIs" делает вещи... или что то не так?

так вроде параметр "sendGlobsAsIs" делает вещи... или что то не так?

Глобально для всех.

2 карбонапи пока решают вопрос :)

2 карбонапи пока решают вопрос :)

Ну нам такое не катит

https://github.com/prometheus/prometheus/releases/tag/2.1.0 / 2018-01-19

wat

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

constantLine($variable) от графита не работает. constantLine(5) - работает

подскажите кто carbon+ clickhouse использует, партицирование по дням в релизах CH не появилось?

подскажите кто carbon+ clickhouse использует, партицирование по дням в релизах CH не появилось?

есть эксперементальное

под флагом

уже месяца 3 как (с 310 релиза)

Alexander https://github.com/yandex/ClickHouse/blob/fb9c7ab81d3d208b0585080e2288fccf0a768ec3/dbms/tests/queries/0_stateless/00502_custom_partitioning_local.sql

Да вот хотелось бы не эксперементал а чтобы в основном релизе было

что быть болеее менее уверенным что оно потом будет работать после апдейтов

и еще интерсно как это на перформанс влияет

Да вот хотелось бы не эксперементал а чтобы в основном релизе было

оно в релизе, просто надо включать

флагом

в момент запуска

или выполнения запроса

хм

а есть где еще про партицирование в CH почитать ?

Хотя это наверное в Церковь CH вопрос

Ну вобщем тут неплохо написано https://clickhouse.yandex/docs/ru/table_engines/custom_partitioning_key.html

Еще интересный вопрос - не слишком ли мелким окажется партицирование по дням?

А какую ты цель преследуешь, делая партиционирование по дням? Я могу придумать только одну - хочется хранить мало дней и дропать все что старше

да - примерно так - хочется хранить фиксированное количество дней

но вообще я вот щас сижу и думаю

можно ли сделать партицирование по части префикса

по его части

чтобы можно было например часть метрик удалить

там ведь есть Partitioned by String

правда это не очень подойдет, хотелось бы какую то функцию от string

правда это не очень подойдет, хотелось бы какую то функцию от string

Хэш

И остатки от деления

Или смирись и не удаляй

просто брать хеш от строки не комильфо

потому что строка полный путь к метрике

ERROR: S client not available

а нужно взять скажем ее 3 части с точками

prod.servers.servername.metrix

а нужно взять скажем ее 3 части с точками

Так тоже можно

и получить их этой строки например первые 2 компоненты

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

можно будет например хрохнуть целое поддерево метрик не потеряв историю по другим

arrayStringConcat(arraySlice(splitByChar('.', name), 0, 3), '.')

да как то так

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

Зависит от количества таких разбиений - в доке до нескольких тысяч вроде как норм

вставка деградирует практически линейно от количества партиций на блок данных. покрайней мере у меня так было когда я переливал висперы в кх

Ну и есть шанс что КХ вообще перестанет успевать это все мерджить

Вообще я не очень понимаю боль с удалением конкретных метрик. Мне пару раз приходилось скрывать метрики из дерева (когда набрасывали несколько десятков миллионов новых ошибочных метрик), но сами данные удалять ниразу не понадобилось - они весят какие-то копейки и не отсвечивают

Ок, допустим, до каких объемов таблицы с CH работают относительно быстро?

И как кстати скрывать метрики?

Вообще я не очень понимаю боль с удалением конкретных метрик. Мне пару раз приходилось скрывать метрики из дерева (когда набрасывали несколько десятков миллионов новых ошибочных метрик), но сами данные удалять ниразу не понадобилось - они весят какие-то копейки и не отсвечивают

Есть же проблема с тем когда эти метрики не удалены/скрыты и большой запрос ch их все равно поднимет с диска, и может уже сожрать все cpu или память или не уложиться в лимиты

И как кстати скрывать метрики?

Заинсертить в таблицу graphite_tree тоже самое, но с флагом Deleted=1. Или переименовать табличку, создать новую и заинсертить в нее из старой все кроме ненужного

Есть же проблема с тем когда эти метрики не удалены/скрыты и большой запрос ch их все равно поднимет с диска, и может уже сожрать все cpu или память или не уложиться в лимиты

Это если ручками селектить по табличке с точками? graphite-clickhouse в запрос явно передает where path in (...) и скрытые метрики в него попасть не могут

Это если ручками селектить по табличке с точками? graphite-clickhouse в запрос явно передает where path in (...) и скрытые метрики в него попасть не могут

Для этого их нужно скрыть сначала )

Да, но скрыть можно и без какого либо кастомного партиционирования. Я выше описал как

Есть еще способ "скрытия". В конфиге carbon-clickhouse поменять значение параметра tree-date на новую дату (с новым месяцем). Он начнет инсертить в нее. Потом с помощью insert from select в эту дату скопировать все кроме удаляемого. И грохнуть партицию со старой датой

гм звучит как описание тулы

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

Будет работать с новым

а, или ты про балансировку. Если про нее то да, должен появится round robin :)

Я вот подумал - было бы круто еще failover иметь, сходил на бекэнд - если точек не приехало идешь на другой и.д. пока бекэнеды не закончаться

А разве вхождение узла в кворум не определяется через zk и в случае разделения запросы не перестают обслуживаться?

Я вот подумал - было бы круто еще failover иметь, сходил на бекэнд - если точек не приехало идешь на другой и.д. пока бекэнеды не закончаться

https://github.com/go-graphite/carbonzipper/blob/grpcNew/zipper/protobuf_group.go#L154-L179

https://github.com/go-graphite/carbonzipper/blob/grpcNew/zipper/protobuf_group.go#L154-L179

https://play.golang.org/p/QkN_j64Km-9