хм

посмотрю

спасибо

Ок, попробую из кх это выцепить

А для чего это нужно?

А для чего это нужно?

Кейс когда после обновления приложения в graphite начинают лететь уникальные метрики по id запроса например - их нужно найти и порезать на релее + вычистить из бд

И как в этом помогают логи новых метрик? Мониторится что логи выросли?

go-carbon же отдаёт количество новых метрик на это аларм если резкий всплеск и он сохраняется, дальше уже иду в лог новых метрик

понятно. ну прям точно так же не получится. надо селектить все это из КХ

@rlomonosov ты ж ведешь список метрик которые есть в КХ

в graphite_tree табличке

ты разве не решаешь периодически что туда что-то надо докидывать?

Этот кэш сбрасывается каждый рестарт и по hup-у. После сброса все метрики станут "новыми". Я бы не стал его использовать для мониторинга

Лучше поставить в крон запрос select count() from graphite_tree group by path having argMax(Deleted, Version) == 0 и его результат слать в графит как отдельную метрику. И уже на ее резкий рост реагировать

Этот кэш сбрасывается каждый рестарт и по hup-у. После сброса все метрики станут "новыми". Я бы не стал его использовать для мониторинга

Может сделать это не кэшом?

а по hup'у подменять на результаты селекта из таблицы

Мне наоборот нужно чтобы оно сбрасывалось. Мы его раз в сутки сбрасываем и все метрики пишутся в табличку graphite tree с новым version. Потом мы по этому version находим старые и неактуальные метрики

Мне наоборот нужно чтобы оно сбрасывалось. Мы его раз в сутки сбрасываем и все метрики пишутся в табличку graphite tree с новым version. Потом мы по этому version находим старые и неактуальные метрики

мы просто эту проблему с другой стороны решаем у себя )

задача удалять неиспользуемые метрики тоже есть в whisper все просто find /var/lib/graphite/whisper -type f -mtime +7 -delete , а в кх как решаете @rlomonosov можешь чуть подробнее про version ?

задача удалять неиспользуемые метрики тоже есть в whisper все просто find /var/lib/graphite/whisper -type f -mtime +7 -delete , а в кх как решаете @rlomonosov можешь чуть подробнее про version ?

Табличка graphite_tree работает на движке ReplacingMergeTree. При мердже из нескольких записей с одинаковым значением Primary Key остается одна (с максимальным значением поля Version) carbon-ch кэширует в памяти список метрик чтобы поменьше писать в graphite_tree. Если метрики еще нет в кэше, то она пишется в graphite_tree с текущим временем (временем получения точки) и добавляет в кэш. Кэш сбрасывается каждый раз при рестарте или сигналом USR1 (ранее в чатике соврал про HUP, на самом деле USR1). Мы у себя раз в сутки шлем всем carbon-ch сигнал USR1. В результате в поле Version в табличке graphite_tree у нас лежит mtime с точностью до суток. Все старые метрики можно заселектить запросом вида SELECT Path, Version FROM graphite_tree GROUP BY Path HAVING max(Version) < таймстемп; А удалить заинсертив их опять в табличку graphite_tree с Deleted = 1 и большим значением Version

спасибо, попробую сделать также

сейчас сравниваю производительность стека carbonapi -> go-carbon(carbonserver) -> whisper и carbonapi -> graphite-ch -> ch и как то пока по времени ответа на один и тот же запрос ch медленне раза в 3 из опций в carbonapi sendGlobsAsIs: true в ch <max_query_size>10485760</max_query_size> больше не меня ничего пока

диск ssd

trigram-index в go-carbon отключен

когда я тестил, то у меня ch был медленнее в два раза. я забил, т.к. это с лихвой компенсировалось скоростью записи и уменьшенной в 100 раз нагрузкой на диск

с нашим потоком метрик 3.5К/s видимо пока рано думать о переходе на ch ) утилизация диска в районе 15% await 3-4ms в пиках то 10К iops на запись. не хотелось бы жертвовать временем отрисовки графиков

можешь еще попробовать яндексовский graphouse. может он быстрее

Там упирается в сам ch по CPU в основном, скорее всего можно подтюнить его

поковырял и разогнал стек carbonapi -> graphite-ch -> ch теперь ch даже быстрее на тяжелых запросах )

carbonapi - maxBatchSize: 100000 в ch <use_uncompressed_cache>1</use_uncompressed_cache>

кстати в graphite-ch в логах можно много интересного найти. особенно если уровень debug включить. там должны быть времена запросов, сортировок и тд

Боты

Сраные

продолжаю разбираться метриками graphite в ch - из доки ch понятно что метрики хранятся полные а достаются в зависимости от движка таблицы (MergeTree или GraphiteMergeTree) без прореживания или с прореживанием, по доке carbon-ch создал GraphiteMergeTree - значит с прореживанием, но что это значит? в graphite ранее использовался файл storage-aggregation.conf - с описанием как агрегировать разные типы метрик - а в ch он не нужен получается совсем? как это работает?

