Анализ логов в Linux и macOS

Файлы журналов macOS

Когда что-то идёт не так в Linux, поиск причины может превратиться в кошмар. Проблема усугубляется, если она прерывистая и вы не знаете, где искать. Вместо бесконечных постов на Stack Overflow или Reddit, стоит взять дело в свои руки и просмотреть системные журналы: там часто хранятся подсказки, которые помогут восстановить работоспособность.

Что такое журналы и где их искать

Определение: журнал (log) — это упорядоченный по времени текстовый файл, в котором приложения и системные службы записывают события, ошибки и служебную информацию.

Многие приложения на Windows, macOS и Linux создают такие файлы. Чаще всего на UNIX-подобных системах их можно найти в каталоге /var/log.

Каталог /var/log на Linux

Часто в логах содержится много рутинных сообщений — просто отчётов о том, что программа делала. Но когда появляется ошибка, почти гарантированно найдётся запись с временной меткой и описанием проблемы. Наша задача — отделить «шум» от полезной информации.

Важно: лог-файлы — первичный источник правды при расследовании инцидентов. Не полагайтесь только на внешние признаки.

Основные принципы чтения логов

Смотрите на временные метки. Они помогают сопоставить события с проявлением проблемы.
Начинайте с последних записей, если проблема была недавно (tail). Для ретроспективного анализа — фильтруйте по диапазону времени (journalctl или log-средства).
Ищите ключевые слова: error, fail, panic, exception, refused, timeout. Но помните про локализацию: иногда программы пишут сообщения на другом языке.
Сравнивайте логи разных систем (приложение, сеть, хост), чтобы найти корреляцию.

Использование стандартных утилит Linux и macOS

Преимущество: все эти утилиты уже есть на большинстве UNIX-подобных систем. Они быстрые и гибкие.

Определения в одну строку:

grep — поиск строк по шаблону;
tail/head — последние/первые строки файла;
less/cat — просмотр содержимого;
sed/awk — постобработка и выбор колонок;
journalctl — просмотр системных логов systemd (современный Linux);
log — unified logging в macOS (для новых версий macOS).

Примеры и подсказки

Поиск слов, нечувствительный к регистру:

grep -i "error" /var/log/syslog

Ищем несколько вариантов с использованием расширенных регулярных выражений:

grep -Ei "error|fail|panic" /var/log/syslog

Показать последние 100 строк файла:

tail -n 100 /var/log/syslog

Следить за файлом в реальном времени (удобно при воспроизведении ошибки):

tail -f /var/log/app.log

Посмотреть первые 20 строк:

head -n 20 /path/to/logfile.log

Смотреть файл постранично:

cat /var/log/app.log | less

Использовать sed/awk, чтобы получить только третий столбец в записях с разделителем:

awk '{print $3}' /var/log/example.log

Пример регулярного поиска по шаблону даты и ключевому слову:

grep -E "2023-11-15.*error" /var/log/app.log

journalctl (systemd): посмотреть логи за последние 2 часа для службы nginx:

journalctl -u nginx --since "2 hours ago"

macOS unified logs: быстрый вывод за последние 10 минут с фильтром по процессу:

log show --predicate 'process == "MyApp"' --last 10m

Подсказка: если лог большой, комбинируйте команды через пайп, например:

journalctl -u myservice | grep -i "timeout" | less

Ошибки, связанные с кодировкой: некоторые логи могут содержать байты не в UTF-8. В таких случаях используйте tools вроде iconv для трансформации или less -R.

Когда использовать vim

vim удобен, если вы хотите быстро искать шаблоны внутри большого файла и делать пометки. В vim есть встроенный поиск по регулярным выражениям и возможность открывать файла большого размера (учтите ограничения по памяти и производительности).

Структуры логов и ротация

Логи часто ротацируются (logrotate), чтобы не заполнять диск. Файлы могут иметь имена с суффиксом .1, .2.gz и т. д. При анализе старых событий не забудьте проверить сжатые файлы (.gz). Пример распаковки и просмотра:

zcat /var/log/syslog.2.gz | grep -i "segfault"

Также логи имеют разные назначения: системные (syslog, messages), аутентификация (auth.log), приложения (app.log), почтовые сервисы, веб-серверы (access.log/error.log). Привычные пути:

/var/log/syslog или /var/log/messages — общесистемные сообщения;
/var/log/auth.log — события аутентификации;
/var/log/kern.log — сообщения ядра;
/var/log/nginx/error.log и access.log — Nginx;
/var/log/mysql/error.log — MySQL.

На macOS старые версии использовали /var/log/system.log и Console.app; в современных версиях macOS используется unified logging и команда log.

Использование программ для управления логами (Log Management)

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

Примеры решений:

