Configure Datadog Agent

The Datadog Agent can send a copy of its data to Bronto in addition to Datadog using its additional_endpoints settings. This lets you evaluate Bronto, for example during a proof of value, with the data you already collect and without changing your application instrumentation. This page covers configuration only. For installation instructions, see the Datadog Agent documentation.

Dual shipping is meant for evaluating Bronto and for the transition period while you move from Datadog to Bronto. The Datadog Agent is built to send data to Datadog and needs a valid Datadog API key, so it is not a long-term way to send data to Bronto. Before you stop using Datadog, replace the Agent with the OpenTelemetry Collector. See When you stop using Datadog.

How it works

Bronto accepts the Datadog Agent’s log format directly. Metrics and traces need to be converted to OpenTelemetry (OTLP) first, which an OpenTelemetry Collector with the Datadog receiver does on the way:

Signal	Path
Logs	Datadog Agent → Bronto ingestion endpoint. See Send logs.
Metrics	Datadog Agent → OpenTelemetry Collector → Bronto. See Send metrics and traces.
Traces	Datadog Agent → OpenTelemetry Collector → Bronto. See Send metrics and traces.

Datadog keeps receiving everything it does today. You can set up each signal on its own. Logs are the quickest way to evaluate Bronto: they only need a change to the Agent’s configuration. Metrics and traces are optional and need an OpenTelemetry Collector in addition to the Agent. The Agent can also dual ship other Datadog data, such as profiles, live processes, Database Monitoring, Network Device Monitoring, and security events. Bronto does not ingest these.

Send logs

Requirements

Use Datadog Agent 7.37.0 or later. Earlier versions work with the following limitations:

Agent version	Notes
7.37.0+	Recommended. Additional endpoints default to `is_reliable: true`.
7.34.0 – 7.36.x	`is_reliable` is available but must be set explicitly.
7.18.0+	Minimum for configuring `additional_endpoints` through environment variables, including the Kubernetes Secret option.

Endpoint and authentication

Use the ingestion endpoint for your Bronto region:

Region	Host
EU	`ingestion.eu.bronto.io`
US	`ingestion.us.bronto.io`

Set api_key to your Bronto API key.

Configuration

Each example sets force_use_http: true. The Agent requires the transport to be set explicitly when additional_endpoints is configured, and the same transport is used for Datadog and every additional endpoint.

Linux
Kubernetes/Helm
Kubernetes/Operator

Edit /etc/datadog-agent/datadog.yaml to add Bronto as an additional log endpoint:

datadog.yaml

logs_config:
  force_use_http: true
  additional_endpoints:
    - api_key: "<YOUR_API_KEY>"
      Host: "ingestion.<REGION>.bronto.io"
      Port: 443
      is_reliable: true

To control which dataset and collection the logs are stored in, see Choose the dataset and collection.

Add Bronto as an additional endpoint by upgrading the Datadog Agent Helm chart:

helm upgrade datadog-agent -f datadog-values.yaml datadog/datadog

datadog-values.yaml

datadog:
  podAnnotationsAsTags:
    kubernetes.annotations.logs.bronto.io/collection: br_collection
  logs:
    enabled: true

agents:
  useConfigMap: true
  customAgentConfig:
    logs_config:
      force_use_http: true
      additional_endpoints:
        - api_key: "<BRONTO_API_KEY>"
          Host: "ingestion.<REGION>.bronto.io"
          Port: 443
          is_reliable: true

agents.customAgentConfig replaces the datadog.yaml generated by the chart. It is not merged. If you already set agents.customAgentConfig, add the logs_config block to your existing configuration. Settings the chart passes as environment variables, such as datadog.logs.enabled, still apply.

Add the kubernetes.annotations.logs.bronto.io/collection annotation to pods whose logs should be forwarded to Bronto. Set its value to a unique identifier for the cluster, e.g. <CLUSTER_NAME>-<ENVIRONMENT>-<REGION>. The podAnnotationsAsTags entry maps this annotation to the br_collection log attribute, which Bronto uses to determine which collection to save the log data under.To keep the API key out of the ConfigMap, see Store the API key in a Kubernetes Secret.

Add the following to your existing DatadogAgent resource, then apply it:

kubectl apply -f datadog-agent.yaml

