Journald Linux: Хватит grep-ать /var/log! Раскрываем мощь journalctl

Пятничный траблшутинг. Вы ищете ошибку, перебирая auth.log, syslog, messages и логи вашего приложения. Это долго и неудобно. В современных системах на systemd есть единый, структурированный журнал, и journalctl — ваш ключ к нему.

Почему journalctl лучше, чем tail и grep:
Централизация: Все логи (ядро, сервисы, система) в одном месте.
Структура: Логи хранятся не как текст, а как записи с метаданными (сервис, PID, приоритет).
Индексация: Поиск по времени или другим полям работает мгновенно.

Команды, которые сэкономят вам часы:
Фильтр по времени (самое важное при расследовании):
Bash

# Показать все логи за последние 10 минут
journalctl --since "10 min ago"

# Показать логи за конкретный промежуток времени
journalctl --since "2025-10-17 16:00:00" --until "2025-10-17 16:05:00"

Фильтр по приоритету (отсекаем шум):
Bash

# Показать только ошибки (err) и более критичные события
journalctl -p err -b

-b показывает логи с момента последней загрузки.

Логи конкретного сервиса в реальном времени:
Bash

# Следим за логами nginx
journalctl -f -u nginx.service

Взгляд архитектора: journalctl — это не просто удобная утилита. Это локальный endpoint для системы Observability. Умение эффективно работать с ним — это базовый навык. Следующий шаг — настроить journald-forwarder (или аналог), который будет отправлять эти структурированные логи в централизованную систему вроде ELK Stack или Graylog для глобального анализа и корреляции событий.

#linux #systemd #journalctl #logging #sre #команды

Linux: Скрипт "Daily Digest". Топ-10 ошибок из journalctl

Сервер "глючит". Лог journalctl — это миллион строк. Вы не можете найти причину в этом "шуме".

Реакция админа: Листать journalctl | grep "error" и надеяться. Реакция архитектора: Агрегировать данные и найти паттерны.

Этот Bash-скрипт — ваш "SRE-ассистент". Он проанализирует логи journalctl за последние 24 часа и покажет Топ-10 самых частых ошибок, отсекая весь "шум".

Код скрипта:
Bash

#!/bin/bash
# --- JournalCTL Error Digest ---

echo "--- Топ-10 ошибок в journalctl за последние 24 часа ---"

# 1. journalctl: Запрашиваем все с приоритетом "error" (3) за последние 24 часа.
# 2. awk: Вырезаем только само сообщение (все, что после ': ').
# 3. sort: Сортируем строки, чтобы одинаковые были рядом.
# 4. uniq -c: "Схлопываем" одинаковые строки и считаем их (count).
# 5. sort -nr: Сортируем по числу (numeric) в обратном порядке (reverse).
# 6. head -n 10: Показываем топ-10.

journalctl --since "24 hours ago" -p err | \
    awk -F': ' '{ $1=""; $2=""; print $0 }' | \
    sort | \
    uniq -c | \
    sort -nr | \
    head -n 10

echo "---------------------------------------------------------"

Как использовать:
Сохраните как digest.sh.
chmod +x digest.sh
sudo ./digest.sh

Взгляд архитектора: Вы не "ищете ошибку". Вы анализируете частотность. Если одна и та же ошибка (Failed password for root) повторилась 5000 раз — это brute-force атака, и вам нужен fail2ban. Если (Disk I/O error) — у вас умирает диск. Это Data-Driven Troubleshooting.

#linux #bash #journalctl #sre #diagnostics #скрипты #devops

🧹 Linux: Укрощаем journald. Как освободить место без удаления файлов?

Если /var/log забит, но logrotate настроен правильно, скорее всего, виноват systemd-journald. Он хранит бинарные логи, которые могут копиться годами и занимать гигабайты. Просто удалять файлы в /var/log/journal/ опасно — можно повредить базу.

Используйте встроенные механизмы очистки (vacuum).

1. Проверяем, сколько места занято:

journalctl --disk-usage
# Вывод: Archived and active journals take up 4.2G in the file system.

2. Освобождаем место (безопасно): Утилита сама удалит самые старые записи, чтобы вписаться в лимит.

# Оставить только последние 500 МБ
sudo journalctl --vacuum-size=500M

# Или оставить логи только за последние 10 дней
sudo journalctl --vacuum-time=10d

3. Как сделать это автоматическим: В файле /etc/systemd/journald.conf раскомментируйте и настройте параметр: SystemMaxUse=500M Теперь systemd сам будет следить за диетой.

#linux #systemd #journalctl #cleanup #maintenance #storage

🧠 Skills: journalctl — 10 команд, которые заменяют grep по /var/log

Коллеги, навык недели. Начиная с Debian 12 rsyslog по умолчанию не ставится — классических текстовых логов на свежих инсталляциях может просто не быть. Всё уходит в бинарный журнал systemd-journald.

🛠 10 БАЗОВЫХ КОМАНД
Bash

# 1. Только ошибки (от err и выше) с момента текущего старта системы
journalctl -p err -b

# 2. Логи конкретного сервиса за последний час
journalctl -u nginx --since "1 hour ago"

# 3. Режим live-мониторинга (аналог tail -f) по конкретной службе
journalctl -u ssh -f

# 4. Список всех зафиксированных загрузок ОС (с их ID и временными метками)
journalctl --list-boots

# 5. Сообщения ядра (dmesg) за ПРЕДЫДУЩУЮ загрузку (ключевое при анализе падений)
journalctl -k -b -1

# 6. Фильтр по исполняемому файлу в чистом текстовом выводе
journalctl _COMM=sshd -o cat | grep -i 'failed'

# 7. Выборка событий в жестком временном окне
journalctl --since "2026-10-05 09:00" --until "2026-10-05 10:00"

# 8. Просмотр структуры записи со всеми служебными метаполями (для построения точных фильтров)
journalctl -o json-pretty -n 1

# 9. Проверка дискового пространства, занятого журналами прямо сейчас
journalctl --disk-usage

# 10. Ротация и очистка архивов старше 30 дней
journalctl --vacuum-time=30d

⚠️ ПРОВЕРЬТЕ ПЕРСИСТЕНТНОСТЬ (сохраняются ли логи после ребута)
Bash

# Проверка наличия каталога постоянного хранения
ls -d /var/log/journal 2>/dev/null && echo "Логи пишутся на диск" || echo "ВНИМАНИЕ: логи живут только в RAM до ребута!"

# Проверка конфигурации лимитов
grep -E '^(Storage|SystemMaxUse)' /etc/systemd/journald.conf

Если каталога /var/log/journal нет — журнал по дефолту сбрасывается в tmpfs (RAM). После аварийной перезагрузки расследовать причину сбоя будет физически невозможно:

Bash

# Включение постоянного хранения логов на диске
mkdir -p /var/log/journal && systemctl restart systemd-journald

💡 В ЧЁМ СУТЬ

Связка флагов

-b -1

и

-p err

закрывает 80% всех типовых инцидентов из серии «почему сервер упал ночью».

Персистентное хранилище на диске с жестко зафиксированным лимитом

SystemMaxUse

в

journald.conf

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

#skills #linux #systemd #journalctl #debian #troubleshooting #sysadmin #admin_future