Необходимость оборачивание операций, которые мы хотим мониторить, в спаны - приводит к новому челленджу.

Допустим в 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 запросы