Логи в Linux: как перестать тонуть в хаосе

Системные журналы (логи) – это «чёрный ящик» вашего сервера. Упал сайт, тормозит база данных, кто-то ломится по SSH? Ответы здесь. Но дьявол, как всегда, в деталях. Мир логирования в Linux многообразен: от архаичных, но всё ещё живых текстовых файлов до современных бинарных журналов. Новичок, открывший папку /var/log/, может впасть в ступор. Давайте разложим всё по полочкам и научимся читать логи.

Прежде всего, важно понимать: единого стандарта «где лежит главный лог» в Linux нет. Всё зависит от дистрибутива и настроек. Но есть база.

Исторически все логи хранились здесь, в обычных текстовых файлах. Эта система жива до сих пор, и вот её ключевые файлы, которые отличаются в разных семействах ОС:

Кроме этих, есть «стандартный набор», общий почти для всех Unix-систем:

С появлением systemd мир изменился. Теперь главный «сборщик» логов – это journald. Он сохраняет события в бинарном (нечитаемом для cat) формате в /var/log/journal/. Это эволюционный шаг, который принесли серьёзные Unix-системы (IBM AIX, Solaris) для обеспечения скорости, надёжности и структурированности хранения логов. Плюс в том, что логи меньше весят, быстрее ищутся и их сложнее незаметно подделать. Минус – их не прочитаешь без специальной утилиты journalctl.

В большинстве систем journald – это первый и главный коллекционер логов. А rsyslog (или syslog-ng в Astra Linux) выступает как мост в мир классических текстовых логов. Он берёт сообщения из journald и по настроенным правилам раскладывает их по папкам /var/log/. Именно поэтому сообщение может быть и в выводе journalctl, и в /var/log/syslog.

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

Если ваши логи лежат в традиционных файлах в /var/log/, вашими верными помощниками будут стандартные утилиты командной строки, которые установлены в любой Linux-системе по умолчанию.

Их сила в простоте и комбинируемости между собой. Самый частый сценарий – наблюдение за событиями в реальном времени с помощью tail:

Эта команда незаменима при отладке: вы запускаете проблемный процесс, и тут же видите все связанные с ним системные сообщения.

Когда нужно найти конкретную ошибку в огромном файле, на помощь приходит grep, а чтобы не листать бесконечную простыню вывода, результат поиска удобно передать в утилиту less для постраничного просмотра и навигации:

Но настоящая мощь классического подхода раскрывается в связке с awk и sed. Эти инструменты позволяют на лету парсить и преобразовывать строки, извлекая только нужные данные. К примеру, если сообщение содержит много технических полей, а вам нужны только дата, время и суть события, следующая команда легко отбросит всё лишнее, очистив вашу картину происходящего:

Если ваша система работает на systemd, вы обязаны знать этот инструмент. Его главное и неоспоримое преимущество – скорость поиска.

В отличие от grep, который построчно сканирует огромный текстовый файл, journalctl запрашивает данные из индексированного бинарного журнала. Это означает, что вы можете получить ответ на сложный вопрос за доли секунды, даже если журнал ведется годами.

Например, чтобы узнать, что случилось с веб-сервером Nginx за последний час, достаточно простого запроса:

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

А привычная для многих администраторов практика следить за логом в реальном времени реализуется простым аналогом tail -f, командой:

Инструмент lnav (Log File Navigator) – это инструмент, который часто незаслуженно обходят стороной, а между тем, он способен облегчить подход к анализу текстовых логов.

По своей сути это не просто просмотрщик, а мощная аналитическая платформа. Он умеет автоматически распознавать десятки форматов от классического syslog до access-логов веб-серверов, и тут же применять к ним подсветку синтаксиса.

Но его ключевая и самая впечатляющая особенность – это встроенная база данных SQLite. При открытии файла lnav полностью загружает и индексирует его содержимое в оперативной памяти, превращая бесформенный поток текста в структурированную базу данных, к которой можно делать прямые SQL-запросы.

Хотите не просто найти слово "error", а сразу посчитать топ-10 IP-адресов, с которых к вам ломились, сгруппировав их по количеству запросов? С lnav это один запрос.

Главный и, пожалуй, единственный его недостаток прямо вытекает из его архитектуры: lnav очень прожорлив до оперативной памяти. Пытаться открыть в нем несколько гигабайтных файлов на сервере с 1 ГБ RAM – плохая идея, которая приведет к зависанию системы. Но для глубокого и интерактивного анализа на вашей рабочей станции это бесценный инструмент, экономящий часы, а то и десятки часов ручного труда.

Хранить логи только на самом сервере – опасно. Если злоумышленник получит права root, он, вероятно, подчистит их и скроет следы атаки. Поэтому в любой серьёзной инфраструктуре логи сразу же отправляются на центральный сервер.

Для этого rsyslog умеет передавать данные по надёжному протоколу TCP (не то что его предок syslog, использовавший ненадёжный UDP) и даже шифровать их с помощью TLS. Настройка сводится к добавлению простой строки на клиенте:

Двойная «собака» (@@) как раз и означает использование TCP. На сервере-приёмнике логи можно раскладывать по папкам с именами клиентов, что наводит порядок. А для тысяч серверов данные логи направляют в мощные системы класса SIEM (например, MaxPatrol, KUMA) или в ELK-стек (Elasticsearch, Logstash, Kibana) для визуализации и сложного анализа.

В отечественной ОС Astra Linux всё работает на тех же принципах, но есть нюансы. Как и везде, главный сборщик – systemd-journald. Но в роли моста к файлам и системам-приёмникам выступает не rsyslog, а более мощный и гибкий syslog-ng. Он отвечает за доставку сообщений в /var/log/syslog, auth.log и другие. Для задач, требующих глубокого аудита безопасности, используется подсистема аудита Linux, которая пишет подробнейшие логи в /var/log/audit/audit.log.

Итак, у вас что-то сломалось. С чего начать и в каком порядке действовать?

Первый и самый быстрый шаг – спросить у системы напрямую через journalctl. Если ваш дистрибутив использует systemd, эта команда сразу покажет всё, что происходило с интересующим вас сервисом. Запросите логи конкретного юнита за последние десять минут, и с огромной вероятностью вы сразу увидите причину сбоя.

Не помогло или логи оказались пустыми? Значит, переходим к классическому текстовому поиску. Здесь важно знать, в каком именно дистрибутиве вы находитесь, потому что названия файлов различаются. Если перед вами Debian или Ubuntu, ваш основной системный журнал – это /var/log/syslog. Если же это CentOS, RHEL или Fedora, то вся картина событий находится в /var/log/messages. Открыв нужный файл, используйте tail -f для наблюдения за событиями в реальном времени – это незаменимый метод, когда вы пытаетесь воспроизвести проблему и сразу видите реакцию системы.

Следующий этап – фильтрация. Гигабайты логов невозможно прочитать глазами, поэтому нужно сузить область поиска. Если вы работаете с текстовыми файлами, ваш главный инструмент – это поиск по ключевым словам. Если же система пишет в journald, то утилита journalctl позволяет отфильтровать сообщения по уровню критичности и покажет только ошибки, причём без медленного перебора всего файла.

Когда первичный осмотр не дал ответа и нужен глубокий анализ, в дело вступает тяжёлая артиллерия. Если у вас большой объём текстовых логов, самое время запустить lnav. Он загрузит данные в оперативную память и позволит делать SQL-запросы, чтобы найти сложные корреляции, которые не увидеть простым грепом.

Если же ваша инфраструктура доросла до централизованного сбора логов, искать нужно не на сервере, а в вашей системе агрегации – будь то SIEM для событий безопасности или ELK-стек для визуализации и комплексной аналитики.

И наконец, если вы работаете с Astra Linux, помните о важном архитектурном отличии: маршрутизацией логов здесь заведует не привычный rsyslog, а его более мощный аналог syslog-ng. А для задач, связанных с глубоким аудитом и расследованием инцидентов безопасности, ваш главный источник истины – это детальнейший журнал, который ведётся подсистемой аудита.

Главный урок, который можно вынести из этого зоопарка технологий, прост: единого, самого правильного способа работать с логами в Linux нет. Ваш главный навык – не знание какой-то одной секретной команды, а понимание того, какая именно подсистема прямо сейчас отвечает за журналирование на вашем сервере.

Зашли вы на Ubuntu и видите /var/log/syslog, а на CentOS – /var/log/messages. Где-то journald дублирует всё в rsyslog, а где-то, как в Astra Linux, уже работает syslog-ng. В одной ситуации вы мгновенно находите ошибку за прошлую среду с помощью journalctl, а в другой – запускаете lnav, чтобы сделать SQL-запрос по гигабайтам текстового лога.

Эта статья – ваша карта местности. Умение быстро определить, где лежат логи и какой инструмент будет самым эффективным именно сейчас, превращает вас в уверенного пользователя Linux-системы.

Работа с логами – одна из десятка тем, которые нужно освоить для уверенного администрирования Linux. Различные практические задания, статьи, заметки, связанные с Linux, вы можете найти в моей «Хакерской кузнице»:

«Хакерская кузница» – это мастерская, где мы куём понимание работы систем, технологий, процессов, архитектуры – всего, до чего сможем докопаться.

Добро пожаловать в кузницу.