🔍 Как построить здоровый мониторинг

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

Меня зовут Настя Кузнецова, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. Хочу рассказать, как мы приводим в порядок мониторинг, какие метрики стоит взять за основу и в чём суть нашего правила 80/20.

❇️ Два главных принципа здорового мониторинга

1️⃣ Помните, что метрики — это маяки, а не микроскопы. Они сигнализируют о наличии проблемы, но не рассказывают детально, какая из шестерёнок огромного механизма барахлит. С алертами та же история: они просто показывают, есть проблема или нет, без указания на конкретную строку в коде

2️⃣ Стремитесь к балансу. Конечно, хочется замониторить все сервисы так, чтобы нигде и никогда не пропустить ни одну проблему. Однако нельзя полагать, что дашборд на 1000+ метрик будет кому-то полезен, ведь в этом случае никто не знает наверняка, на какой именно график надо смотреть, чтобы найти нужную информацию

❇️ Подход 80/20

Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем (80%). А бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения (20%).

🧬 Базовый набор для типичного бэкенда: RED-метрики для HTTP/gRPC, клиентов, очередей и баз данных.

❇️ В HTTP/gRPC-сервере замеряем три вещи:

🟢 Количество запросов. Тут мы можем увидеть, если кто-то решил спустить на нас DDoS или, наоборот, перестал это делать, а также если у нас куда-то утекает трафик

🟢 Ошибки, которые наш сервер отдаёт клиенту. В случае HTTP — это 4xx и 5xx, в случае gRPC — unavailable и прочее

🟢 Длительность запросов. Это помогает узнать, что сервер где-то начал подтормаживать или очень быстро отдавать что-то странное

Всё это даёт возможность понять практически любую проблему на стороне сервера.

❇️ В очереди смотрим на лаги:

Например, мы внесли в неё ряд данных, из-за этого там скопились сообщения, но по какой-то причине их не читают. Поэтому нам и нужны лаги — записанные сообщения минус прочитанные.

Эта метрика позволяет получить разницу позиций в очереди.

❇️ В БД следим за connection pool:

На стороне приложения есть клиентский пул, а между приложением и базой данных — отдельный серверный. Если наблюдать только за одним из них, отклонение на другом уровне останется незаметным, поэтому оба пула нужно включать в общий контур мониторинга.

Метрики клиентского пула обычно можно подключить через Spring Boot и Micrometer. Если в архитектуре есть отдельный серверный пул, его нужно мониторить на стороне компонента, который им управляет.

Такой контур помогает заметить риск заранее — до того, как он повлияет на запросы.

🔶 Читайте больше подробностей на Хабре. Там я поделилась золотыми метриками конкретно для Java-приложений и объяснила, как поймать 20% бизнес-специфичных. А также рассказала, как выбирать полезные алерты.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend