Какие бывают логи: от системных до прикладных

Друзья, мы уже столько всего написали про логи, что пора остановиться и задаться фундаментальным вопросом: а какие вообще бывают логи? Чем отличается лог ядра от лога веб-сервера? Где искать проблемы с железом, а где — ошибки в коде?

Сегодня я разложу всё по полочкам. Это будет такая "типология логов" — от самого низа (железо) до самого верха (ваше приложение). Поехали.

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

Представьте, что вы заходите в комнату, где на полу разбросаны тысячи бумажек. На одних написано "температура процессора 85°C", на других — "пользователь Иванов вошёл в систему", на третьих — "не удалось открыть файл config.json".

Если вы не понимаете, какие бумажки откуда взялись, вы никогда не восстановите картину. А если знаете, что "температура" — от демона терморегуляции, "вход пользователя" — от PAM, а "ошибка файла" — от вашего приложения, вы сразу понимаете, куда копать.

Поэтому давайте классифицировать.

1. Аппаратные логи (Hardware Logs)

Самый низкий уровень. Здесь железо сообщает о своём состоянии.

Что сюда входит

Логи SMART жёстких дисков и SSD — атрибуты: количество перераспределённых секторов, время работы, температура, ошибки чтения .
Логи температуры и напряжения — от процессора, материнской платы, блока питания (обычно через IPMI или ACPI)
Логи встроенных контроллеров — например, BMC (Baseboard Management Controller) в серверах
Логи RAID-контроллеров — состояние массива, деградация дисков

Где искать

В Linux: ```bash

SMART-атрибуты дисков

smartctl -a /dev/sda

Логи IPMI (если есть)

ipmitool sel list

Информация от ядра о железе

dmesg | grep -i "temperature\|error" ```

В Windows: - Просмотр событий → Журналы приложений и служб → Hardware Events

Типичные сообщения

[Hardware] CPU temperature exceeded threshold (85°C) [Hardware] Disk reallocated sector count: 15 [Hardware] Power supply 1 failed

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

2. Логи ядра (Kernel Logs)

Выше железа — ядро операционной системы. Оно управляет памятью, процессами, драйверами, файловыми системами.

Что сюда входит

События драйверов — подключение/отключение устройств, ошибки инициализации
Проблемы с памятью — OOM (Out Of Memory) killer, сбои страниц
Файловые системы — ошибки монтирования, проблемы с суперблоком, переполнение inode
Сетевой стек — проблемы с сетевыми картами, маршрутизацией
Безопасность — SELinux/AppArmor блокировки

Где искать

Linux: ```bash

Просмотр кольцевого буфера ядра

dmesg

Логи ядра также попадают в /var/log/kern.log

tail -f /var/log/kern.log

Через journalctl

journalctl -k ```

Windows: - Просмотр событий → Журналы Windows → Система (с фильтром по источнику "kernel")

Типичные сообщения

kernel: usb 1-1: new high-speed USB device number 4 kernel: EXT4-fs error (device sda1): ext4_lookup: deleted inode referenced kernel: Out of memory: Kill process 1234 (httpd) score 456 or sacrifice child

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

3. Системные логи (System Logs)

Следующий уровень — службы и демоны, которые работают в пространстве пользователя, но обеспечивают работу системы в целом.

Что сюда входит

Системный журнал (syslog) — обощение всех логов в одном месте (традиционно)
systemd journal — современная замена syslog в Linux
Логи инициализации — загрузка системы, запуск/остановка сервисов
Логи авторизации — входы/выходы пользователей, sudo, ssh
Логи cron/at — запланированные задачи
Логи сетевых служб — DHCP, DNS, NTP

Где искать

Linux (традиционный syslog): bash /var/log/syslog # основной лог /var/log/messages # альтернативный системный лог /var/log/auth.log # авторизация /var/log/cron.log # планировщик

Linux (systemd): bash journalctl # все логи journalctl -u ssh.service # логи конкретного сервиса journalctl --since "2026-03-03 10:00" # за период

Windows: - Просмотр событий → Журналы Windows → Система, Безопасность

Типичные сообщения

