Разбор логов: чем смотреть, когда файл вырос до гигабайта

Ночной прогон оставил после себя лог на 1.4 гигабайта одним файлом. Редактор его открывать отказывается, а мне нужно понять, в какой момент полезли отказы.

Первый же grep по нему думал четыре минуты. Так работать нельзя. Чем вы разбираете такие файлы и как потом не доводите до гигабайта?

Четыре минуты у тебя съел разбор кодировки, сам поиск тут ни при чём. Попробуй так и удивись:

LC_ALL=C rg -F 'timeout' progon.log | wc -l

Простая подстановка LC_ALL=C убирает разбор многобайтных символов, а -F отключает разбор шаблона. На гигабайте разница у меня выходила семикратной. Плюс не зови cat file | grep, лишний проход через трубу на таких объёмах слышно.

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

а какой командой? я такое только глазами умею

Вика Сорокина, вот такой, счёт по минуте:

LC_ALL=C rg -F 'timeout' progon.log | cut -c1-16 | uniq -c | sort -k1 -rn | head

Теперь важное, о чём почти никто не думает. Лог прогона отсортирован по времени, потому что пишется подряд. Значит по нему работает поиск делением пополам, и вместо гигабайта вы читаете сотню килобайт.

# найти байтовое смещение первой строки после 03:40
awk -v t="03:40" 'substr($0,12,5) >= t { print NR; exit }' progon.log
# и дальше работать куском
sed -n '4180000,4260000p' progon.log > kusok.log

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

И про хранение сразу: складывайте старое zstd, у него ratio на текстовых логах около десятки, а rg -z ищет прямо внутри сжатого. Гигабайт превращается в сотню мегабайт, поиск замедляется процентов на тридцать, места экономится вдесятеро.

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

плюсую zstd, у меня архив логов за полгода влез в объём одной недели

Про «не доводить до гигабайта» отвечу отдельно, тут нужен logrotate по размеру. Суточная нарезка тут проигрывает:

/var/log/progon/*.log {
    size 200M
    rotate 14
    compress
    compresscmd /usr/bin/zstd
    compressoptions -19 -T0
    dateext
    dateformat -%m%d-%s
    missingok
    notifempty
}

Ключевое место тут size, потому что ночной прогон за одну ночь пишет больше, чем дневная работа за неделю, и суточная нарезка даёт файлы разной толщины. И не ставьте copytruncate бездумно: между копией и обрезанием файла теряются строки, а на активной записи это заметно.

Добавлю сбоку: если лог пишете вы сами, пишите его в json по строке на запись. Тогда разбор перестаёт быть игрой в регулярки.

rg -F '"status":429' progon.jsonl | jq -r '.ts' | cut -c12-16 | uniq -c

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

Артур Вагнер, поддерживаю. Ещё удобно, когда в каждой строке лежит номер задания: потом достаёшь всю судьбу одной страницы одним поиском.

Прогнал замеры на своём файле, разложил по способам.

Тридцать одна секунда против четырёх минут, и это на голом месте.

Отметь ещё, что rg по умолчанию читает файл параллельно, только когда их несколько. На одном файле упор идёт в диск, поэтому на сетевой шаре разница будет скромнее.

скопировала себе все команды из темы, спасибо огромное

Итог по мне: LC_ALL=C с -F дали основной выигрыш, деление пополам по времени закрыло разбор ночных провалов, logrotate по размеру больше не даёт файлам расти.

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