Important: This documentation is about an older version. It's relevant only to the release noted, many of the features and functions have been updated or replaced. Please view the current version.
otelcol.receiver.solace
otelcol.receiver.solace accepts traces from a Solace PubSub+ Event Broker and
forwards it to other otelcol.* components.
Note
otelcol.receiver.solaceis a wrapper over the upstream OpenTelemetry Collectorsolacereceiver from theotelcol-contribdistribution. Bug reports or feature requests will be redirected to the upstream repository, if necessary.
You can specify multiple otelcol.receiver.solace components by giving them different labels.
Usage
otelcol.receiver.solace "LABEL" {
queue = "QUEUE"
auth {
// sasl_plain or sasl_xauth2 or sasl_external block
}
output {
traces = [...]
}
}Arguments
The following arguments are supported:
queue must have the format queue://#telemetry-myTelemetryProfile.
Blocks
The following blocks are supported inside the definition of
otelcol.receiver.solace:
One SASL authentication block is required in the authentication block.
sasl_external must be used together with the tls block.
The > symbol indicates deeper levels of nesting. For example,
authentication > tls refers to a tls block defined inside an
authentication block.
authentication block
The authentication block configures how to authenticate for connecting to the Solace broker.
It doesn’t support any arguments and is configured fully through inner blocks.
sasl_plain block
The sasl_plain block configures how to authenticate to the Solace broker with SASL PLAIN.
The following arguments are supported:
sasl_xauth2 block
The sasl_xauth2 block configures how to authenticate to the Solace broker with SASL XOauth2.
The following arguments are supported:
sasl_external block
The sasl_xauth2 block configures how to authenticate to the Solace broker with SASL External.
It doesn’t support any arguments or blocks. It must be used with the tls block.
flow block
The flow block configures the behaviour to use when temporary errors are encountered from the next component.
It doesn’t support any arguments and is configured fully through inner blocks.
delayed_retry block
The delayed_retry block sets the flow control strategy to delayed retry which will wait before trying to push the message to the next component again.
The following arguments are supported:
tls block
The following arguments are supported:
If the server doesn’t support TLS, you must set the insecure argument to true.
To disable tls for connections to the server, set the insecure argument to true.
If you set reload_interval to "0s", the certificate never reloaded.
The following pairs of arguments are mutually exclusive and can’t both be set simultaneously:
ca_pemandca_filecert_pemandcert_filekey_pemandkey_file
If cipher_suites is left blank, a safe default list is used.
Refer to the Go TLS documentation for a list of supported cipher suites.
debug_metrics block
The debug_metrics block configures the metrics that this component generates to monitor its state.
The following arguments are supported:
disable_high_cardinality_metrics is the Alloy equivalent to the telemetry.disableHighCardinalityMetrics feature gate in the OpenTelemetry Collector.
It removes attributes that could cause high cardinality metrics.
For example, attributes with IP addresses and port numbers in metrics about HTTP and gRPC connections are removed.
Note
If configured,
disable_high_cardinality_metricsonly applies tootelcol.exporter.*andotelcol.receiver.*components.
level is the Alloy equivalent to the telemetry.metrics.level feature gate in the OpenTelemetry Collector.
Possible values are "none", "basic", "normal" and "detailed".
output block
The output block configures a set of components to forward resulting telemetry data to.
The following arguments are supported:
You must specify the output block, but all its arguments are optional.
By default, telemetry data is dropped.
Configure the metrics, logs, and traces arguments accordingly to send telemetry data to other components.
Warning
Having multiple consumers may result in duplicated traces in case of errors because of the retry strategy. It is recommended to only set one consumer for this component.
Exported fields
otelcol.receiver.solace does not export any fields.
Component health
otelcol.receiver.solace is only reported as unhealthy if given an invalid
configuration.
Debug information
otelcol.receiver.solace does not expose any component-specific debug
information.
Example
This example forwards read telemetry data through a batch processor before finally sending it to an OTLP-capable endpoint:
otelcol.receiver.solace "default" {
queue = "queue://#telemetry-testprofile"
broker = "localhost:5672"
auth {
sasl_plain {
username = "alloy"
password = "password"
}
}
tls {
insecure = true
insecure_skip_verify = true
}
output {
traces = [otelcol.processor.batch.default.input]
}
}
otelcol.processor.batch "default" {
output {
traces = [otelcol.exporter.otlp.default.input]
}
}
otelcol.exporter.otlp "default" {
client {
endpoint = sys.env("OTLP_ENDPOINT")
}
}Compatible components
otelcol.receiver.solace can accept arguments from the following components:
- Components that export OpenTelemetry
otelcol.Consumer
Note
Connecting some components may not be sensible or components may require further configuration to make the connection work correctly. Refer to the linked documentation for more details.



