obsdog

Datadog Fundamentals Certification / 04 / 06

Data Collection

What this domain covers

In this domain, you learn the four paths for bringing data into Datadog and the tagging practices that let you make use of that data afterward. The paths are DogStatsD, which sends custom metrics from applications; crawler-based cloud integrations, in which Datadog periodically calls the cloud provider's API; Agent integrations, in which the Agent on a host monitors targets according to the configuration in conf.d; and API endpoints, to which you post metrics and events directly over HTTP. The exam tests your understanding of these mechanisms by applying it to practical situations, with questions such as which path is appropriate in a given scenario, what type a metric sent as COUNT becomes in-app, what happens when you lower the sample rate, and what must not be used as a tag value. Numbers and default values are based on the official documentation as of September 2026.

Topics listed in the official guide

  • DogStatsD
  • Crawlers (cloud integrations)
  • Agent integrations
  • API endpoints
  • Tagging best practices
  • Metrics and time series

Key points

  • DogStatsD is the metrics aggregation service bundled with the Agent; it adds four extensions to StatsD: the Histogram type, service checks, events, and tagging.
  • DogStatsD receives data over UDP, and the application does not wait for a response (the default is UDP port 8125). Received values are aggregated into one point per 10-second flush interval.
  • A DogStatsD COUNT is stored in-app as a RATE, a GAUGE becomes the last value of the interval, and a SET becomes the number of unique values within the interval.
  • HISTOGRAM is aggregated on the Agent side into max / median / avg / count and the 95th percentile; DISTRIBUTION is aggregated on the server side.
  • The sample rate is a value from 0 to 1, where 1 means 100 % submission. COUNT corrects the received value by a factor of 1 / sample rate; GAUGE and SET are not corrected.
  • Cloud integrations use a crawler that periodically calls the provider's API. The default intervals are 10 minutes for AWS (3 minutes for RDS), 2 minutes for Azure, and 5 minutes for GCP.
  • Agent integrations are enabled by renaming conf.yaml.example under conf.d to conf.yaml and restarting the Agent. The default interval is 15 seconds.
  • The API key is passed in the DD-API-KEY header, and endpoints that require it also take an Application key in the DD-APPLICATION-KEY header.
  • Tags must start with a letter, are limited to 200 characters, and are normalized to lowercase. Do not use values that grow without bound, such as user IDs or timestamps, as tags.
  • Custom metrics are counted per unique combination of metric name and tag values (including the host tag). The more tag values there are, the higher the count.

Terms and concepts

DogStatsD

The metrics aggregation service bundled with the Datadog Agent, and the entry point that receives custom metrics, events, and service checks from applications. It implements the StatsD protocol while adding Datadog-specific extensions, namely the Histogram type, service checks, events, and tagging, which are available through the official Datadog client libraries. Because it receives data over UDP, the application continues its work without waiting for a response and is not dragged down if DogStatsD stops. Received values are aggregated into one point per 10-second flush interval.

How Submission Types Map to In-App Types

A metric has a submission type (COUNT / RATE / GAUGE / SET / HISTOGRAM / DISTRIBUTION) and an in-app type shown in Datadog, and the two do not always match. A DogStatsD COUNT is normalized to a per-second value so that it can be compared across Agents and is stored in-app as a RATE, so it may be displayed as a decimal. A GAUGE stores the last value of the flush interval, and a SET stores the number of unique values in that interval as a GAUGE. Data sent directly through the HTTP API does not pass through the Agent and, except for DISTRIBUTION, is stored without aggregation.

HISTOGRAM and DISTRIBUTION

Both types deal with the spread of values, but they differ in where aggregation happens. HISTOGRAM computes statistics on the Agent side for each flush interval and, by default, sends max / median / avg / count and the 95th percentile as separate metrics. Because aggregation is per host, it cannot produce correct percentiles across multiple hosts combined. DISTRIBUTION sends the raw data to Datadog and aggregates it on the server side, so you can later add p50 through p99 percentiles across the whole infrastructure and choose which tags to keep. It suits measuring targets that are independent of hosts, such as services.

Sample Rate

In high-frequency code where even the cost of sending UDP matters, you can pass the DogStatsD client a sample rate from 0 to 1 to send only a fraction of the data. 1 means 100 % submission, and 0.5 means half. DogStatsD corrects the received values according to the type to estimate what the unsampled values would have been. COUNT is multiplied by 1 / sample rate, DISTRIBUTION is counted 1 / sample rate times, GAUGE and SET are not corrected, and for HISTOGRAM only the count statistic is corrected. Traffic goes down, but you lose precision and granularity, so it suits sending many metrics to a separate host.

Crawler-Based Cloud Integrations

The AWS / Azure / Google Cloud integrations are authentication based: you register credentials in Datadog, and a crawler periodically calls the provider's API to pull in metrics and tags. You get CloudWatch metrics for EC2 without an Agent, but the provider API imposes delays; the default intervals are 10 minutes for AWS (3 minutes for RDS), 2 minutes for Azure, and 5 minutes for GCP. For AWS, Metric Streams reduces this to 2 to 3 minutes. Historical data is not imported, and if you need host-level visibility, installing the Agent as well is recommended.

Agent Integrations and conf.d

Agent-based integrations are installed together with the Agent and define the metrics to collect in a Python check method. Enabling one takes three steps: rename conf.yaml.example in the integration's .d folder under conf.d (for example conf.d/apache.d/) to conf.yaml, fill in the required parameters, and restart the Agent. Listing multiple targets under instances lets the same check monitor multiple instances. The default collection interval is 15 seconds and can be changed with min_collection_interval, and you confirm that the configuration was loaded in the Checks section of agent status.

API Endpoints and Authentication

The Datadog API is REST style and returns JSON. For authentication, you pass the API key in the DD-API-KEY header, and for endpoints that require user permissions you also pass an Application key in the DD-APPLICATION-KEY header. The hostname differs by site: api.datadoghq.com for US1 and api.datadoghq.eu for EU1. Metrics are submitted with POST /api/v2/series, and there is no rate limit on submitting metrics and logs. Management endpoints return 429 when the limit is exceeded, and the X-RateLimit headers show your quota.

Tag Rules and Unified Service Tagging

A tag is either key:value or a bare value, and key:value is recommended because it allows grouping by key. A tag must start with a letter, and any character other than letters, digits, underscores, minus signs, colons, periods, and slashes is converted to an underscore. The length limit is 200 characters, and tags are normalized to lowercase, so avoid camelCase. Everything before the first colon is the key, so the key of env:staging:east is env. Unified service tagging aligns the three tags env / service / version to tie metrics, traces, and logs together.

Custom Metrics and Cardinality

Custom metrics are counted as one per unique combination of metric name and tag values (including the host tag). With two endpoint values and two status values, request.Latency counts as four. Every metric sent from DogStatsD or a custom check is treated as custom, so using values that grow without bound, such as request IDs, as tags makes the count explode and directly affects billing. In containers, you choose the cardinality from low (kube_namespace), orchestrator (pod_name), or high (container_id); the default is low.

Check your understanding

Check what you have learned with 5 questions