Как определить, на каком этапе цепочки взаимодействующих сервисов произошёл сбой при выполнении запроса?

Определить, на каком этапе цепочки сервисов произошёл сбой, можно только при хорошо организованной наблюдаемости. Важны единые идентификаторы запросов, структурированное логирование и распределённая трассировка.

1. Корреляционные идентификаторы (request_id / trace_id)

Определение:
Корреляционный идентификатор — это уникальный ID, который присваивается запросу и передаётся через все сервисы, участвующие в его обработке.

1. На входе в первый сервис создаётся request_id (например, UUID).

2. request_id сохраняется в контексте и логируется во всех сообщениях, связанных с этим запросом.

3. При вызове следующего сервиса ID передаётся в заголовке, например X-Request-ID или traceparent (OpenTelemetry).

4. В логах всех сервисов по этому ID можно собрать полную историю запроса.

Пример (упрощённо, Python + FastAPI):

import uuid
from fastapi import FastAPI, Request

app = FastAPI()

@app.middleware("http")
async def add_request_id(request: Request, call_next):
    request_id = request.headers.get("X-Request-ID", str(uuid.uuid4()))
    # здесь можно положить request_id в контекст логгера
    response = await call_next(request)
    response.headers["X-Request-ID"] = request_id
    return response

Далее в каждом лог-сообщении нужно включать request_id.

2. Структурированные логи

Определение:
Структурированное логирование — это логирование в формате, который легко парсить машиной (например, JSON с фиксированными полями).

Что важно:

• всегда логировать:

  • timestamp

  • service_name

  • request_id / trace_id

  • endpoint / operation

  • status (успех/ошибка)

  • error / exception при проблеме

• использовать централизованный сбор логов (ELK, Loki и т.п.)

Тогда, чтобы найти сбой:

1. Берём request_id проблемного запроса.

2. Фильтруем логи по этому ID.

3. Смотрим по времени: какой сервис последний отдал 200, а какой первый вернул ошибку или завис.

3. Распределённая трассировка (distributed tracing)

Определение:
Распределённая трассировка — это способ визуально и технически отслеживать путь запроса через множество сервисов, разбивая его на спаны (spans).

Инструменты: Jaeger, Zipkin, OpenTelemetry.

Как это помогает:

• видим дерево вызовов: Gateway → Auth → OrderService → PaymentService

• по каждому спану:

  • время начала/конца

  • статус (OK/ERROR)

  • метаданные (URL, код ответа)

• на графике сразу видно:

  • где ошибка (спан со статусом ERROR)

  • где “бутылочное горлышко” по времени

4. Метрики и алерты

Метрики дополняют картину:

• error_rate по сервисам и их методам

• latency (p95, p99)

• throughput (RPS)

Если внезапно растёт error_rate у конкретного сервиса, именно он — кандидат на точку сбоя. Дальше уже смотрим трассировку и логи по request_id.

5. Итоговый процесс поиска сбоя

1. Пользователь сообщает о проблеме или алерт срабатывает на рост ошибок.

2. Находим конкретный запрос (по времени, пользователю и т.д.) и его request_id.

3. Открываем:

   • трассировку по этому request_id

   • логи по этому ID

4. Определяем:

   • какой сервис первый вернул ошибку

   • либо где сильно выросла задержка без явной ошибки

5. Переходим к детальной диагностике уже конкретного сервиса.

Краткий вывод

Чтобы понять, где в цепочке сервисов произошёл сбой, нужны:

• единый request_id/trace_id во всех сервисах,

• структурированные логи,

• распределённая трассировка,

• метрики и алерты.

Без этого поиск точки отказа превращается в ручной перебор и угадайку.