sshd[1234]: Accepted password for root from 192.168.1.100 port 54321 cron[5678]: (root) CMD (cd / && run-parts --report /etc/cron.hourly) systemd[1]: Stopping MySQL Community Server... sudo[9012]: user : TTY=pts/0 ; PWD=/home/user ; USER=root ; COMMAND=/bin/bash

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

4. Сервисные логи (Service Logs)

Отдельные сервисы — веб-серверы, базы данных, почтовые серверы — ведут свои собственные логи. Обычно в своих форматах и своих файлах.

Что сюда входит

Веб-серверы (nginx, Apache, IIS) — логи доступа (access log) и ошибок (error log)
Базы данных (MySQL, PostgreSQL, MongoDB) — медленные запросы, ошибки подключения, логи репликации
Почтовые серверы (postfix, sendmail) — логи отправки/доставки
DNS-серверы (bind, unbound) — запросы и ошибки
Прокси и балансировщики (haproxy, squid)

Где искать

По традиции Unix — в /var/log/ в подкаталогах или файлах с именем сервиса:

bash /var/log/nginx/access.log /var/log/nginx/error.log /var/log/mysql/error.log /var/log/postgresql/postgresql-13-main.log /var/log/maillog /var/log/httpd/

В Windows — обычно в собственных каталогах программы или в Event Log с определёнными источниками.

Типичные сообщения

Nginx access.log: 192.168.1.100 - - [03/Mar/2026:14:23:45 +0300] "GET /index.html HTTP/1.1" 200 1234

Nginx error.log: 2026/03/03 14:23:46 [error] 1234#1234: *5678 connect() failed (111: Connection refused)

MySQL error.log: 2026-03-03T14:23:47.123456Z 3 [ERROR] InnoDB: Unable to lock ./ibdata1, error: 11

PostgreSQL log: 2026-03-03 14:23:48 UTC [12345] LOG: checkpoint starting: time 2026-03-03 14:23:49 UTC [12346] ERROR: duplicate key value violates unique constraint "users_pkey"

Сервисные логи — ваше основное оружие при отладке приложений, которые зависят от этих сервисов. Если сайт тормозит — смотрите логи базы данных. Если не грузятся картинки — логи веб-сервера.

5. Прикладные логи (Application Logs)

Самый верхний уровень — ваше собственное приложение. Здесь вы пишете то, что считаете нужным.

Что сюда входит

Бизнес-события — пользователь зарегистрировался, купил товар, отправил сообщение
Ошибки бизнес-логики — недостаточно средств, товар закончился, неверный формат
Технические ошибки — не удалось подключиться к API, таймаут, невалидные данные
Отладочная информация (debug) — входы в функции, промежуточные значения
Метрики производительности — время выполнения запросов

Где искать

Куда скажете. Может быть: - В файлах (обычно logs/ в директории приложения) - В стандартном выводе (stdout/stderr), который потом собирает systemd или Docker - В централизованной системе сбора логов - В базе данных (для бизнес-событий)

Типичные сообщения

Плохо (бесполезно): Error: something went wrong

Хорошо (полезно): 2026-03-03 14:23:45 ERROR [payment-service] Failed to charge user 12345: insufficient funds (balance=10.50, amount=25.00)

Отлично (структурированно): json { "timestamp": "2026-03-03T14:23:45Z", "level": "ERROR", "service": "payment-service", "user_id": 12345, "error": "insufficient_funds", "balance": 10.50, "amount": 25.00, "request_id": "req-abc-123" }

Важное замечание про логи приложений

Вы сами решаете, что писать. И от этого зависит, сможете ли вы потом найти ошибку.

Золотое правило: пишите контекст. "Ошибка подключения к базе данных" — плохо. "Ошибка подключения к базе данных по адресу 192.168.1.100:3306, таймаут 5 секунд, попытка 3 из 5" — хорошо.

6. Логи безопасности (Security Logs)

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

Что сюда входит

События аутентификации — успешные и неуспешные попытки входа
Изменения прав доступа — смена владельцев файлов, прав sudo
События межсетевого экрана — разрешённые и заблокированные соединения
Детекшены IDS/IPS — обнаружения атак
Аудит доступа к конфиденциальным данным

Где искать

В Linux: /var/log/auth.log, /var/log/secure, auditd логи
В Windows: Журналы Windows → Безопасность
В специализированных SIEM-системах

