Datadog
Synopsis
The Datadog target forwards events to the Datadog Cloud SIEM logs intake API over HTTPS. It handles batching and delivery — the event payload is expected to already be a complete JSON document in Datadog's log schema when it reaches the target.
Schema
- name: <string>
description: <string>
type: datadog
pipelines: <pipeline[]>
status: <boolean>
properties:
api_key: <string>
site: <string>
url: <string>
batch_size: <integer>
timeout: <integer>
field_format: <string>
debug:
status: <boolean>
dont_send_logs: <boolean>
Configuration
The following fields are used to define the target:
| Field | Required | Default | Description |
|---|---|---|---|
name | Y | Target name | |
description | N | - | Optional description |
type | Y | Must be datadog | |
pipelines | N | - | Optional post-processor pipelines |
status | N | true | Enable/disable the target |
Connection
| Field | Required | Default | Description |
|---|---|---|---|
api_key | Y* | - | Datadog API key, sent as the DD-API-KEY header |
site | N | datadoghq.com | Datadog site: datadoghq.com (US1), us3.datadoghq.com, us5.datadoghq.com, datadoghq.eu, ap1.datadoghq.com, ddog-gov.com |
url | N* | built from site | Explicit logs intake URL. Overrides site. Default: `https://http-intake.logs.{site}/api/v2/logs` |
max_bytes | N | 5242880 (5 MB) | Maximum size of a single request body or batch, in bytes |
max_bytes caps the size of a single request body or batch. It behaves differently from max_size on the file-writing targets, and the difference is easy to get wrong:
- An explicit
max_bytes: 0IS honoured and removes the ceiling. The value is read withInt64, which returns what you wrote — unlikemax_size, which is read withMustInt64and silently substitutes its default for a zero. - A negative value is rejected at configuration time with max_bytes must not be negative.
The ceiling is validated when the target is built and enforced again on every batch, so a value the receiving service will refuse fails early rather than per request.
* = Conditionally required/optional. Either api_key (endpoint built from site) or an explicit url is required; supplying url makes api_key unnecessary.
Batch Configuration
| Field | Required | Default | Description |
|---|---|---|---|
batch_size | N | 1000 | Maximum events per POST, serialized as a JSON array |
timeout | N | 30 | HTTP client timeout, in seconds |
Processing
| Field | Required | Default | Description |
|---|---|---|---|
field_format | N | - | Optional target-side normalization format applied before delivery. Typically left empty, since the payload already arrives in Datadog's JSON schema from upstream processing. See applicable Normalization section |
Scheduling
See Scheduling and Pool Behavior for interval and cron fields shared by all targets.
Debug Options
| Field | Required | Default | Description |
|---|---|---|---|
debug.status | N | false | Enable debug logging |
debug.dont_send_logs | N | false | Process logs but don't send to target (testing) |
Details
This target is transport-only: it does not render Datadog's log schema itself. It expects each event to already be a complete JSON document when it reaches the target, buffers events in memory, and delivers them as one HTTP POST — a JSON array ([{...},{...}]) — once batch_size is reached or during finalization.
Endpoint and Authentication
An explicit url always wins. Otherwise the endpoint is built from site as `https://http-intake.logs.{site}/api/v2/logs`. When api_key is set, it is sent as the DD-API-KEY request header; configuration validation rejects a target that has neither api_key nor url.
Batching and Retry
Events buffer until batch_size is reached, then POST as a single request. A failed POST does not retry the batch internally: the buffer is cleared unconditionally after Finalize, and delivery failure is surfaced to the sender pool, which handles redelivery through the JetStream layer. Retaining the batch locally in addition to that redelivery would duplicate events at the destination. Error responses include up to the first 1 MB of the response body for troubleshooting.
The target does not render Datadog's JSON schema — it only batches and delivers the payload it receives. Format the event as Datadog-compatible JSON before it reaches this target.
Examples
Basic Configuration
Sending JSON events to Datadog Cloud SIEM logs intake on the default US1 site... | |
EU Site
Routing to the Datadog EU site instead of the US1 default... | |
Explicit Endpoint Override
Overriding the intake URL directly instead of deriving it from | |