Большинство системных служб и программ в Linux пишут логи. В статье разбираемся, что это такое, для чего могут понадобиться, а также — где они находятся и как их правильно читать.
Логи (лог-файлы, журналы) — это файлы, в которые в хронологическом порядке записывается служебная информация: события, ошибки, предупреждения и действия пользователей. Эти данные критически важны для диагностики сбоев, анализа производительности и расследования инцидентов безопасности.
Именно логи позволяют понять, что происходило с сервером в определённое время, то есть фактически восстановить ход событий и найти причину возникших проблем или выявить потенциальную угрозу безопасности сервера.
Обычно администратору приходится работать со следующими типами журналов:
- Системные логи (ядро, авторизация, загрузка).
- Логи веб-сервера (Nginx, Apache, php-fpm).
- Логи баз данных (MySQL/MariaDB, PostgreSQL).
- Логи почтовых и FTP-служб.
Конечно, этим список логов не исчерпывается, но именно эти категории мы разберем подробнее, как наиболее критичные для базового анализа состояния сервера.
Где хранятся логи
Стандарт де-факто для хранения журналов в Linux — директория /var/log. Внутри нее создаются файлы или отдельные подпапки для каждого сервиса.
Важные исключения:
- Кастомное ПО: Программы, установленные в /opt, часто хранят логи внутри своей директории.
- Панели управления: Если вы используете панели (ispmanager, cPanel, Plesk), пути могут отличаться. Например, ispmanager складывает логи виртуальных хостов веб-сервера в /var/www/httpd-logs.
- Docker: В контейнерных средах логи часто пишутся в stdout/stderr и перехватываются драйвером логирования (задается при создании контейнера), а не пишутся в файлы внутри контейнера.
Примечание: Пути к файлам могут отличаться в зависимости от семейств дистрибутивов. В статье мы будем разделять их на Debian-based (Ubuntu, Debian) и RedHat-based (CentOS, AlmaLinux, Rocky Linux и др.).
Как читать логи
Прежде чем разбирать, где лежат логи, нужно понять, чем их открывать. Логи — это текстовые файлы, но они могут быть огромными, поэтому обычные редакторы (вроде nano или vim) для чтения не всегда подходят. Но можно воспользоваться специальными утилитами, которые обрабатывают текст и выдают результат в зависимости от поставленной задачи.
Основные утилиты
- tail — для оперативного мониторинга. Самый популярный инструмент.
- tail -f /path/to/logfile — режим «прямого эфира». Новые строки появляются на экране в момент записи. Идеально для отладки: запустили команду, сделали действие на сайте, увидели ошибку.
- tail -n 100 /path/to/logfile — показать последние 100 строк.
- less — для вдумчивого чтения. Позволяет открывать большие файлы без загрузки их целиком в оперативную память.
- Листать: стрелки вверх/вниз или PageUp/PageDown.
- Поиск: нажмите /, введите текст (например, error) и нажмите Enter.
- Клавиша n ищет следующее совпадение.
- Переход в конец/начало: G (конец), g (начало).
- Выход: клавиша q.
- grep — для фильтрации. Если вы знаете, что ищете, нет смысла читать весь файл.
- grep 'Fatal Error' /var/log/syslog — выведет только строки, содержащие фразу "Fatal Error".
- cat log.txt | grep '502 Bad Gateway'— классический пайплайн. Этим словом обозначают использование символа | (pipe) для передачи вывода одной команды на вход команде, в данном случае, grep (или наоборот). Это дает возможность фильтровать данные последовательно.
- zgrep — это grep, который умеет читать сжатые файлы (обычно .gz) без предварительного распаковывания. Очень удобно для архивных логов: после ротации logrotate сжимает старые файлы (об этом расскажем позже), а zgrep позволяет сразу по ним искать.
- zgrep "что_ищем" файл.log.gz — стандартный пример поиска.
- zgrep -i "timeout" /var/log/mysql/error.log.1.gz — регистронезависимый поиск.
Системные логи
Это основа сервера. Если сервер перезагрузился, завис или к нему подбирают пароль — смотреть нужно в первую очередь системные логи.
Главный системный журнал
В нём собирается информация от большинства служб, которые не имеют своих собственных лог-файлов.
- Debian-based: /var/log/syslog
- RedHat-based: /var/log/messages
Современный стандарт (Systemd): В актуальных дистрибутивах (Ubuntu 20.04+, CentOS 7+) используется система инициализации systemd, которая имеет свой бинарный журнал — journald. Для его просмотра используется команда journalctl.
- journalctl -xe — последние события с подробностями.
- journalctl -u nginx — логи конкретной службы.
Логи ядра (Kernel)
В этих логах вы найдете сообщения драйверов, определение оборудования, ошибки железа. Важно помнить: эти логи ведутся с момента старта сервера. После перезагрузки они обнуляются (но старые могут сохраняться в архивах).
- Файл: /var/log/kern.log или /var/log/dmesg.
- Команда: dmesg -T (выводит буфер сообщений ядра в читаемом виде с временными метками).
Логи авторизации и безопасности
Здесь фиксируются входы по SSH, использование sudo, создания пользователей и попытки брутфорса (подбора паролей).
- Debian-based: /var/log/auth.log
- RedHat-based: /var/log/secure
Прочие системные логи
- /var/log/boot.log — сообщения этапа загрузки ОС.
- /var/log/cron — журнал планировщика задач (запускались ли ваши скрипты по расписанию).
Логи веб-сервера
Так как на VDS чаще всего размещают именно веб-проекты, не менее важными можно считать логи веб-сервера. Веб-серверы генерируют два основных типа логов:
- Access log (журнал посещений) — кто пришел, с какого IP, какую страницу запросил, какой код ответа получил (200, 404, 500).
- Error log (журнал ошибок) — почему сервер не смог обработать запрос.
Рассмотрим, как это реализовано в двух самых популярных веб-серверах — Nginx и Apache, а также затронем логи PHP-интерпретатора, который часто работает в связке с ними.
Nginx
Обычно Nginx стоит как фронтенд (принимает запросы первым).
- Папка: /var/log/nginx/
- Файлы: access.log и error.log. Для каждого сайта в конфигурации Nginx (server { ... }) можно (и нужно) задать свои отдельные файлы логов.
Apache
Часто работает как бэкенд в связке с Nginx или самостоятельно.
- Папка: /var/log/apache2/ (Debian) или /var/log/httpd/ (RHEL).
- Файлы: access.log и error.log.
PHP-интерпретатор
Если сайт работает на PHP, ошибки кода (например, "Call to undefined function") нужно искать именно здесь, а не в логах Nginx.
- Папка: /var/log/php-fpm/
- Настройка: Часто ошибки PHP пишутся прямо в error.log веб-сервера Apache или Nginx, если так настроено.
- Индивидуальная настройка: В php.ini или пуле PHP-FPM можно задать php_error.log в папку конкретного пользователя.
Логи баз данных
Логи базы данных — основной источник диагностики при падениях, тормозах или аномалиях. Они показывают ошибки подключений, сбои выполнения запросов, нехватку ресурсов и другие события, которые не видны извне.
Далее — примеры для двух распространённых в Linux СУБД: MySQL/MariaDB и PostgreSQL. Принципы для остальных БД схожи.
MySQL / MariaDB
Базы данных стараются писать в лог только критически важные события, чтобы не снижать быстродействие.
- Папка: /var/log/mysql/ или /var/log/mariadb/.
- Error log: error.log — сообщения о старте, остановке и критических сбоях.
- Slow Query Log: mysql-slow.log — сюда попадают SQL-запросы, которые выполняются дольше заданного времени (например, дольше 2 секунд). По умолчанию отключен, включается в my.cnf для оптимизации производительности.
PostgreSQL
У PostgreSQL структура логов более гибкая и зависит от настроек (можно настроить уровень детализации, есть различные параметры логирования).
- Папка: /var/log/postgresql/ (Debian) или /var/lib/pgsql/data/pg_log/ (RHEL).
- Если включен параметр logging_collector, ищите файлы с датой в названии, например postgresql-2023-10-25.log.
Почта и FTP
Хотя эти службы сегодня используются реже, их логи могут быть критически важны для решения конкретных задач:
- Почта — когда письма не доходят, уходят в спам или нужно проверить попытки несанкционированной рассылки.
- FTP — для аудита загрузок/скачиваний файлов, если этот устаревающий протокол ещё используется.
Далее — о расположении логов этих служб.
Почтовый сервер
В популярных связках (Exim/Postfix + Dovecot):
- Exim: /var/log/exim/mainlog (основной) и panic.log (критические ошибки).
- Postfix/Dovecot: Часто пишут в общий /var/log/maillog или /var/log/mail.log. Сюда попадает информация о доставке писем, антиспам-проверках и авторизации пользователей IMAP/POP3.
FTP-сервер
Менее популярен сегодня, но если используется:
- vsFTPd: /var/log/vsftpd.log
- ProFTPd: /var/log/proftpd.log
- xferlog: Стандартный файл для многих служб, фиксирующий именно передачу файлов (кто и какой файл скачал/загрузил).
Ротация логов
Сервисы пишут логи непрерывно. Если этот процесс не контролировать, один только access.log посещаемого сайта может за неделю забить всё свободное место на диске.
Для решения этой проблемы используется встроенный механизм ротации (утилита logrotate). Его базовые настройки обычно уже присутствуют в системе по умолчанию для ключевых сервисов.
Как это работает:
- Раз в заданный период (обычно раз в сутки) текущий файл лога (например, syslog) переименовывается (в syslog.1).
- Создается новый пустой файл syslog, куда продолжается запись.
- Старый файл syslog.1 сжимается архиватором gzip (превращается в syslog.2.gz).
- Самые старые архивы (например, старше 14 дней) удаляются.
Настройки ротации лежат в /etc/logrotate.conf и папке /etc/logrotate.d/. Если место на сервере исчезает слишком быстро, стоит проверить настройки ротации и уменьшить количество хранимых копий.
Ротация логов в Linux с помощью logrotate
Читать
Мы разобрали основные типы логов: системные, веб-сервера, почты, FTP и баз данных. На практике их гораздо больше — приложения пишут свои: от очередей задач до мониторинга и кастомных сервисов.
Для удобства можно использовать универсальный принцип поиска и изучения логов:
- Сначала смотрите конфиг службы — обычно в /etc/название/. Ищите параметры с log, path, file.
- Если конфиг неясен — запросите настройки внутри самой службы (например, SHOW VARIABLES в MySQL, SHOW ALL в PostgreSQL).
- Проверьте, пишет ли служба в stdout/stderr — тогда логи будут в journalctl -u название или в /var/log/syslog.
- Для просмотра используйте упомянутые в начале утилиты: tail -f, grep, less и для архивов — zgrep.
Главное: лог почти всегда настраивается явно. Не видите файл — скорее всего, логирование выключено или перенаправлено в журнал системы. Включайте, настраивайте уровень детализации — и лог станет вашим союзником в диагностике.