Как мы все работаем и разрабатываем? Достаточно тривиально, шаблонно, распространенно. Запускаем понравившуюся среду разработки (IDE), включаем режим отладки, и вперед со словами из песен группы Ленинград.
Долго и мучительно, а иногда быстро и легко, мы привыкли уже все отлаживать процесс с помощью IDE. Ибо отладка наше всё.
Что в макроразработке через Intellij IDEA, Visual Studio или PyCharm, что в микроразработке через CoDeSys, STM32CubeIDE или Arduino и во многих других средах разработки смотрим на консоль отладки, следим за точками останова и бегаем по флагам из вкладки во кладку, из окно в окно. Инструментов тьма. Делай что и как хочешь. Быстро найдешь баг.
Разумеется, адепты тестов скажут нужно подключать ещё и принцип TDD, покрывать модульными, интеграционными тестами всё.
На худой конец, можно просто прокликать интерфейс, и в режиме разработчика в браузере, например, просмотреть запросы и нагрузку. А в радиолюбительстве прозвонить цепь, работает или не работает плата. И тому подобное.
Однако, что делать с проектом, который мы вылизали как могли и успели что смогли, передали заказчику, конечному клиенту, покупателю, - на прод. Собрали в пакет или контейнер, и адью?!
Вот, здесь, нам и помогают, спасают логи.
Логирование, как приницп фиксации ошибок и событий в целом в режиме реального времени существует чуть ли не с зарождения самого компьютера. Лишь спустя время логирование систематизировали, стандартизировали и укротили.
Вспомните процедуру ЭКГ, когда с помощью присосок размещают датчики по всему нашему телу. После чего, оператор мониторит процессы на экране, - тот же терминал, - а затем распечатывает результат в виде графика или диаграммы с легендой и соответствующим текстом с датой и временем того или иного сигнала, - события. Вот, вам и тоже самое логирование, где проверили работу не системы на компьютере, а вас.
Разработчики те же врачи. Специальностей тьма. И не каждый, например, терапевт может быть хирургом, а программист электриком.
Итак. Логирование очень удобный, важный, необходимый механизм, когда мы работаем с системой и проектами на проде.
Что просим в первую очередь, когда на стороне клиента возникает баг? Мы просим логи! С такого по такой-то период времени, а лучше целый файл, чтобы мы могли проследить ход событий, приведший к этому самому багу.
Но не переусердствуйте. Ибо всему есть мера. Мы работаем с ограниченными системными ресурсами: памятью, тактовыми частотами и так далее, - в конце концов с разными фиксированными по размерам (высотой, глубиной, шириной, объемами) и количеством компонентов самого компьютера.
Поэтому не получится бесконечно следить, мониторить систему. Очевидно же?!
Как снова на моей практике оказалось не очевидным. Легаси проект, что мы сейчас сопровождаем, изначально на проде не предусматривал ограничение по размеру и количеству логов в системе.
И возвращаясь к проблеме, рассказанной подробно в статье Умение вовремя остановиться, заказчик обнаружил, что проблема обновления также заключалась в том, что свободная память на носителе просто уперлась в потолок. Логов накопилось столько, что девать уже было некуда. А какие тогда операции по распаковке, ребилду и прочему.
Относись к системе как к живому организму. Нагрузишь чрезмерно, не дашь дышать, - сдохнет.