FEATURE: Add the ability to rename metrics (TSH-20610) (copy #8412)#8424
Merged
FEATURE: Add the ability to rename metrics (TSH-20610) (copy #8412)#8424
Conversation
(cherry picked from commit 939d0ee)
(cherry picked from commit 1b75d31)
(cherry picked from commit dc989db)
…-generated suggestions) (cherry picked from commit 7f25d7b)
(cherry picked from commit 5e16dd5)
…-generated suggestions) (cherry picked from commit 6d344e8)
…-generated suggestions) (cherry picked from commit 1bf8f5c)
10 tasks
|
@mergify[bot]: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/ |
✅ Docs preview readyThe preview is ready to be viewed. View the preview File Changes 0 new, 1 changed, 0 removedBuild ID: 134e9fdcabc5f6b8d306202a URL: https://www.apollographql.com/docs/deploy-preview/134e9fdcabc5f6b8d306202a |
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
75cae6f to
df20472
Compare
bnjjj
approved these changes
Oct 15, 2025
This file contains hidden or 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
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.
The need
Many Apollo customers use observability platforms (like Datadog). While OTLP semantic naming is idealistically useful for consistent metrics naming across systems, it does create practical cost management issues. Datadog, for instance, only allows tag indexing to be enabled/disabled by metric name, not by the service emitting the metric. This means customers who wish to have the ability to control the costs for tag ingestion specific by service require the need to rename Router-emitted metrics to isolate them to be able to have the necessary cost insights and controls per emanating service.
For example, for 'http.server.request.duration', the tags needed for Router monitoring can significantly differ from those for other services emitting the same metric. For one service the cardinality of a given tag may be tolerable to budget for, whereas the cardinality of the same tag by another service may not be.
Our previous federated GraphQL solution, Apollo Gateway, we prefixed all metrics with the service name, ensuring uniqueness and provided us direct control over the cost incurred by controlling the indexing on its tags isolated from other services.
The implementation
The logic added to production code is quite minimal; the bulk of this PR involves testing to ensure it works as intended and only affects customer metrics, not Apollo Studio metrics. This change uses the Rust opentelemetry crate's ability to specify instrument names via views, exposing this through a 'rename' directive in the Router config YAML.
Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
This is an automatic copy of pull request #8412 done by [Mergify](https://mergify.com).
Footnotes
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. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
A lot of (if not most) features benefit from built-in observability and
debug-level logs. Please read this guidance on metrics best-practices. ↩Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