AS
А промитей умеет в меньше секунды?
Разрабы говорят да но не стоит
Size: a a a
2020 January 01
AS
А что такое поймать?
AL
А что такое поймать?
Просто лаба)
Еще не придумал
Еще не придумал
AL
Хотя рестарт какого нибудь нджинска как пример
G
Можно монитом такое сообщение отпралять
AS
Рестарт нжинкса будет видно по смене пида
G
Если есть такой таск
RK
если приложение знает о своей недоступности(таймауты на конекшенах, не 200 ск), то оно может и экспортить соответствующую метрику (счетчик), который будет аккумулировать все ошибки.
аналогично можно экспортить метрики с клиентов этого приложения, если вы контролируете их.
В случае с прометеусом всегда нужно помнить, что скрейпы происходят в случайное время и соответственно проектировать мониторинг. Например, у вас есть рейтлимитинг и вы хотите знать когда он срабатывает. Обычная метрика по кол-ву запросов может не показать этого, т.к. неизвестно когда прометеус соберет эти данные. Поэтому лучше в самом приложение записывать случаи срабатывания лимитера в отдельный счетчик и эксопртить еще и его.
Можно еще использовать https://github.com/netdata/netdata и писать в ремоут какой-то.
аналогично можно экспортить метрики с клиентов этого приложения, если вы контролируете их.
В случае с прометеусом всегда нужно помнить, что скрейпы происходят в случайное время и соответственно проектировать мониторинг. Например, у вас есть рейтлимитинг и вы хотите знать когда он срабатывает. Обычная метрика по кол-ву запросов может не показать этого, т.к. неизвестно когда прометеус соберет эти данные. Поэтому лучше в самом приложение записывать случаи срабатывания лимитера в отдельный счетчик и эксопртить еще и его.
Можно еще использовать https://github.com/netdata/netdata и писать в ремоут какой-то.
AS
Ещё это будет видно на блекбоксе если повезёт или не будет видно вовсе. Возможно такой рестарт и не надо видеть если он не аффектит юзеров
AS
если приложение знает о своей недоступности(таймауты на конекшенах, не 200 ск), то оно может и экспортить соответствующую метрику (счетчик), который будет аккумулировать все ошибки.
аналогично можно экспортить метрики с клиентов этого приложения, если вы контролируете их.
В случае с прометеусом всегда нужно помнить, что скрейпы происходят в случайное время и соответственно проектировать мониторинг. Например, у вас есть рейтлимитинг и вы хотите знать когда он срабатывает. Обычная метрика по кол-ву запросов может не показать этого, т.к. неизвестно когда прометеус соберет эти данные. Поэтому лучше в самом приложение записывать случаи срабатывания лимитера в отдельный счетчик и эксопртить еще и его.
Можно еще использовать https://github.com/netdata/netdata и писать в ремоут какой-то.
аналогично можно экспортить метрики с клиентов этого приложения, если вы контролируете их.
В случае с прометеусом всегда нужно помнить, что скрейпы происходят в случайное время и соответственно проектировать мониторинг. Например, у вас есть рейтлимитинг и вы хотите знать когда он срабатывает. Обычная метрика по кол-ву запросов может не показать этого, т.к. неизвестно когда прометеус соберет эти данные. Поэтому лучше в самом приложение записывать случаи срабатывания лимитера в отдельный счетчик и эксопртить еще и его.
Можно еще использовать https://github.com/netdata/netdata и писать в ремоут какой-то.
Всё так но про нетдату не понял. Она имеет какуюто магию?
AL
Рестарт нжинкса будет видно по смене пида
Это я уже сделал, хочется еще варианты поэтому нарисал
A
Хотя рестарт какого нибудь нджинска как пример
А ты уверен, что рестарт надо ловить именно так?
AS
Это я уже сделал, хочется еще варианты поэтому нарисал
Короче определится с поймать и видно. В целом если запросов не было то и не надо ловить
AL
если приложение знает о своей недоступности(таймауты на конекшенах, не 200 ск), то оно может и экспортить соответствующую метрику (счетчик), который будет аккумулировать все ошибки.
аналогично можно экспортить метрики с клиентов этого приложения, если вы контролируете их.
В случае с прометеусом всегда нужно помнить, что скрейпы происходят в случайное время и соответственно проектировать мониторинг. Например, у вас есть рейтлимитинг и вы хотите знать когда он срабатывает. Обычная метрика по кол-ву запросов может не показать этого, т.к. неизвестно когда прометеус соберет эти данные. Поэтому лучше в самом приложение записывать случаи срабатывания лимитера в отдельный счетчик и эксопртить еще и его.
Можно еще использовать https://github.com/netdata/netdata и писать в ремоут какой-то.
аналогично можно экспортить метрики с клиентов этого приложения, если вы контролируете их.
В случае с прометеусом всегда нужно помнить, что скрейпы происходят в случайное время и соответственно проектировать мониторинг. Например, у вас есть рейтлимитинг и вы хотите знать когда он срабатывает. Обычная метрика по кол-ву запросов может не показать этого, т.к. неизвестно когда прометеус соберет эти данные. Поэтому лучше в самом приложение записывать случаи срабатывания лимитера в отдельный счетчик и эксопртить еще и его.
Можно еще использовать https://github.com/netdata/netdata и писать в ремоут какой-то.
Почитаю спасибо
AL
Короче определится с поймать и видно. В целом если запросов не было то и не надо ловить
Нужно именно поймать.
AL
Всем Спасибо за помощь, почитаю про статью повыше)
A
Можно экспортировать время запуска приложения, например
RK
Всё так но про нетдату не понял. Она имеет какуюто магию?
частота скрейпа метрик вроде 1с, насколько я помню.
AS
частота скрейпа метрик вроде 1с, насколько я помню.
Видел на промконе как говорили про 100мс
A
Можно экспортировать время запуска приложения, например
И всё "поймать" будет в поиске когда время запуска поменялось