Datadog agent
Datadog Agent Source
The Datadog Agent source receives logs, metrics, and traces collected by a Datadog Agent and ingests them over HTTP or HTTPS. It is commonly used as a compatibility and migration layer, allowing Datadog Agents to forward data into a custom observability pipeline.
This source can run both as a sidecar or a centralized aggregator.
Collection Model
- Push-based ingestion over HTTP/HTTPS
- Datadog Agents send observability payloads to the configured endpoint
- Incoming data is decoded and normalized
- Signals can be routed independently or together downstream
This source enables seamless reuse of existing Datadog Agent deployments.
Network Binding
address (required, string)
Defines the socket address the source listens on for incoming connections.
Operational notes:
- Must include a port
- Can bind to all interfaces or a specific network interface
- Should be exposed only to trusted Datadog Agents
Signal Control
disable_logs (optional, bool)
Prevents ingestion of log events.
disable_metrics (optional, bool)
Prevents ingestion of metric events.
Metrics support is currently beta.
disable_traces (optional, bool)
Prevents ingestion of trace events.
Trace support is currently alpha.
multiple_outputs (optional, bool)
Controls whether logs, metrics, and traces are exposed as separate outputs.
When enabled:
- Logs are available as <source>.logs
- Metrics as <source>.metrics
- Traces as <source>.traces
This enables independent routing and scaling per signal type.
Decoding and Parsing
decoding (optional, object)
Controls how incoming payloads are decoded into structured events.
The decoder may:
- Determine the signal type
- Parse timestamps
- Apply schema validation
- Convert binary formats into structured data
Supported Codecs
The Datadog Agent source supports multiple decoding codecs, including:
- Raw bytes
- JSON
- Syslog
- GELF
- InfluxDB line protocol
- Protobuf
- Avro
- OTLP (logs, metrics, traces)
- Native Vector formats
- VRL-based custom decoding
Some codecs are experimental and may evolve over time.
VRL Decoding
When VRL decoding is enabled:
- Each incoming event is passed through a VRL program
- The final .target value becomes the decoded event
- Compilation or runtime errors result in decoding failures
This enables advanced customization and enrichment at ingest time.
Framing Configuration
framing (optional, object)
Controls how raw byte streams are split into individual events.
Supported framing strategies include:
- Byte-based framing
- Character-delimited
- Newline-delimited
- Length-delimited
- Octet-counting
- Chunked GELF
- Varint length-delimited
Correct framing is critical for high-throughput or binary payloads.
HTTP Connection Management
keepalive (optional, object)
Controls HTTP connection lifecycle behavior.
Key behaviors:
- Limits maximum connection age
- Adds jitter to avoid synchronized reconnects
- Helps prevent connection storms in large-scale deployments
send_timeout_secs (optional, float)
Defines how long the source waits before returning an HTTP 503 Service Unavailable.
This protects the system when:
- Downstream components are overloaded
- Backpressure builds up
- Datadog Agent timeouts must be handled gracefully
Datadog-Specific Features
parse_ddtags (optional, bool)
Parses the ddtags field from incoming log events and expands it into structured key-value pairs.
Useful for:
- Preserving Datadog tagging semantics
- Improving downstream filtering and aggregation
split_metric_namespace (optional, bool)
Splits metric names at the first . into:
- A namespace
- A metric name
This is useful when downstream systems enforce namespace-based metric models.
store_api_key (optional, bool)
Stores incoming Datadog API keys in event metadata.
When enabled:
- Events forwarded to a Datadog sink can reuse the original API key
- Facilitates hybrid or partial Datadog forwarding scenarios
TLS Configuration
tls (optional, object)
Controls TLS behavior for incoming connections.
Supported capabilities:
- Server certificates and private keys
- Custom CA trust chains
- Client certificate verification
- ALPN protocol negotiation
- Hostname and certificate verification
Disabling verification is strongly discouraged in production environments.
Acknowledgements and Reliability
- Source-level acknowledgements are deprecated
- End-to-end acknowledgements are controlled globally or at sink level
- At-least-once delivery guarantees may result in duplicate events
- Downstream systems should be idempotent
Security Considerations
- Restrict network access to trusted Datadog Agents
- Use TLS for all production deployments
- Avoid exposing the endpoint publicly
- Apply least-privilege routing and filtering downstream
- Monitor dropped and timed-out events
Common Use Cases
- Migrating away from Datadog without redeploying agents
- Dual-shipping observability data
- Centralized ingestion for multiple environments
- Normalizing Datadog telemetry into vendor-neutral pipelines
- Acting as a compatibility layer for legacy setups