генерации примерно 100 в секунду с распределением таймстампа в пределах последних 5 минут (то есть балком заливаю 60k метрик)
стандартная практика - аггрегировать в "http_bucket{...tags, le=[10...]} <count>" теряя в разрешении
предположим я хочу получить максимальное разрешение и возможность гибких выборок потому что пока не знаю какая именно инфа оттуда потребуется
это нормальная практика слать в vm сразу события или оно на такое не расчитано и вообще "плохая практика"? как примерно будет расти потребление памяти и цпу на больших датасетах при условии что диски не проблема? надо ли что-то будет подоптимизировать?
Можно попробовать, но это не совсем нормальная практика для tsdb, в т.ч. и для вм. Лучше складывать показания в гистограммы вроде вот этих - https://medium.com/@valyala/improving-histogram-usability-for-prometheus-and-grafana-bc7e5df0e350 , после чего пушить эти гистограммы в вм с фиксированной частотой вроде 1 раз в 10 секунд. Такие гистограммы позволяют потом смотреть распределение latency на произвольном диапазоне времени с шагом меньше 50% . Например, если latency в пределах от 1 до 10 секунд, то на выходе получим 18 бакетов для следующих диапазонов latency: (1..1.5], (1.5..2], ... (9.5..10]. Это покрывает большинство потребностей при мониторинге.
Обсуждают сегодня