продолжаю разбираться метриками graphite в ch - из доки ch понятно что метрики хранятся полные а достаются в зависимости от движка таблицы (MergeTree или GraphiteMergeTree) без прореживания или с прореживанием, по доке carbon-ch создал GraphiteMergeTree - значит с прореживанием, но что это значит? в graphite ранее использовался файл storage-aggregation.conf - с описанием как агрегировать разные типы метрик - а в ch он не нужен получается совсем? как это работает?

в конфиге указываешь все то же самое

в другом формате

т.е. если у меня в конфиге [min] pattern = \.min$ xFilesFactor = 0.1 aggregationMethod = min [max] pattern = \.max$ xFilesFactor = 0.1 aggregationMethod = max [count] pattern = \.count$ xFilesFactor = 0 aggregationMethod = sum [lower] pattern = \.lower(_\d+)?$ xFilesFactor = 0.1 aggregationMethod = min [upper] pattern = \.upper(_\d+)?$ xFilesFactor = 0.1 aggregationMethod = max [sum] pattern = \.sum$ xFilesFactor = 0 aggregationMethod = sum

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

не очень понятно retention правила из default применяться для pattern если его пропустить

Джентельмены Как в BOSUN завести хост вручную?

Не хочу через него передавать метрики

т.е. если у меня в конфиге [min] pattern = \.min$ xFilesFactor = 0.1 aggregationMethod = min [max] pattern = \.max$ xFilesFactor = 0.1 aggregationMethod = max [count] pattern = \.count$ xFilesFactor = 0 aggregationMethod = sum [lower] pattern = \.lower(_\d+)?$ xFilesFactor = 0.1 aggregationMethod = min [upper] pattern = \.upper(_\d+)?$ xFilesFactor = 0.1 aggregationMethod = max [sum] pattern = \.sum$ xFilesFactor = 0 aggregationMethod = sum

вроде разобрался, но остались непонятнки все же если метрика будет попадать под 2 и более паттерна, например ^.*\.ten_second\..*\.min$ и \.min$ правила retention - у них разные. Имеет ли значение порядок указания в конфиге, т.е. что первое то и будет работать или может будет искать по более полному соответствию? @rlomonosov как это в graphite-ch реализовано ?

вроде разобрался, но остались непонятнки все же если метрика будет попадать под 2 и более паттерна, например ^.*\.ten_second\..*\.min$ и \.min$ правила retention - у них разные. Имеет ли значение порядок указания в конфиге, т.е. что первое то и будет работать или может будет искать по более полному соответствию? @rlomonosov как это в graphite-ch реализовано ?

В graphite-ch будет использовано первое найденное. В самом кх наверно так же, но точно не знаю

вроде разобрался, но остались непонятнки все же если метрика будет попадать под 2 и более паттерна, например ^.*\.ten_second\..*\.min$ и \.min$ правила retention - у них разные. Имеет ли значение порядок указания в конфиге, т.е. что первое то и будет работать или может будет искать по более полному соответствию? @rlomonosov как это в graphite-ch реализовано ?

Как и все - первый сверху сматченный

В graphite-ch будет использовано первое найденное. В самом кх наверно так же, но точно не знаю

Я к тому что конфиг парсится сверху вниз и порядок имеет значение, или все pattern парсятся в массив и поиск идёт по первому совпавшему т.е. это совсем необязательно может быть 1 элемент в конфиге.

Я к тому что конфиг парсится сверху вниз и порядок имеет значение, или все pattern парсятся в массив и поиск идёт по первому совпавшему т.е. это совсем необязательно может быть 1 элемент в конфиге.

Порядок имеет значение

Спасибо

Парни никто шардирование в clickhouse не использует? В доке яши сказано: "Как и ожидалось, более-менее долгие запросы работают в несколько раз быстрее, если их выполнять на трёх серверах, а не на одном. "

там пример на 166 млн строк - отработал за ~0.26сек - помоему вполне внушительный результат

я так понимаю шардирование - путь к успеху =)

Парни никто шардирование в clickhouse не использует? В доке яши сказано: "Как и ожидалось, более-менее долгие запросы работают в несколько раз быстрее, если их выполнять на трёх серверах, а не на одном. "

+1 К вопросу, я верно понимаю, что шардирование настраивается по этому мануалу? https://clickhouse.yandex/docs/ru/table_engines/replication.html

нет, в указанной тобой доке написано: Репликация никак не связана с шардированием.

я смотрю вот тут: https://habrahabr.ru/company/yandex/blog/303282/ Как установить ClickHouse на кластер из нескольких серверов

По кх есть отдельная группа

Там возможно расскажут быстрее

@clickhouse_ru

+1 К вопросу, я верно понимаю, что шардирование настраивается по этому мануалу? https://clickhouse.yandex/docs/ru/table_engines/replication.html

шардирование там касается только distributed таблиц

ты в конфиге определяешь кластер (с репликами, если надо)

создаешь на каждой машине просто *MergeTree таблицы, потом поверх них натягиваешь Distributed (с указанием какой кластер брать)

