Feature Request: Tracing support

[tHBp]

Consider adding tracing support to enable checking runtime performance of queries and downstream API/Database calls.

Apollo supports the same via a plugin.

It can be either directly part of the core, or be implemented as a plugin. But for the latter, I guess we'd have to roll out a plugin architecture.

[mcollina]

Would you like to work on this? I think it would be a nice feature to add.

[tHBp]

Sure, will try to complete a first revision over the weekend.

[xamgore]

Precious information may be found in the apollo-tracing repository.

@tHBp could you please share your work? Maybe I could continue it.

[pscarey]

@xamgore @tHBp

I'd like to flag that the only solution here isn't just Apollo's approach, but also the tracing could be implemented with OpenTelemetry. Adding an OpenTelemetry exporter would be a viable way of supporting many more tracing backends in a performant way.

Wrapping all resolvers in a Schema to achieve detailed tracing (by analysing the GraphQL info object which includes type, path), is viable, but can have large performance impacts. I have implemented this approach on certain APIs for advanced Audit Logging, so it's worth the hit, but ensuring performance is not overly impacted is key for tracing.

A viable approach here may be:

• Wrapping and timing only the key schema/resolvers (i.e. where a resolve function has been provided).
• Only tracing execution time a configurable percentage of the time.

It might be that timing every resolver is possible, but performance impacts should be kept in mind (Apollo is certainly able to achieve this in Apollo Engine / Graph Manager).

I can provide some additional info on how you might go about wrapping the schema if either of you is interested in this.

[mcollina]

I would actually prefer adding OpenTelemtry support.

[PacoDu]

I think we will just need some documentation that explains how to use opentelemetry with mercurius. Some packages are about to be released for graphql instrumentation: @opentelemetry/instrumentation-graphql. I've not tested this package yet.

open-telemetry/opentelemetry-js-contrib#226

[PacoDu]

It works ! I had to clone opentelemetry repo to access @opentelemetry/instrumentation-graphql, but here is a simple tracer and it works pretty well with mercurius and federation :

'use strict'

const api = require('@opentelemetry/api')
const { NodeTracerProvider } = require('@opentelemetry/node')
const { SimpleSpanProcessor } = require('@opentelemetry/tracing')
const { ZipkinExporter } = require('@opentelemetry/exporter-zipkin')
const { GraphQLInstrumentation } = require('@opentelemetry/instrumentation-graphql')

module.exports = serviceName => {
  const provider = new NodeTracerProvider()
  const graphQLInstrumentation = new GraphQLInstrumentation()
  graphQLInstrumentation.setTracerProvider(provider)
  graphQLInstrumentation.enable()
  provider.addSpanProcessor(
    new SimpleSpanProcessor(
      new ZipkinExporter({
        serviceName
      })
    )
  )
  provider.register()
  return api.trace.getTracer(serviceName)
}

[mcollina]

Could we ship that as a small module with a few tests in this org?

[PacoDu]

Could we ship that as a small module with a few tests in this org?

I'm not sure this should be a module, from what I understand about opentelemetry, the tracer definition is for the end user. What we can do on our end is to add some mercurius specific span, maybe on loaders, cache, jit ?

https://open-telemetry.github.io/opentelemetry-js/#library-authors

[mcollina]

I think it would be awesome to wrap resolvers and loaders.

[PacoDu]

I think it would be awesome to wrap resolvers and loaders.

I think it needs more experimentation but the resolvers are already covered automatically via graphql-instrumentation, a parameters allows to configure the depth of the tracing

[mcollina]

I have a feeling it won't work for graphql-jit, but maybe I'm too pessimistic.

[PacoDu]

I have a feeling it won't work for graphql-jit, but maybe I'm too pessimistic.

Yes it wont.

About fastify and opentelemetry, the current landscape is a bit confusing because there is multiple initiative like https://github.com/autotelic/fastify-opentelemetry and https://github.com/mkinoshi/fastify-opentelemetry.

see open-telemetry/opentelemetry-js-contrib#41

fastify-opentelemetry doesn't seem up to date with the latest version of fastify (it uses deprecated hooks). I haven't tested autotelic version yet.

@mcollina Is there any plan to move this kind of integration under the fastify org ?

[mcollina]

https://github.com/autotelic/fastify-opentelemetry should do the trick.