Trace Points в C++: диагностика production-систем без перезапуска
Одна из самых неприятных особенностей production-проблем заключается в том, что они почти никогда не происходят тогда, когда разработчик готов их исследовать. Во время разработки всё работает. На тестовом стенде тоже всё выглядит нормально. Логи кажутся вполне достаточными, а диагностическая информация — продуманной и аккуратно организованной. Но затем в production внезапно появляется странная проблема: соединение иногда сбрасывается без видимой причины, один запрос из нескольких тысяч начинает вести себя иначе, сервер под высокой нагрузкой неожиданно входит в reconnect loop или где-то глубоко внутри системы начинает происходить что-то, что невозможно воспроизвести локально. И почти всегда в этот момент выясняется одна и та же неприятная вещь: логов, которые уже есть в системе, недостаточно. Именно здесь традиционное логирование начинает постепенно ломаться. Большинство систем логирования до сих пор построены вокруг довольно простой идеи: заранее решить, какие сообщения должны писаться постоянно. Разработчик добавляет INFO, WARNING, DEBUG, иногда каналы или категории, после чего приложение отправляется в production с надеждой, что этих логов когда-нибудь хватит для диагностики. Иногда действительно хватает. Но реальные production-системы имеют неприятную привычку ломаться не там и не так, как ожидалось. Более того, проблемы часто возникают именно в тех участках кода, которые казались совершенно неинтересными во время разработки. Первой реакцией обычно становится мысль: “давайте включим DEBUG logging”. На небольших проектах это ещё может работать вполне нормально. Однако в больших системах DEBUG-логи очень быстро превращаются в проблему сами по себе. Они начинают занимать гигабайты, полезная информация тонет в шуме, растёт нагрузка на диск, а иногда и само логирование начинает заметно влиять на производительность и тайминги приложения.
https://habr.com/ru/articles/1035984/
#logging_c++ #tracepoint #debugging #c++ #логирование #отладка_кода
