Datadog Fundamentals common mistakes
Datadog Fundamentals · Understand the traps and how to avoid them.
Memorizing that the Datadog Agent collects infrastructure metrics, then assuming API-based cloud integration metrics such as AWS load balancer metrics will automatically carry the same host tags and be queryable by host.
Datadog ingests infrastructure data through multiple paths; Agent checks and cloud-provider integrations attach different tag sets and dimensions.
What to do instead
For each metric, identify whether it comes from the Agent, a cloud integration, or another source; use the correct integration dimensions and tag enrichment instead of assuming host tags are present.
Submitting a monotonically increasing request counter as a gauge metric and then expecting Datadog to calculate a rate or correctly aggregate it across hosts.
Metric types define how the Agent and platform aggregate and display values; count, rate, and gauge have different semantics.
What to do instead
Learn when to use count, rate, and gauge, and verify how each type is aggregated before building dashboards or monitors on it.
Enabling APM in the Datadog Agent and then expecting traces to appear for an application service that has no tracing library or instrumentation configured.
The Agent can receive traces, but the application must be instrumented to generate and send them.
What to do instead
Distinguish Agent-side APM setup from application instrumentation; confirm tracing is configured for each service and that traces reach the Agent.
Tagging APM data with only a service name and omitting environment and version, then trying to compare deployments or isolate traces by environment.
Unified service tagging relies on consistent env, service, and version tags across telemetry, and missing tags break correlation and filtering.
What to do instead
Apply env, service, and version consistently across APM, logs, and infrastructure data, and use those reserved tags in queries and dashboards.
Assuming every log sent to Datadog is immediately indexed, searchable in Log Explorer, and retained for the same duration.
Log Management separates ingestion from indexing; exclusion filters, indexes, and retention settings determine what is queryable and for how long.
What to do instead
Study the log pipeline from ingestion through indexes and retention, and verify which index and filters a query depends on before troubleshooting missing logs.
Building a log-based monitor on a query that depends on a log stream excluded from indexes, then concluding that log monitoring is broken when no alerts fire.
Monitors and queries operate on indexed data unless specifically configured otherwise, so excluded or unindexed logs may not be evaluated as expected.
What to do instead
Check index configuration, exclusion filters, and monitor query scope before creating the monitor; use a query against indexed logs or adjust indexing.
Using Synthetics browser tests to measure real-user page performance and RUM to check endpoint uptime from external locations.
RUM and Synthetics serve different digital experience monitoring purposes: real-user observation versus proactive synthetic checks.
What to do instead
Map RUM to real user sessions and frontend performance, and Synthetics to proactive API, browser, and uptime testing from controlled locations.
Assuming Cloud SIEM will detect threats in cloud audit logs without forwarding those logs or enabling the relevant cloud integration.
Security signals depend on ingested data sources and enabled detection rules; the platform cannot analyze logs it does not receive.
What to do instead
Identify the required log sources and integrations for each security capability, confirm ingestion, and then validate that the relevant detection rules are enabled.
Treating an SLO as if it were an alerting monitor and expecting it to page someone automatically when the error budget is consumed.
SLOs track reliability objectives and error budgets, while monitors perform alerting; they are related but distinct platform features.
What to do instead
Use SLOs to define and track objectives, and create separate monitors, such as burn-rate or error-budget monitors, when alerting is required.
Confusing dashboards with monitors by expecting a dashboard graph to notify on-call, or using a monitor as the primary long-term trend visualization.
Dashboards visualize data, while monitors evaluate conditions and trigger notifications; each has a different role in the platform.
What to do instead
Use dashboards for visualization and investigation, and configure monitors with appropriate thresholds, evaluation windows, and notification targets for alerting.