Кратко и по шагам — методика трассировки инцидента, корреляции событий между микросервисами и поиска первопричины на основе JSON‑лога с временными метками и ошибками таймаута.
1) Сбор и подготовка данных
- Централизуйте логи (ELK, Loki, Splunk) и парсите JSON в поля: $timestamp$, $service$, $level$, $message$, $trace\_id$, $span\_id$, $parent\_id$, $request\_id$, $latency$, $status$, прочие метаданные.
- Нормализуйте временные метки в UTC и проверяйте смещение часов (clock skew).
2) Выделение инцидента и выбор окна анализа
- Найдите все записи с ошибками таймаута. Определите время первого обнаруженного таймаута как $t_0$.
- Возьмите окно вокруг инцидента: $t\in [t_0-{\Delta }_{-},t_0+{\Delta }_{+}]$, например ${\Delta }_{-}=5\text{s},{\Delta }_{+}=60\text{s}$ (подберите под нагрузку).
3) Корреляция по идентификаторам
- Если есть распределённые trace/span id: группируйте по $trace\_id$ и реконструируйте дерево вызовов — это первичный и самый точный метод корреляции.
- Если их нет: используйте $request\_id$, session/user id, connection id, payload‑поля для связывания вызовов между сервисами.
- При отсутствии явных id: коррелируйте по близости времён и по совпадению входных/выходных параметров (heuristic correlation).
4) Алгоритм поиска первопричины (root cause)
- Найдите первый в хронологии таймаут в цепочке: для каждого таймаута $B$ ищите upstream‑вызовы $A_i$, завершившиеся незадолго до таймаута $B$.
- Сравните латентности: если суммарная задержка upstream превышает порог таймаута приложения $T_B$, то upstream может быть причиной. Формализовано: пусть $L_B=L_{base,B}+{\sum }_i{L}_{A_i\to B}$. Если $L_B>T_B$, то причиной вероятно $A_i$ с большим $\Delta L_{A_i}$.
- Ищите признаки распространения ошибок: повторные таймауты, спайки ошибок по нескольким сервисам, массовые ретраи → возможен retry storm или зависимость очередей.
5) Дополнительные источники данных
- Метрики (CPU, память, GC, сетевые ошибки), APM (span‑duration), очереди/брокеры (lengths), SLO/latency‑histograms.
- Сопоставьте пики метрик с временным окном: если CPU/GC у сервиса $A$ выросли в $[t_0-\delta ,t_0]$, $A$ вероятно вызвал деградацию.
6) Примеры полезных запросов/агрегатов
- Найти все таймауты: message contains "timeout" OR status = "timeout".
- Группировка по trace_id: count per $trace\_id$ и минимальное время: выбрать trace с наибольшим числом ошибок.
- Латентности: посчитать перцентиль $p_{95}(latency)$ по сервисам в окне. (впишите в систему: percentile(latency,95)).
7) Диагностический порядок действий
- 1) Найти первую запись с timeout ($t_0$).
- 2) Выделить все связанные trace_id и смежные сервисы в окне.
- 3) Построить цепочку вызовов (span tree), отметить узлы с увеличенной latency/ошибками.
- 4) Сопоставить с метриками инфраструктуры для подтверждения (ресурсы/GC/сеть).
- 5) Проверить логи на ретраи/параметры таймаутов/конфигурации (timeout values, circuit breaker).
- 6) Сделать гипотезу первопричины и воспроизвести/валидировать.
8) Что делать при отсутствии распределённого трейсинга
- Быстрое улучшение: внедрить OpenTelemetry/Zipkin/Jaeger, пропагировать trace_id/span_id через заголовки; логировать request_id во всех сервисах.
- Короткосрочно: увеличить детализацию логов, включить correlation ids, логировать вход/выход и duration.
9) Меры по предотвращению повторения
- Настроить таймауты и retry с экспоненциальным backoff, circuit breakers, лимиты коннекций, очереди/буферизацию.
- Автоматические алерты на рост $p_{95}$ и ошибок: если $p_{95}(latency)>SLA$ или error rate > threshold.
10) Визуализация и отчёт
- Постройте service dependency graph, sequence diagram / flame graph по trace_id, и краткий отчет: первый затронутый сервис, зависимые сервисы, ключевые метрики и подтверждающие логи.
Ключевые признаки первопричины: первый в цепочке рост latency/исключения в upstream, совпадение по времени с инфраструктурными аномалиями, отсутствие ошибок в downstream до момента задержки upstream.