Datadog Agent & Vector

Berserk's ingest service can serve a Datadog-compatible intake. If you already ship with the Datadog Agent or Vector's datadog_logs and datadog_metrics sinks, you can send logs, metrics and APM traces to Berserk by changing the endpoint and the API key. You don't need to rewrite the pipeline or reshape your events.

The intake accepts logs (/api/v2/logs), metrics (/api/v2/series, /api/intake/metrics/v3/series, /api/beta/sketches) and APM traces (/api/v0.2/traces).

For the general ingest contract (tokens, size limits, what an acknowledgment means), see Ingestion. Coming from Datadog's UI? Datadog → Berserk field mapping says where each facet and attribute lands, with query translations.

Endpoint and API KeyCopy Anchor Link

• Endpoint. The intake listens on the ingest service's Datadog port, 9552, which your deployment exposes behind its ingest host (e.g. https://<your-ingest-host>). It is a different port from OTLP's 4317/4318. Self-hosting? See Enabling the intake.
• API key. Use a Berserk ingest token (ing_…) wherever Datadog expects an API key. It is sent in the DD-API-KEY header, as a Datadog client does by default. The token decides which table the logs land in.
• Key check. Both the Agent and Vector check their key at startup against /api/v1/validate. Berserk answers 200 {"valid":true} for a token it accepts and 403 for one it does not.

VectorCopy Anchor Link

Point the datadog_logs sink at Berserk. The events need no remapping: the sink sends the same Datadog payload it would send to Datadog.

secret:
  berserk:
    type: file
    path: /etc/vector/berserk.json            # {"ingest_token": "ing_…"}
sinks:
  berserk:
    type: datadog_logs
    inputs: [my_logs]
    endpoint: https://<your-ingest-host>
    default_api_key: SECRET[berserk.ingest_token]
    compression: zstd                         # the default; keep it
    request:
      concurrency: 32
      timeout_secs: 60
    batch:
      timeout_secs: 1
    buffer:
      type: disk
      max_size: 1073741824                    # 1 GiB
      when_full: block

Why These SettingsCopy Anchor Link

The key comes from a secret backend. Since Vector 0.57, ${VAR} in a config file is no longer replaced by the environment variable unless Vector runs with --dangerously-allow-env-var-interpolation. Without that flag, default_api_key: ${BERSERK_INGEST_TOKEN} sends the literal text as the key, and Berserk answers 403. A secret backend works on every version that has one: file reads a JSON object, and directory, exec and aws_secrets_manager are the alternatives.

request.concurrency: 32 is the setting that matters most.

• Berserk acknowledges a request only once its batch is durably on object storage, and batches for up to 2 seconds. A request therefore takes about 1–3 seconds, against about 0.1 seconds at Datadog.
• The sink caps each request at 1000 events. That is a hard limit: a larger batch.max_events is a configuration error, not something Vector rounds down. So throughput is roughly concurrency × 1000 events / 2 seconds.
• Vector's default adaptive concurrency starts at 1 request in flight and adds at most one per round trip. That means a few hundred events per second until it ramps up, and every restart starts over.
• A fixed value avoids the ramp. Many requests in flight cost Berserk almost nothing, because they land in the same batch. Raise it for a busy aggregator: about 32 per 15k events/s.

batch.timeout_secs: 1. Berserk batches for 2 seconds anyway; the sink's default of 5 seconds only adds latency.

request.timeout_secs: 60 (the default). Never set it below 30. Berserk can hold a request for up to 25 seconds while it retries object storage. A shorter client timeout turns that into a resend.

buffer.type: disk. While Berserk is throttling or briefly unavailable, Vector's buffer holds the data. The default 500-event memory buffer does not survive a restart.

Retries need no configuration. Vector retries 408, 429 and 5xx indefinitely, and drops other 4xx. It does not read Retry-After; it backs off on its own schedule, up to 30 seconds.

End-to-end acknowledgements. If you enable acknowledgements with a datadog_agent source, the Agent waits for Berserk's acknowledgment. Keep batch.timeout_secs low, or the chain can exceed the Agent's 10-second request timeout.