Splunk — мощная коммерческая платформа с собственным языком запросов. У Splunk есть облегченное издание (Splunk Light). В исходном тексте отмечены ограничения Splunk Light: 500 MB в день на бесплатной версии, возможность апгрейда до 20 GB в день, поддержка до пяти пользователей и облачная версия. Самая дешёвая облачная подписка указывается как $125.00 в месяц.
ELK (Elasticsearch + Logstash + Kibana) — популярный стек с открытым исходным кодом для сбора, хранения и визуализации логов.
Graylog — централизованный сервер логов с удобным веб-интерфейсом.
Grafana Loki — подход для индексирования метаданных и хранения логов рядом с метриками.
Fluentd/Fluent Bit — аггрегаторы логов для доставки в хранилище или систему визуализации.

Плюсы использования менеджеров логов:

Централизация логов с множества хостов;
Удобные дашборды и визуализация;
Алёртинг и автоматическое обнаружение аномалий (в зависимости от продукта);
Упрощённый поиск и корреляция.

Минусы:

Сложность настройки и поддержки;
Стоимость (при облачных провайдерах или коммерческих версиях);
Потребность в хранении большого объёма данных и в политике хранения.

Важно: выбор решения зависит от масштаба инфраструктуры и требований по соответствию и хранению данных.

Практическая методика расследования — шаг за шагом (mini-methodology)

Зафиксируйте время проявления проблемы и идентичные случаи.
Сравните системные и прикладные логи в момент инцидента (± минут 5–10).
Отфильтруйте записи по ключевым словам и уровням (ERROR, WARN, CRITICAL).
Проверяйте связанные подсистемы: сеть, диск, память, аутентификация.
Ищите корреляции: одно и то же событие в логах разных сервисов.
Попробуйте воспроизвести проблему с включённым уровнем debug, если это возможно.
Сформулируйте гипотезу и выполните целенаправленный тест.
Документируйте найденное и внесите правки в мониторинг/алёрты.

Быстрые эвристики и чек-лист по ролям

Роль: разработчик

Проверить логи приложения и трассы стэка (stack traces).
Увеличить уровень логирования на время отладки.
Проверить входные данные и временные метки.

Роль: системный администратор

Проверить свободное место на диске, I/O и ошибки устройства.
Просмотреть системные журналы (kern.log, syslog, dmesg).
Проверить rotatation и права доступа к логам.

Роль: служба поддержки

Собрать логи клиента с указанием временных меток и окружения.
Сформулировать вопрос разработчику с минимально достаточным контекстом (временная метка, хост, PID, пример запроса).

Шаблон сбора информации (минимум):

Время и часовой пояс инцидента
Логи приложения (файл и отрывок ± 2–5 минут)
Системные логи (syslog/journal)
Версия приложения и зависимостей
Повторяемость и шаги воспроизведения

Когда чтение логов не помогает (контрпримеры)

Если запись не ведётся (приложение не логирует ошибки).
Логи повреждены или отсутствуют из-за проблем с диском.
Логи ротируются и сохраняются не там, где вы думаете.
Событие генерируется в памяти и не записывается в файл.

В таких случаях полезно включить дополнительное логирование, использовать трассировку сетевого трафика (tcpdump) или профайлеры.

Сравнение подходов — краткая матрица

CLI (grep, tail, journalctl): быстро, бесплатно, требует навыков.
Splunk/ELK/Graylog: удобно для масштабов, визуализация, алёрты, требуется развертывание и поддержка.
Облачные SaaS-решения: быстрый старт, оплата по объёму, внешняя зависимость.

Диаграмма решения (поможет выбрать инструмент)

graph TD
  A[Проблема с приложением] --> B{Проблема локализуется на одном хосте?}
  B -- Да --> C[Используйте grep/tail/journalctl]
  B -- Нет --> D{Нужно централизованное хранение и визуализация?}
  D -- Да --> E[Рассмотрите ELK/Graylog/Loki/Splunk]
  D -- Нет --> C
  E --> F{Есть бюджет?}
  F -- Да --> G[Платный Splunk или облачный ELK]
  F -- Нет --> H[Открытые решения: ELK + Filebeat/Fluentd]

Критерии приёмки

Вы нашли запись в логах, временная метка которой совпадает с инцидентом.
Сообщение в логе содержит достаточные данные (PID, путь, код ошибки) для воспроизведения или диагноза.
После исправления ошибка не воспроизводится при тех же входных данных.
Добавлены или скорректированы алёрты/логирование, чтобы быстрее отреагировать в будущем.

Советы по безопасности и приватности

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

Заключение

Логи — это основной инструмент при расследовании проблем в Linux и macOS. Навыки работы с grep, tail, journalctl и базовыми утилитами UNIX помогут быстро локализовать причину. Если инфраструктура велика или требуется централизованный анализ, используйте системы управления логами (Splunk, ELK, Graylog, Loki и т. п.). Начните с простого: отметьте временные метки, ищите ключевые слова и сопоставляйте события между системами.

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

Как вы управляете журналами?

Мы рассмотрели способы анализа логов и инструменты, которые упрощают работу. Какие методы используете вы? Предпочитаете стандартные утилиты или развёрнутый стек логирования? Поделитесь опытом в комментариях.

Хочу узнать ваш подход — напишите в комментариях.