Как читать системные логи Linux: инструкция для новичков

Если ваш сервер внезапно перестал отвечать, сайт открывается с ошибкой или служба отказывается запускаться — первое, что нужно сделать, это заглянуть в системные логи Linux. Логи — это подробный дневник событий операционной системы. В нём записано всё: от момента включения питания до последнего действия пользователя. Для новичка чтение логов может показаться сложным, но на самом деле это один из самых надёжных способов понять, что именно происходит с сервером и где искать причину неполадки.

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

Что такое системные логи Linux и зачем они нужны

Системные логи (журналы, logs) — это файлы, в которые операционная система и установленные на ней программы записывают информацию о своей работе. Каждое событие — запуск службы, подключение пользователя, ошибка в работе приложения — попадает в журнал с указанием времени и деталями произошедшего.

Представьте, что вы системный администратор, который обслуживает несколько десятков серверов. Вы не можете сидеть перед монитором каждого из них круглосуточно. Логи становятся вашими «глазами и ушами». Именно они сообщают, кто обращался к сайту, какие ошибки возникали, почему перестал работать тот или иной сервис.

Умение читать системные логи Linux даёт вам следующие возможности:

• Быстро находить причину сбоев. Вместо того чтобы гадать, почему сайт выдаёт ошибку 500, вы открываете лог и видите конкретную строку с описанием проблемы.
• Отслеживать работу сервисов. Например, узнавать, когда и почему остановилась база данных или веб-сервер.
• Повышать безопасность. Логи фиксируют попытки несанкционированного доступа, подбор паролей и другие подозрительные действия.
• Собирать аналитику. По логам можно оценить нагрузку на сервер, частоту запросов и пиковые периоды активности.

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

Облачные серверы от ₸2075 / месIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%Попробовать

Как устроено логирование в Linux

В современных дистрибутивах Linux (таких как Ubuntu 16.04+, Debian 8+, CentOS 7+, RHEL 7+) за сбор и хранение логов отвечает systemd-journald — компонент системы инициализации systemd. Этот демон собирает сообщения из разных источников: ядра, системных служб, приложений, а также сообщения, совместимые со старым стандартом syslog.

Данные хранятся в структурированном бинарном формате в каталоге /var/log/journal/ (при включённом постоянном хранении) или /run/log/journal/ (для временных журналов, которые теряются после перезагрузки). Для чтения этих журналов используется утилита journalctl.

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

Основные компоненты системы логирования:

• systemd — менеджер системы и служб.
• systemd-journald — демон, который собирает и хранит логи.
• journalctl — команда для просмотра и фильтрации журналов.

Каждая запись в журнале содержит метаданные: временную метку, имя службы, идентификатор процесса, идентификатор пользователя, приоритет, имя хоста и идентификатор загрузки. Это позволяет гибко фильтровать информацию при поиске.

Как работать с логами на VPS Serverspace

На виртуальном сервере Serverspace журналы Linux устроены так же, как на любой другой машине с Ubuntu, Debian, CentOS или другим поддерживаемым дистрибутивом. После создания VPS вы подключаетесь по SSH с административными правами и можете читать journalctl, файлы в /var/log/, логи Nginx, Docker, базы данных и собственных приложений.

При этом панель управления Serverspace дополняет диагностику на уровне операционной системы:

• Можно быстро развернуть отдельный тестовый VPS. Linux-сервер создаётся примерно за 40 секунд, а тарификация идёт каждые 10 минут. Это удобно, когда нужно воспроизвести ошибку в изолированной среде, не затрагивая production-сервер.
• Ресурсы можно изменить после диагностики. Если в логах появляются сообщения об исчерпании памяти, нехватке места или перегрузке приложения, в панели можно скорректировать vCPU, RAM, SSD и параметры сети под фактическую нагрузку.
• Перед рискованными изменениями можно создать снимок сервера. Он пригодится как точка возврата перед обновлением системы, изменением конфигурации службы или установкой нового ПО. При этом снимок не заменяет отдельное хранение важных логов и резервных копий данных.
• Инфраструктуру можно автоматизировать. Для нескольких серверов доступны API, CLI и Terraform: с их помощью удобно создавать одинаковые тестовые окружения и стандартизировать базовую конфигурацию машин.
• Управление сосредоточено в одной панели. Там можно работать с виртуальными серверами, сетями, снимками и расходами, а при необходимости — обратиться в круглосуточную поддержку через тикет-систему.

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

Пошаговое руководство: как читать системные логи Linux

Теперь перейдём к практике. Рассмотрим основные команды и приёмы работы с журналами.

