Опубликовано вНовости

Логи на VPS: как найти ошибки, сбои и причины падений

Логи на VPS: как найти ошибки, сбои и причины падений

Когда на VPS что-то ломается, проблема почти всегда оставляет след в логах. Журналирование подсказывает, что именно произошло, когда и на каком компоненте: ядро, сервисы systemd, веб-сервер, приложение, база данных, контейнеры. Задача в том, чтобы быстро собрать нужные фрагменты и не утонуть в шуме.

Ниже — практичная схема, где искать ошибки и сбои на типичном Linux-VPS, как фильтровать по времени и почему иногда “ничего не видно”.

Какие логи на VPS вообще бывают

На большинстве VPS встречаются несколько уровней журналов.

  • Журналы самого хоста: systemd journal, syslog/rsyslog, kern.log, сообщения ядра.
  • Журналы сервисов: nginx/apache, php-fpm, postgresql/mysql, redis, memcached, sshd.
  • Журналы планировщика и сервисов поддержки: cron/systemd timers, logrotate, certbot/renewal.
  • Логи приложений: файлы в директориях проекта или stdout/stderr контейнера/сервиса.
  • Логи окружения: Docker/Podman (обычно через journal или отдельные механизмы), иногда — логи сетевого уровня.

Если вы знаете, какой компонент затронут (например, “не открывается сайт”), вы почти всегда начнёте с его логов. Если причина неизвестна, начинают с общих системных журналов и статуса сервисов.

systemd journal: главный источник для ошибок и падений сервисов

На многих VPS используется systemd, а значит основная точка входа — journalctl. Даже если сервис пишет в файлы, systemd часто фиксирует события старта/остановки, падения и коды ошибок.

Где смотреть journal и какие команды базовые

Основной командный инструмент — journalctl. Типовые сценарии:

  • Просмотр логов текущей загрузки системы:
  • journalctl -b
  • Просмотр только ошибок и предупреждений:
  • journalctl -b -p err
  • journalctl -b -p warning
  • Поиск по конкретному сервису:
  • journalctl -u nginx —since «1 hour ago»
  • journalctl -u php-fpm —since «today»
  • Фильтрация по времени:
  • journalctl —since «2026-05-25 10:00» —until «2026-05-25 10:30»
  • Следить в реальном времени:
  • journalctl -f -u nginx

Если вы ищете “сбой” (crash, restart, exit code), почти всегда полезно посмотреть историю перезапусков и выходов процесса.

Что делать, когда журнал огромный

Журнал может быстро разрастаться. Чтобы не тратить время на лишнее:

  • ограничивайте период через —since/—until;
  • фильтруйте по приоритету: err, warning, emerg;
  • фильтруйте по unit: -u имя сервиса;
  • используйте поиск по строке:
  • — journalctl -u nginx —since «today»: grep -i «error»

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

Частые проблемы: нет логов, потому что они не пишутся

Иногда “логов нет” по простой причине: сервис не настроен на вывод в stdout/stderr или в systemd unit отсутствует запись. Для проверки смотрят настройки сервиса:

  • systemctl status nginx
  • systemctl cat nginx

Если падение происходит до старта логирования, единственным следом могут быть только события systemd (exit code, status=1). Поэтому полезно смотреть journal именно по unit.

Классические файлы логов: /var/log, syslog и kern.log

Даже если systemd доминирует, на многих VPS остаются традиционные логи в /var/log. Это бывает и потому, что некоторые компоненты пишут напрямую в файлы, и потому, что сохраняется привычная схема через rsyslog.

Где искать базовые системные сообщения

Чаще всего используют следующие пути:

  • /var/log/syslog или /var/log/messages (зависит от дистрибутива)
  • /var/log/kern.log (ядро, аппаратные сообщения)
  • /var/log/auth.log (аутентификация, sudo, ssh)
  • /var/log/daemon.log (разные системные демоны)
  • /var/log/cron.log (cron)

Примеры поиска:

  • Ошибки за сегодня:
  • grep -i «error» /var/log/syslog
  • Ошибки авторизации:
  • grep -i «authentication failure» /var/log/auth.log
  • Сообщения ядра:
  • grep -i «error» /var/log/kern.log

