-
Notifications
You must be signed in to change notification settings - Fork 284
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
base: main
Are you sure you want to change the base?
Conversation
6f4dcae to
432f06b
Compare
0a11e90 to
dd0d5d9
Compare
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 <[email protected]>
208b6b9 to
2708010
Compare
| let resource = sdk::Resource::builder() | ||
| .with_attribute(KeyValue::new( | ||
| semconv::attribute::PROCESS_PID, | ||
| std::process::id() as i64, |
There was a problem hiding this comment.
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.
| std::process::id() as i64, | |
| i64::from(std::process::id()), |
| .with_max_queue_size(1000) | ||
| .with_scheduled_delay(Duration::from_secs(5)) |
There was a problem hiding this comment.
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?
| 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"); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.)
| 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"); |
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.