[Subgraph Insights] Add Apollo Connectors Fetch Histogram to Telemetry Plugin

[rregitsky]

---

Description

This is a follow-up to #8013 to add the same functionality for connector fetches. It also adds additional connector instrument selectors that can also be utilized for user-defined custom instruments.

New Apollo Connector Fetch Histogram

This change adds a new, experimental histogram to capture connector fetch duration for Apollo Studio. The instrument,
apollo.router.operations.fetch.duration has the following attributes:
apollo.client.name
apollo.client.version
has_errors
apollo.operation.id
graphql.operation.kind
graphql.operation.name
subgraph.name
This can be toggled on using a new boolean config flag:

telemetry:
  apollo:
    experimental_subgraph_metrics: true

The instrument is currently only sent to GraphOS and is not available in 3rd-party OTel export targets. It is not
user customizable. For this purpose, users can take advantage of the existing customizable instrument
http.client.request.duration measuring the same value.

Additional Connector Custom Instruments

This also adds new custom instrument selectors for Connectors and enhances some existing selectors. The new selectors are:

• supergraph_operation_name
  • The supergraph's operation name
• supergraph_operation_kind
  • The supergraph's operation type (e.g. query, mutation, subscription)
• request_context
  • Takes the value of the given key on the request context
• connector_on_response_error
  • Returns true when the response does not meet the is_successful condition. Or, if that condition is not set,
    returns true when the response has a non-200 status code

These selectors were modified to add additional functionality:

• connector_request_mapping_problems
  • Adds a new boolean variant that will return true when a mapping problem exists on the request
• connector_response_mapping_problems
  • Adds a new boolean variant that will return true when a mapping problem exists on the response

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

• PR description explains the motivation for the change and relevant context for reviewing
• PR description links appropriate GitHub/Jira tickets (creating when necessary)
• Changeset is included for user-facing changes
• Changes are compatible¹
• Documentation² completed
• Performance impact assessed and acceptable
• Metrics and logs are added³ and documented
• Tests added and passing⁴
  • Unit tests
  • Integration tests
  • Manual tests, as necessary

Exceptions

Note any exceptions here

Notes

Footnotes

1. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩

2. Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩

3. A lot of (if not most) features benefit from built-in observability and debug-level logs. Please read this guidance on metrics best-practices. ↩

4. Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩

[apollo-librarian]

✅ Docs preview ready

The preview is ready to be viewed. View the preview

File Changes

0 new, 1 changed, 0 removed

* graphos/routing/(latest)/observability/telemetry/instrumentation/selectors.mdx

Build ID: 0bd4a26aad93696005e93307
Build Logs: View logs

URL: https://www.apollographql.com/docs/deploy-preview/0bd4a26aad93696005e93307

[bonnici]

Looks good to me besides one small comment

[bonnici]

I feel like this error message might need to be updated? 😂

[rregitsky]

It's just a test, but fine 😅 I'll make it more "professional"