Любая система, даже самая тихая и спокойная, любит поговорить о своих переживаниях. В Linux эти откровения записываются в журналы — от скромного /var/log/messages до многоголосья systemd-journal. Грамотно читать и анализировать логи — все равно что понимать язык собственного сервера: полезно, увлекательно и иногда спасает нервы и карьеру. Разберёмся, где живут сообщения, чем их читать и как превратить хаос строк в ценные инсайты.
Зачем вообще нужны журналы
Кто-то заводит дневник, чтобы вспоминать яркие моменты, а система пишет логи, чтобы администратор быстрее находил ту самую крошечную ошибку, которая валит сервис в час пик. Логи помогают:
- отслеживать ошибки и сбои;
- понимать поведение приложений под нагрузкой;
- расследовать инциденты безопасности;
- собирать статистику и создавать метрики.
Одним словом, журналы — это фонарик, освещающий закоулки системы. Остаётся научиться направлять луч туда, где темнее всего.
/var/log: старейшина семейства
До появления systemd почти все события складывались в каталог /var/log. Здесь и по сей день хранятся:
- /var/log/messages — общие системные сообщения;
- /var/log/auth.log или secure — аутентификация и sudo;
- /var/log/kern.log — слово ядра;
- лог веб-сервера в /var/log/nginx/ или apache2/;
- и ещё дюжина файлов, о которых вспоминаешь, когда что-то идёт не так.
Чтение классических логов возможно старым, но надёжным набором инструментов: less, tail -f для «живого» чтения и могущественный grep. Например:
tail -f /var/log/auth.log | grep "Failed"
Скучно? Да, но работает даже на минималистичном rescue-дистрибутиве.
Переезд в эпоху systemd и journalctl
Когда systemd пришёл во многие дистрибутивы, он захотел единый источник правды о событиях. Так родился бинарный журнал, читаемый командой journalctl. Его плюсы:
- централизованность — собирает сообщения ядра, сервисов и самого systemd;
- метаданные — уровень важности, пользователь, PID, а иногда даже имя собаки разработчика (шутка, пока);
- фильтрация по времени, сервису, приоритету без внешних скриптов.
Примеры, которые экономят седину:
# последние 50 строк лога сервиса sshd journalctl -u sshd -n 50 # ошибки ядра за последние 30 минут journalctl -k --since "30 min ago" -p err # посмотреть, что было во время последней перезагрузки journalctl -b -1
А если хочется постоянной «текущей ленты»:
journalctl -f -u nginx.service
Настройка объёма журнала
По умолчанию журнал хранится в /var/log/journal и может разрастись. Меняем лимиты в /etc/systemd/journald.conf:
SystemMaxUse=1G RuntimeMaxUse=500M
После изменения нужно перезапустить демон:
systemctl restart systemd-journald
rsyslog: классик, который ещё в строю
rsyslog остаётся популярным, особенно если требуется отправка логов на удалённый сервер или специфичная фильтрация. Его конфигурация в /etc/rsyslog.conf и /etc/rsyslog.d/ может выглядеть страшновато, но правила отправки всего auth-трафика на центральный хост пишутся в пару строк:
auth.* @log.example.com:514
Таким способом строятся корпоративные «соборчики» логов, где один хост собирает всё и вся. Кстати, если надо TLS, достаточно добавить два «@@».
Полезные приёмы фильтрации и поиска
Поскольку чтение логов руками часто превращается в охоту за нужной иголкой, важно уметь:
- Сужать временной окно: journalctl --since «2025-05-16 10:00:00» --until «2025-05-16 12:00».
- Фильтровать по приоритету: -p warning..crit — всё жёлтое и красное.
- Комбинировать критерии: время + юнит + PID.
- Убирать лишнее через grep -v или встроенный _PID фильтр.
Не забывайте про jq , если выводите журнал в JSON (journalctl -o json):
journalctl -u docker -o json | jq 'select(.MESSAGE | test("error"))'
Типичные сценарии: от «не включается Nginx» до «кто ломился в SSH»
Возьмём две популярные беды и кратко покажем, как логи помогают их разрешить.
Nginx не стартует после изменения конфигурации
journalctl -u nginx -n 20
Чаще всего увидите «bind() to 0.0.0.0:80 failed»: порт уже занят другой программой. lsof -i :80 быстро покажет виновника.
Подбор пароля к SSH
journalctl -u sshd -p warning --since yesterday | grep "Failed password"
Оттуда же легко вытащить IP-адреса злоумышленников и забанить их, например, через Fail2Ban .
Ротация и хранение: не дай диску лопнуть
Даже самые скромные логи умеют незаметно превратиться в пухлый роман. Тут вступает в силу logrotate. Проверяем конфигурацию:
cat /etc/logrotate.d/nginx
/var/log/nginx/*.log {
weekly
rotate 4
compress
missingok
notifempty
}
Эта магия оставит четыре архивных файла и будет сжимать их в gzip. Запускаем вручную для проверки: logrotate -f /etc/logrotate.conf.
Анализ и визуализация: когда строк уже слишком много
Читать многомегабайтные журналы глазами — сомнительное удовольствие. На сцену выходят:
- GoAccess — мгновенные отчёты по веб-логам;
- Loki + Grafana — модное облако графиков;
- Graylog — веб-интерфейс для больших инсталляций;
- Logwatch — ежедневные email-отчёты «коротко о главном».
Подключить, скажем, Loki не труднее, чем первой попыткой собрать IKEA-шкаф: немного ругани, но результат того стоит. Достаточно настроить promtail, который читает локальные файлы и отправляет их в Loki. Графаны потом рисуют красивые панели, за которые шеф дарит плюсик к премии.
Безопасность логов
Не забывайте: журналы нередко содержат персональные данные и пароли в строке ошибок (да, мы знаем, что «так не должно быть», но бывает). Поэтому:
- ограничьте доступ к каталогу /var/log правильными правами;
- шлите логи на удалённый сервер, чтобы злоумышленник не мог их стереть локально;
- маскируйте чувствительные данные фильтрами rsyslog или самого приложения;
- регулярно проверяйте, какие данные уходят в журнал — иногда туда летит лишнее.
Заключение
Логи — как сплетни в офисной кухне: много лишнего шума, но среди него скрыта жизненно важная информация. Научившись фильтровать, сортировать и визуализировать события, вы сэкономите часы (а то и дни) на поиске причин сбоев. Используйте journalctl для оперативной диагностики, /var/log для привычной классики, rsyslog — когда нужна гибкость маршрутизации, а Loki или Graylog — чтобы приятно удивить менеджеров отчётами «в цвете». И пусть ваш сервер рассказывает только хорошие истории!
