это не не точно, а при операциях сложения умножения и тд происходят огругления. Ошибки накапливаются и в конечном итоге будут расхождения какие-нибудь. Например купил чего-то на 1р, а сняли 1.000000000001, а если таких операций много, то это уже беда.
Да и сравнивать такие числа через == не выйдет будет давать false на 1 == 1.00000000001.
Ну это для понимания ситуации
Чтобы с деньгами работать надо писать свои реализации типа. Не знаю как они выглядят внутри, но например хранит число в строке, а в строку хоть какие числа поместятся

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

чтобы ошибки не было нужно округлять число. можно ограничивать юзверей. запрещать им выставлять цены меньше определенного количества знаков. попробуйте сделать в банке вклад на одну копейку под 1 процент каждый месяц. они вас выгонят и не спросят

а ещё запретить покупать товары, которые дробятся на нечетное количество частей)

каким типом?

Любым, но не знаю поддерживает ли клиент голэнговский это

metric_name [ "{" label_name "=" " label_value " { "," label_name "=" " label_value " } [ "," ] "}" ] value [ timestamp ]

и в какой из них можно положить map - не ясно

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

это охеренная оценка моей деятельности 🙂


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