Шаг 1. Просмотр всех системных логов

Самый простой способ увидеть все системные логи — выполнить команду journalctl без параметров. Вы увидите все записи в хронологическом порядке — от самых старых к самым новым.

journalctl

Обычно вывод занимает несколько экранов. Для навигации используйте клавиши Пробел (пролистывание вперёд), b (назад) и q (выход).

Если вы хотите просмотреть логи традиционных текстовых файлов, загляните в каталог /var/log/. Там вы найдёте такие файлы:

Для просмотра таких файлов используйте стандартные команды: cat, less, tail.

Шаг 2. Просмотр логов в реальном времени

Если вы хотите наблюдать за событиями в системе прямо сейчас, используйте ключ -f (от англ. follow — следить). Это аналог tail -f для системного журнала.

journalctl -f

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

Для традиционных логов можно использовать команду tail -f /var/log/syslog (или /var/log/messages в зависимости от дистрибутива).

Шаг 3. Фильтрация по времени

Полный журнал может быть огромным. Гораздо эффективнее сузить поиск до определённого периода. journalctl позволяет указывать временные диапазоны с помощью ключей --since и --until.

Примеры:

journalctl --since "1 hour ago"

Покажет логи за последний час.

journalctl --since "2026-08-01" --until "2026-08-02"

Покажет логи за 1 августа 2026 года.

journalctl --since "2026-08-01 08:00:00" --until "2026-08-01 09:00:00"

Покажет логи с 8 до 9 утра.

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

Шаг 4. Просмотр логов конкретной службы

Вместо того чтобы просматривать весь системный журнал, можно сфокусироваться на одной службе. Для этого используйте ключ -u (от unit — юнит).

journalctl -u nginx

Покажет все логи веб-сервера Nginx.

journalctl -u sshd

Покажет логи SSH-сервера (включая попытки входа).

journalctl -u docker

Покажет логи Docker.

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

Шаг 5. Фильтрация по уровню важности (приоритету)

Каждое сообщение в журнале имеет приоритет — от emerg (авария) до debug (отладочная информация). С помощью ключа -p можно показывать только сообщения определённого уровня и выше.

Таблица приоритетов журналов systemd:

Примеры:

journalctl -p err

Покажет только ошибки и более критические сообщения (приоритеты 0–3).

journalctl -p warning --since today

Покажет предупреждения и ошибки за сегодня.

Шаг 6. Просмотр логов текущей загрузки

Ключ -b показывает только сообщения, накопленные с момента последней перезагрузки. Это удобно, если вы только что перезапустили сервер и хотите увидеть, что происходило во время загрузки.

journalctl -b

Можно комбинировать с другими ключами, например, показать только ошибки текущей загрузки:

journalctl -b -p err

Если сервер перезагружался и после этого что-то сломалось, journalctl -b покажет только сообщения текущей сессии, без «хвоста» от прошлых загрузок.

Шаг 7. Поиск по ключевым словам

Часто нужно найти все записи, содержащие определённое слово, например, error, failed или имя конкретного файла. Для этого используйте grep.

journalctl | grep -i error

Найдёт все записи со словом «error» (регистр не важен).

journalctl -u nginx | grep "502"

Найдёт в логах Nginx все упоминания ошибки 502.

Для традиционных файлов можно использовать grep аналогично:

grep "error" /var/log/syslog

Преимущества и ограничения systemd-журналов

По сравнению с традиционными текстовыми логами система journald имеет ряд преимуществ, но и некоторые ограничения.

Основные преимущества systemd-журналов:

• Централизованное хранение всех логов в одном месте.
• Богатые метаданные для каждой записи.
• Гибкая фильтрация по множеству критериев.
• Возможность просматривать логи, даже если файловая система не смонтирована (журнал хранится в оперативной памяти).

Ограничения:

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

На практике оба подхода сосуществуют: systemd-journald собирает логи, а многие приложения по-прежнему пишут в /var/log/. Поэтому полезно уметь работать и с теми, и с другими.

Практические сценарии: где и как применять чтение логов

Рассмотрим пять типовых ситуаций, в которых умение читать системные логи Linux помогает быстро решить проблему.

Сценарий 1. Служба не запускается

Вы выполнили sudo systemctl start nginx, но служба не стартует. Вместо того чтобы гадать, смотрите логи:

journalctl -u nginx -b -p err

Вы увидите конкретную ошибку: например, «bind() to 0.0.0.0:80 failed (98: Address already in use)» — порт уже занят, или «nginx: [emerg] unknown directive» — ошибка в конфигурации.

Сценарий 2. Проблемы с подключением по SSH

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

