Split telemetry into parse, validate and execution #1172
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This get a bit closer to what we see in other implementations, like the javascript one, where we have explicit phases for parse and validation. This way, we can instrument Absinthe in a similar fashion, and break down how much work is done inside the framework (by parse/validation) and by the execution engine itself (and resolvers). Example of those phases in [Apollo Federation + JS impl][1]. [1]: https://www.apollographql.com/docs/federation/opentelemetry/#graphql-specific-spans
andrewhr
added a commit
to andrewhr/opentelemetry-erlang-contrib
that referenced
this pull request
May 27, 2022
Add instrumentation for `Absinthe`, the GraphQL Elixir-framwork. Relies on
some new telemetry work on Absinthe:
* [Added telemetry for async helper][1], used to propagate traces
* [Improved telemetry for batch helper][2], used to propagate traces
* [Tweaked pipeline instrumentation][3], that splits parse/validate/execute
phases, following the approach of [JavaScript libraries][4]
Span names and attributes also follow the [JavaScript impl][4], the
closes to a future [Semantic Attribute][5] spec.
The "span tracker" used here is to connect traces in a shape that
resembles the query shape instead of execution shape. One example is:
```
query {
users {
name
}
}
```
In case `name` is an async resolver (for example), the execution will
resembles a recursive function, and such our trace will be:
```
RootQueryType.users
User.name
User.name
User.name
```
With the span tracker, the above trace will become:
```
RootQueryType.users
User.name
User.name
User.name
```
That helps visually scan the traces, and it's friendly to folks who
doesn't know much about Absinthe internals.
[1]: absinthe-graphql/absinthe#1169
[2]: absinthe-graphql/absinthe#1170
[3]: absinthe-graphql/absinthe#1172
[4]: https://www.npmjs.com/package/@opentelemetry/instrumentation-graphql
[5]: open-telemetry/opentelemetry-specification#2456
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This get a bit closer to what we see in other implementations, like the javascript one, where we have explicit phases for parse and validation.
This way, we can instrument Absinthe in a similar fashion, and break down how much work is done inside the framework (by parse/validation) and by the execution engine itself (and resolvers). Example of those phases in Apollo Federation + JS impl.