`http.request` resource name only showing request method

[eidsvold]

Hi,

We are using Container-Based APM on our Kubernetes cluster. We have the agent running in the cluster and dd-trace is enabled by annotations and environment variables, not via application code. It works great.

We have a Fastify API that makes multiple outgoing HTTP requests using axios. The issue we have is that the http.request resource names are named only by the HTTP method. We are not able to see metrics for different outgoing requests as they are all named GET or POST.

Is it possible to include the request URL in the resource name? The dd-trace-java does this, as we have this granularity for our Java APIs.

For incoming requests, fastify.request names the resources by request method and URL. We would love the same for outgoing requests.

node: 20.10
typescript: 5.7.2
fastify: 5.1.0
axios: 1.6.8
K8s: admission.datadoghq.com/js-lib.version: v5.27.1

[robin-thomas]

@eidsvold See whether v5.28.0 is working for you. I noticed it broke in v5.25.0 for fastify and then after upgrading to v5.28.0, its working for me.

Could be related to #4942. Not sure.

[robinth91]

The issue is back after upgrading to v5.30.0

[dkeller-sondermind]

Hi just chiming in here to add, we were also experiencing similar issues where dd-trace was not picking up express.request resource traces after upgrading to 5.30.0. Downgrading to 5.28.0 resolved the issue. We have a simple index.ts entrypoint with dd-trace as the first import, followed by express and all other dependencies.

Node 22 (node:22-alpine docker image)
Typescript 5.7.2
Express 4.21.2

Unverified, but quickly glancing through changelog, perhaps this might be caused by the hook registration order changes in #4913 ? Or the router hooks added in packages/datadog-instrumentations/src/router.js (Released in 5.29.0)

[eidsvold]

I tried both v5.45.0 and v5.28.0, but I'm still getting only GET or POST, no URL or path 🙁

[camgaertner]

Issue still present in 5.48.1

[vinnymac]

I just finished a migration of a few API services from express to fastify, and was worried about this negatively effecting my team. However, fastify works correctly and I am on v5.38.0 of dd-trace-js atm.

My advice, ensure dd-trace runs before Fastify. Both your build tooling and your own import hierarchy could be negatively impacting datadog tracing. I've had issues many years ago with this, and now have a habit of working around this issue using --require. Which skips any build processes or bad code from getting in your way.

If someone is already properly configured, and still has an issue I would be curious to find what the difference is between my fastify setup and your own.

[bengl]

It seems that there are two issues in this thread:

1. Sometimes folks aren't getting paths in the resource name for inbound requests.
   • As some have commented, to ensure that Fastify and other frameworks are instrumented, dd-trace needs to be loaded first, ahead of any other code. This allows it to intercept code loading. The easiest way to ensure this is the case is with --require=dd-trace/init if compiling to CJS. For ESM, please follow our public docs on ESM usage.
2. The original post here asks for paths in the resource name for outbound requests.
   • By default, we don't support this, since the cardinality for resource names would be too high. For inbound requests, we use the web framework's routing table to assign a normalized path, but we don't have something like that available for outbound requests.
   • Instead you can manually set the resource name on outbound requests using a hook.

Example Hook:

tracer.use('http', {
  client: {
    hooks: {
      request (span, req, res) {
        span.setTag('resource.name', `${req.method} ${normalize(req.path)}`
      }
    }
  }
})

function normalize(reqPath) {
  // You should do some normalization of request path here, like 
  // removing the query string, or other parameters.
  return reqPath
}

[bengl]

I'm going to go ahead and close this, since my previous comment should address all the issues here. That said, please feel free to comment again if this doesn't address your issues, or you'd prefer an alternative solution.