datadog-agent.yaml

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    podAnnotationsAsTags:
      kubernetes.annotations.logs.bronto.io/collection: br_collection
  features:
    logCollection:
      enabled: true
  override:
    nodeAgent:
      customConfigurations:
        datadog.yaml:
          configData: |-
            logs_config:
              force_use_http: true
              additional_endpoints:
                - api_key: "<BRONTO_API_KEY>"
                  Host: "ingestion.<REGION>.bronto.io"
                  Port: 443
                  is_reliable: true

customConfigurations replaces the node Agent’s default datadog.yaml. It is not merged. If you already set customConfigurations.datadog.yaml, add the logs_config block to your existing configData.

The global.podAnnotationsAsTags entry maps the kubernetes.annotations.logs.bronto.io/collection pod annotation to the br_collection log attribute, as described in the Kubernetes/Helm tab.To keep the API key out of the DatadogAgent resource, see Store the API key in a Kubernetes Secret.

For the full additional_endpoints configuration reference, see the Datadog Agent log forwarding documentation.

Choose the dataset and collection

By default, Bronto stores each log in:

the dataset named by the log’s Datadog service tag
the collection named by the log’s Datadog source tag

You can override either one by setting the br_dataset or br_collection tag on the log. In Kubernetes, the Agent sets source for each container from its short image name, unless you set it in the pod’s log configuration. Containers in the same pod therefore often have different sources. For example, a service’s application container, its service mesh sidecar (such as proxyv2 for Istio) and its init containers each end up in a different collection, all under the same dataset name. To group logs by cluster instead, set br_collection to a cluster identifier with the kubernetes.annotations.logs.bronto.io/collection pod annotation, as shown in the Kubernetes tabs above. To set the dataset the same way, map a second annotation to br_dataset:

datadog-values.yaml

datadog:
  podAnnotationsAsTags:
    kubernetes.annotations.logs.bronto.io/collection: br_collection
    kubernetes.annotations.logs.bronto.io/dataset: br_dataset

On a host, set the tags in the log source’s configuration in the Agent’s conf.d directory:

conf.d/<APP_NAME>.d/conf.yaml

