Модуль 6.2: Аналіз логів

Вирішення проблем | Складність: [MEDIUM] | Час: 25–30 хв

Передумови

Перед початком цього модуля:

Обов’язково: Модуль 6.1: Системне вирішення проблем
Обов’язково: Модуль 1.2: Процеси та systemd
Бажано: Знання основ регулярних виразів.

Що ви зможете робити після цього модуля

Після завершення цього модуля ви зможете:

Запитувати логи ефективно за допомогою journalctl, grep, awk та фільтрів за часовими мітками
Кореляти події з різних джерел логів для побудови хронології інциденту
Визначити поширені патерни помилок та їхні першопричини із записів логів
Спроєктувати стратегію агрегації логів для середовища з кількома сервісами

Чому цей модуль важливий

Логи (журнали) — це головне джерело істини при пошуку багів. Кожен додаток, сервіс та саме ядро системи пишуть логи. Вміння швидко знайти, прочитати та проаналізувати їх — це те, що відрізняє профі від новачка.

Розуміння аналізу логів допоможе вам:

Знаходити точні повідомлення про помилки — справжню причину збоїв.
Пов’язувати події — що сталося безпосередньо перед проблемою?
Відстежувати шлях запиту через декілька сервісів.
Налаштовувати моніторинг — ви будете знати, на що саме ставити алерт.

Без ефективного читання логів ви займаєтесь не відлагодженням, а гаданням.

Джерела логів у Linux

┌─────────────────────────────────────────────────────────────┐
│                    ДЖЕРЕЛА ЛОГІВ                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Класичні (syslog)              Сучасні (journald)          │
│  /var/log/syslog (система)      journalctl                  │
│  /var/log/auth.log (безпека)    journalctl -u service       │
│  /var/log/kern.log (ядро)       journalctl -k               │
│                                                             │
│  Логи додатків                  Логи контейнерів            │
│  /var/log/nginx/access.log      docker logs <name>          │
│  /var/log/mysql/error.log       kubectl logs <pod>          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Робота з journalctl

journalctl — це стандартний інструмент для перегляду логів у системах із systemd.

Основні фільтри

# Тільки логи конкретного сервісу
journalctl -u nginx

# Логи з моменту останнього завантаження системи
journalctl -b

# Логи за останні 30 хвилин
journalctl --since "30 min ago"

# Тільки помилки та критичні записи
journalctl -p err

# Логи в реальному часі (як tail -f)
journalctl -f

Текстовий аналіз через термінал

Коли логи лежать у звичайних файлах, вашими кращими друзями стають grep, awk та tail.

# Знайти слово "error" незалежно від регістру
grep -i "error" /var/log/syslog

# Подивитися 5 рядків ДО і ПІСЛЯ помилки (контекст)
grep -C 5 "Failed" /var/log/app.log

# Порахувати кількість унікальних IP-адрес у логах nginx
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -n 10

Логи в Kubernetes

У Kubernetes поди ефемерні. Якщо под видалено, його логи зазвичай зникають разом із ним.

# Логи поточного пода
kubectl logs my-pod

# Логи ПОПЕРЕДНЬОГО екземпляра (якщо под перезавантажився)
kubectl logs my-pod --previous

# Стежити за логами декількох подів за міткою
kubectl logs -l app=nginx -f

Тест

Як подивитися тільки логи ядра через journalctl?

Відповідь
`journalctl -k` (або `journalctl --dmesg`).
Яка команда в Linux дозволяє стежити за додаванням нових рядків у текстовий файл логу?

Відповідь
`tail -f <файл>`.
Навіщо потрібен прапор -C 5 у команді grep?

Відповідь
Він показує контекст — по 5 рядків навколо кожного знайденого слова. Це допомагає зрозуміти, що передувало помилці та що сталося після неї.
Де в Kubernetes шукати логи, якщо под постійно перезавантажується і звичайний kubectl logs показує тільки порожній запуск?

Відповідь
Потрібно додати прапор `--previous`: `kubectl logs <назва> --previous`. Це покаже вивід попереднього (того, що впав) контейнера.

Практична вправа

Завдання: Навчитися швидко фільтрувати системні логи.

Знайдіть у системному журналі всі записи, що стосуються SSH:
Terminal window
```
journalctl -u ssh
```
Подивіться 20 останніх помилок у всій системі:
Terminal window
```
journalctl -p err -n 20
```
Спробуйте знайти спроби невдалого входу у файлі /var/log/auth.log (якщо він є):
Terminal window
```
sudo grep "failed" /var/log/auth.log
```
Перевірте, скільки місця на диску займають логи journald:
Terminal window
```
journalctl --disk-usage
```

Критерії успіху: Ви вмієте обмежувати вивід логів за часом, сервісом та пріоритетом.

Підсумок

journalctl — для системних сервісів.
grep/awk — для текстових файлів.
—previous — “золоте правило” для дебагу в Kubernetes.
Контекст (сусідні рядки) важливіший за саме повідомлення про помилку.

Далі: Модуль 6.3: Відлагодження процесів — навчіться бачити, що програма робить насправді за допомогою strace.