Измерение настолько гранулярных данных и триггеры на них на наш взгляд неэффективны. У нас используются метрики либо кумулятивные, либо апроксимированные.
Например, мы не смотрим время ответа на каждый запрос пользователя на наших серверах. мы смотрим на сумму времен ответа на все запросы пользователя в каждую секунду. То есть дискретность данной метрики крайне высокая, но за счет того, что она кумулятивна, в ней отсутствует влияние естественных всплесков. Понятно, что представленную в примере метрику бесполезно делать, если у вас условно 1-2 rps на сервера.
Также широко используется стандартная общепринятая практика по мониторингу 95 / 99 персентили, в зависимости от стабильности показателей. Например мониторинг времен проведения одной транзакции (в автоматическом режиме) ведется по 95 персентили. А мониторинг некоторых сервисов, стоящих «за нами» — по 99. В этом случае конечно сложно достичь дискретности в 1 секунду, но на достаточном потоке данных получить дискретность в 15-30 секунд вполне можно
Ох, раскопали выступление полуторогодовой давности…
1. Потом, кровью и опытом:)
Дело в том, что по опыту сбой всегда вызывает резкий взлет показателей, и никогда плавный. При этом потолок взлета не меньше 3х от нормальных показателей. Так что у нас алерты настроены в среднем по больнице на 2 — 2.5х от нормальных показателей.
2. Это проблема тогда, когда мы обращаем внимание на систему в целом. В нашем же случае мы мониторим еще и время работы отдельных компонент — сервисов системы. И если какой-то компонент начал работать медленнее обычного мы это заметим сильно раньше чем это критично скажется на производительности всей системы целиком. При этом отдельный компонент может конечно в теории стать узким местом всей системы, но маленькую часть быстрее масштабировать, быстрее исправлять и дорабатывать, тем более не откатывая коммиты полугодовой давности.
HighLoad++, Евгений Кузовлев (EcommPay IT): что делать, когда минута простоя стоит $100000
Измерение настолько гранулярных данных и триггеры на них на наш взгляд неэффективны. У нас используются метрики либо кумулятивные, либо апроксимированные.
Например, мы не смотрим время ответа на каждый запрос пользователя на наших серверах. мы смотрим на сумму времен ответа на все запросы пользователя в каждую секунду. То есть дискретность данной метрики крайне высокая, но за счет того, что она кумулятивна, в ней отсутствует влияние естественных всплесков. Понятно, что представленную в примере метрику бесполезно делать, если у вас условно 1-2 rps на сервера.
Также широко используется стандартная общепринятая практика по мониторингу 95 / 99 персентили, в зависимости от стабильности показателей. Например мониторинг времен проведения одной транзакции (в автоматическом режиме) ведется по 95 персентили. А мониторинг некоторых сервисов, стоящих «за нами» — по 99. В этом случае конечно сложно достичь дискретности в 1 секунду, но на достаточном потоке данных получить дискретность в 15-30 секунд вполне можно
HighLoad++, Евгений Кузовлев (EcommPay IT): что делать, когда минута простоя стоит $100000
1. Потом, кровью и опытом:)
Дело в том, что по опыту сбой всегда вызывает резкий взлет показателей, и никогда плавный. При этом потолок взлета не меньше 3х от нормальных показателей. Так что у нас алерты настроены в среднем по больнице на 2 — 2.5х от нормальных показателей.
2. Это проблема тогда, когда мы обращаем внимание на систему в целом. В нашем же случае мы мониторим еще и время работы отдельных компонент — сервисов системы. И если какой-то компонент начал работать медленнее обычного мы это заметим сильно раньше чем это критично скажется на производительности всей системы целиком. При этом отдельный компонент может конечно в теории стать узким местом всей системы, но маленькую часть быстрее масштабировать, быстрее исправлять и дорабатывать, тем более не откатывая коммиты полугодовой давности.