Анализ трассировок и карт сервисов

Мониторинг и устранение неполадок в AWS

John Q. Martin

Principal Consultant

Что такое карта сервисов?

Создаётся автоматически из данных трассировок: ручная настройка не нужна

Табло отправления с рядами сервисов, каждый с цветным индикатором статуса: зелёный — в норме, жёлтый — задержка, красный — остановлен

С первого взгляда: зелёный = в норме · жёлтый = задержка · красный = остановлен

Как открыть:

Консоль X-Ray → Service map
Примените фильтры
Нажмите на узел → подробная разбивка

Цветовое кодирование карты сервисов

Легенда цветового кодирования карты сервисов: зелёный — успешные вызовы, жёлтый — клиентские ошибки, красный — ошибки сервера, фиолетовый — превышение лимитов, серый — нет трафика

Открыв карту сервисов, сразу обращайте внимание на всё, что не окрашено в зелёный.

Нажмите на любой узел, чтобы увидеть: распределение времени отклика, разбивку по HTTP-статусам, типы ошибок.

Чтение карты сервисов

Карта сервисов: API Gateway и OrderService связаны с DynamoDB Inventory и жёлтым сервисом Payment

Анализ критического пути

Критический путь = наиболее длинная цепочка вызовов

API Gateway (50ms)
  -> OrderService (50ms)
    -> PaymentService (100ms)
      -> External API (200ms)

Total: 400ms

External API = 50% суммарной задержки

Что с этим делать:

External API — основная цель оптимизации
Варианты: добавить кэширование, задать таймаут + fallback, согласовать SLA

Для сравнения — альтернативный путь:

OrderService -> DynamoDB
Total: 120ms (fast)

Риски зависимостей

Риски зависимостей в карте сервисов: циклические зависимости, единые точки отказа и рискованные внешние зависимости

Работа с временными шкалами трассировок

Временная шкала трассировки с подсегментами, где вызов payment-api — самая длительная операция

Горизонтальная ось — время: когда операции начались и сколько длились
Вертикальная ось — иерархия сервисов: подсегменты вложены под родительские
HTTP.POST к payment-api (100–250 мс) = самая длительная отдельная операция

Паттерн 1: последовательные узкие места

До (последовательно — 80 мс):

Query 1 (10-30ms)
         -> Query 2 (30-50ms)
                  -> Query 3 (50-70ms)
                           -> Query 4 (70-90ms)

После (параллельно — 20 мс):

Временная шкала трассировки: четыре запроса выполняются параллельно и завершаются за 20 мс

Паттерн 2: N+1 запросы и избыточные вызовы

Проблема N+1 запросов:

Get user list       (10-20ms)
Get user 1 details  (20-30ms)
Get user 2 details  (30-40ms)
... ×100 sequential queries

Решение: пакетные запросы, жадная загрузка

Избыточно болтливые сервисы:

50 мелких вызовов между двумя сервисами вместо одного пакетного
Каждый вызов: установка соединения + сериализация + round-trip
Накладные расходы возрастают в 50 раз

Решение: пакетные запросы, очереди сообщений, кэширование

Паттерн 3: холодные старты и каскадные сбои

Два временных отрезка: холодный старт имеет большой оранжевый блок инициализации и небольшой зелёный обработчик; тёплый старт — только небольшой зелёный обработчик

Холодный старт Lambda:

Холодный: 3000 мс (2500 мс инициализация + 500 мс обработчик)
Тёплый: 500 мс (только обработчик)
При первом вызове виден крупный сегмент инициализации

Решение: выделенная конкурентность, оптимизация инициализации

Каскадный сбой:

Service A [Error]
  -> Service B [Timeout 5s]
    -> Service C [Timeout 5s]
      -> Database [Timeout 5s]

Одинаковые таймауты стекируются по всей иерархии трассировки

Решение: таймауты, автоматические выключатели, fallback-стратегии

Фильтрация трассировок с помощью аннотаций

Консоль X-Ray: фильтрация трассировок по парам ключ-значение аннотаций

Сравнение групп:

Премиум-пользователи: среднее 200 мс, бесплатные: 150 мс → задержку добавляют премиум-функции
EU West в 3 раза медленнее US East → проблема межрегионального доступа к данным

Рабочий процесс анализа трассировок

Выявление — фильтр: response_time > 1000ms, сортировка по длительности
Анализ — поиск длительных операций, последовательных узких мест, возможностей для параллелизации
Аннотации — проверка бизнес-контекста: ID пользователя, ID заказа, среда
Метаданные — изучение деталей запроса и сообщений об ошибках
Корреляция — сопоставление с CloudWatch Logs
Диагностика — первопричина: медленный запрос, таймаут, алгоритм, исчерпание ресурсов
Устранение — оптимизация кода, добавление кэширования, параллелизация, масштабирование
Проверка — сравнение трассировок до и после, мониторинг задержки и частоты ошибок

Создание оповещений на основе данных X-Ray

# High latency alarm
aws cloudwatch put-metric-alarm \
  --alarm-name HighLatency \
  --metric-name ResponseTime \
  --namespace AWS/XRay \
  --statistic Average \
  --period 300 \
  --threshold 1000 \
  --comparison-operator GreaterThanThreshold

# High error count alarm
aws cloudwatch put-metric-alarm \
  --alarm-name HighErrorCount \
  --metric-name ErrorCount \
  --namespace AWS/XRay \
  --statistic Sum \
  --period 300 \
  --threshold 50 \
  --comparison-operator GreaterThanThreshold

Итоги видео

Карты сервисов — автоматически создаваемые схемы архитектуры: узлы (сервисы), рёбра (соединения), цветовая индикация состояния
Цветовое кодирование — зелёный (успех), жёлтый (4xx), красный (5xx), фиолетовый (429), серый (нет трафика)
Критический путь — наиболее длинная цепочка вызовов, указывает на цель оптимизации
Временные шкалы — выявляют последовательные узкие места, N+1 запросы, холодные старты и каскадные сбои
Аннотации — фильтрация и группировка трассировок по бизнес-контексту
Рабочий процесс — восемь шагов: выявление → анализ → аннотации → метаданные → корреляция → диагностика → устранение → проверка

Анализ трассировок и карт сервисов

Мониторинг и устранение неполадок в AWS