Да кто этот ваш
observability?😐
☺️Если вы никогда не работали с микросервисами, то вполне возможно, что даже не слышали о таких вещах как
метрики и
трейсы, а весь дебаг в проде сводился к добавлению новых логов и перевыкатке сервиса.
В монолитном приложении проще найти баг, потому что монолит вы можете развернуть локально в дебаг режиме и расставить брейкпоинты, или же в логах получить полный стэктрейс при ошибке.
В микросервисах все сложнее, тут у вас не отдельные модули, а отдельные сервисы, вам сложно продебажить всю цепочку вызовов локально. У вас запрос может пройти через десяток сервисов, каждый со своей базой, своими версиями, своими особенностями. И когда пользователь жалуется на ошибку, вы даже не знаете, с какого сервиса начинать искать.🤨
Представьте ситуацию, когда у вас несколько микросервисов, через которые проходит запрос, в котором проблема, вы смотрите на логи (если они вообще есть😁) и не можете понять, где может крыться ошибка. Вы добавили побольше логов, пытаетесь воспроизвести ошибку и не можете найти лог, привязанный к вашему запросу. После нескольких часов поиска бага, вы рвете волосы на голове и материтесь на монитор (да, было😱).
Я был в такой ситуации, тогда я дебажил асинхронный пайплайн обработки ивентов из очереди. Чтобы разобраться, мне пришлось писать огромные
логи принты с исчерпывающими данными о состоянии приложения, вплоть до значений переменных и body запроса. Баг я, конечно, нашел, но какой ценой. Сейчас это кажется смешным, но будь у нас хотя бы нормальные структурированные логи, то баг нашелся бы гораздо быстрее.😣
✅Теперь я расскажу вам о том, что может помочь вам разбираться с багами быстрее - это
структурированные логи,
трейсы и
метрики.
🗒Логи обычно помогают локализовать ошибку в рамках сервиса, с помощью них вы можете найти конкретное место, в котором произошла ошибка, если, конечно, вы правильно написали лог, а не напихали "ERROR: %s" по всему коду. Лучше использовать структурированные логи в формате json, так их проще фильтровать по атрибутам.
🔫
Трейсы нужны для того, чтобы отсмотреть всю цепочку вызовов, на трейсе буквально поминутно расписано, кто где и когда
соснул хуйца сделал сетевой вызов. Для правильной работы трейсов вам нужно иметь какой-то уникальный id, который будет привязан ко всем логам во всех сервисах. То есть он должен переходить от сервиса к сервису с запросом. Так вы сможете находить логи, привязанные к одному запросу в разных сервисах.
🎧
Метрики же помогают численно описать состояние вашего сервиса, обычно базовые метрики - это latency и ошибки по ручкам + какие-то метрики производительности: загрузка cpu, ram и т.д. Метрики обычно выводятся в Grafana, там вы можете увидеть метрику, привязанную ко времени, так вы можете следить за состоянием сервиса на дистанции. Также на метрики можно настроить алерт, например, можно назначить алерт на всплеск 5xx ошибок у вашего сервиса, так вы сможете сразу узнать о проблемах в вашем сервисе.
😁Если вашим сервисом пользуется больше двух землекопов и вы не хотите дебажить вслепую, то рано или поздно вам придется разобраться с этими инструментами.
🫡Если вам интересно послушать о надежности сервисов, то накидайте огоньков и клоунов.