feat(http): add error handling for exporting
Description
When using the OTEL http exporters the std.out gets polluted by unhandled error traces. I don't think that this should be the desired result. This happens when the endpoint is not available when exporting telemetry. This can be cause by different events but in general I think it should be better handled. Therefore I added error handling with more specific and shorted error messages.
Type of change
I'm not sure if the change type is rather fix or feature, as the service was still running.
- [x] New feature (non-breaking change which adds functionality)
How Has This Been Tested?
- [x] Don't provide a collector at the configured endpoint
Does This PR Require a Contrib Repo Change?
- [ ] Yes. - Link to PR:
- [x] No.
Checklist:
- [x] Followed the style guidelines of this project
- [x] Changelogs have been updated
- [x] Unit tests have been added
- [x] Documentation has been updated
The committers listed above are authorized under a signed CLA.
- :white_check_mark: login: pafi-code / name: Paul (397b0409e0990404fefdc6e34d97f7a4f2dc42c4, 80a5f8757701802c7ec75d9a318f082de00de88f, 8d9e42e424bca2f43762f3522938445656bd8d5e, 943634fe4d3c87a0ef064e9978bb389f65343db1, afc67a39c980b5cca7675716793a85ce475975d8, b36fb7907a102e0e1b2ec235dcfcf8870955d4cb, b8cea5cbf6bf3313dde96e65442f143ceb289f22, bcc20fd0cc4459d753fb623a273955fda726b668, cc3f2f7ad41161d1caaff0bc84cdd4594a930c2e, ef2ff34b0dba8583e5c78c86b1535ef422af879a, f501b946a843dc45211305e56b8389e0ec6dc5a9, f63e8100b0eb2aa3a659002f0c83f98fefb820ed, fb0684e37bb617abbeef1921457db132f3ddfdde)
Okay so I know that the pipeline is failing and I assume this PR should be rebased, but for me there is still the question if my proposed fix is actually how it should be handled. Would appreciate some more feedback here. Also I've created an issue related to this PR: https://github.com/open-telemetry/opentelemetry-python/issues/4712
@emdneto I had a look into the existing tests and too be honest I have no clue what's going on. I'm not used to the sort of testing that you guys are doing. Would appreciate if you could help regarding the tests.
Have we considered just using urllib3.util.Retry instead of rolling our own retry-backoff loop?
Docs: https://requests.readthedocs.io/en/latest/user/advanced/#example-automatic-retries
@herin049 should this be part of this PR as this is a refactor and not a fix?
Regarding the two failing checks I'm not really sure what I should do.
For the public_symbols_check I did not introduce those changes for which it is failing.
For the changelog: Should I update anything there?
I will rebase the PR once again, after we got the approvals. Is there any time limit regarding how long we wait for approval or do we just wait? (not trying to stress here, just curious about the process)