Слышал, что записть в Distributed таблицы значительно медленнее

Слышал, что записть в Distributed таблицы значительно медленнее

в мануалах пишут, что лучше писать в обычную таблицу что бы после уже шла синхронизация реплик, а читать уже через Distributed, я верно понимаю. что если реплики строятся по принцепу RAID 1 то и Distributed таблица не нужна?

ну так оно и понятно

в мануалах пишут, что лучше писать в обычную таблицу что бы после уже шла синхронизация реплик, а читать уже через Distributed, я верно понимаю. что если реплики строятся по принцепу RAID 1 то и Distributed таблица не нужна?

Дистрибьютед только лишь виртуальная таблица поверх 1 или более обычных на разных серверах

о мне ответили

ERROR: S client not available

vladimir kolobaev, [24.07.17 10:04] Всем привет! Пытаюсь разобраться с шардированием, и возникла пара вопросов: 1. "Distributed-таблицы" надо создавать для каждой локальной таблици отдельно, или можо создать одну "Distributed-таблицу" на все локальные. 2. Нужно ли менять в настройках приложения, которое пишет в КХ, локальную таблицу на "Distributed-таблицу" 3. Нужно ли менять в настройках приложения, которое ходит в КХ за данными, локальную таблицу на "Distributed-таблицу" Roman Khavronenko, [24.07.17 10:09] [In reply to vladimir kolobaev] Привет! 1. Для каждой таблицы отдельно 2. Если Вы хотите, чтобы данные распределялись по кластеру - пишите в Distributed таблицу. Или самостоятельно выбирайте нужный шард и пишите в его локальную таблицу 3. Если Вы хотите получать данные со всех шард - да

мне нравится такой вариант: 1. carbon-c-relay -> пишем сразу во все ноды в локальные таблици в carbon-clickhouse 2. graphite-clickhouse -> читаем из Distributed-таблиц сразу со всех нод

и зукипером поддерживаем репликацию, между нодами

напишите, что-ли, статью на хабре как графит на кликхаусе запустить. С этим шардами, репликами настройками в XML(!!!) ничё не понятно .

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

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

О.о

Шардирование - это замечательно. Но я так и не понимаю как народ живет с графитом с шардированием без перешардирования и возможности удаления старых данных, вот хоть убей. В доках сказано что можно добавлять новые шарды с большим весом и "закрывать" старые ставя им минимальный вес (ну, если новому шарду дать вес 1000000000 а старому 1, то на 1 Гб даных в новый шард в старый будет попадать всего 1Мб) - но это же жестокий ручной "костыль".

Шардирование - это замечательно. Но я так и не понимаю как народ живет с графитом с шардированием без перешардирования и возможности удаления старых данных, вот хоть убей. В доках сказано что можно добавлять новые шарды с большим весом и "закрывать" старые ставя им минимальный вес (ну, если новому шарду дать вес 1000000000 а старому 1, то на 1 Гб даных в новый шард в старый будет попадать всего 1Мб) - но это же жестокий ручной "костыль".

минимальный вес 0

что значит "не писать никогда"

при этом для чтения он останется доступным

А, значит шард можно запечатать полностью. Ну ОК. Но все одно это какой то дремучий пиздец из прошлого века и антипаттерн. А ручное добавление северов и шардов, в 20матьего17 году?

Меньше магии - лучше, имхо

А, значит шард можно запечатать полностью. Ну ОК. Но все одно это какой то дремучий пиздец из прошлого века и антипаттерн. А ручное добавление северов и шардов, в 20матьего17 году?

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

А, значит шард можно запечатать полностью. Ну ОК. Но все одно это какой то дремучий пиздец из прошлого века и антипаттерн. А ручное добавление северов и шардов, в 20матьего17 году?

https://clickhouse.yandex/docs/en/single/index.html#document-table_engines/resharding

@Civiloid А вы у себя уже перешли на Кликхаус?

@Civiloid А вы у себя уже перешли на Кликхаус?

нет, даже не начали :)

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

но не более

вот и я не спешу. а то, что получается, я зря сервера с 10 SSD-шками в RAID0 заказывал

кстати, никто не пробовал zfs в качестве файлухи к графиту?

кстати, никто не пробовал zfs в качестве файлухи к графиту?

мы в какой-то момент пробовали как эксперимент, но не было особо времени потюнить zfs. Поэтому не взлетело

в смысле что хочется же получить тогда сжатие

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

Я все хочу попробовать, но в клауде нашем это не просто, а на железе мы новых серверов не развертываем :)

а без него разницы с ext4 нет практически никакой

Я пробовал btrfs со сжанием - всё очень хуёво

Я пробовал btrfs со сжанием - всё очень хуёво

аналогичный опыт, да )

А смысл zfs без сжатия для графита ? Зфс сам по себе медленнее, что xfs что ext4

Особенно заметно на hdd что для графита не очень актуально конечно

@AlexAkulov мы тыкали в btrfs помоему на ядре 4.9, у нас просто каждый день ядро в себя уходило