Логирование и анализ логов
Логирование и анализ логов
Что такое логи
Логи — это хронологические записи о том, что происходило в системе. Каждая строка лога содержит временную метку и описание события: запрос пришёл, функция выполнилась, ошибка произошла.
Для тестировщика логи — это детективный инструмент. Когда API возвращает 500 Internal Server Error, именно в логах ты найдёшь настоящую причину.
Уровни логирования
Логи делятся по уровням серьёзности:
| Уровень | Смысл | Пример |
|---|---|---|
DEBUG | Детальная отладочная информация | Параметры SQL-запроса |
INFO | Нормальные события системы | Пользователь залогинился |
WARN | Потенциальная проблема, но система работает | Медленный запрос (800 мс) |
ERROR | Ошибка, требующая внимания | Не удалось подключиться к БД |
FATAL | Критическая ошибка, приложение упало | Нет памяти, процесс завершён |
В продакшене обычно показывают INFO и выше. DEBUG-логи включают только при расследовании.
Что содержит строка лога
Типичная строка лога выглядит так:
2024-11-15T10:23:45.123Z [INFO] [req-abc123] POST /api/users 201 - 45ms - userId: null
2024-11-15T10:23:48.456Z [ERROR] [req-def456] Unhandled exception: Cannot read property 'id' of undefined
at UserService.createUser (userService.js:42:18)
at async UsersRouter.handler (usersRouter.js:15:5)
Компоненты:
- Временная метка — когда произошло событие
- Уровень —
INFO,ERRORи т.д. - Request ID — уникальный идентификатор запроса (
req-abc123) - Сообщение — что произошло
- Stack trace — для ошибок: точное место в коде
Типы логов
- Application logs — события приложения (авторизация, бизнес-логика, ошибки)
- Access logs — все HTTP-запросы (метод, путь, статус, время)
- Error logs — только ошибки с трейсами
Инструменты для просмотра логов
| Инструмент | Контекст |
|---|---|
tail -f app.log | Терминал — смотреть логи в реальном времени |
| Kibana | Централизованное хранилище логов, поиск и фильтрация |
| Grafana | Визуализация метрик и логов |
| Datadog | Мониторинг, логи, трейсинг в одном месте |
| AWS CloudWatch | Логи для приложений на Amazon AWS |
Зачем тестировщику логи
1. Найти причину 500 Internal Server Error
Когда API вернул 500, в ответе обычно нет подробностей. Открываешь логи, фильтруешь по времени запроса — и видишь настоящую ошибку:
ERROR TypeError: Cannot read property 'email' of null
2. Проверить корректность обработки
Нужно убедиться, что при отправке заказа реально создалась запись. Смотришь INFO-логи и находишь подтверждение:
INFO Order #4521 created for user #88, total: 1250.00
3. Найти логи конкретного запроса
Каждый запрос получает уникальный requestId. Ты копируешь его из заголовка ответа (X-Request-Id) и фильтруешь логи — видишь весь путь одного запроса через систему.
4. Написать точный баг-репорт
Вместо «сервер вернул ошибку» ты пишешь:
2024-11-15 10:23:48 — ERROR: Duplicate entry 'ivan@example.com' for key 'users.email'
Это конкретно, разработчику понятно, где искать.
Корреляция логов
В микросервисной архитектуре один запрос может пройти через несколько сервисов. Request ID (или Trace ID) позволяет собрать все логи одного запроса из разных сервисов в единую цепочку.
[req-xyz789] Auth Service: token validated - userId: 42
[req-xyz789] Order Service: creating order for userId: 42
[req-xyz789] Payment Service: ERROR - card declined
[req-xyz789] Order Service: rolling back - order cancelled
Что мы запомним
- Логи — хронологические записи событий с временными метками и уровнями серьёзности
- Уровни: DEBUG → INFO → WARN → ERROR → FATAL
- Для анализа используют Kibana, Grafana, Datadog или просто
tail -fв терминале - Тестировщик читает логи, чтобы: найти причину ошибки, проверить аудит-трейл, написать точный баг-репорт
Request IDпомогает найти все логи одного конкретного запроса