Fluent Bit & Fluentd logs

Already shipping logs with Fluent Bit or Fluentd? Point their OpenTelemetry output at Ultraviolet and every log line shows up in the Logs explorer — correlated to traces, searchable, and available for alerts — without swapping out your existing log agents or re-instrumenting anything.

Because it’s a receiver, this works the same connected or air-gapped: your log forwarder pushes to your core, and nothing leaves your environment.

Turn on the receiver

The receiver is off by default. Enable it in your Helm values:

ingestGateway:
  otlpHttp:
    enabled: true
    port: 4318   # the standard OTLP/HTTP port your forwarder will send to

This adds the standard OTLP/HTTP endpoints (/v1/logs, /v1/metrics, /v1/traces) on the ingest gateway. Upgrade the release to apply it.

Point Fluent Bit at it

Fluent Bit ships an opentelemetry output plugin. Add it to your fluent-bit.conf:

[OUTPUT]
    Name             opentelemetry
    Match            *
    Host             <ingest-gateway-host>
    Port             4318
    Logs_uri         /v1/logs
    # Fluent Bit gzips by default; the receiver accepts it.

Or in the YAML config format:

pipeline:
  outputs:
    - name: opentelemetry
      match: '*'
      host: <ingest-gateway-host>
      port: 4318
      logs_uri: /v1/logs

Reload Fluent Bit and log lines start flowing. Open the Logs page to confirm.

Fluentd

Fluentd forwards the same way through the opentelemetry output plugin, pointed at http://<ingest-gateway-host>:4318/v1/logs.

How fields map

Ultraviolet keeps your log record’s timestamp, severity, body, and attributes. A couple of well-known resource attributes are promoted to first-class fields so your logs line up with the rest of your telemetry:

Log field	Becomes	Notes
service.name	Service	Set it as a resource attribute on the forwarder.
Severity	Severity	Collapsed to the six standard levels.
trace_id / span_id	Trace correlation	Click straight from a log to its trace.
site_id, cluster_id	Site / cluster	Optional — see multi-site below.

Every other attribute is kept as a searchable dimension on the log line, and your log pipeline rules (drop/sample/enrich) apply to these logs just like any other source.

Attributing to a site

For a single deployment there’s nothing to set — logs land under your default site. If you feed several environments into one core, either add site_id / cluster_id resource attributes on the forwarder, or connect it over the same secured link your remote sites use, and the site identity comes from the connection automatically.

Securing the endpoint

When your core is set up for secure remote sites, the OTLP/HTTP endpoint requires the same client certificate as any other remote connection — so a forwarder sending from outside the cluster is authenticated just like an enrolled site. Inside the cluster, the in-cluster address is used directly.

Sending metrics and traces too

The same endpoint serves /v1/metrics and /v1/traces. Any tool that speaks OTLP/HTTP — a standalone OpenTelemetry Collector, an SDK exporter, or a curl script — can deliver metrics and traces here as well, not just logs.