Absinthe: Telemetry integration & design

[binaryseed]

Hello! I recently released a basic New Relic integration with Absinthe:

• https://github.com/binaryseed/new_relic_absinthe/blob/master/lib/new_relic/absinthe/middleware.ex

It works fine as a Middleware, but it'd be really sweet to have a Telemetry integration that could be leveraged generically, and it'd make the instrumentation automatic instead of requiring a custom middleware stack. I'm working on a New Relic telemetry exporter and have been keeping a close eye on how the Telemetry project evolves.

• https://github.com/beam-telemetry/telemetry

I'd like to offer to build into Absinthe a telemetry integration. To get started, we should sketch out a design of what the events might look like!

Possible events:

• [:absinthe, :resolver, :call] - Triggered for each resolver that calls a function (ie: not the default Map.get)

metadata = %{
  type: :absinthe_resolver_call,
  schema: inspect(res.schema),
  type: Absinthe.Type.name(res.definition.schema_node.type, res.schema),
  field_name: res.definition.name,
  query_path: Absinthe.Resolution.path(res) |> Enum.join("."),
  parent_type: res.parent_type.name
}

• [:absinthe, :resolution, :complete] - Triggered at the end of a completed query resolution

metadata = %{
  type: :absinthe_resolution_complete,
  schema: inspect(res.schema),
  query_complexity: operation.complexity,
  operation_type: operation.type,
  operation_name: operation.name
}

This is just pulled from what I have in the New Relic middleware, hoping it's a good starting off point to discuss...

---

@benwilson512 @bruce
cc/ @arkgil @josevalim

[zacck]

@binaryseed we could also label events, with which part of the pipeline is working on the Blueprint?

[binaryseed]

@zacck are you suggesting we post an event for each phase of the resolution pipeline? My concern there is that it might be too granular to be very meaningful

[zacck]

@binaryseed well, maybe we can pick out parts of interest? or allow users to choose? But yes I agree with you each step might be too much to be meaningful

[arkgil]

I don't know what are the practices for monitoring GraphQL APIs, but maybe a good starting point would be to publish an event when Absinthe starts and finishes resolving the top-level mutation or query? This would allow monitoring at least the processing time of operations invoked directly by the clients, and one can always expand from here.

[zacck]

@arkgil Your suggestion seems to be the very exact same as what @binaryseed says to start with, I think this would at the very least open the door to other events that people would need at the very least

[arkgil]

Sorry, I misunderstood the original proposal! I thought that what @binaryseed meant is that the event is fired for each resolver, even the ones for nested fields. :)

[josevalim]

Telemetry allows anyone to publish whatever events they want. So starting
with a minimum is fine and users can annotate other pieces of code they

want to instrument.

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

[zacck]

@churcho @wanjikumac @ricoh @yordis any suggestions on what to trace?

[WanjikuMac]

Just started interacting with the GraphQL API's, I agree with @binaryseed and @arkgil on publishing an event when Absinthe starts and finishes resolving the top-level mutation or query: @zacck this is what I would probably trace.

• [ ] To at least enable monitoring the processing time of operations.
• [ ] Give a clear trace of errors encountered while publishing an event

[bgentry]

I'm super interested in this as well and would love to be able to help by integrating a generic telemetry design with AppSignal. I'll be keeping an eye on this and #663, but please feel free to ping me in if there's anything I can answer about that integration or if it's ready to take a crack at it :v:

[binaryseed]

@bgentry Cool! Do you have an existing Absinthe instrumentation? What do you think of the fields listed out as metadata in my original comment? The code to emit the events is in place (pending review from maintainers) and next I'm going to add the metadata fields

[bgentry]

@binaryseed well I just now set up AppSignal's unofficial Absinthe support but it is super minimal. Your metadata suggestions look good to me!

[yordis]

@zacck I would say that I wouldn't expect these packages to be that magical.

I would prefer to simply call some function with a simple API design in my resolvers even when it means repeating code. DRY comes with a cost, and for these type of DRYs most likely people get wrong (or insert a better word that says, you didn't do it wrong but it doesn't work for all the use cases).

Since the $1M question is, how much info we send and when?, and the answer to that question is completely depending on the use cases and even the business scale or needs.

I wouldn't go for the magical route but for a route that has a really nice API and makes it easier for people to use when makes sense to them.

But that is just my 2 cents on the topic.

[binaryseed]

@arkgil How do you imagine that telemetry_metrics would fit into the picture in an integration like this?

[binaryseed]

FYI my PR has all the functionality now: https://github.com/absinthe-graphql/absinthe/pull/663

[conradwt]

@binaryseed I would like to recommend that this PR gets extracted into its own Hex package, absinthe-telemetry, and allow developers to add it on an as-needed basis. Why? I would like the Absinthe project to focus on implementing the GraphQL spec for the Elixir Language. Furthermore, telemetry collection is nice functionality to have but it's not a requirement of every project that wishes to use Absinthe. When you're ready to move your application to production, there are a plethora of non-paid as well as and paid projects for telemetry collection. Just my 2 cents.

[bruce]

@binaryseed, et al — we’ll get back to you soon on this; handling prep work/support for a product launch at CES.

[josevalim]

Just one note: I would recommend a minimal telemetry as part of Absinthe. Telemetry doesn't really compare with most other libraries because Telemetry does not do any publishing. It is not tied to any backend. It is just an event dispatching mechanism to make it easier for all of those other paid and non paid libraries to extract information from absinthe. The library was designed to be minimal and have very low footprint.

In fact, if you perform logging in absinthe, i would even recommend replacing those by telemetry and then you do the logging from telemetry.

Ecto, Plug and Phoenix will ship with telemetry support by default too.

[arkgil]

@binaryseed there is no need for special integration with telemetry_metrics since it works with any event published with telemetry. Any additional constraints will be imposed by something which understands metric specs defined by telemetry_metrics - reporters, exporters, or how we call it.

[binaryseed]

Thanks @bruce, good luck with your launch! I forget sometimes that ya'll do something besides Absinthe :)