Если вы не знаете, что именно за сервис пишет в файлы, проще начать с journalctl по unit и посмотреть, есть ли ссылка на путь логов в конфиге.

Как не попасть в ловушку с ротацией логов

Ротация (logrotate) может переносить старые файлы в .1, .2.gz и т.д. Тогда “ранние ошибки” не найдутся в текущем файле.

Признаки проблемы:

  • вы ищете нужную дату, а в текущем лог-файле её нет;
  • есть только свежие записи.

Решение:

  • проверить наличие архивов: ls -lah /var/log/nginx
  • искать по архивам с zgrep:
  • zgrep -i «error» /var/log/nginx/error.log.1.gz

Ошибки веб-сервера: nginx и Apache

Для сайтов типичный сценарий выглядит так: браузер показывает ошибку, а сервер фиксирует её в access/error логах. На VPS это один из самых быстрых способов найти причину.

nginx: где искать ошибки и причины 4xx/5xx

Обычно в nginx есть два ключевых файла:

  • access.log: запросы (статусы, время, адрес)
  • error.log: ошибки (включая конфиги, upstream, таймауты)

Типовые действия:

  • Посмотреть последние ошибки:
  • tail -n 200 /var/log/nginx/error.log
  • Найти ошибку по времени (если знаете примерный интервал):
  • grep «2026/05/25» /var/log/nginx/error.log
  • Проверить, что было с конкретным upstream:
  • grep -i «upstream» /var/log/nginx/error.log

Для разборов проблем с php часто важны сообщения про fastcgi_pass и таймауты.

nginx: полезно смотреть конфиги и уровень логирования

Если error.log пустой, причина может быть в уровне логирования в конфиге nginx. Обычно это настраивается директивой error_log.

Смотрите, что реально используется:

  • — nginx -T: grep -n «error_log»

Если конфиг менялся перед сбоем, проверьте, не переключили ли уровень на “слишком тихий”.

Apache: где смотреть error_log и что добавить для диагностики

В Apache аналогично: есть errorlog и accesslog. Пути зависят от дистрибутива и конфигурации, но обычно это /var/log/apache2/error.log или /var/log/httpd/error_log.

Практика:

  • Последние ошибки:
  • tail -n 200 /var/log/apache2/error.log
  • Быстро найти строки про конкретный модуль:
  • grep -i «php» /var/log/apache2/error.log
  • Для проблем конфигурации полезны строки вида syntax error, unknown directive, module not found.

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

php-fpm и приложения на PHP: журналировать так, чтобы было видно сбои

Когда сайт на PHP падает, nginx и systemd покажут симптомы, но истинная причина чаще в php-fpm. Там бывают таймауты, нехватка процессов, ошибки конфигурации и падения воркеров.

Где обычно смотреть логи php-fpm

Точки зависят от версии и сборки, но часто используются:

  • /var/log/php8.x-fpm.log
  • либо journalctl -u php-fpm

Практика с systemd (удобно, если сервис единый):

  • — journalctl -u php8.2-fpm —since «today»: tail -n 200
  • journalctl -u php-fpm —since «1 hour ago»

Что искать в ошибках php-fpm

Паттерны, которые помогают быстро ориентироваться:

  • timeout / upstream timed out
  • primary script unknown / file not found (ошибки путей)
  • child exited / pool has reached max children (исчерпание процессов)
  • permission denied (права на директории, сокеты, файлы)

Если у вас есть только общий nginx error.log, но нет php-fpm логов, полезно проверить, включён ли вывод ошибок в php-fpm и не “глушится” ли журналирование.

Журналы баз данных: PostgreSQL, MySQL, MariaDB, Redis

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

PostgreSQL: что обычно важно

Для PostgreSQL логов несколько сценариев: конфигурация может писать в файл или через systemd/journald. Обычно ищут в:

  • каталоги с log в настройках PostgreSQL
  • либо journalctl -u postgresql

Практика:

  • — journalctl -u postgresql —since «today»: tail -n 200
  • если есть файлы, то смотреть последние error/warning.

Важные признаки:

  • deadlock detected (если проблема с конкурентностью)
  • timeout / terminating connection due to statement timeout
  • connection problems и ошибки WAL/репликации (если настроены)