journalctl -u sshd -p err

Или для традиционных логов:

grep "Failed password" /var/log/auth.log

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

Сценарий 3. Сайт недоступен или работает медленно

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

journalctl -u nginx -f

В реальном времени вы увидите, какие запросы приходят и с какими кодами ответа они завершаются. Ошибки 500, 502 или 504 укажут на проблему на стороне сервера. Если вы используете PHP, загляните в логи PHP-FPM:

journalctl -u php-fpm -p err

Если сайт размещён на VPS Serverspace, после анализа журналов стоит проверить, не связана ли проблема с нехваткой ресурсов. Например, записи Out of memory, ошибки записи на диск или регулярные остановки процесса под нагрузкой могут указывать на необходимость освободить место, оптимизировать приложение либо увеличить RAM, vCPU или SSD в панели управления. Важно сначала подтвердить причину по логам и только после этого менять конфигурацию сервера.

Сценарий 4. Проблемы с аппаратным обеспечением

Сервер внезапно перезагрузился или ведёт себя нестабильно. Возможно, проблема в оборудовании. Просмотрите логи ядра:

dmesg -T | grep -i error

Или используйте journalctl -k для просмотра сообщений ядра.

Ошибки, связанные с дисками (I/O error, ata), памятью (EDAC, MCE) или сетью (eth0: link down), помогут быстро локализовать неисправность.

Сценарий 5. Анализ безопасности

Вы подозреваете, что в систему проник злоумышленник. Проверьте логи входа:

last — показывает последние успешные входы.
journalctl -u sshd | grep "Accepted" — успешные подключения по SSH.
grep "Failed password" /var/log/secure — неудачные попытки входа.

Регулярный мониторинг таких логов — важная часть поддержания безопасности вашего VPS-сервера.

Частые ошибки при работе с логами и как их избежать

Новички часто совершают одни и те же ошибки при чтении системных логов Linux. Вот основные из них и способы их предотвращения.

Ошибка 1. Просмотр всего журнала без фильтрации

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

Решение: Всегда используйте фильтры: по времени (--since), по службе (-u), по приоритету (-p) или комбинируйте их.

Ошибка 2. Игнорирование уровня важности сообщений

Симптом: Вы тратите время на чтение информационных сообщений (info, debug), хотя проблема, скорее всего, скрыта среди ошибок (err) или предупреждений (warning).

Решение: Начинайте поиск с journalctl -p err — это отсечёт большую часть «шума».

Ошибка 3. Недостаток прав для просмотра логов

Симптом: Вы получаете сообщение об отказе в доступе при попытке прочитать некоторые логи.

Решение: Используйте sudo для просмотра логов, требующих прав root. Например: sudo journalctl.

Ошибка 4. Забывают про ротацию и переполнение диска

Симптом: Диск заполняется, и система начинает работать нестабильно. Логи продолжают расти.

Решение: Регулярно проверяйте размер журнала и при необходимости ограничивайте его:

journalctl --disk-usage — показывает, сколько места занимают журналы.
sudo journalctl --vacuum-size=500M — оставляет не более 500 МБ.
sudo journalctl --vacuum-time=7d — удаляет записи старше 7 дней.

Для постоянного ограничения размера отредактируйте файл /etc/systemd/journald.conf и задайте параметр SystemMaxUse=500M.

Ошибка 5. Не используют комбинации ключей

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

Решение: Комбинируйте ключи. Например, чтобы увидеть ошибки службы Nginx за последний час:

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

Или чтобы найти все ошибки в логах текущей загрузки:

journalctl -b -p err

Вывод: что делать дальше

Системные логи Linux — это мощнейший инструмент диагностики, который должен быть в арсенале каждого, кто работает с серверами. Научившись читать логи с помощью journalctl и базовых команд работы с текстовыми файлами, вы сможете:

• Быстро определять причины сбоев служб и приложений.
• Отслеживать подозрительную активность и повышать безопасность.
• Эффективно мониторить состояние сервера.
• Экономить время на поиск и устранение неисправностей.

Начните с малого: запомните основные команды — journalctl -f, journalctl -u, journalctl -p err, journalctl --since — и постепенно осваивайте более сложные комбинации.

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

В реальном проекте тот же подход помогает принимать обоснованные решения. Если журналы указывают на ошибку конфигурации, её исправляют внутри системы. Если серверу не хватает памяти, процессорных ресурсов или диска, параметры VPS можно изменить через панель управления. Перед крупным обновлением или экспериментом можно создать снимок, а управление несколькими машинами автоматизировать через API, CLI или Terraform.

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

Часто задаваемые вопросы