MetricsCopy Anchor Link

The datadog_metrics sink needs the same endpoint and key. Berserk reads both protobuf series formats, v2 and v3. Pin series_api_version: v2 anyway: Vector's next release switches its default to v3, and Vector's v3 encoder has not been tested against Berserk yet.

sinks:
  berserk_metrics:
    type: datadog_metrics
    inputs: [my_metrics]
    endpoint: https://<your-ingest-host>
    default_api_key: SECRET[berserk.ingest_token]
    series_api_version: v2
    request:
      concurrency: 16

Vector sends distributions (histogram metrics) as sketches, which Berserk stores as histograms (below).

TracesCopy Anchor Link

The datadog_traces sink relays what Vector's datadog_agent source receives from your Agents:

sinks:
  berserk_traces:
    type: datadog_traces
    inputs: [agent.traces]
    endpoint: https://<your-ingest-host>
    default_api_key: SECRET[berserk.ingest_token]
    compression: zstd
    request:
      concurrency: 64
    batch:
      timeout_secs: 2

• compression: zstd: the sink's default is no compression.
• concurrency: the sink batches per host, so an aggregator in front of many Agents sends many small requests. Size it at about number of hosts ÷ batch timeout × 2.5 s.
• batch.timeout_secs: 2: the default of 10 s can exceed the Agent's own 10 s request timeout when end-to-end acknowledgements are on.
• Mind the Agent 7.84 warning at the top of this page.

Datadog AgentCopy Anchor Link

The Agent can send logs to an additional endpoint with its own API key, while the rest of its data keeps going to Datadog. That is the low-risk way to start: dual-ship, compare, then cut over.

logs_enabled: true
logs_config:
  force_use_http: true
  additional_endpoints:
    - api_key: "ing_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
      Host: "<your-ingest-host>"
      Port: 443
      is_reliable: true

• force_use_http: true is required: the intake speaks the Agent's HTTP logs protocol, not its TCP one.

To dual-ship metrics too, add a top-level additional endpoint. It must be https://:

additional_endpoints:
  "https://<your-ingest-host>":
    - ing_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

• is_reliable: true makes the Agent treat Berserk like its primary endpoint: it retries and applies backpressure instead of dropping data when Berserk is slow.

To dual-ship APM traces, add an additional trace endpoint (Agent 6.7+; the environment variable needs 7.19+):

apm_config:
  additional_endpoints:
    "https://<your-ingest-host>":
      - ing_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The Agent sends each log line as-is in message, with status set to its default for the source (usually info). Datadog's intake then parses JSON lines; Berserk does the same (see mapping). So a JSON line's level becomes the severity and its dd.trace_id stays searchable, exactly as in Datadog.

How Metrics Are MappedCopy Anchor Link

Each Datadog point becomes one row, with the standard metric columns. Tags become attributes (the env/version/service/host promotions above apply); the host resource becomes resource['host.name']. Series v2 and v3 map identically. scope_name is datadog, and scope_version records the API a point arrived on: v2, v3, or beta for sketches.

