feat: base opentelemetry integration

[PacoDu]

This PR adds a base mercurius span to the fastifyGraphql decorator and the cached attribute.

[PacoDu]

I would generically prefer if we provided hooks (similar to fastify, or even simpler) for APMs to plug into. This is totally ok but it's non-scalable as there are a few different implementations for this.

As stated in https://github.com/mercurius-js/mercurius/pull/346#issuecomment-739436886 this is just a cleanup of the previous PR with the tracer declaration and the base mercurius span. Unfortunately, I don't have time to push this implementation further for now.

But, I'm not sure to understand what you mean by providing hooks, as opentelemetry is already providing an API for the end-user to extend the tracing and how it is plugged. This implementation is based on opentelemetry recommendations: https://open-telemetry.github.io/opentelemetry-js/#library-authors

[mcollina]

But, I'm not sure to understand what you mean by providing hooks, as opentelemetry is already providing an API for the end-user to extend the tracing and how it is plugged. This implementation is based on opentelemetry recommendations: https://open-telemetry.github.io/opentelemetry-js/#library-authors

Some APMs do not implement OpenTelemetry but they have similar concepts/libraries. They'd need to put logic in the same places. Instead of calling opentracing directly, we could do:

app.graphql.setTracing({
  ... // all the methods for those points
})

[Sytten]

I also support hooks, I am trying to build an SDK for graphmetrics.io and we are not openmetrics compliant for now (we will consider it when the spec stabilizes a bit). I think we can get quite far with the new 6.12.0 hooks, but we are missing a hook on the field level to measure their resolution time (not applicable for gateway/federation obviously).

[mcollina]

@Sytten this is probably not the right issue to talk about. Maybe you can open a new one? Or just send a PR.

[airhorns]

FWIW I think the aspirations of opentelemetry is to avoid having different APM products all have their own interfaces, and instead give library authors one generally accepted API to integrate against. We'd build integrations against @opentelemetry/api, which defines one interface for tracing, and then Datadog, Honeycomb, Lightstep, and others all support the otel ecosystem with exporters or network endpoints for it to talk to. They are all collaborating on the client libraries explicitly so that we don't all have to try to build support for each individually or none at all. The idea would be if you want to export telemetry from your system to whatever new APM product comes along, you write a new opentelemetry exporter instead of a new integration for each piece of your system. I don't know if it will work and it is early days yet, but at least in the kubernetes space, a lot of communities have standardized on opentelemetry being the way to get telemetry data out of their system, and users use whatever exporter they want (or the opentelemetry collector, which is like a network attached exporter that can redirect to yet more places).