iS
art of monitoring - устарел, но что-то полезное можно узнать
Size: a a a
2020 August 09
iS
https://www.robustperception.io/ - от создателей прома
iS
ну и блоги всяких графан и графитов
e
not enough memory for processing 52419000 data points across 401 time series with 52419 points in each time series; possible solutions are: reducing the number of matching time series; switching to node with more RAM; increasing -memory.allowedPercent; increasing
не понимаю, почему step=300, когда interval=12h
step query arg (300s)"не понимаю, почему step=300, когда interval=12h
2020 August 10
AS
AS
Ага. Говорит tool agnostic
AN
not enough memory for processing 52419000 data points across 401 time series with 52419 points in each time series; possible solutions are: reducing the number of matching time series; switching to node with more RAM; increasing -memory.allowedPercent; increasing
не понимаю, почему step=300, когда interval=12h
step query arg (300s)"не понимаю, почему step=300, когда interval=12h
степ выставляет графана автоматически от интервала который ты выбрал и разрешения экрана
Wo
Ага. Говорит tool agnostic
AS
ага. спасибо.
#book
#book
AS
ты читал ? норм ?
Wo
не читал. не осуждаю 🙂
e
помогите понять tsdb, точнее prometheus/vm
у меня есть какие-то события. у каждого события есть теги.
условно, пусть мы решили учитывать в некотором городе события "машина сбила пешехода", ну вот несколько тегов:
- цвет машины
- район
- пол водителя
- пол пешехода
нужно иметь возможность посчитать количество событий в каких-то интервалах с определёнными тэгами, например, женщин на красных машинах, сбивших пешеходов на прошлой неделе.
в обычном sql всё понятно - теги в индексируемые поля, select count(*) from xx where ...
я столкнулся с тем, что если для какой-то комбинации тегов нет записи, то берётся предыдущая.
в influxdb это настраивается fill(), а тут как?
или правильно нулевые значения в базу класть для всех «пустых» комбинацией тэгов? или вообще переходить со значений на счётчики? но это усложняет прогу, которая кладёт в базу
или для потенциально разреженных данных лучше вообще обычный sql использовать?
у меня есть какие-то события. у каждого события есть теги.
условно, пусть мы решили учитывать в некотором городе события "машина сбила пешехода", ну вот несколько тегов:
- цвет машины
- район
- пол водителя
- пол пешехода
нужно иметь возможность посчитать количество событий в каких-то интервалах с определёнными тэгами, например, женщин на красных машинах, сбивших пешеходов на прошлой неделе.
в обычном sql всё понятно - теги в индексируемые поля, select count(*) from xx where ...
я столкнулся с тем, что если для какой-то комбинации тегов нет записи, то берётся предыдущая.
в influxdb это настраивается fill(), а тут как?
или правильно нулевые значения в базу класть для всех «пустых» комбинацией тэгов? или вообще переходить со значений на счётчики? но это усложняет прогу, которая кладёт в базу
или для потенциально разреженных данных лучше вообще обычный sql использовать?
МК
Принято считать, что события - это не для tsdb.
Но если этого не знать...
У ВМ есть флаг, который fill инфлюкса не заменит, но ограничит диапазон времени, который заполняется последним значением.
Но если этого не знать...
У ВМ есть флаг, который fill инфлюкса не заменит, но ограничит диапазон времени, который заполняется последним значением.
МК
В любом случае, это от лукавого. Экспортер должен отвечать на вопрос, сколько событий по его сведениям произошло на текущий момент. И таки да, это счетчик.
S
В любом случае, это от лукавого. Экспортер должен отвечать на вопрос, сколько событий по его сведениям произошло на текущий момент. И таки да, это счетчик.
+1
и еще vm/prom не любят высоко кардинальные значения label при подсчете, хотя у VM с эти вроде как сильно получше
и еще vm/prom не любят высоко кардинальные значения label при подсчете, хотя у VM с эти вроде как сильно получше
N
помогите понять tsdb, точнее prometheus/vm
у меня есть какие-то события. у каждого события есть теги.
условно, пусть мы решили учитывать в некотором городе события "машина сбила пешехода", ну вот несколько тегов:
- цвет машины
- район
- пол водителя
- пол пешехода
нужно иметь возможность посчитать количество событий в каких-то интервалах с определёнными тэгами, например, женщин на красных машинах, сбивших пешеходов на прошлой неделе.
в обычном sql всё понятно - теги в индексируемые поля, select count(*) from xx where ...
я столкнулся с тем, что если для какой-то комбинации тегов нет записи, то берётся предыдущая.
в influxdb это настраивается fill(), а тут как?
или правильно нулевые значения в базу класть для всех «пустых» комбинацией тэгов? или вообще переходить со значений на счётчики? но это усложняет прогу, которая кладёт в базу
или для потенциально разреженных данных лучше вообще обычный sql использовать?
у меня есть какие-то события. у каждого события есть теги.
условно, пусть мы решили учитывать в некотором городе события "машина сбила пешехода", ну вот несколько тегов:
- цвет машины
- район
- пол водителя
- пол пешехода
нужно иметь возможность посчитать количество событий в каких-то интервалах с определёнными тэгами, например, женщин на красных машинах, сбивших пешеходов на прошлой неделе.
в обычном sql всё понятно - теги в индексируемые поля, select count(*) from xx where ...
я столкнулся с тем, что если для какой-то комбинации тегов нет записи, то берётся предыдущая.
в influxdb это настраивается fill(), а тут как?
или правильно нулевые значения в базу класть для всех «пустых» комбинацией тэгов? или вообще переходить со значений на счётчики? но это усложняет прогу, которая кладёт в базу
или для потенциально разреженных данных лучше вообще обычный sql использовать?
Звучит больше как аналитика
N
И кликхаус
e
В любом случае, это от лукавого. Экспортер должен отвечать на вопрос, сколько событий по его сведениям произошло на текущий момент. И таки да, это счетчик.
Но это по независимому счётчику на каждую комбинацию тэгов поддерживать?
МК
+1
и еще vm/prom не любят высоко кардинальные значения label при подсчете, хотя у VM с эти вроде как сильно получше
и еще vm/prom не любят высоко кардинальные значения label при подсчете, хотя у VM с эти вроде как сильно получше
Ну вот не понимаю я этого - кардинальность не любят.
Любят они карбинальность и нормально хранят ряды, и нормально их отдают. Не любят они отдавать выборку по большому количеству рядов сразу.
Ну так это касается любой бд, даже реляционной - те с удовольствием и в легкую отдают лярды строк из одной таблицы и не любят декартовы произведения бодьших таблиц.
Любят они карбинальность и нормально хранят ряды, и нормально их отдают. Не любят они отдавать выборку по большому количеству рядов сразу.
Ну так это касается любой бд, даже реляционной - те с удовольствием и в легкую отдают лярды строк из одной таблицы и не любят декартовы произведения бодьших таблиц.