MySQL/MariaDB: где смотреть ошибки соединения и запросов

Для MySQL/MariaDB также бывает сочетание файла и journald. В первую очередь ищут:

  • ошибки сервера (ошибки диска, повреждение, нехватка ресурсов)
  • проблемы соединений (max connections, handshake, auth plugin)
  • slow query log (если включён)

Если приложение начинает “тормозить”, slow query log часто даёт больше пользы, чем просто error.log.

Redis: ошибки памяти и сетевые проблемы

Redis чаще всего сообщает:

  • OOM / out of memory
  • connection errors
  • maxmemory policy / eviction

Ищут через:

  • journalctl -u redis-server —since «today»
  • или файлы, указанные в конфиге redis.

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

sshd, auth и доступ: когда “сбои” на самом деле проблемы доступа

Не каждый сбой — это падение сервисов. Иногда система работает, но вы не можете войти, не работает деплой, не доступны репозитории или ключи. Тогда в ход идут журналы аутентификации.

Где смотреть попытки входа и сбои

Типовые файлы:

  • /var/log/auth.log
  • иногда /var/log/secure

Примеры поиска:

  • неудачные входы:
  • grep -i «Failed password» /var/log/auth.log
  • grep -i «authentication failure» /var/log/auth.log
  • успешные входы:
  • grep -i «Accepted» /var/log/auth.log
  • события sudo:
  • grep -i «sudo» /var/log/auth.log

Почему sudo и ключи могут “внезапно сломаться”

Частые причины:

  • права на home и .ssh/authorized_keys стали неправильными;
  • поменялись пользователи/группы;
  • обновление конфигов sshd изменило политику (например, запрет паролей);
  • закончились ключи деплоя или изменились строки authorized_keys.

Слои ошибок обычно видно в auth.log раньше, чем вы успеете заметить “просто не работает”.

Cron, systemd timers и фоновые задачи

Если у вас периодические задания (обновления, бэкапы, очистка очередей), сбой может происходить не постоянно, а “пачками”. В таком случае ключ к диагностике — найти конкретный тайминг.

Где искать cron-ошибки

Пути зависят от системы, но часто:

  • /var/log/cron.log
  • /var/log/syslog (cron сообщения там тоже бывают)

Поиск:

  • grep CRON /var/log/syslog
  • grep -i «error» /var/log/cron.log

systemd timers: что смотреть

Если вместо cron используются systemd timers, удобно смотреть:

  • systemctl list-timers —all
  • — journalctl —since «today»: grep -i «timer» (или по unit конкретного задания)

Ещё один полезный ход: если задания вызывают скрипт, их ошибки чаще всего печатаются в stderr/stdout. Тогда они попадают в journal и их можно фильтровать.

Сеть, firewall и маршрутизация: логи, которые объясняют “похоже, что не работает”

Иногда сайт “не открывается” из-за сетевых ограничений: firewall, неправильные правила, блокировки по стране/диапазону, лимиты на уровне провайдера. В таких случаях полезны сетевые логи.

Где искать события firewall

Если используется UFW:

  • — journalctl —since «today»: grep -i «ufw»

Если nftables/iptables напрямую:

  • — journalctl —since «today»: grep -i «nft»
  • либо смотрят kern.log и сообщения ядра (зависит от настройки)

Если вам нужно “быстро понять” — смотрите записи, где есть действие блок/accept и источник/назначение. Точные пути и названия зависят от того, как именно настроен VPS, но ядро и system journal обычно дадут направление.

Типичные сетевые симптомы в логах

  • connection refused (порт не слушает или firewall блокирует)
  • timeout (маршрут/фильтрация/ресурсные проблемы)
  • reset by peer (часто конкретный сервис закрывает соединение)
  • слишком много rejections (правила применяются слишком широко)

Сопоставляйте время с тем, когда вы наблюдали проблему. Если “в 12:05 всё упало”, лог должен показать изменения примерно в этот интервал.

Ядро и аппаратные ошибки: dmesg и kern.log

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

Где смотреть kernel messages

  • dmesg (показывает текущую кольцевую буферизацию ядра)
  • /var/log/kern.log (если настроено)

