Проверка логов Linux, которая спасла меня от скрытого сбоя (это должен знать каждый администратор)

Большинство сбоев не начинаются с аварии.

Они начинаются с крошечного предупреждения, скрытого где-то в логах вашей системы, тихо сообщающего вам:

«Сейчас что-то сломается».

Как инженер по безопасности Linux, управляющий сотнями серверов в корпоративных средах, я усвоил одну вещь:

👉 Если вы успеете вы поймаете сигнал заранее, вы полностью избежите сбоя.
👉 Если вы его пропустите, вам придётся тушить пожар в 3 часа ночи.

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

🔧 Однострочная команда, предсказывающая 80% сбоев

Перед любым вмешательством в продакшн-систему я запускаю следующую команду:

grep -Ei "fail|error|warn|critical" /var/log/syslog | tail -50

Эта команда делает три вещи:

1. Сканирует на наличие наиболее опасных ключевых слов.
2. Сужает результат до последних 50 событий (чтобы не перегружать).
3. Точно отображает проблемы, о которых сигнализировала система.

Почему это работает

Потому что Linux всегда сообщает, когда что-то начинает ухудшаться:

• Замедление дискового ввода-вывода
• Давление на память
• Нестабильная работа сервисов
• Ошибки доступа
• Нестабильность сети
• Аномалии безопасности

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

🔥 Реальный пример: Скрытый сбой диска, который вот-вот взорвётся

Несколько месяцев назад во время моей предварительной проверки на сервере Ubuntu появилась следующая строка:

EXT4-fs warning: mounting fs with errors

Никаких алертов.
Никаких писем.
Ни одна система мониторинга не зафиксировала это.

Но эта единственная строчка мне сказала:

«Ваша файловая система вот-вот будет повреждена».

В течение 10 минут я перенёс рабочие нагрузки, выполнил полную проверку файловой системы и предотвратил катастрофический сбой.

А если бы я не проверил логи?
Этот сервер бы окончательно вышел из строя.

🛡️ Почему каждый DevOps-разработчик или бэкенд-инженер должен это делать

Большинство продакшн-сбоев можно разделить на три категории:

1️⃣ Деградация инфраструктуры

I/O errors  
OOM kills  
Network congestion  
Clock drift

2️⃣ Проблемы приложений

Service restarts  
Uncaught exceptions  
Deprecation warnings

3️⃣ Аномалии безопасности

Failed SSH attempts  
Permission denied errors  
Unexpected sudo usage

И все они оставляют следы в логах, до того, как станут реальной проблемой.

⚡ Сделайте его еще более впечатляющим: добавьте цвет и анализ частоты.

Вот проверка частоты логов, которую я использую при реагировании на инциденты:

grep -Ei "error|fail|critical" /var/log/syslog | \
awk '{print substr($0, index($0,$5))}' | \
sort | uniq -c | sort -nr | head -10

Здесь показаны наиболее часто повторяющиеся ошибки.

Отлично подходит для:

• Приоритизации задач
• Выявление шумных сервисов
• Выявления трендов до их эскалации

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

Системные логи показывают сбои.
Логи аутентификации показывают злоумышленников.

Выполняйте это один раз в день:

grep -Ei "failed|invalid|root|denied" /var/log/auth.log | tail -30

Вы мгновенно обнаружите:

• попытки перебора паролей по SSH
• некорректные cron-задачи
• злоупотребление правами sudo
• Попытки несанкционированного доступа

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

🧠 Контрольный список, который я использую перед любым деплоем

Вы можете скопировать это в ваш внутренний runbook.

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

• 🔍 Выполнить grep -Ei "fail|error|warn" по системным логам
• 🔥 Проверка логов аутентификации на предмет подозрительного поведения входа
• 🧠 Проверка частоты повторяющихся ошибок
• 🔧 Проверка перезапусков сервисов за последние 24 часа
• 📦 Убедиться, что место на дисках и inode в порядке
• 🛡️ Подтвердить отсутствие скрытых предупреждений ядра

Один только этот контрольный список предотвратил:

• Сбои
• Откаты
• «Тушение пожаров» после развертывания
• Нарушения безопасности, вызванные игнорируемыми аномалиями в логах.

📌 Заключительные мысли

Логи — это нервная система вашей инфраструктуры.

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

Если вы вынесете из этой статьи только одну мысль, пусть это будет следующее:

👉 Проверяйте свои логи до возникновения проблем, а не после.