Send Vector logs and traces to Sazabi with the opentelemetry sink

Last verified on Nov 8, 2026.

Vector reads, reshapes and routes events. That reshaping is why people run it: you can parse a line, drop a field or split a stream before anything leaves the host. Sazabi, the AI-native observability and security platform, is one more destination for that stream, reached over OTLP/HTTP.

What Sazabi reads from Vector

Logs and traces, through Vector's opentelemetry sink with the otlp encoding codec. Vector's own docs say the codec uses protobuf, supports native batching and is the recommended path. The older json codec writes newline-delimited JSON, which is not a valid OTLP request body, so avoid it here.

Logs need one extra step. The otlp codec does not build the resourceLogs envelope, so a remap transform builds it first and the sink's inputs must point at that transform, not at the raw source. Traces are simpler: the sink goes to /v1/traces and takes events that are already OTLP-shaped, such as those from an opentelemetry source with use_otlp_decoding.traces on. Metrics sent this way are accepted at intake but dropped.

Questions it answers

• Did the line that Vector parsed into .level arrive with the right severity?
• Which host wrote the first error, going by the host.name resource attribute?
• Are the same events reaching Sazabi and my other sinks?
• Are traces from the opentelemetry source reaching the traces sink?
• Did a redeploy of the Vector config leave records malformed?

A worked example: mapping severity into the envelope

Sazabi's remap builds timeUnixNano, a body with a stringValue, a severityText and a host.name resource attribute. Vector's own syslog example for this sink also puts service.name in the resource attributes. Suppose your application logs JSON with level, service and message. A trimmed transform that follows both:

transforms:
  sazabi_logs_otlp:
    type: remap
    inputs: ['app_json_logs']
    source: |
      timestamp_nanos = to_unix_timestamp!(now(), unit: "nanoseconds")
      severity_text = upcase(string!(.level ?? .severity ?? ""))
      .resourceLogs = [{
        "resource": {
          "attributes": [
            { "key": "host.name",    "value": { "stringValue": .host ?? "" } },
            { "key": "service.name", "value": { "stringValue": .service ?? "" } }
          ]
        },
        "scopeLogs": [{
          "scope": { "name": "vector" },
          "logRecords": [{
            "timeUnixNano": timestamp_nanos,
            "body":         { "stringValue": .message ?? encode_json(.) },
            "severityText": severity_text
          }]
        }]
      }]

Note inputs. The Sazabi docs warn that a wildcard input also matches internal_metrics and other unrelated components, so name the real source. A line such as {"level": "warn", "service": "checkout-api", "message": "retry 3 of 5 to payments.example.com"} leaves with WARN as its severity text and the message as its body.

If records show up empty or malformed, the sink is reading the raw source instead of the transform. If nothing shows up, check that protocol.uri has the full https:// host and the /v1/logs suffix. For a second opinion on what arrived, ask in a thread for the newest records from the Vector source and compare the body with the original line.

How it fits with other integrations

Vector and Fluent Bit solve the same shipping problem, with different config languages. Grafana Alloy does it with Collector components, and the Datadog Agent can run beside Vector on the same host. All of them speak the protocol described on the OpenTelemetry page, and the telemetry pipelines category lists more.