Небольшой вопрос по бизнес-метрикам. В моем понимании, это метрики, которые показывают, насколько хорошо мы предоставляем ту или иную бизнес-услугу пользователю. С указанными бизнес-метриками (отслеживание статусов транзакций, скорость обработки транзакций, время нахождения в статусе X) соглашусь. Не очень понятен следующий момент: ваш бизнес-мониторинг состоит из одной метрики nifi_amount_items_queued? Или мониторятся все три указанные метрики?
Также не очень понятно, зачем нужно мониторить количество данных в очереди. Разве это значение всегда показывает аномальную ситуацию, на которую нужно срочно реагировать? Как пример - в очередь прилетело 9000 запросов, но они обработались за пару минут и не создали критичной очереди. В этом случае алерт сработает, хотя ничего страшного не случилось. Или другой пример - в очередь поместили 100 жирных запросов, каждый из которых обрабатываются сутки. За ними встали еще 1000 лёгких запросов. И они не смогут обработаться, пока не обработаются те 100. То есть время нахождения транзакций в очереди будет сильно большим. Похоже на сбой, хотя мониторинг его не обнаружил.
Хаос инжиниринг вообще классная активность. Кажется, что её нужно проводить регулярно в независимости от того, сколько девяток от вас требуют. Здорово, когда инженеры знают, как себя может повести любая их система в той или иной ситуации.
SREшник?)
Добрый день!
Небольшой вопрос по бизнес-метрикам. В моем понимании, это метрики, которые показывают, насколько хорошо мы предоставляем ту или иную бизнес-услугу пользователю. С указанными бизнес-метриками (отслеживание статусов транзакций, скорость обработки транзакций, время нахождения в статусе X) соглашусь. Не очень понятен следующий момент: ваш бизнес-мониторинг состоит из одной метрики nifi_amount_items_queued? Или мониторятся все три указанные метрики?
Также не очень понятно, зачем нужно мониторить количество данных в очереди. Разве это значение всегда показывает аномальную ситуацию, на которую нужно срочно реагировать? Как пример - в очередь прилетело 9000 запросов, но они обработались за пару минут и не создали критичной очереди. В этом случае алерт сработает, хотя ничего страшного не случилось. Или другой пример - в очередь поместили 100 жирных запросов, каждый из которых обрабатываются сутки. За ними встали еще 1000 лёгких запросов. И они не смогут обработаться, пока не обработаются те 100. То есть время нахождения транзакций в очереди будет сильно большим. Похоже на сбой, хотя мониторинг его не обнаружил.
Хаос инжиниринг вообще классная активность. Кажется, что её нужно проводить регулярно в независимости от того, сколько девяток от вас требуют. Здорово, когда инженеры знают, как себя может повести любая их система в той или иной ситуации.
Статья супер!! Очень подробный анализ. Спасибо!