Totals of counts and rates. Counts and rates are delta sums, so otel_increase($raw) totals them and otel_rate($raw) rates them, whether or not the sender gave an interval (Vector's counts carry none). Datadog counts can also go down (DogStatsD decrement), so they are stored as non-monotonic; for a count that does, use otel_delta($raw), since otel_increase warns about a negative increment.

Histogram (|h) metrics arrive already aggregated by the Agent, as .avg, .median, .max, .95percentile gauges and a .count rate.

Percentiles from distributions. Use otel_histogram_percentile, which merges the delta histograms in each group:

my_metrics
| where metric_name == "checkout.latency"
| summarize p50 = otel_histogram_percentile($raw, 50), p99 = otel_histogram_percentile($raw, 99) by bin(timestamp, 1m)

Re-binning Datadog's buckets onto the histogram's costs some precision: a percentile can be off by up to about 3.3%, where Datadog's own sketch is within about 0.8%.

How Traces Are MappedCopy Anchor Link

Each Datadog span becomes one row, with the standard span columns. Both trace payload formats (the Agent's classic one and 7.84's indexed one) map identically.

Joining logs and traces. A log's trace_id and span_id lead to its span; Correlating logs and traces lists the tracer versions that need a setting for that.

APM stats (/api/v0.2/stats) are acknowledged and discarded: they can be computed from the spans.

How Fields Are MappedCopy Anchor Link

Each Datadog log entry becomes one row, with the standard log columns:

JSON log lines. When message is a JSON object, its fields become attributes, and Datadog's reserved names are remapped the way Datadog's own pipelines do it:

A severity key only counts if its value is a recognised severity. In an access log, "status": "410" is an HTTP status, so the envelope's status stays and 410 remains an attribute.

Correlating Logs and TracesCopy Anchor Link

Berserk's trace views, the jump from a log to its trace, and trace-find all use the OpenTelemetry columns trace_id, span_id and parent_span_id. Every Datadog span and every log with a dd.trace_id has them. They lead from a log to its spans when the log's trace_id matches the spans' trace_id, which depends on the tracer version.

Datadog tracers began generating 128-bit trace ids by default in November 2023. From the versions below, they also write 128-bit ids into logs by default, as 32 hex digits. They switch to decimal only for a trace that really is 64-bit. Berserk reads a decimal id as a 64-bit trace, with the high 64 bits zero, which is how the spans of such a trace are stored too.

• From the "Works from" version on, nothing needs configuring: 128-bit log injection is on by default (Python 2.12 removed the setting).
• Versions in the last column generate 128-bit trace ids but, by default, write only the low 64 bits into logs. Their logs get a trace_id that matches no span, so a log's trace link finds nothing. Set DD_TRACE_128_BIT_TRACEID_LOGGING_ENABLED=true on those services, or upgrade. With it, Python 2.3 – 2.11 writes the 128-bit id as one long decimal number, which Berserk reads too.
• Tracers older than the last column generate 64-bit trace ids, so logs and spans agree, and linking works.
• The Datadog Agent and Vector versions do not matter here. Both pass log trace ids through unchanged. For traces sent through Vector, see the warning at the top of this page.

dd.trace_id and dd.span_id work for every version, including the ones in the last column. They hold the low 64 bits in decimal on spans and logs alike, as Datadog shows them:

my_table
| where attributes['dd.trace_id'] == "9532127138774266268"

ResponsesCopy Anchor Link

The intake follows Datadog clients' retry rules, which differ from OTLP's in two places:

Service checks (/api/v1/check_run), host metadata (/intake/, /api/v1/metadata) and APM stats (/api/v0.2/stats) are acknowledged and discarded.

Enabling the Intake (Self-Hosted)Copy Anchor Link

The intake is off by default. In the Helm chart, enable the listener and route it:

ingest:
  config:
    datadogEnabled: true
  datadogIngress:
    enabled: true
    className: <your-ingress-class>
    hosts:
      - host: dd-intake.example.com
        paths:
          - path: /
            pathType: Prefix
            portName: datadog
    tls:
      - hosts: [dd-intake.example.com]
        secretName: dd-intake-tls

A host of its own is simplest: Datadog clients append many paths to their endpoint. To share a host with other services instead, route these Exact paths to portName: datadog:

/api/v2/logs, /api/v2/series, /api/intake/metrics/v3/series, /api/beta/sketches, /api/v0.2/traces, /api/v1/validate, /_health, /api/v1/check_run, /intake/, /api/v1/metadata, /api/v0.2/stats

Tested WithCopy Anchor Link

The intake is tested against real payloads captured from these senders, and Vector runs end to end in CI:

Version CompatibilityCopy Anchor Link

Berserk accepts series in API v2 and v3 (both protobuf), but not v1 (JSON). Most version boundaries that matter are about the series format, and about traces through Vector:

TroubleshootingCopy Anchor Link

Then confirm end to end:

bzrk search "<your table> | where scope_name == 'datadog' | take 10" --since "5m ago"