Когда-о мне сказали:
«Логи — это не мусор. Это крик системы, которую ты не услышал вовремя.»

С тех пор я перестал игнорировать /var/log.
А вы?

Зачем вообще смотреть логи?

Потому что:

• Сервер может работать, но что-то уже идёт не так.
• Ошибка сегодня — катастрофа завтра.
• Атаки, сбои, баги, деградация — всё это оставляет следы в логах.
• И если ты не читаешь логи, ты не админ. Ты надеешься.

Какие логи смотреть в первую очередь?

Вот мой топ-лист логов на любой Unix-системе (Linux, BSD, macOS в серверных ролях):

1. /var/log/syslog или /var/log/messages

Общий системный лог (в зависимости от ОС и демона syslog/rsyslog/syslog-ng).
Сюда летит всё: загрузка, сетевые интерфейсы, драйверы, cron, cron, cron… (да, я повторил, потому что cron убивал больше систем, чем rm -rf /).

Что искать:
- error, fail, fatal, critical, warning — но не слепо по ключевым словам, а в контексте.
- Повторяющиеся сообщения — особенно от cron, systemd, kernel.

2. /var/log/auth.log (или /var/log/secure на RHEL)

Аутентификация, SSH, sudo, входы/выходы.
Самое горячее место. Здесь начинаются взломы.

Что искать:
- Failed password, Invalid user, Connection closed, Too many authentication failures — особенно многократно.
- Попытки входа с несуществующих пользователей (Invalid user admin, root, oracle, postgres).
- Успешные входы в нерабочее время.
- Массовые попытки — признак брутфорса.
- Необычные IP-адреса (особенно из Китая, Бразилии, РФ — шутка, но не совсем).

Катастрофа: Accepted password for root — если у тебя разрешён SSH-доступ для root, ты уже проиграл.

3. /var/log/kern.log

Логи ядра. Здесь — железо, драйверы, OOM, сетевые ошибки, SELinux/AppArmor.

Что искать:
- Out of memory: Killed process — OOM killer убил процесс. Серьёзно.
- Hardware error, I/O error — диски, RAID, SSD на грани.
- Kernel panic, Oops, BUG — система уже умирала или вот-вот умрёт.
- SELinux is preventing — если включён, значит, что-то не работает из-за политик.

4. /var/log/dmesg или dmesg в реальном времени

Буфер ядра. Часто дублируется в kern.log, но лучше смотреть напрямую.

Команда:

dmesg | grep -i "error\|fail\|warn\|oom"

5. Логи сервисов: Apache, Nginx, MySQL, Postfix и т.п.

Каждый сервис пишет в свой лог. Надо знать, где.

Примеры:
- Nginx: /var/log/nginx/error.log — ищи 502, 504, connect() failed, Connection refused.
- MySQL/MariaDB: /var/log/mysql/error.log — Can't connect to local MySQL server, InnoDB: Database was not shut down normally.
- Postfix: /var/log/mail.log — status=deferred, connect to [x] failed, relay access denied.

Катастрофа:
- Connection refused при старте сервиса — значит, не поднялся.
- disk full в логе БД — скоро всё упадёт.

Что НЕ должно быть в логах вообще?

Следующие вещи — красные флажки. Если увидел — беги:

Сообщение	Почему страшно
Out of memory: Kill process	Система не хватает RAM. Процесс убит.
Filesystem read-only	Диск сломался или перешёл в read-only.
Hardware error, I/O error	Железо умирает. Диск, RAID, контроллер.
Authentication failure (много раз)	Брутфорс. Скоро будет Accepted.
sudo: [user] : command not allowed	Кто-то пытается стать root.
Segmentation fault (часто)	Баг в софте или признак компрометации.
No space left on device	Диск полон. Логи, /tmp, /var — проверяй.

Как автоматизировать контроль?

Умный админ не сидит и не читает логи вручную. Он настраивает мониторинг.

Пример: скрипт для поиска критичных слов

#!/bin/bash
# check_critical_logs.sh
# Ищем опасные слова в ключевых логах

LOGS="/var/log/syslog /var/log/auth.log /var/log/kern.log"
KEYWORDS="error fail fatal critical segmentation\ fault oom-killer read-only I/O\ error"

for log in $LOGS; do
    if [ -f "$log" ]; then
        echo "=== Проверка: $log ==="
        grep -iE "$KEYWORDS" "$log" | grep -v "systemd\[" | tail -20
    fi
done

Запускай через cron раз в 10 минут и пушь в Telegram/email при совпадении.

Что должно быть в логах, но в минимуме?

• warning — нормально, если редко. Но если их 1000 в день — копай глубже.
• connection refused — может быть, если сервис перезагружается. Но если каждый час — что-то не так.
• timeout — сеть, БД, внешние сервисы. Проверяй стабильность.

Золотое правило:
Если сообщение повторяется — оно не предупреждение. Это проблема.

Инструменты, которые должен знать каждый админ

• journalctl -f -u nginx.service — смотреть лог сервиса в реальном времени.
• logrotate — следи, чтобы логи не съели весь диск.
• grep, awk, sed, tail -f, less +F — база.
• rsyslog + syslog-ng — централизованный сбор логов (на отдельный сервер!).
• fail2ban — блокирует IP после множества Failed password.
• Prometheus + Grafana + Loki — если хочешь быть pro.

Вывод: будь слепым — умрёшь

Логи — это твой главный инструмент диагностики.
Не жди, пока сервер упадёт.
Смотри логи регулярно, автоматизируй, реагируй.

Лучший админ — не тот, кто всё починит.
Лучший админ — тот, кто ничего не сломается, потому что всё видит заранее.

P.S.
Написал скрипт, который парсит логи и шлёт алерты?
Выкладывай в GitHub.
Я поставлю звёздочку.
А ты — получишь благодарность от другого админа, который тоже не хочет просыпаться в 3 ночи.

Подписывайся на блог. Будем копать глубже: от auditd до eBPF.

Посетителей сегодня: 0

© Digital Specialist | Не являемся сотрудниками Google, Яндекса и NASA

Кто я | HSH | Контакты и регион