AS
ключевая проблема в том, что важен каждый инкремент. будь это счетчик запросов к вебсервису, я бы особо не парился
Сдаётся мне вы считаете базу прома приемлемым местом для хранения информации пригодной для биллинга. Рассмотрите другие варианты
Size: a a a
2019 December 09
A
Сдаётся мне вы считаете базу прома приемлемым местом для хранения информации пригодной для биллинга. Рассмотрите другие варианты
Не, не биллинг, б-же упаси. Просто счетчик ошибок с высокой кардинальностью который редко инкрементится, а приложение часто деплоится
AS
Окей
A
Пока есть только компромиссный вариант в виде дублирования метрик в какой-нибудь централизованный statsd_exporter
A
Но может что получше предложите
AS
У вас точно не event logging?
A
У вас точно не event logging?
На грани
AS
Ну так может таки в очередь а потом в кх?
AS
Ну так в порядке понимания
A
Event logging у нас отдельно реализован, но чуть менее гранулярные метрики будут удобны
A
Были даже идеи из нашего ELK скрейпить, но чет дичь немного
AS
Дичь ага
AS
Но в целом путь прома либо инит каунтеров либо готовность к тому что часть метрик может начаться внезапно
AS
Сами промовцы говорят что если важно возможно таки нужно в евент логгинг
AS
Ибо +- 1 чего либо на очень важно для графика или алерта
A
ну хорошо, а как принято алертинг делать на ивентах?
A
очередь + кх + экспортер?
AS
Никак не принято. Объем велик сканить много. Дорого.
A
Ладно, спасибо, остановлюсь на дублировании в централизованное что-нибудь