Skip to content

Latest commit

 

History

History
72 lines (56 loc) · 6.14 KB

README.md

File metadata and controls

72 lines (56 loc) · 6.14 KB
Raw

Datadog Exporter

Status
Stability alpha: logs
beta: traces, metrics
Distributions contrib
Issues Open issues Closed issues
Code Owners @mx-psi, @dineshg13, @liustanley, @songy23, @mackjmr, @ankitpatel96
Emeritus @gbbr

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

The Datadog Exporter now skips APM stats computation by default. It is recommended to only use the Datadog Connector in order to compute APM stats. To temporarily revert to the previous behavior, disable the exporter.datadogexporter.DisableAPMStats feature gate. Example: otelcol --config=config.yaml --feature-gates=-exporter.datadogexporter.DisableAPMStats

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 #16834, #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:

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.

Remap OTel’s service.name attribute to service for logs

For Datadog Exporter versions 0.83.0 and later, the service field of OTel logs is populated as OTel semantic convention service.name. However, service.name is not one of the default service attributes in Datadog’s log preprocessing.

To get the service field correctly populated in your logs, you can specify service.name to be the source of a log’s service by setting a log service remapper processor.