Здесь нашел

https://groups.google.com/forum/#!topic/prometheus-users/wDY7wimGZl4

таки завезли, но в доке нет curl -v -XPOST 'http://localhost:9090/api/v2/admin/tsdb/delete_series' --data '{"matchers": [{ "instance":"$node_name"}]}'

2 версия Прометея?

2 версия Прометея?

да

https://gnocchi.xyz кто смотрел?

Канонически, графит из чего задумывался? Протокол + карбон сторадж?

http api на чтение, протокол на запись, хранилка в whisper. В принципе все это модульное и в рамках разумного заменяемое

gnocchi довольно жестко завязан на ceph (с возможностью заменить на некоторые альтернативные штуки)

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

gnocchi довольно жестко завязан на ceph (с возможностью заменить на некоторые альтернативные штуки)

А написано Ceph/S3/Redis/Swift

в принципе да, но ceph recommended там

типа на s3 все будет тухло работать, понятно

@kireevco оно очень вероятно на запись будет нормально работать и на с3 и на цефе, но на чтение плохо

просто потому что оно вероятно пишет жирные блобы

либо выйдет очень дорого) если худые)

на с3 то само собой

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

в родном carbon'е

читаю, везде пишут про consistent hash или rule based

то есть пишем в carbon cache а он отправляет в carbon storage, активно пуша данные в разные места...

типа как influx relay работает выходит...

Графана же сама читать не умеет? АГрегировать данные из двух прометеусов не возможно?

@kireevco в родном стеке - carbon-relay делает балансировку и всякое такое

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

резервирование методом двойной записи и ручной синхронизации через rsync + whisper-fill

carbon-cache он кэширует и пишет на диск сразу

@kireevco в родном стеке - carbon-relay делает балансировку и всякое такое

Как это по ощущениям работает? Это стабильно, вообще? из минусов eventual consistency видится

Как это по ощущениям работает? Это стабильно, вообще? из минусов eventual consistency видится

минусов два

во первых представь себе два клиента пишут в два разных relay'а (смотрящих на 1 сторадж, например разные в ДЦ) тчоку с одним именем, одним тс, но разным value

в graphite'е - last write wins

Да, понятно.

релей в ДЦ1 отправит ее в сторадж ДЦ1 и ДЦ2

до ДЦ2 она скорее медленее дойдет

возможна такая ситуация когда точка из ДЦ1 запишется в ДЦ2, а в ДЦ1 окажется точка из ДЦ2 )

Чтение, соответственно тоже. Понятно

в оригинальном стеке короче все плохо с этим

с чтением - кто первый ответил тот и прав

в оригинальном стеке короче все плохо с этим

Пили быстрее свой релей

Пили быстрее свой релей

вопрос не в релее. В принципе концепция такая

@kireevco в общем у нас свои костыли есть поверх этого дела. Например демон который броадкастит запросы по стораджам и склеивает ответы

сам consistent hash в релее оригинальном отвратного качества

поэтому в carbon-c-relay'е есть jump hash, который очень хорошее распределение дает

По факту нужна какая-то Умная прокся которая будет слать клиента туда где данные актуальные

По факту нужна какая-то Умная прокся которая будет слать клиента туда где данные актуальные

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

так как у тебя нет control plane'а, то нет сущности которая знает что актуально, а что нет

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

Сложный вопрос

так как у тебя нет control plane'а, то нет сущности которая знает что актуально, а что нет

Именно

@p8sih именно под мониторинг такие гарантии (никаких) отлично работают на самом деле

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

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

Фин сектор?

Фин сектор?

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

Не думаю что там это тоже некритично

@p8sih под фин сектор совсем свои требования. Я бы сказал там и float64 как точка тоже не очень

Интересно что там

Какие нить суровые оракла

https://blogs.oracle.com/utilities/need-to-track-hundreds-of-billions-of-data-points-these-opower-engineers-open-source-software-can-help - LOL

2014 год правда