logs:
  - type: file
    path: /var/log/<APP_NAME>/*.log
    service: <APP_NAME>
    source: <SOURCE>
    tags:
      - "br_dataset:<DATASET>"
      - "br_collection:<COLLECTION>"

How logs appear in Bronto

The Datadog Agent sends each log with its tags and metadata, such as service, source, host and Kubernetes tags like kube_namespace and pod_name. Bronto stores these as attributes of the event, separately from the fields it parses from the log message. Some tags you see in Datadog are not in the Agent’s payload, so they don’t reach Bronto. Datadog adds host tags and cloud provider tags, such as the cluster name, region and account, when it receives the log. To identify the cluster in Bronto, set br_collection as described in Choose the dataset and collection. Bronto reads a log’s severity from standard Elastic Common Schema and OpenTelemetry severity fields. Datadog’s status attribute is not one of these. If a log has no standard severity field, its status is the one the Agent assigns: info for logs written to stdout and error for logs written to stderr. To keep the level your application logs, write it to an ECS-compliant field such as log.level.

Store the API key in a Kubernetes Secret

The Kubernetes examples above store the Bronto API key in plain text in a ConfigMap or DatadogAgent resource. For production, set the endpoint through the DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS environment variable and source it from a Kubernetes Secret instead. Environment variables take precedence over datadog.yaml, so you don’t need customAgentConfig or customConfigurations with this approach. Create the Secret in the namespace where the Datadog Agent runs:

kubectl create secret generic bronto-logs-endpoint \
  --namespace <DATADOG_AGENT_NAMESPACE> \
  --from-literal=additional-endpoints='[{"api_key": "<BRONTO_API_KEY>", "Host": "ingestion.<REGION>.bronto.io", "Port": 443, "is_reliable": true}]'

Then reference it from the Agent configuration:

Kubernetes/Helm
Kubernetes/Operator

datadog-values.yaml

datadog:
  podAnnotationsAsTags:
    kubernetes.annotations.logs.bronto.io/collection: br_collection
  logs:
    enabled: true
  env:
    - name: DD_LOGS_CONFIG_FORCE_USE_HTTP
      value: "true"
    - name: DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS
      valueFrom:
        secretKeyRef:
          name: bronto-logs-endpoint
          key: additional-endpoints

datadog-agent.yaml

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    podAnnotationsAsTags:
      kubernetes.annotations.logs.bronto.io/collection: br_collection
  features:
    logCollection:
      enabled: true
  override:
    nodeAgent:
      env:
        - name: DD_LOGS_CONFIG_FORCE_USE_HTTP
          value: "true"
        - name: DD_LOGS_CONFIG_ADDITIONAL_ENDPOINTS
          valueFrom:
            secretKeyRef:
              name: bronto-logs-endpoint
              key: additional-endpoints

Verify log collection

After you apply your configuration and restart the Datadog Agent:

Run the Agent status command and check the Logs Agent section:
# Linux sudo datadog-agent status # Kubernetes kubectl exec -it <AGENT_POD_NAME> -- agent status
The Bronto endpoint is listed alongside the Datadog endpoint, for example Reliable: Sending compressed logs in HTTPS to ingestion.<REGION>.bronto.io on port 443. If it shows TCP instead of HTTPS, check that force_use_http is set.
Check the Agent logs for delivery errors. Failed requests to an additional endpoint are logged as warnings that include the endpoint URL, for example failed to post http payload. On Linux, the Agent logs are in /var/log/datadog/. In Kubernetes, run kubectl logs <AGENT_POD_NAME> -c agent.
Confirm your log data is being ingested to Bronto on the Search page.

Send metrics and traces

The Datadog Agent sends metrics and traces in Datadog’s own format, which Bronto does not ingest directly. Run an OpenTelemetry Collector with the Datadog receiver between the Agent and Bronto. The receiver accepts the Agent’s payloads and the Collector forwards them to Bronto over OTLP. This part is optional. Set it up if you want to evaluate metrics and traces in Bronto as well as logs.

Requirements

An OpenTelemetry Collector distribution that includes the datadog receiver, such as otelcol-contrib. This setup was tested with otelcol-contrib 0.158.0.
For traces, check your Datadog Agent version:

Agent version	Traces
7.83.x and earlier	Supported with the configuration below.
7.84.0 and later	Requires the `disable-convert-traces` APM feature. See Traces with newer Agents.

The Datadog receiver is an alpha component for traces and is in development for metrics. Its behavior can change between Collector releases.

Step 1: Run the Collector

Configure the Datadog receiver and one OTLP exporter per signal:

otel-config.yaml

receivers:
  datadog:
    endpoint: 0.0.0.0:8127

processors:
  batch: {}

exporters:
  otlphttp/brontometrics:
    metrics_endpoint: "https://ingestion.<REGION>.bronto.io/v1/metrics"
    compression: gzip
    headers:
      x-bronto-api-key: <YOUR_API_KEY>
  otlphttp/brontotraces:
    traces_endpoint: "https://ingestion.<REGION>.bronto.io/v1/traces"
    compression: gzip
    headers:
      x-bronto-api-key: <YOUR_API_KEY>

service:
  pipelines:
    metrics:
      receivers: [datadog]
      processors: [batch]
      exporters: [otlphttp/brontometrics]
    traces:
      receivers: [datadog]
      processors: [batch]
      exporters: [otlphttp/brontotraces]

The receiver listens on port 8127 because the Datadog Agent already uses 8126 for APM. Any free port works, as long as the Agent configuration in the next step uses the same one. Run the Collector where every Datadog Agent can reach it. In Kubernetes, install it with the OpenTelemetry Helm chart as a Deployment. The chart configures Service ports separately from receivers, so add a datadog port for 8127. Without it, the Agents can’t reach the receiver through the Service:

values.yaml

mode: deployment
fullnameOverride: otel-collector

image:
  repository: otel/opentelemetry-collector-contrib

ports:
  datadog:
    enabled: true
    containerPort: 8127
    servicePort: 8127
    protocol: TCP

config:
  receivers:
    datadog:
      endpoint: 0.0.0.0:8127

  processors:
    batch: {}

  exporters:
    otlphttp/brontometrics:
      metrics_endpoint: "https://ingestion.<REGION>.bronto.io/v1/metrics"
      compression: gzip
      headers:
        x-bronto-api-key: <YOUR_API_KEY>
    otlphttp/brontotraces:
      traces_endpoint: "https://ingestion.<REGION>.bronto.io/v1/traces"
      compression: gzip
      headers:
        x-bronto-api-key: <YOUR_API_KEY>

  service:
    pipelines:
      metrics:
        receivers: [datadog]
        processors: [batch]
        exporters: [otlphttp/brontometrics]
      traces:
        receivers: [datadog]
        processors: [batch]
        exporters: [otlphttp/brontotraces]

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install otel-collector open-telemetry/opentelemetry-collector \
  --namespace <NAMESPACE> --values values.yaml

With fullnameOverride: otel-collector, use otel-collector.<NAMESPACE>.svc.cluster.local as <COLLECTOR_HOST> below. For more on running the Collector in Kubernetes, see Connect OpenTelemetry Collector to Bronto. The Bronto API key only needs to be set in the Collector. The Agent does not need it for metrics and traces.

Step 2: Point the Agent at the Collector

Add the Collector as an additional endpoint for metrics (additional_endpoints) and traces (apm_config.additional_endpoints). The Agent requires an API key for every endpoint, but the Datadog receiver ignores it, so any placeholder value works.

Linux
Kubernetes/Helm
Kubernetes/Operator

Edit /etc/datadog-agent/datadog.yaml:

datadog.yaml

additional_endpoints:
  "http://<COLLECTOR_HOST>:8127":
    - "unused"

apm_config:
  additional_endpoints:
    "http://<COLLECTOR_HOST>:8127":
      - "unused"
  # Datadog Agent 7.84.0 and later only
  features: ["disable-convert-traces"]

Restart the Agent to apply the change.

Set the endpoints as environment variables, so you don’t need to replace the chart’s datadog.yaml:

datadog-values.yaml

datadog:
  env:
    - name: DD_ADDITIONAL_ENDPOINTS
      value: '{"http://<COLLECTOR_HOST>:8127": ["unused"]}'
    - name: DD_APM_ADDITIONAL_ENDPOINTS
      value: '{"http://<COLLECTOR_HOST>:8127": ["unused"]}'
    # Datadog Agent 7.84.0 and later only
    - name: DD_APM_FEATURES
      value: "disable-convert-traces"

helm upgrade datadog-agent -f datadog-values.yaml datadog/datadog

If you run the Cluster Agent with cluster checks, also set DD_ADDITIONAL_ENDPOINTS under clusterAgent.env to dual ship the metrics it collects.

Add the environment variables to the node Agent in your DatadogAgent resource:

datadog-agent.yaml

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  override:
    nodeAgent:
      env:
        - name: DD_ADDITIONAL_ENDPOINTS
          value: '{"http://<COLLECTOR_HOST>:8127": ["unused"]}'
        - name: DD_APM_ADDITIONAL_ENDPOINTS
          value: '{"http://<COLLECTOR_HOST>:8127": ["unused"]}'
        # Datadog Agent 7.84.0 and later only
        - name: DD_APM_FEATURES
          value: "disable-convert-traces"

kubectl apply -f datadog-agent.yaml

If you already set apm_config.features or DD_APM_FEATURES, add disable-convert-traces to your existing list instead of replacing it.

Traces with newer Agents

Starting with version 7.84.0, the Datadog Agent converts traces into a new internal format before sending them. The Datadog receiver cannot read this format yet. It accepts the payloads without an error and produces no spans, so traces never reach Bronto and neither the Agent nor the Collector reports a problem. The disable-convert-traces APM feature keeps the Agent on the previous trace format. Metrics and logs are not affected. The feature is not part of Datadog’s public documentation, so test it in a non-production environment first, and check Verify metrics and traces after every Agent upgrade.

What to expect in Bronto

Metrics

Datadog metric	In Bronto
Gauge	Gauge
Count and rate	Sum with delta temporality
DogStatsD histogram	Gauges per aggregate (for example `.avg`, `.median`, `.max`, `.95percentile`) and a `.count` sum
Distribution	Not supported. Distributions arrive as exponential histograms, which Bronto doesn’t support yet. They are dropped.

Datadog tags become metric attributes. The receiver translates common tags to OpenTelemetry resource attributes, so filter on the translated names:

Datadog tag	Attribute in Bronto
`service`, `env`, `version`	`service.name`, `deployment.environment.name`, `service.version`
`container_id`, `container_name`, `image_name`, `image_tag`	`container.id`, `container.name`, `container.image.name`, `container.image.tags`
`kube_namespace`, `pod_name`, `kube_deployment`, `kube_cluster_name`	`k8s.namespace.name`, `k8s.pod.name`, `k8s.deployment.name`, `k8s.cluster.name`
`cloud_provider`, `region`, `zone`	`cloud.provider`, `cloud.region`, `cloud.availability_zone`

The receiver also translates other Kubernetes, ECS, and HTTP tags. See the receiver’s tag mapping for the full list. host.name comes from the hostname the Agent reports, not from a tag. Other key:value tags keep their key, and tags without a value get an unnamed_ prefix. Besides your custom metrics, the Agent sends the metrics from its checks (for example system.*, container.*, and integration metrics) and its own telemetry under datadog.*. The Agent’s own telemetry can be a large share of the metric names. To leave it out, add a filter processor to the metrics pipeline:

otel-config.yaml

processors:
  filter/drop-agent-telemetry:
    metrics:
      metric:
        - 'IsMatch(name, "^(datadog|n_o_i_n_d_e_x)\\.")'

service:
  pipelines:
    metrics:
      receivers: [datadog]
      processors: [filter/drop-agent-telemetry, batch]
      exporters: [otlphttp/brontometrics]

Traces Traces keep their service and parent-child structure, and the receiver restores full 128-bit trace IDs. Bronto receives the same traces as Datadog: the ones the Agent keeps after sampling. Span names usually stay as they are in Datadog, but the receiver renames spans from common integrations to follow OpenTelemetry naming:

Datadog span name	Name in Bronto
`http.request`, `web.request`, `servlet.request`	HTTP method and route, for example `GET /checkout`, when the span has an `http.method` tag
`postgresql.query`, `redis.query`	Query summary, or the database operation and name
`grpc.server`, `grpc.client`	`<service>/<method>`, for example `helloworld.Greeter/SayHello`
`aws.request`, `aws.command`	`<service>/<operation>`, from the span’s `aws.service` and `aws.operation` tags
`spring.handler`	The Datadog resource name

The original Datadog name of a renamed span is not kept, so search for these spans by their new name. The Datadog resource name is always stored in the dd.span.Resource span attribute. Agent warnings The Agent also sends host metadata to the /intake path of every metrics endpoint. The Datadog receiver rejects it, so the Agent logs recurring warnings like error "405 Method Not Allowed" while sending transaction to "http://<COLLECTOR_HOST>:8127/intake/". You can ignore these warnings. Metrics are not affected.

Verify metrics and traces

After you apply the configuration and restart the Agent:

Run the Agent status command. The Collector is listed under Forwarder → Endpoints for metrics and under APM Agent → Endpoints for traces.
Check the Agent logs for errors that include the Collector’s URL. Apart from the /intake/ warnings described above, there should be none.
Check the data in Bronto:
- Metrics: search for one of your metrics, or a check metric such as system.load.1, in the Metric Explorer.
- Traces: confirm your services appear in Explore Traces.

Always check traces in Bronto, not only in the Agent’s status. If the Agent sends a trace format the receiver can’t read, the Agent and the Collector both report success.

When you stop using Datadog

Dual shipping only works while the Datadog Agent still sends data to Datadog. Before your Datadog contract ends, move your collection to OpenTelemetry:

Deploy the OpenTelemetry Collector to collect logs, metrics, and traces and send them to Bronto. See Connect OpenTelemetry Collector to Bronto.
Point your applications at the Collector instead of the Datadog Agent. See Send Metrics to Bronto and Send Traces to Bronto.
Check that your data arrives in Bronto, then remove the Datadog Agent.

Overview

Ingest with agents

Ingest from AWS

Ingest from Azure

Ingest from CDN and edge

Ingest from apps and platforms

Ingest from Vercel

Ingest from infrastructure and databases

Ingest OpenTelemetry data

Configure Datadog Agent

How it works

Send logs

Requirements

Endpoint and authentication

Configuration

Choose the dataset and collection

How logs appear in Bronto

Store the API key in a Kubernetes Secret

Verify log collection

Send metrics and traces

Requirements

Step 1: Run the Collector

Step 2: Point the Agent at the Collector

Traces with newer Agents

What to expect in Bronto

Verify metrics and traces

When you stop using Datadog

​How it works

​Send logs

​Requirements

​Endpoint and authentication

​Configuration

​Choose the dataset and collection

​How logs appear in Bronto

​Store the API key in a Kubernetes Secret

​Verify log collection

​Send metrics and traces

​Requirements

​Step 1: Run the Collector

​Step 2: Point the Agent at the Collector

​Traces with newer Agents

​What to expect in Bronto

​Verify metrics and traces

​When you stop using Datadog

How it works

Send logs

Requirements

Endpoint and authentication

Configuration

Choose the dataset and collection

How logs appear in Bronto

Store the API key in a Kubernetes Secret

Verify log collection

Send metrics and traces

Requirements

Step 1: Run the Collector

Step 2: Point the Agent at the Collector

Traces with newer Agents

What to expect in Bronto

Verify metrics and traces

When you stop using Datadog