Reference

Components

otelcol

otelcol.receiver.datadog

Open source

Experimental

otelcol.receiver.datadog

EXPERIMENTAL: This is an experimental component. Experimental components are subject to frequent breaking changes, and may be removed with no equivalent replacement. The stability.level flag must be set to experimental to use the component.

otelcol.receiver.datadog accepts Datadog metrics and traces over the network and forwards it to other otelcol.* components.

You can specify multiple otelcol.receiver.datadog components by giving them different labels.

Usage

otelcol.receiver.datadog "LABEL" {
  output {
    metrics = [...]
    traces  = [...]
  }
}

Arguments

otelcol.receiver.datadog supports the following arguments:

Name	Type	Description	Default	Required
`endpoint`	`string`	`host:port` to listen for traffic on.	`"localhost:8126"`	no
`max_request_body_size`	`string`	Maximum request body size the server will allow.	`20MiB`	no
`include_metadata`	`boolean`	Propagate incoming connection metadata to downstream consumers.	`false`	no
`read_timeout`	`duration`	Read timeout for requests of the HTTP server.	`"60s"`	no
`compression_algorithms`	`list(string)`	A list of compression algorithms the server can accept.	`["", "gzip", "zstd", "zlib", "snappy", "deflate"]`	no

By default, otelcol.receiver.datadog listens for HTTP connections on localhost. To expose the HTTP server to other machines on your network, configure endpoint with the IP address to listen on, or 0.0.0.0:8126 to listen on all network interfaces.

Blocks

The following blocks are supported inside the definition of otelcol.receiver.datadog:

Hierarchy	Block	Description	Required
tls	tls	Configures TLS for the HTTP server.	no
cors	cors	Configures CORS for the HTTP server.	no
debug_metrics	debug_metrics	Configures the metrics that this component generates to monitor its state.	no
output	output	Configures where to send received traces.	yes

tls block

The tls block configures TLS settings used for a server. If the tls block isn’t provided, TLS won’t be used for connections to the server.

The following arguments are supported:

Name	Type	Description	Default	Required
`ca_file`	`string`	Path to the CA file.		no
`ca_pem`	`string`	CA PEM-encoded text to validate the server with.		no
`cert_file`	`string`	Path to the TLS certificate.		no
`cert_pem`	`string`	Certificate PEM-encoded text for client authentication.		no
`include_system_ca_certs_pool`	`boolean`	Whether to load the system certificate authorities pool alongside the certificate authority.	`false`	no
`key_file`	`string`	Path to the TLS certificate key.		no
`key_pem`	`secret`	Key PEM-encoded text for client authentication.		no
`max_version`	`string`	Maximum acceptable TLS version for connections.	`"TLS 1.3"`	no
`min_version`	`string`	Minimum acceptable TLS version for connections.	`"TLS 1.2"`	no
`cipher_suites`	`list(string)`	A list of TLS cipher suites that the TLS transport can use.	`[]`	no
`reload_interval`	`duration`	The duration after which the certificate is reloaded.	`"0s"`	no
`client_ca_file`	`string`	Path to the TLS cert to use by the server to verify a client certificate.		no

If reload_interval is set to "0s", the certificate never reloaded.

The following pairs of arguments are mutually exclusive and can’t both be set simultaneously:

ca_pem and ca_file
cert_pem and cert_file
key_pem and key_file

If cipher_suites is left blank, a safe default list is used. Refer to the Go Cipher Suites documentation for a list of supported cipher suites.

client_ca_file sets the ClientCA and ClientAuth to RequireAndVerifyClientCert in the TLSConfig. Refer to the Go TLS documentation for more information.

cors block

The cors block configures CORS settings for an HTTP server.

The following arguments are supported:

Name	Type	Description	Default	Required
`allowed_origins`	`list(string)`	Allowed values for the `Origin` header.	`[]`	no
`allowed_headers`	`list(string)`	Accepted headers from CORS requests.	`["X-Requested-With"]`	no
`max_age`	`number`	Configures the `Access-Control-Max-Age` response header.	`0`	no

The allowed_headers argument specifies which headers are acceptable from a CORS request. The following headers are always implicitly allowed:

Accept
Accept-Language
Content-Type
Content-Language

If allowed_headers includes "*", all headers are permitted.

debug_metrics block

The debug_metrics block configures the metrics that this component generates to monitor its state.

The following arguments are supported:

Name	Type	Description	Default	Required
`disable_high_cardinality_metrics`	`boolean`	Whether to disable certain high cardinality metrics.	`true`	no
`level`	`string`	Controls the level of detail for metrics emitted by the wrapped collector.	`"detailed"`	no

disable_high_cardinality_metrics is the Grafana Alloy equivalent to the telemetry.disableHighCardinalityMetrics feature gate in the OpenTelemetry Collector. It removes attributes that could cause high cardinality metrics. For example, attributes with IP addresses and port numbers in metrics about HTTP and gRPC connections are removed.

Note
If configured, disable_high_cardinality_metrics only applies to otelcol.exporter.* and otelcol.receiver.* components.

level is the Alloy equivalent to the telemetry.metrics.level feature gate in the OpenTelemetry Collector. Possible values are "none", "basic", "normal" and "detailed".

output block

The output block configures a set of components to forward resulting telemetry data to.

The following arguments are supported:

Name	Type	Description	Default	Required
`logs`	`list(otelcol.Consumer)`	List of consumers to send logs to.	`[]`	no
`metrics`	`list(otelcol.Consumer)`	List of consumers to send metrics to.	`[]`	no
`traces`	`list(otelcol.Consumer)`	List of consumers to send traces to.	`[]`	no

You must specify the output block, but all its arguments are optional. By default, telemetry data is dropped. Configure the metrics, logs, and traces arguments accordingly to send telemetry data to other components.

Exported fields

otelcol.receiver.datadog does not export any fields.

Component health

otelcol.receiver.datadog is only reported as unhealthy if given an invalid configuration.

Debug information

otelcol.receiver.datadog does not expose any component-specific debug information.

Example

This example forwards received telemetry through a batch processor before finally sending it to an OTLP-capable endpoint:

otelcol.receiver.datadog "default" {
  output {
    metrics = [otelcol.processor.batch.default.input]
    traces  = [otelcol.processor.batch.default.input]
  }
}

otelcol.processor.batch "default" {
  output {
    metrics = [otelcol.exporter.otlp.default.input]
    traces  = [otelcol.exporter.otlp.default.input]
  }
}

otelcol.exporter.otlp "default" {
  client {
    endpoint = sys.env("OTLP_ENDPOINT")
  }
}

Compatible components

otelcol.receiver.datadog can accept arguments from the following components:

Components that export OpenTelemetry otelcol.Consumer

Note
Connecting some components may not be sensible or components may require further configuration to make the connection work correctly. Refer to the linked documentation for more details.

Was this page helpful?

Suggest an edit in GitHub

Create a GitHub issue

Email docs@grafana.com

Help and support

Community

Feedback

Relevant sources:

Feedback

otelcol.receiver.datadog

Usage

Arguments