Анализ логов интеграции: как быстро находить каскадные ошибки по trace_id

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

Базовая схема поиска

Сначала находим первый error, затем подтягиваем соседние warning и info-события в небольшом временном окне. Так мы видим не только факт падения, но и его предысторию.

with seed as (
    select trace_id, min(created_at) as first_seen
    from app_logs
    where level = 'error'
      and created_at >= now() - interval '6 hours'
    group by trace_id
)
select l.created_at, l.service_name, l.level, l.message
from app_logs l
join seed s on s.trace_id = l.trace_id
where l.created_at between s.first_seen - interval '30 seconds'
                      and s.first_seen + interval '2 minutes'
order by l.trace_id, l.created_at;

Почему это работает

Команда поддержки получает компактный сюжет инцидента, а не разрозненный поток строк. На практике это заметно снижает время первой диагностики и количество ложных гипотез.

Если trace_id нет, его стоит внедрять раньше любой сложной системы лог-аналитики.

Что еще добавить

Полезно помечать лог-сообщения стадией процесса: прием, преобразование, запись, ответ внешней системы. Тогда даже без трассировки видно, на каком шаге началась деградация.