Практика:

  • — dmesg: grep -i «error»
  • tail -n 200 /var/log/kern.log

Если система перезагружалась, dmesg может не сохранить исторические записи до полной перезаписи буфера. Тогда более надёжно смотреть journald и kern.log, если журнал сохраняется.

На что обращать внимание

  • ошибки I/O (диск, файловая система)
  • сообщения про OOM killer (убийство процессов из-за памяти)
  • ошибки драйверов (сетевые карты, блочные устройства)
  • watchdog reset (если есть перезапуск из-за зависаний)

Это как раз те случаи, когда приложение “вроде бы ни при чём”, но перезапуски повторяются и падают один за другим.

Контейнеры и логи Docker/Podman: где искать, когда процессы живут не на “голом” хосте

Если на VPS используются контейнеры, “где смотреть ошибки” меняется. Часть логов остаётся в journald, часть — в Docker logs, часть — внутри контейнера.

Быстрый старт: логи контейнера

Обычно используют:

  • docker ps
  • docker logs <containeridor_name> (с опциями времени, если доступны в вашей версии)

Если контейнер перезапускается, полезно посмотреть последние строки и понять, почему он падает:

  • docker logs —tail 200 <container>

Как связать логи контейнера с сервисом на хосте

Иногда контейнер запускается через systemd unit или compose. Тогда вы снова приходите к systemd journal:

  • journalctl -u <unit> —since «today»

Часто именно там видно цепочку: “контейнер не поднялся → сервис перезапускается → приложение не отвечает”.

Типичные ошибки в контейнерных логах

  • логирование отключено в приложении, а контейнер пишет пусто;
  • приложение пишет в файл внутри контейнера, но вы не монтировали volume, поэтому файлы исчезают при пересоздании;
  • коды ошибок есть, но в логах не настроены уровни и нет понятных строк (например, нет traceback).

Если вы проектируете запуск контейнера, удобно заранее настроить вывод ошибок в stderr, чтобы они попадали в docker/journal.

Как искать причину: рабочий порядок действий при “сбой начался сейчас”

Когда инцидент происходит, важна последовательность. Иначе вы будете смотреть всё подряд и ничего не найдёте.

Шаг 1. Зафиксируйте интервал

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

Примеры:

  • journalctl —since «15 minutes ago» -p err
  • — grep -i «error» /var/log/nginx/error.log: tail

Шаг 2. Определите затронутый компонент

Если сайт не отвечает — nginx + php-fpm + приложение. Если отвечает, но выдаёт ошибки — часто приложение и база. Если не можете войти — auth/ssh.

Это экономит много времени: один час чтения лога “в целом” почти всегда хуже, чем 10 минут по конкретному сервису.

Шаг 3. Снимите “верхушку” проблем

Для быстрых выводов:

  • посмотрите последние ошибки (tail)
  • отфильтруйте по err
  • проверьте exit code и перезапуски (systemd unit)

Шаг 4. Ищите связующие строки

Чтобы связать симптомы и причину, ищите уникальные маркеры:

  • request id / correlation id (если приложение поддерживает)
  • upstream name и upstream timeout
  • конкретные пути файлов и имена модулей
  • номера версий/коммитов, если деплой пишет в лог

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

Полезные приёмы: grep, journalctl, tail и “чтение без паники”

Логи — это текст. Значит, вам нужны инструменты, которые позволяют не терять контекст.

Сочетание journalctl и grep

  • — journalctl -u nginx —since «today»: grep -i «upstream timed out»
  • — journalctl -p err —since «today»: grep -i «fatal»

Если grep сработал, выпишите 2-3 строки вокруг находки (не только одну). Так обычно видно цепочку: сначала warning, потом error.

tail -f для живого следа

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

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

или

  • journalctl -f -u php-fpm

Это помогает поймать момент, когда ошибка возникает, и не поднимать архивы.

Ошибка: искать по “error” слишком буквально

Проблемы бывают с другой формулировкой: fatal, panic, crash, refused, timeout, segfault. Слепой grep по error может дать ложное ощущение “всё чисто”.

