Kibana — это инструмент для визуального просмотра серверных логов, без которого в микросервисной архитектуре почти невозможно найти причину ошибки. Пока проект простой и состоит из одного сервера, достаточно консоли браузера. Но как только запрос проходит через несколько микросервисов и внешних провайдеров, обычная 500-я ошибка превращается в загадку: она могла возникнуть в любой из четырёх точек цепочки, и без специального инструмента понять, где именно, невозможно.
Почему в микросервисах логи — это отдельная тема
В классической трёхзвенной архитектуре всё просто: клиент обращается к серверу, сервер — к базе данных. Если пришла ошибка, достаточно посмотреть консоль браузера, а затем серверный лог-файл — и стек-трейс покажет причину. Но большинство реальных проектов устроены сложнее: 90% всех систем и практически 100% крупных построены на микросервисной архитектуре, где вместо одного сервера — целый набор небольших сервисов, каждый со своей узкой задачей.
Работает это так: клиент отправляет запрос не напрямую в нужный сервис, а через API Gateway — общую шину, единую точку входа. Хороший образ для этого — информационное бюро в аэропорту: все пассажиры подходят к одной стойке, а сотрудница перенаправляет каждого в нужном направлении — по билетам туда, по багажу сюда. Точно так же общая шина принимает все запросы от клиента и решает, какому микросервису их передать.
Например, в системе управления заказами (Order Management System) может быть под десяток микросервисов: один отвечает за сами заказы, другой — за пользователей и авторизацию, третий — за отправку email и SMS-уведомлений, четвёртый — за платежи, и так далее. Это похоже на устройство обычной компании: у юриста, менеджера и специалиста службы безопасности разные задачи, но все они работают в одной организации. Когда звонят в компанию и просят соединить с конкретным юристом, секретарь переключает звонок именно на нужного человека — так же общая шина маршрутизирует запросы.
Работает это так: клиент отправляет запрос не напрямую в нужный сервис, а через API Gateway — общую шину, единую точку входа. Хороший образ для этого — информационное бюро в аэропорту: все пассажиры подходят к одной стойке, а сотрудница перенаправляет каждого в нужном направлении — по билетам туда, по багажу сюда. Точно так же общая шина принимает все запросы от клиента и решает, какому микросервису их передать.
Например, в системе управления заказами (Order Management System) может быть под десяток микросервисов: один отвечает за сами заказы, другой — за пользователей и авторизацию, третий — за отправку email и SMS-уведомлений, четвёртый — за платежи, и так далее. Это похоже на устройство обычной компании: у юриста, менеджера и специалиста службы безопасности разные задачи, но все они работают в одной организации. Когда звонят в компанию и просят соединить с конкретным юристом, секретарь переключает звонок именно на нужного человека — так же общая шина маршрутизирует запросы.
Путь запроса и 4 точки возможного сбоя
Возьмём пример: менеджер в интерфейсе нажимает «Обновить статус заказа». Запрос уходит на сервер, попадает в API Gateway, тот направляет его в микросервис заказов, тот в свою очередь обращается к микросервису уведомлений, а уведомления отправляют запрос во внешний сервис email-рассылки. Если на любом из этапов что-то пошло не так, в браузере пользователь увидит одну и ту же обезличенную 500-ю ошибку.
Проблема в том, что 500-я ошибка могла родиться в четырёх разных местах: упала сама общая шина, упал микросервис заказов, упал микросервис уведомлений, либо проблема на стороне внешнего провайдера email-рассылки. В консоли браузера эта информация не видна в принципе — оттуда видно только финальный ответ клиенту, а не то, что происходило внутри системы. Чтобы понять, где именно сломалась цепочка, нужно логировать не только клиента, но и каждый микросервис отдельно, а также взаимодействие между ними и с внешними системами.
Проблема в том, что 500-я ошибка могла родиться в четырёх разных местах: упала сама общая шина, упал микросервис заказов, упал микросервис уведомлений, либо проблема на стороне внешнего провайдера email-рассылки. В консоли браузера эта информация не видна в принципе — оттуда видно только финальный ответ клиенту, а не то, что происходило внутри системы. Чтобы понять, где именно сломалась цепочка, нужно логировать не только клиента, но и каждый микросервис отдельно, а также взаимодействие между ними и с внешними системами.
Kibana: где искать и что смотреть
Kibana — это визуальная обёртка над лог-файлами серверов. Важно понимать: это не отдельная самостоятельная система, а просто удобный способ просматривать логи, чтобы не искать нужную запись вручную через grep в терминале.
Основной рабочий экран для тестировщика — раздел Analytics → Discover. Там отображаются все записи логов за выбранный период (по умолчанию — последние 15 минут), которые можно фильтровать по времени, по конкретному микросервису, по коду ошибки или просто по тексту в сообщении — например, набрать «500» и увидеть все записи с этим кодом.
Каждая запись содержит служебные технические поля вроде идентификаторов и версии агента, но самое важное — поле message. Именно в нём хранится содержимое запроса: метод, путь, заголовки, тело запроса, заголовки и тело ответа, а также user-agent — по нему видно, откуда пришёл запрос: из браузера, из Postman или из другой системы. Записи в Kibana упорядочены по времени, поэтому, зная примерный момент возникновения ошибки, можно восстановить всю цепочку событий.
Основной рабочий экран для тестировщика — раздел Analytics → Discover. Там отображаются все записи логов за выбранный период (по умолчанию — последние 15 минут), которые можно фильтровать по времени, по конкретному микросервису, по коду ошибки или просто по тексту в сообщении — например, набрать «500» и увидеть все записи с этим кодом.
Каждая запись содержит служебные технические поля вроде идентификаторов и версии агента, но самое важное — поле message. Именно в нём хранится содержимое запроса: метод, путь, заголовки, тело запроса, заголовки и тело ответа, а также user-agent — по нему видно, откуда пришёл запрос: из браузера, из Postman или из другой системы. Записи в Kibana упорядочены по времени, поэтому, зная примерный момент возникновения ошибки, можно восстановить всю цепочку событий.
Trace ID — как локализовать сбой за пару минут
На реальном проекте объём логов измеряется тысячами, а то и миллионами записей в день, и искать нужную цепочку вручную по времени бывает почти нереально. Здесь на помощь приходит ключевая фишка микросервисного логирования — Trace ID.
Каждому запросу, который инициирует клиент, сервер присваивает уникальный идентификатор, и этот идентификатор передаётся дальше через всю цепочку вызовов: от общей шины к микросервису заказов, от него к микросервису уведомлений, от того — к внешнему провайдеру. Все записи, относящиеся к одному действию пользователя, имеют одинаковый Trace ID, независимо от того, сколько сервисов участвовало в обработке запроса.
Найти Trace ID просто — он приходит в заголовках любого ответа от сервера, и увидеть его можно во вкладке Network в DevTools или в Postman. Дальше рабочий флоу тестировщика выглядит так: увидели 500-ю ошибку → открыли DevTools или Postman → нашли Trace ID в заголовках ответа → перешли в Kibana → отфильтровали по этому идентификатору → получили всю цепочку запросов в хронологическом порядке → прошли по ней глазами и нашли, на каком именно этапе произошёл сбой → скопировали ссылку на нужную запись → приложили в баг-репорт. Именно эта последовательность действий составляет девяносто процентов работы ручного тестировщика с системами логирования на микросервисных проектах.
Умение читать логи в Kibana и работать с Trace ID — это тот уровень знаний, который выделяет кандидата на собеседовании и реально пригождается на большинстве современных проектов, потому что монолитная архитектура сегодня скорее исключение. В Quality Academy на курсе «Инженер по ручному тестированию» микросервисы, Kibana и работа с Trace ID разбираются на практике — на реальной учебной системе с несколькими сервисами.
-------
Каждому запросу, который инициирует клиент, сервер присваивает уникальный идентификатор, и этот идентификатор передаётся дальше через всю цепочку вызовов: от общей шины к микросервису заказов, от него к микросервису уведомлений, от того — к внешнему провайдеру. Все записи, относящиеся к одному действию пользователя, имеют одинаковый Trace ID, независимо от того, сколько сервисов участвовало в обработке запроса.
Найти Trace ID просто — он приходит в заголовках любого ответа от сервера, и увидеть его можно во вкладке Network в DevTools или в Postman. Дальше рабочий флоу тестировщика выглядит так: увидели 500-ю ошибку → открыли DevTools или Postman → нашли Trace ID в заголовках ответа → перешли в Kibana → отфильтровали по этому идентификатору → получили всю цепочку запросов в хронологическом порядке → прошли по ней глазами и нашли, на каком именно этапе произошёл сбой → скопировали ссылку на нужную запись → приложили в баг-репорт. Именно эта последовательность действий составляет девяносто процентов работы ручного тестировщика с системами логирования на микросервисных проектах.
Умение читать логи в Kibana и работать с Trace ID — это тот уровень знаний, который выделяет кандидата на собеседовании и реально пригождается на большинстве современных проектов, потому что монолитная архитектура сегодня скорее исключение. В Quality Academy на курсе «Инженер по ручному тестированию» микросервисы, Kibana и работа с Trace ID разбираются на практике — на реальной учебной системе с несколькими сервисами.
-------
Полезные ссылки школы
Сайт Quality Academy:
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena