Infrastructure Monitoring
Start from the Agent
The Datadog Agent (v7) is a host-level daemon that collects system metrics, runs integration checks under /etc/datadog-agent/conf.d/, and forwards metrics, logs, and traces to the platform. Metrics reach Datadog either through the Agent (including DogStatsD for custom metrics) or directly through the HTTP API. Contrast this with cloud integrations (AWS, Azure, GCP), which poll provider APIs without any Agent - a frequent distractor in questions asking "what must be installed to monitor X".
Metric types are immutable
Know the five submission types: gauge, count, rate, histogram, and distribution. Once a metric name is submitted with a type, that type is fixed; changing it later splits or corrupts the series. Counts are submitted as deltas and converted with an interval, gauges report the latest value - questions often hinge on that distinction.
Tagging and cardinality
Tags are key:value pairs applied at the host, integration, or submission level. Tag unification merges host tags from different sources, and env powers Host Map scoping and unified service tagging (env, service, version). Custom metric billing scales with the number of distinct tag combinations (time series), so high-cardinality tags such as pod_name, request_id, or user_id are the classic cost trap. Use the Estimated Usage page and Metrics Summary to audit.
Container visibility
Autodiscovery templates (container labels/annotations with %%host%%, %%port%% variables) let one Agent monitor dynamic container workloads; the Host Map only shows hosts that actually report to Datadog, so cloud-integrated hosts appear only through cloud metadata.
Worked rule of thumb: a check emitting requests.count with 4 services × 25 endpoints × 30 pods creates 3,000 series from one metric name; replacing pod_name with kube_deployment typically collapses that to about 100.