AV
В процессе
Size: a a a
2020 July 01
DR
о, круто
AV
https://github.com/qnikst/prometheus-haskell -- смотреть тут
AV
Форк но PR я даже не хочу пытаться делать, т.к. в течении ближайших месяцев всю либу перепилю, API правда наверное оставлю
AV
Из интересного там нормальный prometheus-metrics-ghc, который не пропускает данные и работает пошустрее
D
@evgrom не попробовал с unliftio?
AV
https://github.com/qnikst/prometheus-haskell/tree/master/prometheus-metrics-ghc
Документация в наличии, а красивые картинки из прода, пока не приделал
Документация в наличии, а красивые картинки из прода, пока не приделал
ЕР
@evgrom не попробовал с unliftio?
Не
AV
И prometheus-client-extra там есть варианты Counter и Gauge для целочисленных значениях полностью на атомиках и без выделения памяти
AV
ещё вариант попробовать руками n потоков запустить
AV
async:mapConcurrently_ workersCount $ \n -> for_ [n*size..(n+1)*size-1] $ \i -> ...
AV
И если ещё не поменял логгер на канал, то поменяй
DR
design goal основной к библиотеке у тебя какой?
AV
Из интересного там нормальный prometheus-metrics-ghc, который не пропускает данные и работает пошустрее
Вот в следующей итерации я хочу добавить гаугу которая выдаёт максимум в окне, у меня такая на сишке для prometheus-metrics-ghc. Я правда понял, что может хотеться не только максимум, но как тут правильно апи делать не понимаю, там всё unboxed.
AV
Мне нужны быстро работающие и не аллоцирующие на каждый чих метрики
AV
+ набор примитивов, которые могут чуть сгладить убогость прометея
AV
У себя я пользуюсь глобальным registry и unsafeRegister поэтому их апи меня более чем устраивает, а то как метрики хранятся и отдаются кажется фиксированы самим дизайном прометея
AV
@catamorphism а тебе от прометея что нужно?
DR
да вот прям сейчас особо ничего, но каждый раз как с ним из хаскеля работал в прошлые разы меня подташнивало
DR
плюс там была проблема с лейблами, но это скорее болячка самого прометея