Observability & Logging Lab

Три столпа observability. Логи (logs) — текстовые события «что произошло» с временной меткой, уровнем (INFO/WARN/ERROR) и контекстом. Метрики (metrics) — числовые показатели во времени: error rate, latency (p50/p95/p99), RPS, число 5xx. Трейсы (traces) — путь одного запроса через все сервисы, разбитый на спаны. Вместе они отвечают на вопрос «почему система ведёт себя не так»: метрики показывают «когда и насколько плохо», логи — «что именно сломалось», трейсы — «на каком сервисе и шаге».

Инструменты. Kibana/Elasticsearch — поиск и фильтрация логов по полям (сервис, уровень, trace_id, временное окно). Grafana — дашборды с метриками и графиками (error rate, latency, счётчики ошибок), здесь видно всплеск. Sentry — агрегация ошибок и стек-трейсов фронтенда/бэкенда с группировкой по типу. Браузерный DevTools (Network/Console) — первая линия для веб-дефекта: статус ответа, тело ошибки, JS-исключения. QA комбинирует их: график в Grafana → лог в Kibana → стек в Sentry.

Ключевые сигналы. 5xx (500/502/503/504) — серверные ошибки, прямой признак сбоя. Error rate — доля неуспешных запросов от всех (рост с 0,2% до 7,1% — это инцидент). Latency p95 — время ответа, которое укладывает 95% запросов; скачок p95 (например, до 6200ms при норме ~300ms) сигналит о деградации/таймаутах. QA сопоставляет всплеск этих метрик с временем жалоб пользователей, чтобы определить окно инцидента.

Идентификаторы корреляции. trace_id (он же request_id / correlation_id) — сквозной идентификатор запроса, который протягивается через все сервисы и попадает в каждый лог-запись и спан. По нему собирают весь путь одного запроса воедино: какой сервис вызвал какой, где выросла задержка, где упало. Без корреляции расследование в микросервисах превращается в чтение тысяч несвязанных строк; trace_id связывает их в одну историю.

Связать UI-дефект с backend-сигналами. Пользователь видит «Ошибка оплаты» — это симптом. QA не угадывает, а идёт по цепочке: в DevTools берёт статус и trace_id упавшего запроса → по trace_id находит лог-запись на бэкенде → видит, какой сервис и с какой ошибкой ответил → подтверждает метрикой (всплеск 5xx/latency этого сервиса). Так фронтовый симптом превращается в конкретную backend-причину с доказательствами.

Affected service и корень. Цель — назвать сбойный сервис и причину, а не «всё лежит». В трейсе видно, на каком спане запрос провёл максимум времени или упал; в логе этого сервиса — конкретная ошибка (например, provider_timeout). Это и есть affected service. Отделяйте корень от следствия: 500 на checkout — следствие, таймаут платёжного провайдера — корень.

User impact — масштаб для бизнеса и приоритизации. Метрики переводят в человеческий язык: сколько пользователей затронуто (affected_users_estimate), какая доля операций падает (error rate), какие функции недоступны (оформление заказа = деньги). Это определяет severity инцидента и срочность. «7,1% ошибок на checkout, ~320 пользователей не могут оплатить» — это понятная для всех оценка влияния, в отличие от сухого «выросли 5xx».

Incident timeline. Расследование оформляют как хронологию: когда метрика начала расти (начало), когда замечено/заведено, первое доказательство в логах, найденный корень, момент стабилизации. Timeline нужен и для устранения, и для постмортема: он показывает, как развивался инцидент и сколько длилось влияние на пользователей. Каждый пункт привязан к времени и к доказательству (метрика/лог/трейс).

QA evidence в observability. Доказательство инцидента — это связка сигналов: скрин графика метрик с всплеском и окном, конкретная строка лога с trace_id и текстом ошибки, фрагмент трейса с проблемным спаном, оценка влияния (user impact). Формула: «метрика показала всплеск в окне X → лог с trace_id Y дал причину Z на сервисе S → затронуто N пользователей». Такое evidence делает инцидент воспроизводимым и понятным для разработчиков и менеджмента.

Учебный инцидент (sandbox) для задач лабы. Checkout отдаёт 500. Метрики: checkout_error_rate вырос с 0,2% до 7,1%; payment_provider_latency_p95 = 6200ms; payment_service_5xx_count = 184; affected_users_estimate = 320. Лог-строка: `2026-06-08T10:15:42Z ERROR payment-service trace_id=trc_91x7 order_id=ord_9001 provider=stripe_sandbox error=provider_timeout message="Payment provider did not respond within 5000ms"`. Трейс по trace_id=trc_91x7 показывает, что время уходит и запрос падает на payment-service при обращении к внешнему провайдеру. На эти данные опираются все задачи ниже.