Телеграмм чат группы metrics

тоесть данные бы хранились дважды. и занимали бы в 2 раза больше места.

01:08пожаловаться #1

что эффективно говорит нам что мы можем сделать не так.
мы можем сделать 2 кластера. каждый из которых будет иметь полный набор данных.
в каждый будет писать прометей. тоесть на каждом проме по 2 remote_write. это будет стоить +60% mem per prometheus

01:10пожаловаться #2

вероятность выхода из строя одной ноды в каждом кластере в один момент времени не высока. пренебрежём ею.

01:11пожаловаться #3

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

01:11пожаловаться #4

ну, нужны 2 кластера и promxy, да. Ну и персистентность дисков, синхронизировать данные между кластерами будет проблематично.

01:14пожаловаться #5

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

01:15пожаловаться #6

Ну нам то такое все равно не актуально, у нас данные в один пром не влазят, так что консолидация маст хэв.

01:15пожаловаться #7

их можно просто забекфилить и всё. и это потребуется только в том случае если даунтайм превысит 2 часа

01:15пожаловаться #8

Denys 💛📈 💫 Zhdanov

Ну нам то такое все равно не актуально, у нас данные в один пром не влазят, так что консолидация маст хэв.

а у меня тоже. мне надо 2 десятка промов

01:15пожаловаться #9

про 28 часов тоже обсудили, 8 - 14 дней надо

01:16пожаловаться #10

ваше право.

01:16пожаловаться #11

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

01:17пожаловаться #12

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

01:18пожаловаться #13

если данных не много то два кластера вм это две виртуалки.

01:19пожаловаться #14

там сверху в тестах на капец жирных тачках было 66 милионов на загрузку в секунду.
разделим на 10 что бы отбросить любой маркетинг.
много тут народу с 6милионами в секунду ?

01:20пожаловаться #15

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

Serge Yuriev in Церковь метрик

01:27пожаловаться #16

Aliaksandr Valialkin

Для анализа трендов хорошо подходит оператор offset. Например, metric offset 1d вернет данные для metric за предыдущий день, но таймстемпы у них будут за текущий день. Это позволяет сравнивать их с текущими данными. Например, график по metric > (metric offset 1d) покажет моменты времени, когда значения metric за текущее время превышали значения сутки назад

Ну собственно именно такие квантили за несколько недель я и хочу считать :)

Roman Khavronenko in Церковь метрик

01:29пожаловаться #17

Denys 💛📈 💫 Zhdanov

а где здесь проблемы с масштабированием?

Serge Yuriev in Церковь метрик

01:40пожаловаться #18

Denys 💛📈 💫 Zhdanov

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

Спасибо, буду изучать

01:52пожаловаться #19

Stas in Церковь метрик

Aleksey Shirokikh

у меня в проде именно так. 2 прома со своими VM, отдельно promxy + grafana. У промов 5 дней retention, и на каждом по alertmanager в кластер (для дедупликации). При падении одного из промов есть доступ к tsdb, есть алерты. t3.large - прометеи+vm (3-4% cpu util), 17K точек в секунду, 0.5М активных ts