Как читать логи, если видишь их впервые

открыл лог первый раз и сразу закрыл. двадцать тысяч строк, все на одно лицо, где там ошибка непонятно.

скрипт падает примерно раз в час, в консоли пишет «смотри лог». подскажите, как вообще подходить к такому файлу, с какого конца читать?

С конца, но не совсем. Объясню порядок.

Лог никто не читает подряд. Сначала ты сужаешь файл до интересного куска, потом глазами читаешь уже двадцать строк.

Первый заход:

grep -i -n 'error\|fail\|exception' progon.log | tail -50

Получишь последние полсотни строк со словами про сбой, с номерами строк. Дальше берёшь номер первой такой строки и смотришь вокруг неё:

sed -n '4100,4160p' progon.log

И вот тут правило, которое экономит часы: интересна первая ошибка в цепочке, все следующие обычно её следствия. Люди читают самую нижнюю строку и чинят следствие.

то есть снизу вверх листать до места, где всё началось?

Да. И главный ориентир тут время. У каждой строки в начале метка времени, найди момент падения и отмотай на минуту назад. Всё, что попало в эту минуту, и есть история болезни.

Если меток времени нет, это первое, что надо поправить в своём скрипте. Лог без времени почти бесполезен.

А я долго не знала про tail -f. Смотришь лог живьём, пока прогон идёт, и прямо видишь, на чём он спотыкается.

Разберём типичную строку, чтобы слово «лог» перестало пугать.

08-19 03:14:22  WARN   fetcher   attempt 2 failed for /catalog/91 timeout after 15s

Слева направо: дата и время, уровень важности, имя куска программы, который это написал, дальше человеческий текст.

Уровни почти везде одинаковые:

Начинай с ERROR и FATAL. К WARN возвращайся, когда с ERROR уже разобрался.

о, уровни у меня есть, я думал это просто слова большими буквами

Ещё про размер файла. Двадцать тысяч строк это мелочь, less откроет мгновенно. Когда дорастёшь до файлов на гигабайт, cat перестанет годиться, машина задумается надолго.

Для больших файлов набор такой: less для листания, grep для поиска, zgrep для сжатых архивов логов.

Раз тема пошла, дам порядок разбора, которым пользуюсь сам. Работает почти на любом логе.

Шаг первый: понять окно времени. Когда всё было хорошо и когда сломалось. Две метки, больше ничего.

Шаг второй: вырезать это окно в отдельный файл. С маленьким файлом работать не страшно, оригинал остаётся нетронутым.

Шаг третий: посчитать, чего и сколько. Часто картина видна сразу по счётчику видов ошибок.

Шаг четвёртый: взять самый частый вид и найти его первое появление в окне. Дальше читать вокруг этой строки.

Шаг пятый: если ничего не понял, сравнить с логом удачного прогона. Разница между рабочим и сломанным заходом обычно и есть ответ.

Сохранила порядок себе. Пятый шаг про сравнение с удачным прогоном вообще не приходил в голову.

Добавлю мелочь, на которой сама просидела вечер. Проверяйте часовой пояс машины и время внутри самого лога. У меня записи шли по UTC, будильник срабатывал по местному, и я искала событие на три часа мимо.

timedatectl покажет, как настроена система.

Дарья права. И ещё: заведите привычку писать в лог не только ошибки, но и вехи. Старт прогона, конец, сколько обработано за час. Тогда лог читается как дневник.

докладываю. нашёл по счётчику: 412 раз timeout на одном домене, всё остальное следствие. первая ошибка была в 03:14, за минуту до неё строка про смену адреса.

теперь читаю логи спокойно, спасибо всем.