New component: Solace Receiver

[mcardy]

The purpose and use-cases of the new component

The Solace Receiver would collect traces from a Solace PubSub+ Event Broker using Azure AMQP Golang client API. This component would provide message tracing capabilities for a Solace PubSub+ Event Broker. It will enable full end to end message lifecycle tracing exportable to backends such as Jaeger, Zipkin or Datadog for visualization.

Solace is currently actively working on a next generation OpenTelemetry tracing integration into the event broker. The release of this component will be coordinated with community to align with a public availability of a Solace event messaging broker with tracing support.

The Solace Receiver will receive trace messages as Guaranteed Messages from a Solace PubSub+ event broker and produce trace spans for the OpenTelemetry Collector.

Example configuration for the component

The configuration parameters are:

• broker (Solace broker using amqp over tls; optional; default: localhost:5671; format: ip(host):port)
• queue (The name of the Solace queue to get span trace messages from; non optional; format: queue:https://#telemetry-myTelemetryProfile)
• max_unacknowledged (The maximum number of unacknowledged messages the Solace broker can transmit; optional; default: 10)
• transport (Defines different transport settings)
  • tls (Advanced tls configuration, secure by default)
    • insecure (The switch from ‘amqps’ to 'amqp’ to disable tls; optional; default: false)
    • server_name_override (Server name is the value of the Server Name Indication extension sent by the client; optional; default: empty string)
    • insecure_skip_verify (Disables server certificate validation; optional; default: false)
    • ca_file (Path to the User specified trust-store; used for a client to verify the server certificate; if empty uses system root CA; optional, default: empty string)
    • cert_file (Path to the TLS cert for client cert authentication, it is required when authentication sasl_external is chosen; non optional for sasl_external authentication)
    • key_file (Path to the TLS key for client cert authentication, it is required when authentication sasl_external is chosen; non optional for sasl_external authentication)
  • auth (Authentication settings. Permitted sub sub-configurations: sasl_plain_text, sasl_xauth2, sasl_external)
    • sasl_plain_text (Enables SASL PLAIN authentication)
      • username (The username to use, non optional for sasl_plain_text authentication)
      • password (The password to use; non optional for sasl_plain_text authentication)
    • sasl_xauth2 (SASL XOauth2 authentication)
      • username (The username to use; non optional for sasl_xauth2 authentication)
      • bearer (The bearer token in plain text; non optional for sasl_xauth2 authentication)
    • sasl_external (SASL External required to be used for TLS client cert authentication. When this authentication type is chosen then tls cert_file and key_file are required)

Examples:

Simple single node configuration with SASL plain text authentication (and tls enabled by default)

receivers:
  solace:
    broker: [localhost:5671]
    auth:
      sasl_plain_text:
        username: otel
        password: otel01$
    queue: queue:https://#telemetry-profile123
 
service:
  pipelines:
    traces:
      receivers: [solace]

High availability setup with SASL plain text authentication (and tls enabled by default)

receivers:
  solace/primary:
    broker: [myHost-primary:5671]
    auth:
      sasl_plain_text:
        username: otel
        password: otel01$
    queue: queue:https://#telemetry-profile123
 
  solace/backup:
    broker: [myHost-backup:5671]
    auth:
      sasl_plain_text:
        username: otel
        password: otel01$
    queue: queue:https://#telemetry-profile123
 
service:
  pipelines:
    traces/solace:
      receivers: [solace/primary,solace/backup]

Telemetry data types supported

Trace

Sponsor (Optional)

No sponsor as of now

[djaglowski]

@open-telemetry/collector-contrib-approvers, is there anyone very familiar with traces who would like to sponsor this? Otherwise, I will take it as my round robin assignment.

[djaglowski]

I'll sponsor this.

(Also, I won't make it to the SIG meeting tomorrow, so I will remove the agenda item. Feel free to readd if you have more to address at the SIG.)

[mcardy]

As part of our component, we unmarshal data into a protobuf generated model currently generated with go generate. To do this, we are using http:https://google.golang.org/protobuf/cmd/protoc-gen-go. I noticed that, as part of the workflows, go generate is run in all components' directories, and this is currently failing as a result. Is protoc-gen-go something we could add to the root installTools directive?

[djaglowski]

As part of our component, we unmarshal data into a protobuf generated model currently generated with go generate. To do this, we are using http:https://google.golang.org/protobuf/cmd/protoc-gen-go. I noticed that, as part of the workflows, go generate is run in all components' directories, and this is currently failing as a result. Is protoc-gen-go something we could add to the root installTools directive?

@bogdandrutu, do you mind weighing in on this?

[adirmatzkin]

Hi @mcardy 👋
I was just wondering if this receiver (which uses Azure's go client for AMQP) can serve the same need @corentinaltepe presented in issue 10592.

If it is very similar, maybe we could talk about making it a bit more general and not vendor-specific so we will have a general AMQP Receiver?

In my situation for example, I need a receiver to read from RabbitMQ... But I guess it will be great for more solutions using AMQP 😎

[mcardy]

Hi @adirmatzkin,

Unfortunately I don't think the Solace receiver can serve the same purpose of 10592. The AMQP transport is only a portion of the puzzle. Any AMQP receiver based component needs to map the incoming message data to OpenTelemetry models as well as report relevant stats and make decisions around upgrade scenarios. This accounts for the majority of the code within the Solace Receiver component and this is not generalizable.

Also, Azure AMQP is an AMQP v1.0 client whereas RabbitMQ AMQP is v0.9.1. Despite the similar name these are completely different specs.