и вижу 2 варианта реализации.
#1 делать свой класс, создавать метрику а ля GaugeMetricFamily, и регать в REGISTER. В таком случае метод collect дёргается на каждый scrape
#2 сделать отдельные функции на каждую метрику, дёргать их в фоне каждые N секунд, и обновлять метрики внутри. при этом scrape забирает просто "текущие" метрики
Так вот, вроде как #1 - феншуйный, но... с точки зрения, что scrape может занять долгое время -- мне там в интернет сходить, в базу, в железо или куда угодно, короче это может повиснуть, упасть, выполняться хз сколько. Интуитивно хочется сделать scrape метрик и актуализацию метрик - независимыми асинхронными процессами, и чтобы метрики максимально быстро отдавались в мониторинг.
Вопрос -- где я неправ в рассуждениях, и почему #1 более феншуйный/правильный/удобный вариант? или it depends и т.д.?
я про кейс, когда экспортеру самому нужно собирать и вычислять метрики , а не просто прокси, который "быстро забирает готовое откуда-то"
Лучше выбрать первый вариант, т.к. он проще в использовании конечными пользователями вашей библиотеки для экспорта метрик. Если у вас есть метрики, требующие ресурсоемких вычислений, то специально для них пользователи могут написать дополнительную обвязку для кэширования периодически вычисляемого значения, чтобы при скрейпе просто отдавать значение из кэша. Так сделано в https://godoc.org/github.com/VictoriaMetrics/metrics#NewGauge
ну, если это библиотека - возможно.. но если я сам и есть пользователь, и это не библиотека - а конечный экспортер 😐
Вы являетесь и автором и пользователем этой библиотеки. Т.е. со стороны пользователя (т.е. вас) ничего не меняется - первый вариант легче в использовании. Соответственно, код, использующий эту внутреннюю либу, получится проще, чем во втором варианте
Обсуждают сегодня