Управление логами в Linux: полное руководство по просмотру и настройке

Введение / Зачем это нужно

Логи в Linux — это детальный журнал событий системы и приложений. Они незаменимы для диагностики проблем, аудита безопасности и мониторинга. Без должного управления логи могут неконтролируемо расти, заполняя весь доступный диск и приводя к сбоям. Этот гайд поможет вам освоить полный цикл работы с логами: от их просмотра и мониторинга до настройки автоматической ротации, что гарантирует стабильность системы и сохранность важных записей.

Требования / Подготовка

Перед началом убедитесь, что у вас есть:

1. Доступ к терминалу Linux (Ubuntu, CentOS, Debian или другой дистрибутив).
2. Права суперпользователя (sudo) для некоторых операций (просмотр системных логов, очистка, настройка logrotate).
3. Установленные базовые утилиты: coreutils (содержит tail, less, truncate), logrotate (обычно предустановлен). Для систем на базе systemd доступен journalctl.
4. Понимание, какая система логирования используется:
   • Традиционный syslog: логи в текстовых файлах в /var/log/ (например, /var/log/syslog, /var/log/auth.log).
   • systemd-journald: бинарный журнал, управляемый через journalctl. Может храниться в /var/log/journal/ или в памяти.

Пошаговая инструкция

Шаг 1: Изучение структуры и расположения логов

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

1. Посмотрите содержимое каталога /var/log/:

   ls -lh /var/log/
   

   
   Вы увидите множество файлов и каталогов: syslog, auth.log, kern.log, apache2/ (логи веб-сервера), nginx/, а также каталоги journal/ (если используется journald) и архивы .gz (сжатые старые логи).
2. Определите, используется ли journald:

   systemctl status systemd-journald
   

   
   Если служба активна (active (running)), то основные логи можно читать через journalctl, а текстовые файлы в /var/log/ могут быть вторичными или содержать только критичные сообщения.
3. Проверьте, какие процессы пишут в логи. Например, для nginx:

   ps aux | grep nginx
   

   
   В выводе ищите параметр error_log, который укажет путь к его логам.

Шаг 2: Просмотр логов с помощью tail и less

Эти две команды — основа для работы с текстовыми логами (syslog).

• tail — показывает конец файла. Идеально для просмотра последних событий.

  # Последние 10 строк системного лога
  sudo tail /var/log/syslog
  
  # Последние 50 строк лога аутентификации
  sudo tail -n 50 /var/log/auth.log
  
  # Следить за новыми записями в реальном времени (Ctrl+C для выхода)
  sudo tail -f /var/log/syslog
  

• less — интерактивный просмотрщик для больших файлов. Позволяет прокручивать, искать и переключаться между файлами.

  sudo less /var/log/syslog
  

  
  Управление в less:
  • Пробел / PgDown — следующая страница.
  • b / PgUp — предыдущая страница.
  • /текст — поиск вперед. n — следующее совпадение.
  • ?текст — поиск назад.
  • q — выход.
• Для journald используйте journalctl:

  # Показать все записи journal (аналог less)
  sudo journalctl
  
  # Последние 50 записей
  sudo journalctl -n 50
  
  # Фильтрация по службе (например, nginx)
  sudo journalctl -u nginx.service
  
  # Просмотр с момента загрузки
  sudo journalctl -b
  
  # Реальный мониторинг (аналог tail -f)
  sudo journalctl -f
  

Шаг 3: Мониторинг логов в реальном времени

Для оперативного отслеживания событий (например, при отладке) используйте режим слежения.

1. Для текстовых логов (syslog):

   sudo tail -f /var/log/syslog | grep --line-buffered "ERROR"
   

   
   Конструкция | grep --line-buffered фильтрует только строки с "ERROR" в реальном времени.
2. Для journald:

   # Отслеживать все новые записи
   sudo journalctl -f
   
   # Отслеживать записи конкретной службы
   sudo journalctl -u ssh.service -f
   
   # Отслеживать записи с определенным приоритетом (например, err)
   sudo journalctl -p err -f
   

3. Комбинированный мониторинг (если нужно смотреть оба источника):

   # В двух отдельных окнах терминала запустите:
   sudo tail -f /var/log/syslog
   sudo journalctl -f
   

Шаг 4: Очистка старых и ненужных логов

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

1. Безопасное усечение (очистка) конкретного файла (файл остается, но его содержимое обнуляется). Это самый быстрый способ освободить место.

   # Усечь файл до нулевого размера
   sudo truncate -s 0 /var/log/syslog
   
   # Альтернативный способ (тоже обнулит файл)
   sudo echo > /var/log/syslog
   

2. Удаление старых архивных логов (.gz):

   # Удалить все сжатые логи старше 30 дней в /var/log/
   sudo find /var/log/ -name "*.gz" -type f -mtime +30 -delete
   
   # Удалить все файлы логов, кроме основных (осторожно!)
   sudo find /var/log/ -type f ! -name 'syslog' ! -name 'auth.log' -delete
   