Лучше составить несколько поисковых слов под ваш стек:

  • для веба: 502, timeout, upstream, connect() failed
  • для PHP: PHP Fatal, child exited, max children
  • для БД: deadlock, timeout, terminating connection
  • для системы: OOM, killed process, segfault, watchdog

Почему “ошибки есть”, но вы их не видите

Иногда в момент сбоя логов нет не потому, что всё хорошо, а потому что журналирование настроено неудачно.

Типичные причины

  • неверный путь к логам (смотрите не тот файл, либо он не обновляется);
  • лог-файл не существует, потому что нет прав на запись;
  • логирование направлено в stdout/stderr, но вы смотрите только файлы;
  • включена слишком строгая фильтрация по уровню (например, error_log на слишком низком уровне);
  • ротация быстро “выносит” нужные записи;
  • приложение пишет в файл внутри контейнера без volume, и при перезапуске всё пропадает.

Если вы подозреваете такую ситуацию, начните с systemd status и unit конфигов, а затем сверяйте, куда направлены выводы.

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

После того как инцидент закрыт, полезно сделать настройку логирования более удобной. Цель не в “написать больше”, а в “писать так, чтобы быстро найти причину”.

Что можно улучшить на уровне сервисов

  • убедитесь, что systemd unit получает stdout/stderr приложения;
  • настройте разумные уровни логов для nginx/php-fpm;
  • включите корреляцию request id в приложении (если оно поддерживает);
  • настройте ротацию логов так, чтобы не потерять ключевой период.

Частая ошибка: хранить бесконечно и не утилизировать

Если не настроена ротация или ограничения, диск может закончиться. Тогда вы получите новый инцидент: система перестанет писать логировать и даже сервисы могут упасть из-за нехватки места.

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

Чек-лист: где смотреть ошибки и сбои на VPS (быстро по приоритету)

Если нужно действовать быстро, держите порядок.

  • systemd journal:
  • journalctl -b -p err
  • journalctl -u <сервис> —since «<интервал>»
  • веб-слой:
  • nginx: /var/log/nginx/error.log и access.log
  • apache: /var/log/apache2/error.log (или аналог)
  • php-fpm:
  • journalctl -u php-fpm (или php8.x-fpm)
  • база данных:
  • journalctl -u postgresql/mysql/redis (в зависимости от стека) или файлы логов БД
  • доступ/ssh:
  • /var/log/auth.log или /var/log/secure
  • фоновые задачи:
  • /var/log/cron.log или journalctl по unit timers
  • ядро/диск/память:
  • /var/log/kern.log и dmesg для OOM, I/O error, перезапусков
  • контейнеры:
  • docker logs + journalctl по unit, через который они запускаются

Если вы делаете всё по этому списку и не находит причину, значит проблема может быть “на границе”: в лимитах (CPU/IO), в конфигурации (не тот порт/сокет), или в отсутствии логирования внутри приложения.

Как сформировать запрос “посмотрите логи” так, чтобы вам реально помогли

Если вы работаете в команде или отдаёте проблему специалисту, формат имеет значение. Полезный пакет обычно содержит:

  • интервал времени сбоя (например, “с 12:05 до 12:20 МСК”);
  • затронутый сервис/endpoint (например, “/login на сайте”);
  • последние N строк error логов (nginx/apache/php-fpm/БД);
  • фрагмент journalctl по unit с —since/—until;
  • признак воспроизводимости (падает постоянно или раз в день/по расписанию).

Так вы ускоряете диагностику и избегаете ситуации, когда в ответ приходит вопрос “а где это смотреть”.

Заключение

Чтобы находить ошибки и сбои на VPS, важно знать не один “правильный файл”, а несколько источников и порядок, в котором их проверять. Начинайте с systemd journal по времени и unit — это чаще всего даёт точный контекст падений. Затем переходите к логам веб-сервера, php-fpm, базы и доступа, а при признаках нестабильности системы — к ядру и kern.log.

Соберите для своего VPS небольшой персональный сценарий: какие unit у вас есть, где лежат nginx/apache/php-fpm логи, и как быстро отфильтровать записи по интервалу. В следующий раз, когда “вдруг перестало работать”, вы будете разбирать проблему не часами, а минутами.