--- title: Datadog agent slug: telemetry-pipeline/datadog-agent docTags: createdAt: 2025-04-21T00:48:40.455Z --- ## 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 \.logs - Metrics as \.metrics - Traces as \.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