Как читать логи Linux: journalctl, grep, tail и порядок диагностики
Логи помогают восстановить цепочку событий до сбоя. Важно не читать их подряд, а сначала сузить время, сервис и тип ошибки, затем проверить соседние записи.
С чего начать диагностику
Зафиксируйте симптом и точное время, когда он появился. Формулировка «сайт не работал утром» почти бесполезна, а «в 09:42 запросы к API начали отвечать 502» уже задает границы поиска. Запишите имя сервиса, хост, окружение и последнее изменение перед сбоем.
Сначала проверьте состояние процесса и свободные ресурсы, затем переходите к журналу конкретного сервиса. Такой порядок отделяет проблему приложения от нехватки памяти, заполненного диска, сетевого сбоя или остановленного процесса.
- уточнить время и длительность сбоя;
- проверить статус сервиса через systemctl status;
- проверить свободное место и память;
- открыть журнал только нужного сервиса и периода.
Как работать с journalctl
В системах с systemd основной журнал доступен через journalctl. Ключ -u ограничивает выдачу конкретным unit, а --since и --until задают временной интервал. Например, journalctl -u nginx --since "2026-07-10 09:35" --until "2026-07-10 09:50" покажет события Nginx вокруг сбоя.
Для просмотра новых сообщений в реальном времени используют -f. Ключ -p позволяет выбрать приоритет, но начинать только с error не всегда полезно: предупреждение перед ошибкой часто объясняет причину. Сначала посмотрите компактный интервал полностью, после чего сужайте фильтр.
Когда нужны tail и grep
Не все приложения пишут в systemd journal. Для обычных файлов пригодится tail -n 200, который покажет последние строки, и tail -f для наблюдения за новыми событиями. Не запускайте бесконечное слежение без ограничения на загруженном сервере: удобнее открыть отдельную сессию и остановить команду после воспроизведения ошибки.
grep ищет маркер в тексте. Используйте grep -i для поиска без учета регистра, -n для номера строки и -C 3 для трех строк контекста до и после совпадения. Ищите не только слово error, но и идентификатор запроса, адрес, имя задания или фрагмент сообщения пользователя.
Как читать одну запись
Разделите сообщение на время, источник, уровень, идентификатор и текст. Затем найдите первое отклонение в цепочке, а не самое громкое сообщение в конце. Ошибка подключения к базе может породить десятки вторичных 500-ответов, но исправлять нужно причину соединения.
Сопоставляйте события между сервисами по времени и request ID. Учитывайте часовой пояс контейнера и хоста. Если время расходится, сначала приведите его к одной зоне, иначе соседние события окажутся в неверном порядке.
Что сохранить после инцидента
В рабочую заметку включите симптом, период, ключевые строки без персональных данных, найденную причину и действие, которое восстановило сервис. Добавьте способ раннего обнаружения: метрику, алерт или проверку. Так разовая диагностика превращается в улучшение системы.
Перед передачей логов удаляйте токены, пароли, персональные данные и содержимое приватных запросов. Полный файл редко нужен: обычно достаточно небольшого временного окна и связанных идентификаторов.
