Hi, thank you for your suggestion! It would be great to leverage Kafka's resiliency, but I'm not sure how we could do that. The Agent is normally the one which sends the signals to the end location. Would each Agent component send data to Kafka, only for another component on the same Agent process to pick it up? It seems like a lot of unnecessary networking overhead.

Another issue with this is that it'd mean the user of the Agent has to be able to run Kafka. The Agent is normally a self sufficient executable, so this would be a big break from convention for us.

I think a more realistic solution would be something like #323. This article explains it in a bit more detail.

@ptodev, once we have all the data in Kafka we can use either native consumers (Tempo/Mimir) to consume data or Agent to consume it and push it to the backend system.
The main problem right now is if we push data directly from the Agent to Mimir/Loki/Tempo and the ingesters are overloaded/unavailable, the dataset will be discarded and lost. With Kafka in the middle, we will have some kind of buffer where the data can live for a couple of hours/days. So data will not be lost and will be ingested eventually.
I would say it is a more guaranteed way for observability data delivery.

and again, this shouldn't be the only way how data can be ingested. Having a Kafka exporter (Kafka as destination) will allow building such systems that have Kafka in place. But whoever doesn't have it or doesn't want it can still use the existing approach to push directly to the backend system.

it seems to me you're trying to look for equivalent of Filebeat's Kafka output and Vector's Kafka sink?

Having said that, the PR you've linked is for Kafka's message consumption, which can be done by the agent's loki.source.kafka :D

@hainenber, I'm looking for something like this: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/kafkaexporter. The idea is to use Agent to collect all kinds of observability data and push it to Kafka. Then it can be consumed by different systems (another Agent,Mimir,Tempo, another external system).

I see, thank you for clarifying. It would certainly be possible to port Collector's Kafka exporter. I suspect it won't be a lot of effort - most of the time would be spent in documenting the features. However, I do not know to what extent databases such as Mimir, Loki, and Tempo can ingest signals from Kafka (especially on Grafana Cloud).

Also, if we reuse the OTel Collector's component, we wouldn't be able to send "profile" signals, because they are not yet part of the OTel standard.

@ptodev I think "profiles" will eventually be onboarded as well in OTel.

Realistically, I don't think the core development team can work on adding an otelcol.exporter.kafka component in the near future. However, we would welcome a community contribution for it.

This issue has not had any activity in the past 30 days, so the needs-attention label has been added to it.
If the opened issue is a bug, check to see if a newer release fixed your issue. If it is no longer relevant, please feel free to close this issue.
The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your issue will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity.
Thank you for your contributions!