You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Connectors were introduced via #2336.
As they're also exporters, it makes sense to have sending_queue/retry_after_failure support like existing exporters.
Describe the solution you'd like
A similar solution like exporterhelper/* for connectors, which will have the ability to retry for non-permanent errors and queueing.
Describe alternatives you've considered
I got this idea recently and I would like to hear what @open-telemetry/collector-approvers have to say on this.
I can work on this if all of us agree with the proposal/design.
The text was updated successfully, but these errors were encountered:
As they're also exporters, it makes sense to have sending_queue/retry_after_failure support like existing exporters.
The difference is that connectors always emit data to other pipeline components, like receivers and processors. I don't see a reason why connectors would need this, unless we're also doing it for receivers and processors.
Is your feature request related to a problem? Please describe.
Connectors were introduced via #2336.
As they're also exporters, it makes sense to have
sending_queue
/retry_after_failure
support like existing exporters.Describe the solution you'd like
A similar solution like
exporterhelper/*
for connectors, which will have the ability to retry for non-permanent errors and queueing.Describe alternatives you've considered
I got this idea recently and I would like to hear what @open-telemetry/collector-approvers have to say on this.
I can work on this if all of us agree with the proposal/design.
The text was updated successfully, but these errors were encountered: