Хабр разбирает автоинструментацию в APM: где теряются 4 секунды запроса

Запрос выполняется 4 секунды. В монолите разработчик включил бы профилировщик и нашёл тяжёлый метод за вечер. В системе, где запрос проходит через API Gateway, несколько микросервисов, очередь сообщений, базу данных и внешний API, профилировщик на одной машине показывает лишь кусок картины. Хабр опубликовал разбор того, как APM отвечает на вопрос «куда ушло время» с помощью распределённой трассировки и автоматической инструментации.

Trace и span: из чего собирается картина

В distributed tracing каждый запрос представлен как trace, то есть полный маршрут через все компоненты. Trace делится на span: каждый отдельный вызов на фронте, бэкенде или шине получает собственный отрезок времени. У span есть идентификатор, ссылка на родителя, время начала и длительность. Из этих связей собирается дерево вызовов.

Чтобы span из разных сервисов попали в одно дерево, контекст должен передаваться вместе с запросом. Сейчас это обычно заголовок traceparent из стандарта W3C Trace Context. В нём лежат идентификатор трассы (16 байт), идентификатор текущего span (8 байт) и флаги, например признак семплирования. Сервис принимает заголовок, создаёт дочерний span и передаёт контекст дальше.

Как работает автоинструментация

Ручной вариант выглядит так: разработчик оборачивает вызовы в код трассировки в каждом сервисе. В командах из десятков сервисов это быстро превращается в долг. Автоинструментация убирает эту работу: агент подключается к рантайму и сам добавляет измерения вокруг известных библиотек.

Механизмы зависят от платформы:

• Java: агент через -javaagent и java.lang.instrument модифицирует байт-код при загрузке классов, часто на базе ASM или Byte Buddy.
• .NET: используется Profiling API среды CLR.
• Python и Node.js: подменяются функции в популярных библиотеках (monkey-patching, хуки загрузки модулей).
• Go и компилируемые языки: чаще применяют eBPF или ручные обёртки, потому что рантайм менее податлив.

Агент знает типовые точки: HTTP-серверы и клиенты, драйверы баз данных, клиенты очередей. Ему не нужно понимать бизнес-логику, чтобы замерить входящий запрос, SQL-запрос или публикацию сообщения. Из этих замеров рождаются span, которые уходят в коллектор и дальше в хранилище APM.

Где у такого подхода предел

Автоинструментация видит то, что заранее описано. Если время уходит в собственный алгоритм внутри метода, в блокировку на общем ресурсе или в пул потоков, стандартные хуки покажут лишь один длинный span без объяснений. Здесь помогают дополнительные span вокруг критичных участков и профилирование потоков.

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

Практика: с чего начать

Если в системе больше трёх-четырёх сервисов, а инциденты разбираются по логам вручную, начинать стоит с минимального набора шагов:

• Включить автоинструментацию на одном критичном пути, например оформлении заказа, а не на всей инфраструктуре сразу.
• Проверить сквозную передачу traceparent через шлюз, очереди и асинхронные обработчики: на них трассы рвутся чаще всего.
• Добавить вручную span вокруг тех участков, где автоагент показывает «чёрный ящик».
• Настроить семплирование так, чтобы медленные запросы (например, выше p95) сохранялись всегда.
• Сверить результат с метриками и логами по общему trace ID, чтобы переход между сигналами занимал секунды.

Такой подход переводит разговор «система тормозит» в конкретику: 3,1 секунды ушло на внешний API, 0,6 на запрос к базе, остальное на очередь. С этого начинается оптимизация, а не с догадок.