-
Notifications
You must be signed in to change notification settings - Fork 666
Handle partial success responses from OTLP export services #865
Copy link
Copy link
Closed
Labels
A-commonArea:common issues that not related to specific pillarArea:common issues that not related to specific pillarM-exporter-otlpenhancementNew feature or requestNew feature or requestrelease:allowed-for-stableChanges that can still be added before Stable, but won't require Breaking Interfaces.Changes that can still be added before Stable, but won't require Breaking Interfaces.
Milestone
Metadata
Metadata
Assignees
Labels
A-commonArea:common issues that not related to specific pillarArea:common issues that not related to specific pillarM-exporter-otlpenhancementNew feature or requestNew feature or requestrelease:allowed-for-stableChanges that can still be added before Stable, but won't require Breaking Interfaces.Changes that can still be added before Stable, but won't require Breaking Interfaces.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Problem Statement
Following the specification change to add partial success responses, each OTel SDK is encouraged to handle the resulting error message string in an appropriate way, considering existing norms. This requires OTLP v0.19.
Proposed Solution
For each of the
Export*ServiceRequestmethods used by OTLP Trace and Metrics exporters, construct an error and call the appropriate handler with the error message string and the number of spans/points(/logs) dropped. Future OTel specifications may call for optional treatment of the number of dropped items, but presently that is just additional information to include in the handled error.