3. Очистка журнала journald (если он используется и занимает много места):

   # Очистить журнал до текущей сессии (аналог rotation)
   sudo journalctl --rotate
   sudo journalctl --vacuum-time=1d  # Оставить только записи за последний день
   
   # Очистить журнал, освободив определенный объем (например, 100M)
   sudo journalctl --vacuum-size=100M
   

Шаг 5: Настройка автоматической ротации через logrotate

logrotate — стандартный инструмент для автоматического ротации, сжатия и удаления логов. Обычно он настроен по умолчанию, но для приложений может потребоваться дополнительная конфигурация.

1. Основной конфигурационный файл: /etc/logrotate.conf. Он содержит глобальные настройки (часто include /etc/logrotate.d;).
2. Конфигурации для конкретных логов размещаются в /etc/logrotate.d/. Например, для nginx там может быть файл nginx.
3. Пример конфигурации для вашего приложения (создайте файл /etc/logrotate.d/myapp):

   sudo nano /etc/logrotate.d/myapp
   

   
   Вставьте конфигурацию (замените /var/log/myapp/app.log на путь к вашему логу):

   /var/log/myapp/*.log {
       daily              # Ротировать ежедневно
       rotate 7           # Хранить 7 архивов (7 дней)
       compress           # Сжимать ротированные логи (gzip)
       delaycompress      # Сжимать не сразу, а при следующей ротации (чтобы можно было читать текущий)
       missingok          # Не выдавать ошибку, если лог-файл отсутствует
       notifempty         # Не ротировать пустые файлы
       create 644 root root # Создавать новый лог-файл с этими правами после ротации
       sharedscripts      # Запускать скрипты (postrotate) один раз на все файлы в блоке
       postrotate
           # Команда для уведомления приложения о ротации (например, переоткрыть файл)
           # systemctl reload myapp.service > /dev/null 2>&1 || true
       endscript
   }
   

4. Тестирование конфигурации (без реального выполнения):

   sudo logrotate -d /etc/logrotate.conf
   

   
   Флаг -d (debug) покажет, какие действия logrotate собирается предпринять.
5. Принудительный запуск logrotate (для теста или ручного сценария):

   sudo logrotate -f /etc/logrotate.conf
   

6. Для journald настройка ротации происходит в /etc/systemd/journald.conf:

   [Journal]
   SystemMaxUse=100M   # Максимальный размер журнала на диске
   SystemMaxFileSize=50M # Максимальный размер одного файла журнала
   MaxRetentionSec=1month # Хранить не дольше месяца
   

   
   После изменений перезапустите службу: sudo systemctl restart systemd-journald.

Проверка результата

1. После настройки logrotate:
   • Убедитесь, что в /var/log/ появились сжатые архивы (.gz) вашего приложения.
   • Проверьте, что приложение продолжает писать в новый (неархивированный) лог-файл.
   • Посмотрите даты файлов: ls -lh /var/log/myapp/.
2. Для journald:

   sudo journalctl --disk-usage  # Покажет текущий размер журнала
   sudo journalctl --list-boots  # Покажет доступные загрузки (ротации)
   

3. Общий мониторинг:

   df -h /var/log  # Убедитесь, что место на разделе не заполнено
   sudo du -sh /var/log/*  # Посмотрите, какие логи самые большие
   

Возможные проблемы

• "Permission denied" при просмотре/очистке логов:
  • Решение: Всегда используйте sudo для системных логов. Проверьте права на файл (ls -l /var/log/syslog). Если приложение пишет в лог от своего пользователя, убедитесь, что у этого пользователя есть права на запись.
• Диск /var/ заполнен, система нестабильна:
  • Решение: Срочно очистите самые большие логи (шаг 4). Затем настройте агрессивную ротацию через logrotate или journald (уменьшите rotate и SystemMaxUse). Рассмотрите возможность переноса /var/log на отдельный раздел.
• Логи приложения не ротируются через logrotate:
  • Проверьте:
    1. Правильность пути к лог-файлу в конфиге /etc/logrotate.d/.
    2. Запускается ли logrotate (обычно через cron: grep logrotate /etc/crontab /etc/cron.*/*).
    3. Нет ли опечаток в конфиге (проверьте через logrotate -d).
    4. Не перекрывает ли ваша конфигурация настройки из основного logrotate.conf.
• После ротации приложение перестало писать в лог:
  • Решение: Чаще всего приложение нужно уведомить о смене файла. В блоке postrotate скрипта добавьте команду переоткрытия лога (например, kill -USR1 <pid> или systemctl reload service). Для многих демонов (nginx, apache) это стандартная практика.
• Journald не освобождает место после vacuum:
  • Проверьте, не смонтирован ли журнал в tmpfs (/run/log/journal). В этом случае он хранится в памяти и очищается при перезагрузке. Для постоянного хранения на диске убедитесь, что каталог /var/log/journal/ существует (sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald).