Признаюсь честно: года три назад я смотрел на логи, как кот на закрытую дверь. Казалось, что там какая-то магия, доступная только разработчикам в чёрных свитерах. Я открывал консоль, видел горы непонятного текста и… шёл к разрабу с вопросом: «Тут что-то упало, посмотришь?»
Сейчас я понимаю: логи — это не враг, а лучший друг QA. Это дневник приложения, где оно честно пишет всё, что с ним происходит. Иногда ругается матом (ERROR), иногда просто ворчит (WARN), а иногда тихо радуется (INFO).
Если вы до сих пор боитесь логов — этот пост для вас. Мы разберёмся, что с ними делать, какие команды реально нужны, и как перестать бегать к разработчику каждые 5 минут.
Логи — это не страшно, это как читать чужой дневник
Представьте: приложение — это человек. Оно делает что-то, а потом записывает в блокнот:
- «Открыл страницу, всё ок» (INFO)
- «Пользователь нажал кнопку, но я не знаю, что с ней делать» (WARN)
- «Всё сломалось, я в панике, help» (ERROR)
Логи — это и есть этот блокнот. Наша задача — научиться читать его быстро и понимать, где приложению реально больно, а где оно просто капризничает.
Главный секрет: в 90% случаев достаточно уметь фильтровать, искать по ключевым словам и смотреть на стек ошибки. Остальное — опыт и любопытство.
Инструменты: без них как без рук
Я не буду перечислять всё подряд. Дам только то, чем сам пользуюсь каждый день.
1. tail -f — «смотри за логом в реальном времени»
Команда, которая спасает, когда ты запустил приложение и хочешь видеть, что происходит прямо сейчас.
tail -f /var/log/myapp.log
Можно добавить -i для регистронезависимости, -A 5 чтобы показать ещё 5 строк после найденной.
Это как сказать другу: «Найди в этом трёхтомнике все упоминания слова “кот”».
3. less — «читай длинные логи без боли»
Если лог весит несколько гигабайт, открывать его в блокноте — мазохизм. less позволяет листать, искать, выходить.
less app.log
Навигация: / + слово — поиск, n — следующее вхождение, q — выход.
После того как попробуешь less, обычный блокнот покажется тебе каменным топором.
4. jq — «разберись с JSON-логами»
Современные приложения часто пишут логи в JSON. Читать их глазами — ад. jq превращает это в красивые структуры.
cat app.json | jq '.'
А можно выбрать только нужные поля: jq '.timestamp, .level, .message'
jq — это как причёска для хаотично разбросанных волос.
Реальный кейс: как я нашёл баг по логам и сэкономил 2 часа
Была у меня история. Тест упал, интерфейс показывал «Ошибка сервера». Я уже собрался идти к разработчику, но решил: дай-ка загляну в логи.
Захожу на сервер, делаю:
tail -100 app.log | grep ERROR
Ответ:
ERROR [2026-03-28 14:32:11] NullPointerException: user.getId() called on null
Всё. Мне не нужно больше ничего. Я знаю: приложение пыталось получить ID пользователя, а пользователь был null. Значит, где-то не пришла авторизация или сессия протухла.
Я пошёл к разработчику не с «упало, посмотри», а с «упало из-за NullPointer в методе getUser, скорее всего проблема в токене». Мы за 5 минут нашли, что токен не обновлялся.
Разработчик даже спасибо сказал. Такое бывает, я не шучу.
Чек-лист: что делать, если увидел лог
Чтобы не теряться, просто пройдите по шагам:
- Определите уровень: ERROR, WARN, INFO? Если INFO — скорее всего не проблема.
- Найдите исключение: Java — Exception, Python — Traceback. Это ваша цель.
- Посмотрите на стек: где именно случилась ошибка (файл, строка).
- Проверьте контекст: что было до ошибки? (первые строки до Exception)
- Если JSON-лог: используйте jq, чтобы вычленить message и stackTrace.
И главное — не паникуйте. Логи пугают только тех, кто с ними не дружит.
А теперь вопрос к вам
Я честно признался, как раньше боялся логов. А вы?
- Какой самый странный или смешной баг вы находили по логам?
- Есть любимая команда, без которой вы не представляете работу?
- Может быть, у вас есть история, когда разработчик сказал: «О, ты сам посмотрел логи? Ты суперзвезда!»?
Делитесь в комментариях. Обещаю, что ни один лог не будет обижен.
P.S. Если хотите больше таких разборов с юмором и пользой — подписывайтесь. В следующий раз расскажу, как подружиться с терминалом, если вы его боитесь 😉