Send RabbitMQ and LavinMQ logs to any OpenTelemetry (OTLP) endpoint

The OTLP log integration lets any CloudAMQP-hosted RabbitMQ or LavinMQ instance send broker logs to any backend that accepts OpenTelemetry Protocol (OTLP) over HTTP.

How do I send RabbitMQ or LavinMQ logs to an OTLP backend?

Our log integrations have always been vendor-shaped: Datadog, Grafana Cloud, Splunk, CloudWatch, Coralogix, Google Cloud, Uptrace. Handy if you use one of them. No help at all if your logs live somewhere else, whether that is SigNoz, Honeycomb, or an OTLP gateway of your own. Until now, the answer was to file a request and wait for us to build another integration.

The OTLP log integration removes the waiting. You provide the endpoint and the credentials it expects, and the OpenTelemetry Collector on each broker node ships the logs to it. It is the same pipeline that powers every other OTel log integration we offer, minus the vendor-specific defaults.

How does OTLP log authentication work?

The endpoint is the full HTTPS URL your backend receives logs on, path included. Most OTLP backends document a base URL, so add /v1/logs to it:

https://otlp.example.com:4318/v1/logs
https://api.honeycomb.io/v1/logs
https://ingest.eu.signoz.cloud:443/v1/logs

We send to that URL exactly as you enter it, the same way the Prometheus remote write integration does. That is what makes a gateway with its own path work.

Authentication comes in four shapes:

Mode	What it's for
Basic auth	A username and a password or token
Headers	Bearer tokens and API keys, one `key: value` pair per line
OAuth2	A client ID, client secret and token URL; we fetch the access token for you and refresh it before it expires
None	Receivers behind a proxy that authenticates for you, or that take the token as a query parameter in the URL

Most hosted OTLP backends want their API key in a header rather than in basic auth. Honeycomb reads x-honeycomb-team and SigNoz Cloud reads signoz-ingestion-key . That is why headers are sent in every authentication mode, not only when you pick header authentication: you can combine a tenant or routing header with basic auth or OAuth2 if your receiver needs both.

OAuth2 is for receivers that sit behind an identity provider, such as an OTLP gateway guarded by an OIDC proxy or a backend that issues short-lived tokens instead of static API keys. Enter the client ID, the client secret and the token URL of your identity provider, plus any scopes it requires, and the Collector runs the client credentials flow on each node. You never paste a bearer token that expires a week later. Under the hood this is the OpenTelemetry Collector oauth2client extension, and the four fields we expose use the same names it does: client_id , client_secret , token_url and scopes .

Does your backend expect another authentication method? Write to support@cloudamqp.com and let us know what it needs.

Structured records, not text lines

Broker logs leave the node as OpenTelemetry log records, rather than raw lines for the other end to parse. The message is the body, and the broker log level maps to the OpenTelemetry severity number, so a warning from RabbitMQ or LavinMQ arrives as WARN in your backend without any parsing rules.

Every record carries service.name with the cluster name and host.name with the node hostname, plus an appname attribute that reads rabbitmq or lavinmq . On a multi-node cluster, you can filter down to one node with a click, and severity is a proper field you can alert on.

Setting it up

Copy the OTLP/HTTP URL of your backend and make sure it ends in /v1/logs , or in whatever path your gateway listens on.
Pick an authentication mode and fill in what it requires: a username and password, OAuth2 client credentials and a token URL, or headers.
Add any headers your backend expects, such as an API key header.
Paste it all into the Integrations tab for your instance in the CloudAMQP console, then save. Logs start arriving within a minute.

Summary

The OTLP log integration turns every OTLP/HTTP receiver into a CloudAMQP log destination for both RabbitMQ and LavinMQ instances. You get structured broker logs with severity, cluster, and node attributes, delivered by the OpenTelemetry Collector on each node. Authenticate with basic auth, OAuth2 client credentials, headers, or neither; headers ride along in every mode. Setup takes a full URL and whatever credentials your backend expects.

The OTLP log integration documentation has the details, or browse all CloudAMQP integrations.

FAQ

Does the OTLP integration work with self-hosted OpenTelemetry collectors?

Yes. Any OTLP/HTTP receiver the broker nodes can reach over HTTPS works, including a self-hosted Collector or a gateway with its own path.

What authentication does the OTLP log integration support?

Basic auth (username and password or token), headers (for bearer tokens and API keys), OAuth2 client credentials (client ID, client secret, token URL and optional scopes), or none for receivers that don't need it. Headers are sent in every mode, so you can combine a routing header with basic auth or OAuth2 if your backend needs both.

Can I use OAuth2 with the OTLP log integration?

Yes. Select OAuth2, enter the client ID, client secret and token URL from your identity provider, and add scopes if it requires them. The OpenTelemetry Collector on each node fetches the access token with the client credentials flow and refreshes it before it expires, so there is no static token to rotate.

What log attributes does CloudAMQP send with each record?

Every record carries service.name (the cluster name), host.name (the node hostname), and an appname attribute set to rabbitmq or lavinmq . The broker log level maps directly to the OpenTelemetry severity number.