но думается фин сектор прам в оракл и пишет

и только деньги мешками докидывает за лицензии

PROFIT

@kireevco в общем у нас свои костыли есть поверх этого дела. Например демон который броадкастит запросы по стораджам и склеивает ответы

Ну сейчас и оригинальный так умеет. Но там все таки пытчон, а тут - провославный Го. ?

Ну сейчас и оригинальный так умеет. Но там все таки пытчон, а тут - провославный Го. ?

а да, забываю-с )

но думается фин сектор прам в оракл и пишет

ак был же стеб про хранение временных рядов постами в wordpress

Ребят, поясните мне как работает роллап в кликхаусе

Из него же данные не удалаются? Накой тогда вообще роллап нужет там?

Ну не то чтобы не удаляются вообще

Дропай партиции и все

ERROR: S client not available

не это понятно

я дропаю партиции

например за ноябрь

роллапы тоже уйдут в небытие?

Из него же данные не удалаются? Накой тогда вообще роллап нужет там?

Во время мержа файликов он смотрит нужно ли что то пороллапить и роллапит если нужно (если речь про GraphiteMergeTree).

Да про него

Дропаешь партиции - все что в партиции теряется. Если aggregating merge tree то в нем также агрегации делаются при мерже

но все же удаляя партицию за ноябрь я получается удаляю данные, и за ноябрь роллапных данных не увижу?

но все же удаляя партицию за ноябрь я получается удаляю данные, и за ноябрь роллапных данных не увижу?

Да.

гм

Роллапы будут когда мерж процесс до них дойдет

Если дойдет

Поэтому они по времени не детерминированы и в общем случаи негарантированы

подскажите, почему может быть такое поведение у grafana что при выставленном single mode в Hover tooltip на плагине graph, при наведении на одном графике только выделенное значение показывается а на соседнем начинают отражаться все

подскажите, почему может быть такое поведение у grafana что при выставленном single mode в Hover tooltip на плагине graph, при наведении на одном графике только выделенное значение показывается а на соседнем начинают отражаться все

Выставлено для графика мульти?

я так понимаю там 2 режима - all series и single, при обоих выставленных single возникает ситуация описанная выше

Да.

Это точно так? В чём тогда сакральный смысл роллапов в GraphiteMergeTree, если они дропаются вместе с партициями? Чем они тогда лучше materialized views?

Это точно так? В чём тогда сакральный смысл роллапов в GraphiteMergeTree, если они дропаются вместе с партициями? Чем они тогда лучше materialized views?

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

Это точно так? В чём тогда сакральный смысл роллапов в GraphiteMergeTree, если они дропаются вместе с партициями? Чем они тогда лучше materialized views?

Проще работать с ними.

Они делают не стейт, а чиселку

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

Что тут непонятного? Огрубление данных в роллапах - для экономии места, чтобы можно было дольше хранить. Но при этом дроп партиции удаляет и огрублённые данные за этот месяц. Странно как-то... Где тут логика?

Что тут непонятного? Огрубление данных в роллапах - для экономии места, чтобы можно было дольше хранить. Но при этом дроп партиции удаляет и огрублённые данные за этот месяц. Странно как-то... Где тут логика?

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

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

Да, тормознул похоже. С обычным MergeTree попутал. В случае GraphiteMergeTree детальные данные ограничены во времени и не распухают, а мигрируют в огрублённые. Тогда ОК.

Что тут непонятного? Огрубление данных в роллапах - для экономии места, чтобы можно было дольше хранить. Но при этом дроп партиции удаляет и огрублённые данные за этот месяц. Странно как-то... Где тут логика?

дроп не огрубляет (ну или огрубляет до несуществования :D )

мерж это фоновый процесс слияния кусков

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

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

точнее optimize final должен помочь

точнее optimize final должен помочь

Он дорогой очень по месту

Он дорогой очень по месту

и по цпу тоже

ЦПУ бесконечен место реже...

Он дорогой очень по месту

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