AS
окей
Size: a a a
2021 June 21
AS
пинг раз в пару секунд
AS
и поехали
AD
Не уверен что я это найду 🙂 А если взять упрощенно "для нас нормально если бОльшая часть реквестов обрабатывается за N времени". Я так понимаю, что "percentile" про это? Мне наверное для первого шага будет достаточно просто понять по каким бакетам у меня реквесты попадают
AS
первый шаг определить на каком месте вы снимаете какой из sli
AD
Вот у меня есть например цифры когда реквест был сделан, и когда он был закончен (для контекста - идентификация клиента, начало процесса и когда он идентифицирован). Сейчас я могу вручную в базе видеть, что клиент А был в идентификации 5 часов, клиент Б 30 минут. Я думал эти данные использовать.
AS
типично avalaibility снимать с балансера по кодам ответов. latency и квалити c приложения ибо там можно разрезать по api endpoint
AS
довольно бесполезные данные честно говоря. особенно если считать что точка съеьма — база. мониторинг поверх базы будет либо сильно отставать либо очень дорогим по колву кверей
AS
вот тут читать для понимания https://sre.google/workbook/implementing-slos/
AS
как мониторить приложение которое всегда отдаёт 200 и в нём код ошибки я так и не понял.
вероятно тогда с балансера можно смотреть только на 502/504
вероятно тогда с балансера можно смотреть только на 502/504
AD
Ну тут у меня ивенты приходят со стороны, и в нем например статусы "идентификация создана/провалена/успешная". И вот во этот момент я могу отправить данные. Но ваще да, у меня у самого мутно, как эти цифры собирать ваще
AD
Спасибо, читаю.
G
prometheus/prometheus tagged: 2.28.0 / 2021-06-21
Link: https://github.com/prometheus/prometheus/releases/tag/v2.28.0
Release notes:
Link: https://github.com/prometheus/prometheus/releases/tag/v2.28.0
Release notes:
* [CHANGE] UI: Make the new experimental PromQL editor the default. [#8925](https://github.com/prometheus/prometheus/pull/8925)More
* [FEATURE] Linode SD: Add Linode service discovery. [#8846](https://github.com/prometheus/prometheus/pull/8846)
* [...
AV
В прометеусе increase может вернуть дробное значение на промежутке с только целыми значениями метрики, как уже заметил Алексей. Если вас такое поведение не устраивает, то можете попробовать victoriametrics - там increase в таком случае возвращает ожидаемое целое значение. См. подробности в https://docs.victoriametrics.com/MetricsQL.html .
AV
Прометеус считает значение range функций с таймстемпом в конце указанного range'а. Например,
increase(requests_total[1d]) вернет количество запросов за последние сутки, но при этом в таймстемпе будут указаны текущие сутки. Отрицательный offset помогает сдвинуть такой таймстемп на сутки назад, чтобы он указывал на начало суток, по которым подсчитана метрика.AV
В общем случае да, но в частном, когда sla фиксирован и не собирается меняться, то достаточно завести два счетчика запросов - один для всех запоосов, второй - для запросов, не уложившихся в sla. По этим счетчикам можно подсчитать процент запросов, не уложившихся в sla, на любом интервале времени.
2021 June 22
AD
А я правильно понимаю, что если обработка запроса (читай - инкремент и декремент gauge) происходит быстрее, чем scrape, то эти данные просто пропадут?
AD
Т.е. scrape интервал - 15 секунд, а инкремент и декремент gauge за 5 секунд, ровно в этом окошке пятнадцатисекундном.
AS
поэтому надо воздерживаться от использования gauge
AD
Да, я уже заменил его на каунтер, это я скорее проверить, правильно ли я понял проблему 🙂