Необходимость оборачивание операций, которые мы хотим мониторить, в спаны - приводит к новому челленджу. Допустим в Fastify есть хук onRequest, который в коллбэке передает нам метод done - он содержит весь стек вызовов на обработку текущего запроса, и весь запрос легко обернуть в спан: app.addHook('onRequest', (req, reply, done) => { tracer.trace('GET', async () => { done(); }) }) Но в Tramvai есть базовые механизмы, которые мы тоже хотим мониторить: - линии Command Line Runner - значимые хуки роутера - запросы через наши Http Client И это привело меня к необходимости изменения архитектуры этих механизмов, и в целом выбрать подход куда двигаться базовым модулям Tramvai. Я рассматривал два основных варианта как референс - хуки Fastify, и хуки Webpack Tapable, на последнем варианте в итоге и остановился. Реализовал несколько кастомных Tapable хуков, которые позволяют добавить в цепочку или для параллельного запуска любые действия (синхронные и асинхронные), а также обернуть их, самый важный для нас момент. Примеры Tapable хуков можно посмотреть в юнит-тесте - https://github.com/tramvaijs/tramvai/blob/main/packages/libs/hooks/src/tapable.spec.ts Отрефакторил Command Line Runner, Router, Http Client interceptors, тут сразу подсвечу мою недоработку которая может в будущем выстрелить - стоило сделать подмену реализаций (выбор старой или новой реализации) через параметры сборки, я же просто создал копии файлов, отрефакторил и переключил старый на новый хардкодом, прогнав все тесты. Это позволило сделать простой кастомный автоинструментарий, состоящий из оборачивания подходящих Tapable хуков, пример с роутингом - https://github.com/tramvaijs/tramvai/blob/f9d7bde4991b07689b95347efd64b9eea17b59b8/packages/modules/opentelemetry/src/instrumentation/router.ts#L34 Также нашим пользователям это позволит интегрировать сбоку подробный мониторинг любыми своими инструментами, а таже расширить поведение фреймворка дополнительной логикой. И конечно тут не без значимых минусов: - хуки и особенно оборачивание (через метод wrap) раздувает стек вызовов JS кода, заметно усложняет отладку - также это незначительно, но влияет на перформанс, но тут заметнее влияние на создание большого количества спанов (повод не делать их слишком много и не мониторить мелкие задачи) - хуки усложняют код, делают поведение не линейным и менее прозрачным - сделал для всех хуков описание и визуализацию - https://tramvai.dev/docs/features/app-lifecycle#commandlinerunner-hooks В итоге уже время и практика использования покажет, насколько было верное решение) Еще из небольших но интересных вещей по телеметрии: - для сквозного поиска между трейсами и логами добавил корреляцию для логов, достаю из асинхронного контекста id'шники спанов и трейсов и добавляю в каждый лог - для сквозного поиска между разными сервисами добавил всплытие контекста - учитываю id'шники спанов и трейсов из заголовков входящего запроса на сервер, добавляю соответствующие заголовки в исходящие HTTP запросы