Вместо введения. Когда приложение состоит из одного процесса и нескольких десятков методов, найти причину медленной работы относительно просто: можно включить профилировщик, посмотреть логи и найти проблемный участок кода. В распределённой системе всё меняется. Один пользовательский запрос может пройти через API Gateway, несколько микросервисов, очередь сообщений, базу данных и внешний API. При этом каждый компонент может находиться на отдельном сервере или контейнере. Если такой запрос выполняется 4 секунды, возникает вполне практический вопрос: Где именно были потрачены эти 4 секунды?:На сети? На базе данных? На блокировке потока? На выполнении конкретного метода? На внешнем сервисе? Именно для ответа на этот вопрос в APM используются трассировка (distributed tracing) и инструментация приложений. Один из наиболее интересных подходов - автоматическая инструментация, при которой разработчику не требуется вручную добавлять tracing-код в каждый сервис. Разберём, как это работает на уровне архитектуры и что происходит внутри приложения. Что такое трассировка Начнём с базовых понятий. В distributed tracing каждый пользовательский или системный запрос представляется как trace - распределённая трасса (или давайте скажем - полный маршрут прохождения цепочки запросов). Trace состоит из отдельных операций - span (каждый отдельный вызов - на фронте, на бэке, на шине). Упрощённо это можно представить так: Читать далее