Implement partial success logging in OTLP exporters
Log partial success
Partial successes during OTLP export is now logged.
Fixes #4803
Type of change
- [X] New feature (non-breaking change which adds functionality)
- [?] This change requires a documentation update
How Has This Been Tested?
Added new unit tests covering the relevant cases.
Does This PR Require a Contrib Repo Change?
- [X] No.
Checklist:
- [X] Followed the style guidelines of this project
- [X] Changelogs have been updated
- [X] Unit tests have been added
- [] Documentation has been updated - unsure what to update
Why put this log behind an env var ? Why not just always log when the field is set -- I'm assuming it's only set when there was a partial success -- it doesn't sound too noisy to me.
I'm uncertain as to the level of noisiness, and so I wanted to minimize disruption to existing users. I could imagine it being somewhat annoying if every batch included one persistently malformed span that just ended up creating log spam.
A more sophisticated approach might be to opt-in to recording every partial success, while elevating the verbosity and logging the partial success unconditionally if every record was a failure (if num_rejected_{type} matches the number of items in the batch). But I wanted to keep things relatively simple.
We already have the DuplicateFilter on this logger, maybe we should tweak that to de-dupe based on line no and module instead of message which can be unique so that it filters stuff out better.
I think it's a bit weird to put just 1 log message behind this env var
Thanks for the review, @DylanRussell . I updated the logic to no longer make the logging conditioned on OTEL_LOG_LEVEL. I'm not sure what the DuplicateFilter is you are referring to ... are you asking to also remove the special casing for logs (because you are not concerned about partial success causing a loop?)