Admin Future
239 subscribers
50 photos
1 video
4 files
87 links
Превращаем эникейщиков в System Architects.
🚀 Твой навигатор в мире IT-инфраструктуры:

▪️ Hard Skills: Linux, Windows, Network, Security
▪️ Tools: Лучший софт и скрытые фишки
▪️ Mindset: Как думать, чтобы платили много


Админ - @maksimshap
Download Telegram
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
🔥2
🧹 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