ob-col/exporter/datadogexporter

Datadog Exporter

Status
Stability	alpha: logs
	beta: traces, metrics
Distributions	contrib, aws, observiq
Issues
Code Owners	@mx-psi, @gbbr, @dineshg13, @liustanley, @songy23, @mackjmr

Please review the Collector's security documentation, which contains recommendations on securing sensitive information such as the API key required by this exporter.

Visit the official documentation for usage instructions.

FAQs

Why am I getting errors 413 - Request Entity Too Large, how do I fix it?

This error indicates the payload size sent by the Datadog exporter exceeds the size limit (see previous examples https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/16834, https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/17566).

This is usually caused by the pipeline batching too many telemetry data before sending to the Datadog exporter. To fix that, try lowering send_batch_size and send_batch_max_size in your batchprocessor config. You might want to have a separate batch processor dedicated for datadog exporter if other exporters expect a larger batch size, e.g.

processors:
  batch:  # To be used by other exporters
    timeout: 1s
    # Default value for send_batch_size is 8192
  batch/datadog:
    send_batch_max_size: 100
    send_batch_size: 10
    timeout: 10s
...
service:
  pipelines:
    metrics:
      receivers: ...
      processors: [batch/datadog]
      exporters: [datadog]

The exact values for send_batch_size and send_batch_max_size depends on your specific workload. Also note that, Datadog intake has different payload size limits for the 3 signal types:

• Trace intake: 3.2MB
• Log intake: https://docs.datadoghq.com/api/latest/logs/
• Metrics V2 intake: https://docs.datadoghq.com/api/latest/metrics/#submit-metrics

Fall back to the Zorkian metric client with feature gate

Since v0.69.0, the Datadog exporter has switched to use the native metric client datadog-api-client-go for metric export instead of Zorkian client by default. While datadog-api-client-go fixed several issues that are present in Zorkian client, there is a performance regression with it compared to Zorkian client especially under high metric volume. If you observe memory or throughput issues in the Datadog exporter with datadog-api-client-go, you can configure the Datadog exporter to fall back to the Zorkian client by disabling the feature gate exporter.datadogexporter.metricexportnativeclient, e.g.

otelcol --config=config.yaml --feature-gates=-exporter.datadogexporter.metricexportnativeclient

Note that we are currently migrating the Datadog metrics exporter to use the metrics serializer instead. The feature flag exporter.datadogexporter.metricexportnativeclient will be deprecated and eventually removed in the future, following the feature lifecycle.