New component: ActiveMq Artemis receiver

[syron]

The purpose and use-cases of the new component

A new receiver to get messages from an Artemis queue. However, my question is, if that should be a component for activemq or if it should be an AMQP receiver?

Example configuration for the component

activemq:
  endpoint: "username:password@hostname:port"
  queue: "myqueue"

Will need to dig deeper into it, how we are using it at my clients site. But we are also using client certificates, so it will be much like other queue based receivers.

However, the question again is if this should be some amqp based receiver instead of vendor specific.

Telemetry data types supported

metrics, logs and traces - all types. could even be profiles.

Code Owner(s)

syron

Sponsor (optional)

@atoulme

Additional context

At my clients site, we are heavily investing into otlp and we are looking into multiple reliable options for transmission, where we are using both kafka topics, otlp endpoints but we also would like to use our artemis brokers.

[atoulme]

Yes, it should be amqp by default. What is the go support for this protocol?

[syron]

The library https://github.com/Azure/go-amqp is well implemented for the use cases I have used it. It implements the necessary functions for a receiver. This could actually be an exporter as well, but I guess that would be a new component proposal.

If this is an amqp receiver, I mean it would support even azure service bus and other brokers that implement amqp. And again, it could be an amqp exporter as well.

And the configuration should be:

amqp:
  endpoint: "amqp(s)://hostname"
  tls: ...
  queue: "myqueue"

[atoulme]

In effect, this would be similar to how we support kafka and azure event hubs. You would want to take advantage of encoding extensions to reduce the work on marshaling data back and forth. Does that work?

[syron]

Yes. That's possible if the system receiving the data can connect to e.g. amqp to read the data. Like the kafka connector for zipkin in which we can use the zipkin encoding. Also, it just came to my mind. Going through the encoding extension, that could be an alternative to the nodiniteexporter that I have created an issue for and the amqp implementation would be a solution for that as well. Nodinite e.g. doesn't understand OTLP yet, however, it can connect to an AMQP queue, using an extended encoder extension support nodinite, there would be no need for an additional exporter. But that would also bring up the question to me if it really is feasible for all systems to be supported by the collector? Nevermind. AMQP however is a widely used protocol, so it seems it could be natural part of the collector. - sorry for the long answer to your question.

[atoulme]

I will sponsor. Bring it on.

[syron]

I will sponsor. Bring it on.

Oh, that is awesome, thanks @atoule. I will start working on it as soon as I can.