Add support for partial success in an OTLP export response [2]#2696
Conversation
|
Hi all, just an update on the current state of this PR: All discussions are solved and I think we should be good to go! The last thing to be solved (here) was around using the partial success to convey warnings/suggestions to clients when ALL the data was accepted. This is useful, for example, when the server did some massaging on the data (character normalization) and wants to send a "warning" to clients that this happened. Another usage would be to signal suggestions to clients, e.g. "hey you are sending the data via a less efficient/secure way, you should do xyz" like @reyang suggested here. Let me know your thoughts. |
|
@joaopgrassi please rebase (or otherwise resolve "This branch is out-of-date with the base branch")? |
|
@jmacd rebased and also allowed edits from maintainers on the branch, in case it needs again and I'm away. |
Fixes #2454, Closes #2636
This is a second take on #2636. It's basically the same changes, except it uses
rejected_<signal>semantics instead ofaccepted_<signal>as discussed in the PRs and in the spec meeting on 7/19/2022.Changes
This PR adds guidance around how servers can signal a partial success to clients. It indicates in which situations servers can respond with a partial success and how the fields introduced in opentelemetry-proto #414 should be populated.
I also refactored the
OTLP/gRPC Responsesection a bit, to make it consistent with the HTTP one. The main inconsistency I found was that the gRPC section did not have clear sections forSuccess,Failureas the HTTP does. Now both share the same sections and the wording should be consistent between the two.Related
Proto change: open-telemetry/opentelemetry-proto#414
cc @tigrannajaryan @jmacd @jsuereth @jack-berg @reyang @yurishkuro