Типичные сообщения

sshd[1234]: Failed password for root from 192.168.1.100 port 54321 ssh2 sudo[5678]: user : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/home/user ; USER=root auditd[9012]: type=USER_LOGIN msg=audit(1648993425.123:456): pid=1234 uid=0 auid=1000 ses=1

Логи безопасности нужно хранить особенно тщательно и защищать от изменений. Они — улики при расследовании инцидентов.

7. Логи доступа (Access Logs)

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

Что сюда входит

Веб-логи — каждый HTTP-запрос
FTP-логи — загрузка/скачивание файлов
Логи файловых серверов — кто открывал какие файлы
Логи печати — кто и что распечатал

Где искать

Обычно в /var/log/ с соответствующими именами, либо в специализированных системах.

Типичные сообщения

192.168.1.100 - - [03/Mar/2026:14:23:45 +0300] "GET /wp-admin HTTP/1.1" 404 1234

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

8. Логи аудита (Audit Logs)

Отдельная категория, часто требуемая регуляторами. Отличается тем, что логи нельзя изменить или удалить.

Что сюда входит

Все действия администраторов (кто, когда, что сделал)
Изменения конфигурации
Доступ к персональным данным
Финансовые транзакции

Где искать

В специально защищённых хранилищах, часто с WORM-принципом (write once, read many) — записал и нельзя стереть.

Сравнительная таблица

| Тип логов | Что логирует | Где искать | Типичные проблемы | |-----------|--------------|------------|-------------------| | Аппаратные | Железо: диски, температура, БП | SMART, IPMI, dmesg | Перегрев, умирающие диски | | Ядра | Драйверы, память, ФС, сеть | dmesg, kern.log | Ошибки драйверов, OOM | | Системные | Сервисы ОС, авторизация, cron | syslog, journalctl | Проблемы с запуском, взломы | | Сервисные | Веб-серверы, БД, почта | /var/log/имя_сервиса | 500-е ошибки, медленные запросы | | Прикладные | Ваше приложение | Куда настроили | Баги, бизнес-ошибки | | Безопасности | Входы, sudo, firewall | auth.log, Windows Security | Атаки, подбор паролей | | Доступа | HTTP, FTP, файлы | access.log | Сканирование, утечки | | Аудита | Действия админов, изменения | Защищённое хранилище | Compliance, расследования |

Как не запутаться в этом зоопарке

Совет 1: Централизуйте

Когда у вас 10 серверов, бегать по файлам бессмысленно. Ставьте систему сбора логов (ELK, Graylog, Loki) и свозите всё туда.

Совет 2: Добавляйте теги

В централизованной системе помечайте, откуда лог: - host: server1 - type: kernel - service: nginx - environment: prod

Тогда сможете фильтровать: "покажи мне все kernel-логи с server1 за последний час".

Совет 3: Знайте, где чьё

Запомните (или запишите) соответствие: проблема с сетью — смотрим логи ядра и сетевых сервисов; сайт тормозит — логи веб-сервера и базы данных; кто-то ломится — логи безопасности.

Совет 4: Не смешивайте

Не пишите логи своего приложения в системный syslog без префиксов — потом не отделите. Или используйте facility (в syslog) или свой тег.

Коротко: шпаргалка

| Если проблема... | Смотрим в... | |-----------------|--------------| | Комплекс не включается | Аппаратные логи (BMC, IPMI) | | Синий экран/ядро падает | Логи ядра (dmesg, kern.log) | | Сервис не стартует | Системные логи (journalctl -u сервис) | | Сайт не отвечает | Сервисные логи (nginx error.log) | | База данных тормозит | Сервисные логи (mysql slow.log) | | Кто-то взламывает | Логи безопасности (auth.log) | | Приложение выдаёт ошибку | Прикладные логи (ваш app.log) | | Нарушили compliance | Логи аудита |

Вместо заключения

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

Поэтому не зацикливайтесь на одном типе. Учитесь смотреть на систему целиком, связывать события из разных источников. Тогда логи станут не просто файлами, а настоящей картиной мира вашего проекта.

А если вы только начинаете — освойте сначала системные логи и логи вашего приложения. Это 90% повседневных задач. Остальное придёт с опытом.