Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

chore(tracing): Use upstream tracing batch exporter #4279

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sfleen wants to merge 1 commit into main
base: main
Choose a base branch
Loading
from sfleen/tracing-upstream-exporter

Conversation

@sfleen
Copy link
Collaborator

@sfleen sfleen commented Nov 12, 2025

The proxy used its own custom trace exporter for some time. It was built before the upstream OpenTelemetry libraries were available, and they have outlived their usefulness.

This replaces the custom exporter with a batch exporter configured to export to the same endpoint with the same service configuration.

In the future, this exporter can be installed as a global default trace processor, which would decouple it from the service layer where the proxy generates spans for requests.

@sfleen sfleen requested a review from a team as a code owner November 12, 2025 20:10
@cratelyn cratelyn self-requested a review November 13, 2025 15:36
@sfleen sfleen force-pushed the sfleen/semconv branch 2 times, most recently from 6f4dcae to 432f06b Compare November 14, 2025 13:28
@sfleen sfleen force-pushed the sfleen/tracing-upstream-exporter branch 3 times, most recently from 0a11e90 to dd0d5d9 Compare November 14, 2025 13:48
Base automatically changed from sfleen/semconv to main November 14, 2025 20:53
The proxy used its own custom trace exporter for some time. It was built before the upstream OpenTelemetry libraries were available, and they have outlived their usefulness.
This replaces the custom exporter with a batch exporter configured to export to the same endpoint with the same service configuration.
In the future, this exporter can be installed as a global default trace processor, which would decouple it from the service layer where the proxy generates spans for requests.
Signed-off-by: Scott Fleener <scott@buoyant.io>
@sfleen sfleen force-pushed the sfleen/tracing-upstream-exporter branch 2 times, most recently from 208b6b9 to 2708010 Compare November 17, 2025 15:50
let resource = sdk::Resource::builder()
.with_attribute(KeyValue::new(
semconv::attribute::PROCESS_PID,
std::process::id() as i64,
Copy link
Member

@unleashed unleashed Nov 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unlikely to happen anytime soon, but easy to future-proof potential pid space growth.

Suggested change
std::process::id()asi64,
i64::from(std::process::id()),

Comment on lines +53 to +54
.with_max_queue_size(1000)
.with_scheduled_delay(Duration::from_secs(5))
Copy link
Member

@unleashed unleashed Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these hardcoded numbers be defined as constants?

Comment on lines +231 to +246
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "telemetry.sdk.name");
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "telemetry.sdk.version");
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "telemetry.sdk.language");
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "service.name");
Copy link
Member

@unleashed unleashed Nov 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not asserting anything?

cratelyn reacted with thumbs up emoji
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

presumably we'll want something like this? (only one assertion is added below, but we'd want the the same for the other three.)

Suggested change
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "telemetry.sdk.name");
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "telemetry.sdk.version");
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "telemetry.sdk.language");
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "service.name");
assert!(
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "telemetry.sdk.name")
.is_some()
);
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "telemetry.sdk.version");
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "telemetry.sdk.language");
resource_span_resource
.attributes
.iter()
.any(|attr| attr.key == "service.name");

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cratelyn cratelyn Awaiting requested review from cratelyn

1 more reviewer

@unleashed unleashed unleashed left review comments

Reviewers whose approvals may not affect merge requirements

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /