Buglapse

Обзор ​

httpTracingIntegration записывает каждый исходящий HTTP-запрос спаном http.client, названным по методу и пути (POST /v1/charges). Она следит за обоими способами, которыми процесс Node делает запросы:

  • глобальный fetch();
  • node:http / node:https — и все библиотеки поверх них (axios, got, node-fetch, SDK сторонних API).

Каждый спан записывает http.method, http.url и http.status_code. Статус — ok для ответа 2xx и error в остальных случаях, включая сетевые сбои. Собственные запросы SDK на /api/envelope игнорируются.

Запрос, сделанный во время активного спана, становится его дочерним, так что с HttpServerIntegration вызовы, которые делает обработчик запроса, видны внутри трейса этого запроса.

Использование ​

ts
import { use } from '@buglapse/node'
import { httpTracingIntegration } from '@buglapse/node/integrations'

use(httpTracingIntegration())

Передача трейса дальше ​

Каждый исходящий запрос также получает заголовки traceparent и tracestate, указывающие на его спан http.client, — сервис на @buglapse/node с HttpServerIntegration (или на любом SDK, читающем W3C Trace Context) записывает свою работу дочерней этому спану, в том же трейсе. См. Распределённый трейсинг.

По умолчанию их получает любой адрес. tracePropagationTargets сужает это — строка совпадает как подстрока адреса, RegExp — по test():

ts
init({
    dsn: process.env.BUGLAPSE_DSN,
    tracePropagationTargets: ['https://billing.internal', /^https:\/\/api\.example\.com\//],
    integrations: [httpTracingIntegration()],
})

Запрос, у которого уже есть traceparent, не трогается, а записи tracestate других вендоров сохраняются. С propagateSentryTrace: true те же запросы получают ещё и sentry-trace и baggage Sentry.

У самой интеграции опций нет. Спан node:http заканчивается, когда ответ дочитан до конца; ответ, который ваш код не читает, оставляет свой спан неотправленным.