Datadog Fundamentals key terms

Lightweight software installed on hosts that collects metrics, logs, and traces and forwards them to Datadog. It runs checks on a schedule and can be configured locally or centrally through the platform.

Any physical or virtual machine, or container node, that reports data to Datadog. Hosts are identified by hostname and typically counted against per-host billing and licensing limits.

A key-value label attached to metrics, logs, traces, or other data so you can filter, group, and aggregate in queries, dashboards, and monitors. Datadog also applies reserved tags automatically.

A Datadog configuration that connects a third-party technology such as AWS, Kubernetes, or PostgreSQL so its metrics, logs, or events are collected, often through the Agent or a cloud API crawler.

A metrics aggregation protocol bundled with the Datadog Agent that accepts StatsD-style packets and adds Datadog-specific features such as tags, histograms, service checks, and distribution metrics.

An Agent capability that watches container runtimes for new workloads and applies configuration templates from labels or files, so checks are scheduled automatically without manual Agent edits.

A specialized Datadog Agent deployed in Kubernetes clusters that centralizes cluster-level metadata and check scheduling, reducing load on node Agents and enabling cluster checks and orchestration metadata.

An alert definition that evaluates a query or condition over time, covering metrics, logs, traces, or synthetic tests, and notifies the right people when a threshold, anomaly, or outage condition is met.

A scheduled period during which Datadog suppresses monitor notifications for a defined scope of hosts or tags. Used for maintenance windows so expected outages do not page responders.

The complete record of a single request as it travels through a distributed system, composed of spans arranged in a hierarchy and linked by a shared trace identifier.

A single timed operation inside a trace, such as a database query or outbound HTTP call, recording start time, duration, associated service and resource, status, and metadata tags.

A group of related traces from one application or workload, identified by the service name tag. Datadog aggregates latency, errors, and dependencies per service across all its instances.

Instrumentation that propagates trace context across service boundaries so spans produced by different services and hosts are stitched together into a single end-to-end request trace.

The setup that generates spans and traces, such as Datadog tracing libraries, Agent-based auto-instrumentation, or OpenTelemetry SDKs and collectors configured to send data to Datadog.

Settings that decide how much trace data is sampled at the tracing library and Agent level, helping teams control volume and cost while preserving visibility into errors and slow requests.

An APM rule that selects which ingested spans are kept beyond the default sampled set, based on service, resource, tags, or error status, so important traces remain queryable for the full retention period.

An APM feature that continuously samples code-level CPU, memory, and lock usage in production and associates profiles with services and traces, helping pinpoint expensive functions.

A Datadog feature that groups similar exceptions from logs and traces into issues, tracks frequency and first or last seen times, and links each issue to releases and relevant code.

An ordered set of processors that parse, enrich, and transform logs after ingestion and before indexing, allowing attributes to be extracted, sensitive fields removed, and logs routed or dropped.

A storage bucket for logs with its own retention period, daily quota, and exclusion filters. Which indexes a log enters determines whether and how long it can be queried.

A rule on a log index that drops all or a percentage of matching logs before indexing, based on a query, so high-volume low-value logs do not consume the index quota.

A custom metric generated from a log query that counts matching logs, optionally grouped by attributes such as status or endpoint, and can be used in dashboards and monitors.

A log attribute declared as a facet so it appears in the log explorer's facet list and can be used for search, grouping, and analytics, with values mapped to a specific data type.

Archives store all ingested logs long-term in cloud object storage. Rehydration temporarily reloads a filtered subset of archived logs into an index so older data can be queried.

A feature that scans logs, traces, and other ingested data for patterns such as credit card numbers or email addresses, then hashes, redacts, or masks the matches before they are broadly visible.

Standard log attributes Datadog uses for built-in behavior, such as host, service, source, status, and message. These populate standard columns and facets automatically when a log is ingested.

Collection of performance and error data from actual users' browsers and mobile apps, reporting views, sessions, actions, and resources that can be linked to backend traces.

A Real User Monitoring feature that records browser or mobile sessions as a replayable timeline of DOM and user events, helping debug issues while honoring privacy masking rules.

Proactive testing that runs scripted API and browser tests from managed or private locations on a schedule, alerting when availability, correctness, or performance degrades from a user's perspective.

A Synthetics worker you deploy and run inside your own network so browser and API tests can reach internal or private endpoints that Datadog's managed public locations cannot access.

Google's user-experience metrics for loading, interactivity, and visual stability that Datadog collects from real users, providing benchmarks and views of how pages actually perform.

Continuous assessment of cloud accounts and Kubernetes configurations against security benchmarks and custom rules, surfacing misconfigurations as findings with severity, context, and remediation guidance.

An Agent-based capability that monitors process, file, and network activity on hosts and containers at runtime to detect suspicious behavior and generate security signals for investigation.

A record of potential threat activity created when a detection rule matches observed events. Signals are grouped, triaged, and can trigger notifications, cases, or automated workflows.

Scanning of container images, hosts, and serverless functions for known vulnerabilities, prioritizing findings by exploitability, severity, and whether the workload handles sensitive data.

A registry of services with ownership, dependencies, and metadata, linking traces, on-call rotations, SLOs, runbooks, and dashboards so teams share one consistent view of their systems.

A reliability target for a service expressed as a ratio of good events to total events, such as 99.9 percent of requests served under 300 milliseconds, evaluated over a rolling window.

The amount of allowed unreliability implied by an SLO over its time window, calculated as 100 percent minus the target, used to decide whether to ship faster or prioritize reliability work.

The workflow for declaring, coordinating, and resolving incidents, including severity levels, responder paging, shared timelines, stakeholder updates, and post-incident review.

A permissions model that grants rights to roles and then assigns roles to users or teams, governing who can view or edit dashboards, monitors, logs, and administrative settings.