Жопа горит, а сервис лежит
Как-то раз в чатик нашего проекта написали сообщение о том, что одна из ручек сервиса не работает, просто отдает 500ю ошибку. Я полез разбираться и обнаружил, что она стабильно имеет 100 запросов в секунду, которые отваливаются с ошибкой. Сижу и думаю, какого хрена я про это узнал спустя месяц, еще и от клиентов?!
Такие ситуции нужно ловить сразу, иначе косяки выплывают наружу, и пользователи грустят. А где их грусть, там и негодование начальника ахаха. Так что надо как-то следить за состоянием сервиса.
И дело не только в том, что хочется запалить момент, когда он начнёт просасывать. Хочется иметь больше информации о моменте, когда посыпались ошибки, иначе придётся открывать шоу "Экстрасенсы ищут баг на проде". А если сервисов несколько? Прикинь, система из 50-ти сервисов. Там вообще хрен поймёшь что произошло, если никак не мониторить её состояние.
Что нам нужно, чтоб штаны остались сухими?
1. Логи
Это база. Печатаем ошибки, чтоб потом понять на каком из этапов что-то пошло не так. Но не стоит писать "произошла ошибка пук". В лог нужно добавлять необходимый контекст. Произошла ошибка в обработке какой-нить задачи - напиши айдишник этой задачи. Сломался парсинг атрибутов пользователя - бахни в лог инфы о пользаке, чтоб понятно было кто он такой.
Сколько раз мне логи время экономили... Видишь ошибку, лезешь в логи, а там написано "ты, дурень, зачем указатель ниловый разыменовал" и сразу всё на свои места становится. Быстрая правка - и в продакшн.
2. Метрики
Они нужны, чтобы запалить, сколько всяких ошибок сервис наваливает. Кроме этого, можно засекать нагрузку на сеть, на CPU, на диск и так далее. И, конечно, всякие бизнесовые показатели тоже отлеживать важно.
Из самых базовых текнических метрик можно за основы взять 4 золотых сигнала, которые умные дядьки из гугла рекомендуют.
➡️ Latency - время обработки запроса. Сервак отвечает дольше обычного - повод подумать, а всё ли ок. И конечно важно разделить это время для успешных запросов, и тех, что с ошибкой. А то один кривой запрос всю статистику запороть может.
➡️ Traffic - обычно это количество запросов в секунду. Можно прикинуть нагрузку, которая летит в сервис и если она возрастёт, то мы это заметим.
➡️ Errors - моя любимая метрика. Сколько запросов лажает и отдает пользователю ошибку. Чем больше ошибок, тем сильнее горит жопа у всех причастных.
➡️ Saturation - насколько хреново вашему сервису. Можно оценивать заполненность оперативы, или нагрузку на CPU, или показатели системы ввода-вывода. Короче, что важнее в конкретном сервисе, то и палим.
3. Алерты
Они-то в начале истории меня и подвели. Мало метрики считать, надо ещё и оповещать, когда они отклоняются от нормы. То есть в момент, когда у нашей ручки начинают копиться ошибки в ответах, алерт менеджер должен присылать собщение "ребятки, у нас жопа на проде". В Озоне помню ещё и железная леди звонила. Спишь ночью, и тут звонок, а из трубки сексуальный машинный голос "Привет, это алерт, исправь меня пожалуйста".
4. Трейсы
Это киллер-фича в мире микросервисов. Твой фронтенд может дернуть один микросервис, а тот ещё с десяток сервисов под капотом вызовет, и потом иди разбирайся, кто и где налажал в этой цепочке. А трейсы весь путь запроса пометят, еще и в красивом UI отрисуют. Там сразу будет видно, кто всем подсирает своими 500ками.
Мониторинг — это не просто хотелка перфекциониста, это необходимость в современных реалиях, иначе жопа твоя будет гореть не переставая.
Как-то раз в чатик нашего проекта написали сообщение о том, что одна из ручек сервиса не работает, просто отдает 500ю ошибку. Я полез разбираться и обнаружил, что она стабильно имеет 100 запросов в секунду, которые отваливаются с ошибкой. Сижу и думаю, какого хрена я про это узнал спустя месяц, еще и от клиентов?!
Такие ситуции нужно ловить сразу, иначе косяки выплывают наружу, и пользователи грустят. А где их грусть, там и негодование начальника ахаха. Так что надо как-то следить за состоянием сервиса.
И дело не только в том, что хочется запалить момент, когда он начнёт просасывать. Хочется иметь больше информации о моменте, когда посыпались ошибки, иначе придётся открывать шоу "Экстрасенсы ищут баг на проде". А если сервисов несколько? Прикинь, система из 50-ти сервисов. Там вообще хрен поймёшь что произошло, если никак не мониторить её состояние.
Что нам нужно, чтоб штаны остались сухими?
1. Логи
Это база. Печатаем ошибки, чтоб потом понять на каком из этапов что-то пошло не так. Но не стоит писать "произошла ошибка пук". В лог нужно добавлять необходимый контекст. Произошла ошибка в обработке какой-нить задачи - напиши айдишник этой задачи. Сломался парсинг атрибутов пользователя - бахни в лог инфы о пользаке, чтоб понятно было кто он такой.
Сколько раз мне логи время экономили... Видишь ошибку, лезешь в логи, а там написано "ты, дурень, зачем указатель ниловый разыменовал" и сразу всё на свои места становится. Быстрая правка - и в продакшн.
2. Метрики
Они нужны, чтобы запалить, сколько всяких ошибок сервис наваливает. Кроме этого, можно засекать нагрузку на сеть, на CPU, на диск и так далее. И, конечно, всякие бизнесовые показатели тоже отлеживать важно.
Из самых базовых текнических метрик можно за основы взять 4 золотых сигнала, которые умные дядьки из гугла рекомендуют.
➡️ Latency - время обработки запроса. Сервак отвечает дольше обычного - повод подумать, а всё ли ок. И конечно важно разделить это время для успешных запросов, и тех, что с ошибкой. А то один кривой запрос всю статистику запороть может.
➡️ Traffic - обычно это количество запросов в секунду. Можно прикинуть нагрузку, которая летит в сервис и если она возрастёт, то мы это заметим.
➡️ Errors - моя любимая метрика. Сколько запросов лажает и отдает пользователю ошибку. Чем больше ошибок, тем сильнее горит жопа у всех причастных.
➡️ Saturation - насколько хреново вашему сервису. Можно оценивать заполненность оперативы, или нагрузку на CPU, или показатели системы ввода-вывода. Короче, что важнее в конкретном сервисе, то и палим.
3. Алерты
Они-то в начале истории меня и подвели. Мало метрики считать, надо ещё и оповещать, когда они отклоняются от нормы. То есть в момент, когда у нашей ручки начинают копиться ошибки в ответах, алерт менеджер должен присылать собщение "ребятки, у нас жопа на проде". В Озоне помню ещё и железная леди звонила. Спишь ночью, и тут звонок, а из трубки сексуальный машинный голос "Привет, это алерт, исправь меня пожалуйста".
4. Трейсы
Это киллер-фича в мире микросервисов. Твой фронтенд может дернуть один микросервис, а тот ещё с десяток сервисов под капотом вызовет, и потом иди разбирайся, кто и где налажал в этой цепочке. А трейсы весь путь запроса пометят, еще и в красивом UI отрисуют. Там сразу будет видно, кто всем подсирает своими 500ками.
Мониторинг — это не просто хотелка перфекциониста, это необходимость в современных реалиях, иначе жопа твоя будет гореть не переставая.