Пациент скорее жив?

Мониторинг — моя любимая тема. Могу говорить часами про него. И сегодня поговорим про метрики работоспособности бизнес-логики. Их еще некоторые называют "продуктовыми" метриками, но это неверно

Итак, замониторить состояние сервисов — задача привычная и тривиальная. Сервис работает, трафик ходит, БД отзывается, значит все ок. Рисуем зелененький кружочек. Но вот только пользователям, как правило, все равно, что у вас все работает. Если не работает пользовательский сценарий, значит не работает приложение (или его часть). И то, что инфраструктура у вас в полном порядке, не говорит, ровным счетом, ни о чем

Значит, нужно мониторить сценарий бизнес-логики. И вот тут начинается самое интересное. Зачастую люди полагаются на золотые сигналы или, например, считают, что достаточно дернуть хвост API и померить там лэтенси или вообще, сам факт того, что он отвечает. Но, зачастую, бизнес-процесс является распределенной транзакцией, ходит в несколько сервисов, да еще и в определенной последовательности. А еще круче, если у вас, например, внутри есть какие-то p2p-транзакции между инстансами одного сервиса или между сервисами.

Можно поставить APM и соорудить там карту вызовов и все такое. Но нет, инфру не хотелось утяжелять в данном случае, да и объем трафика таков, что эластик в данном конкретном примере потребовал бы к себе очень много внимания. Да и доработка кода тоже прошла бы не быстро.

Ну и че делать-то, в итоге? В итоге, я сделал так.

Каждый сервис, абсолютно каждый, умеет отдавать ровно 2 метрики (на самом деле гораздо больше конечно, но нас интересуют две): это лэтенси последнего запроса и средний лэтенси за последние N единиц времени. К сервисам все это подключается на уровне дополнительной либы просто и не требует от разрабов вообще никаких телодвижений. Ну и на уровне мониторинга мы просто собираем цепочку вызовов для проверки любой последовательности обращения к API. Сумма (или перцентиль, тут уж от ситуации зависит) наших метрик и будет нашим пиком на графике

А в графане, в итоге, мы можем собрать интегральный дашборд, где мы можем увидеть проблему в контексте одновременно бизнес-логики и состояния инфраструктуры. Зачастую, если фейловеры работают хорошо, то до дашборда с бизнес-логикой проблема может и не дойти

А еще такие дашборды очень любит бизнес, потому что там все реально понятно