[exporter/prometheusremotewrite] Add the possibility to disable queuing

[trasc]

Description: Add the possibility to disable the sending queue in prometheusremotewrite exporter

A new configuration key, remote_write queue.enabled is added, which
controls the queue enabling.

Link to tracking Issue: N/A

Testing: No regressions on local runes

Documentation: Small update of README.md

[mx-psi]

@trasc What's the current behavior if you set the queue size to zero? Does the exporter work at all?

[trasc]

@trasc What's the current behavior if you set the queue size to zero? Does the exporter work at all?

Currently, when set to 0 , the queue is always "full", and just drops any incoming data.

[mx-psi]

I see, thanks! I think there are two issues here:

1. the exporterhelper should not allow setting the queue size to zero (maybe with a Validate helper?) and
2. people may want to disable the queue entirely on this exporter in particular.

For (1), can you open an issue on github.com/open-telemetry/opentelemetry-collector?

For (2), I feel like it's more consistent to add a new enabled field for this instead of reusing the queue_sizefor enabling/disabling this. What do you think? Would also want @rakyll to confirm that it's safe to disable the queue.

[trasc]

I see, thanks! I think there are two issues here:

1. the exporterhelper should not allow setting the queue size to zero (maybe with a Validate helper?) and

For (1), can you open an issue on github.com/open-telemetry/opentelemetry-collector?

I don't think that adding Validate will be very effective, since is very likely to never be called unless the user will specifically do it. In this case QueueSettings is built only on component creation not on config validation. The best way that I could think of to enforce this kind of config constraints will be to do it when applying the Options, but unfortunately, the Option function prototype is not returning an error. Changing the Option prototype just for the exporterhelper will brake the Options pattern across the project.

Another approach could be just to make sure that the scenario is properly documented in https://github.com/open-telemetry/opentelemetry-collector/blob/main/exporter/exporterhelper/README.md,

2. people may want to disable the queue entirely on this exporter in particular.

For (2), I feel like it's more consistent to add a new enabled field for this instead of reusing the queue_sizefor enabling/disabling this. What do you think? Would also want @rakyll to confirm that it's safe to disable the queue.

I've added a dedicated config key enabled and a new error indicating that a 0 sized queue will result in dropping all data.

[mx-psi]

Changes on this exporter look good. Will create an issue to further discuss how to deal with the 0 queue size at the exporterhelper level.

@anuraaga If you find the time, would you mind reviewing this to get it merged before the holidays? 🙏

[jpkrohling]

@anuraaga, if you are OK with this change, ping me and I'll merge it today. Otherwise, it will probably have to wait until next year :-)

[anuraaga]

Apologies have been having trouble following my notification lately