Collect RabbitMQ logs with OpenTelemetry

Overview

RabbitMQ writes a broker log covering connections, channels, queues, and errors. The OpenTelemetry Collector’s filelog receiver tails that log, parses each entry, folds multi-line crash reports into single records, and ships them to Osuite over OTLP. This page collects logs; for queue, message, and connection metrics see Monitor RabbitMQ with OpenTelemetry.

Prerequisites

• RabbitMQ writing its log to a file. On Debian, Ubuntu, and RHEL the default is /var/log/rabbitmq/rabbit@<hostname>.log.
• The OpenTelemetry Collector installed on the broker host, with read access to the log directory.
• An Osuite ingest token and endpoint — see Getting Started.

Note

The official RabbitMQ container image logs to stdout. In containers, collect that stream with Docker container logs or Kubernetes pod logs instead of tailing a file.

Collector config

This otel-collector.yaml tails the broker log. The multiline block treats any line that does not start with a timestamp as a continuation, so a crash report or Erlang stack trace arrives as one record. The regex assumes the RabbitMQ 3.7+ default log format.

receivers:
  filelog/rabbitmq:
    include:
      - /var/log/rabbitmq/rabbit@*.log
    start_at: end
    multiline:
      line_start_pattern: '^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d+'
    operators:
      - type: regex_parser
        regex: '^(?P<timestamp>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d+[+-]\d{2}:\d{2}) \[(?P<level>\w+)\] <(?P<pid>[\d.]+)> (?P<message>(?s).*)'
        timestamp:
          parse_from: attributes.timestamp
          layout_type: strptime
          layout: '%Y-%m-%d %H:%M:%S.%f%z'
        severity:
          parse_from: attributes.level
          mapping:
            debug: debug
            info: info
            warn: warning
            error:
              - error
              - critical

processors:
  batch: {}
  resourcedetection:
    detectors: [system]
  resource:
    attributes:
      - key: service.name
        value: rabbitmq
        action: upsert

exporters:
  otlp/osuite:
    endpoint: ingest.<region>.osuite.io:443
    tls:
      insecure: false
    headers:
      x-osuite-ingest-token: <your-ingest-token>

service:
  pipelines:
    logs:
      receivers: [filelog/rabbitmq]
      processors: [batch, resourcedetection, resource]
      exporters: [otlp/osuite]

Parsing and enrichment

• Format assumption — the regex parses the RabbitMQ 3.7+ default log line (timestamp [level] <pid> message), for example 2025-10-15 12:34:56.789012+00:00 [info] <0.123.0> accepting AMQP connection. Older releases and custom log formats differ; adjust the capture groups if yours does.
• Severity — RabbitMQ levels are debug, info, warning, error, and critical. The mapping folds warning to warn and critical to error in the record’s SeverityNumber. See severity.
• Multiline and crash reports — Erlang crash reports and supervisor errors span many lines. The line_start_pattern starts a new record only at a timestamped line, so a full report stays in one record’s body.
• Timestamps — RabbitMQ writes an ISO-8601 timestamp with a +00:00 style zone offset, parsed by the %z layout.
• Host and service attributes — the resourcedetection and resource processors tag each record with the host name and a stable service.name.

Verify in Osuite

What you should see

Within a minute, RabbitMQ records appear in the Logs Explorer tagged with service.name=rabbitmq and the host name. Filtering by severity isolates error and critical entries, and a crash report appears as a single multi-line record.

Troubleshooting

If the timestamp fails to parse, your build may write a zone offset without the colon (+0000) or a different format entirely — check the actual log lines and adjust the %z layout to match. If crash reports split into separate records, the line_start_pattern does not match your timestamp prefix; align it with the real format.

No data in Osuite after a few minutes? Work through these checks.

• Endpoint — confirm the exporter targets exactly ingest.<region>.osuite.io:443 for your region, over TLS.
• Token — confirm the ingest header carries a valid <your-ingest-token> and has not been rotated.
• Pipeline — confirm the signal you expect (traces, logs, or metrics) is wired into an active pipeline with the otlp/osuite exporter attached.
• Export errors — check the application or Collector logs for OTLP export failures (auth, DNS, TLS, connection refused).
• Network — confirm the host has outbound access to the ingest endpoint on port 443.
• Timing — allow up to a minute for the first data to appear before assuming a failure.

Still stuck? Ask the Investigation Agent or contact support.