Как посмотреть логи сервера

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

Короткий ответ, если нужно прямо сейчас. В Linux логи лежат в каталоге /var/log/, смотрят их командой tail -f, а службы под systemd - через journalctl. В Windows - в оснастке «Просмотр событий», она же eventvwr.msc.

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

Где лежат логи: таблица путей

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

Общее правило для Linux: почти всё лежит в /var/log/ и его подкаталогах. Если не знаете, что именно ищете, начните с просмотра содержимого этого каталога.

Отдельная история - systemd. Современные службы пишут не в текстовые файлы, а в двоичный журнал systemd, и обычным cat его не прочитать. Для него есть своя команда, о ней ниже.

Как посмотреть логи в Linux

Четыре команды закрывают почти все задачи.

Смотреть в реальном времени

tail -f /var/log/nginx/error.log

Файл остаётся открытым, и новые строки появляются на экране по мере записи. Это основной режим при отладке: запускаете команду, воспроизводите проблему, смотрите, что пишется. Выход - Ctrl+C.

Посмотреть последние строки

tail -n 100 /var/log/syslog

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

Найти нужное

grep "error" /var/log/nginx/error.log
grep -i "failed password" /var/log/auth.log

Первая команда вытащит строки со словом error, вторая - неудачные попытки входа без учёта регистра. Полезное сочетание - grep вместе с tail:

tail -f /var/log/nginx/access.log | grep " 500 "

Так вы видите в реальном времени только пятисотые ошибки, а остальной поток вас не отвлекает.

Журнал systemd

journalctl -u nginx
journalctl -u nginx -f
journalctl --since "1 hour ago"
journalctl -p err -b

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

Подробнее про управление службами - в гайде по systemd.

Как посмотреть логи в Windows

В Windows логи хранятся не файлами, а в собственной подсистеме событий.

Через интерфейс. Нажмите Win+R, введите eventvwr.msc. Откроется «Просмотр событий». Основные разделы - «Журналы Windows»: Приложение, Безопасность, Система. Ошибки удобно отфильтровать: правая панель → «Фильтр текущего журнала» → уровень «Ошибка» и «Критическое».

Через PowerShell. Быстрее, когда нужно что-то найти:

Get-WinEvent -LogName System -MaxEvents 50
Get-WinEvent -FilterHashtable @{LogName='System'; Level=2} -MaxEvents 20

Первая покажет полсотни последних событий системного журнала, вторая - только ошибки (уровень 2).

У каждого события есть код (Event ID) - по нему проще всего искать причину. Код плюс название службы в поисковике обычно приводят к ответу быстрее, чем чтение описания события.

Логи веб-сервера: Apache и Nginx

У обоих серверов по два основных файла, и путать их не стоит.

access.log - все запросы к сайту. Кто пришёл, что запросил, что получил в ответ.
error.log - ошибки самого веб-сервера и приложения: отказы, недоступные файлы, проблемы с правами.

Как читать строку access.log

Типовая строка выглядит так:

192.0.2.10 - - [29/Jul/2026:10:15:32 +0300] "GET /price.pdf HTTP/1.1" 404 153 "https://example.com/" "Mozilla/5.0..."

Разбирается она по порядку: адрес клиента, время запроса, метод и путь, код ответа, размер ответа в байтах, откуда пришёл посетитель, каким браузером.

Ключевое здесь - код ответа:

Быстрый способ понять, что происходит с сайтом, - посчитать коды ответов за сегодня:

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

Команда выведет список кодов с количеством. Если пятисотых стало заметно больше обычного - идти в error.log.

Логи почты, FTP и PHP

Почта. В Debian и Ubuntu - /var/log/mail.log, в RHEL - /var/log/maillog. Там видно приём и отправку писем, отказы доставки и причины отклонения. Первое, куда смотрят, когда «письма не уходят».

FTP. Расположение зависит от службы: у vsftpd путь задаётся в конфигурации (/var/log/vsftpd.log по умолчанию), у ProFTPD пишется через syslog. Смотрят подключения, аутентификацию и передачу файлов.

PHP. Здесь чаще всего и возникает вопрос «где хранятся логи php». Ответ: там, куда указывает параметр error_log в php.ini. Если он не задан, ошибки уходят в лог веб-сервера - то есть в error.log Apache или Nginx. Посмотреть текущее значение:

php -i | grep error_log

Отдельно проверьте log_errors = On - без этого PHP не пишет ошибки вообще.

Логи СУБД

О базах данных в статьях про логи забывают, а зря: половина «тормозов сайта» видна именно там.

PostgreSQL пишет в каталог внутри своей директории данных, обычно /var/log/postgresql/ в Debian и Ubuntu. Первое, что там настраивают, - log_min_duration_statement: он заставляет записывать запросы дольше заданного порога. Это самый короткий путь к списку медленных запросов.

MySQL и MariaDB держат журнал ошибок (/var/log/mysql/error.log или /var/log/mysqld.log) и отдельный журнал медленных запросов, который включается параметрами slow_query_log и long_query_time.

MS SQL Server ведёт свой журнал ошибок, доступный через SQL Server Management Studio, и дополнительно пишет часть событий в журнал приложений Windows.

Общая логика одна: у СУБД есть журнал ошибок и журнал медленных запросов. Первый нужен, когда база не поднимается, второй - когда она поднимается, но всё тормозит.

Как читать логи: что искать

Открыть файл мало, в нём тысячи строк. Порядок, который экономит время.

Сначала время. Определите, когда именно случилась проблема, и смотрите только этот промежуток. Отсюда, кстати, важность синхронизации часов: если время на серверах разъехалось, события в разных журналах не сойдутся в одну картину - подробнее в материале про NTP-сервер.

Потом уровень. В большинстве логов у записи есть уровень: info, warning, error, critical. Начинайте с ошибок и критических, информационные пропускайте.

Ищите первую ошибку, а не последнюю. Сбой обычно тянет за собой каскад сообщений. Ценность имеет самая ранняя запись в цепочке - остальное её следствия.

Смотрите, что было до. Часто причина видна в предупреждениях за несколько минут до отказа: кончалось место, росло время ответа, сыпались повторные подключения.

Не доверяйте одному источнику. Если приложение упало, посмотрите заодно системный журнал: возможно, его убил механизм нехватки памяти, и в логе самого приложения об этом ничего не будет.

Ротация логов: чтобы диск не кончился

Логи растут постоянно, и забитый под завязку раздел с /var/log - классическая причина отказа сервера. За это отвечает logrotate.

Настройки лежат в /etc/logrotate.conf и в отдельных файлах для каждой службы в /etc/logrotate.d/. Задаётся в них обычно четыре вещи: как часто вращать (ежедневно, еженедельно), сколько копий хранить, сжимать ли старые файлы и что делать со службой после ротации.

Проверить, как отработает конфигурация, не дожидаясь ночи:

logrotate -d /etc/logrotate.conf

Ключ -d запускает в режиме проверки, без реальных действий.

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

truncate -s 0 /var/log/nginx/access.log

Зачем нужны логи

Коротко, по делу.

• Диагностика. Сбой почти всегда оставляет след. Логи - первое место, куда смотрят, когда что-то перестало работать.
• Безопасность. Неудачные попытки входа, обращения к чужим файлам, необычная активность - всё это видно в журналах. Как выстроить это системно, разобрано в статье про мониторинг безопасности серверов.
• Расследование. Кто и когда изменил файл, удалил данные, поменял настройки. Тема отдельно разобрана в материале про аудит файлов на файловом сервере.
• Раннее предупреждение. Ошибки дисков и памяти появляются в системном журнале задолго до отказа. Это тот случай, когда чтение логов экономит не время, а данные.
• Требования. В ряде отраслей хранение журналов - обязательное требование, а не выбор администратора.

Когда серверов становится больше нескольких, читать логи на каждом руками нереально. Тогда их собирают централизованно - в syslog-сервер или систему мониторинга. Что и как отслеживать, разобрано в комплексном мониторинге серверов.

Короткие ответы

Где хранятся логи на сервере?
В Linux - в /var/log/ и подкаталогах: /var/log/syslog или /var/log/messages для системных событий, /var/log/nginx/ и /var/log/apache2/ для веб-сервера. В Windows - в подсистеме событий, открывается через eventvwr.msc.

Как посмотреть логи в реальном времени?
tail -f /путь/к/файлу для текстовых логов, journalctl -u имя_службы -f для служб systemd.

Где хранятся логи PHP?
Там, куда указывает параметр error_log в php.ini. Если он не задан, ошибки пишутся в лог веб-сервера. Проверить: php -i | grep error_log.

Чем access.log отличается от error.log?
В access.log попадают все запросы к сайту с кодами ответов, в error.log - только ошибки веб-сервера и приложения. При пятисотых ошибках причину ищут в error.log.

Почему после удаления лога не освободилось место?
Служба продолжает писать в удалённый файл. Вместо rm используйте truncate -s 0 или перезапустите службу.

Как посмотреть логи, если служба не запускается?
Через journalctl -u имя_службы. Причина отказа при старте пишется в журнал systemd, а не в файл логов самой службы - он в этот момент может быть ещё пустым.

Что означает код 502 в логах?
Веб-сервер не получил ответа от бэкенда - обычно от PHP-FPM или приложения. Смотреть надо логи этого бэкенда, а не веб-сервера.

Коротко о главном

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

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