What Is Datadog?

The idea in one sentence

Datadog is one SaaS backend that a lightweight Agent (or an OpenTelemetry pipeline — proven below, no Datadog-specific SDK required) feeds with tagged telemetry, and every product you see in the UI — Infrastructure Monitoring, Log Management, APM, RUM, Synthetics, Cloud Security, CI Visibility, Agent Observability — is really just a different lens over that same stream of data.

One platform, several products

Most teams meet Datadog one product at a time — someone installs the Agent for host metrics, someone else turns on APM, someone else starts shipping logs. It’s easy to assume these are separate tools that happen to share a login. They aren’t. Underneath, there is exactly one thing arriving at Datadog’s backend: telemetry with tags attached to it. Metrics, logs, traces, and process snapshots are different shapes of that telemetry, but they share the same tagging model, the same organization, and the same billing account.

That single backend is what powers the full product family (confirmed against docs.datadoghq.com’s own navigation index):

• Infrastructure Monitoring — host and container metrics, the Host Map, resource-level dashboards.
• APM (Application Performance Monitoring) — distributed traces, the service map, latency and error-rate views.
• Log Management — collection, processing pipelines, indexing, and search over log events.
• RUM (Real User Monitoring) — Browser RUM and Mobile RUM: real end-user session/view/action/error events from actual browsers and apps, not synthetic checks.
• Synthetic Monitoring — scripted, scheduled checks (API tests, browser tests) that probe your systems the way RUM observes real users, but on a schedule instead of waiting for traffic.
• Cloud Security — misconfiguration/posture scanning and runtime threat detection, marketed today under the umbrella Cloud Security Management (CSM).
• CI Visibility — pipeline and test-run observability for CI systems, correlating flaky tests and slow builds back to the same services.
• Agent Observability — monitoring, troubleshooting, and evaluating LLM-powered applications (chatbots, agents). Real, current docs fact worth calling out explicitly: docs.datadoghq.com/llm_observability/ is the product formerly (and still commonly, in older material and AI training data) called “LLM Observability” — the product itself now presents as Agent Observability. If you see “LLM Observability” in a prompt, docs snippet, or generated code, treat it as the same product under a renamed umbrella, not a separate one.
• Monitors & SLOs — alerting rules and error-budget tracking evaluated over any of the above.
• Software Catalog — a directory of services that ties ownership metadata back to the same metrics, logs, and traces.

None of these are bolt-on tools with their own storage silo. They’re views. The reason this matters practically: when you improve your tagging once (the next lesson in this module covers this in depth), every one of these views gets better at the same time — you are not re-configuring eight products, you’re configuring one data model.

The Agent and the backend

The Agent is a small piece of software you run next to your infrastructure — on a host, as a container, or as a Kubernetes DaemonSet. Its job is narrow: collect data locally and ship it to the Datadog backend over HTTPS. It does not render dashboards, evaluate monitors, or store history — all of that lives in Datadog’s SaaS backend, which is why the Agent itself stays lightweight and disposable. The Agent is not the only front door, though — proven below, the Agent can also accept telemetry over the vendor-neutral OTLP protocol, not just its own native protocols.

flowchart LR
    Host["Host / Container"] -->|metrics, checks| Agent
    App["Instrumented app (Datadog tracer)"] -->|traces| Agent
    OTelApp["Instrumented app (OpenTelemetry SDK)"] -->|OTLP grpc/http| Agent
    Files["Log files"] -->|logs| Agent
    Agent -->|HTTPS intake| Backend["Datadog Backend (one site)"]
    Backend --> Infra["Infrastructure Monitoring"]
    Backend --> Logs["Log Management"]
    Backend --> APM["APM"]
    Backend --> Mon["Monitors / SLOs"]
    Backend --> Cat["Software Catalog"]

Where telemetry comes from

OpenTelemetry and OTLP ingestion

Every prior section describes the Datadog-native path: Datadog’s own Agent, Datadog’s own tracer libraries. A large and growing share of AI-generated instrumentation code defaults to the OpenTelemetry SDK instead (@opentelemetry/sdk-node, opentelemetry-instrument, OTEL_EXPORTER_OTLP_ENDPOINT) — vendor-neutral, not Datadog-specific. Datadog supports this path natively, two ways: the Agent can receive OTLP directly, and a standalone OpenTelemetry Collector can export to Datadog.

The Agent as an OTLP receiver — proven with a real config

Enabling otlp_config in datadog.yaml turns the Agent itself into an OTLP gRPC/HTTP receiver, no separate Collector required:

datadog.yaml

api_key: "<DD_API_KEY>"
site: "datadoghq.com"

otlp_config:
  receiver:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

Mounted into a real datadog/agent:7 container, agent status confirms it actually turned on — not just accepted the YAML key:

$ docker exec dd-otlp agent status
...
  feature_otlp_enabled: true
...
====
OTLP
====

  Status: Enabled
  Collector status: Running

feature_otlp_enabled: true in the Metadata section and the dedicated OTLP status block (Status: Enabled, Collector status: Running) are two independent confirmations from the same real container that the receiver is live on 4317/4318, ready for any OpenTelemetry SDK pointed at it with OTEL_EXPORTER_OTLP_ENDPOINT=http://<agent-host>:4318.

The Datadog Exporter in an OpenTelemetry Collector

The other supported path skips the Agent entirely: an OpenTelemetry Collector (otel/opentelemetry-collector-contrib, real pulled version 0.161.0) with the Datadog Exporter built in, forwarding straight to Datadog’s intake:

otel/collector.yaml

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  datadog:
    api:
      key: "${env:DD_API_KEY}"
      site: datadoghq.com

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]

Validated for real with the Collector binary’s own validate subcommand (not a schema guess — the actual Go config loader the Collector runs on startup):

$ docker run --rm -e DD_API_KEY=<fake> \
    -v "$PWD/collector.yaml":/etc/otelcol-contrib/config.yaml:ro \
    otel/opentelemetry-collector-contrib:latest \
    validate --config=/etc/otelcol-contrib/config.yaml
$ echo $?
0

The Datadog exporter’s API key field is nested (api.key), a shape that is easy to get wrong from memory — a flat apikey: key is a real, common mistake, and the same validate command rejects it immediately, real error text:

Error: exporters::datadog: api.key is not set

Semantic convention mapping

OpenTelemetry and Datadog both eventually want a service/env/version triad, but they don’t start with the same attribute names. Per docs.datadoghq.com/opentelemetry/schema_semantics/semantic_mapping/: OTel’s service.name maps to Datadog’s service tag, service.version maps to version, and deployment.environment.name maps to env — that last one specifically replaces the older, now-deprecated deployment.environment convention, and requires Datadog Agent 7.58.0+, Datadog Exporter v0.110.0+, or direct OTLP intake to be mapped correctly. This is the same service/env/version trio the next lesson covers in depth for unified service tagging — this section only covers how an OTel-instrumented app’s attributes land in that same model, not the full tagging story.

Full internals — the OTLP ingest path inside the Agent, exporter semantics, and the complete semantic-convention table — are covered in OTLP and Open Standards.

Sites and regions

A Datadog organization does not float freely across the internet — it lives in exactly one site (Datadog’s term for a region), such as US1, US3, US5, EU1, or AP1. The site you’re on determines the hostnames your Agent and API calls must use — for example a US1 org talks to api.datadoghq.com, while an EU1 org talks to api.datadoghq.eu. Point an Agent at the wrong site’s intake and it will authenticate against the wrong backend entirely — this is one of the most common first-day setup mistakes, and it’s worth checking your site explicitly rather than assuming.

# datadog.yaml (Agent main config) — site must match your org
api_key: "<DD_API_KEY>"
site: "datadoghq.eu"   # e.g. datadoghq.com (US1), datadoghq.eu (EU1), us3.datadoghq.com, ap1.datadoghq.com

API keys vs. Application keys

These two credential types get confused constantly because both are just strings you paste somewhere, but they authorize completely different things:

• An API key authorizes submitting data — it’s what the Agent puts in its config so it can send metrics, logs, and traces to Datadog. It is scoped to your organization, not to any individual person.
• An Application key authorizes acting as a user — it’s paired with a specific user’s permissions and is used to call Datadog’s read/management APIs (querying metrics, creating dashboards, managing monitors via API or Terraform). If that user is deactivated or loses permissions, anything using their Application key loses that access too.

A simple rule of thumb: if you’re configuring something to send data into Datadog, you need an API key. If you’re writing a script or Terraform provider that needs to read or manage Datadog resources on someone’s behalf, you need an Application key alongside an API key.

# Typical pairing for a script that talks to Datadog's API
export DD_API_KEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
export DD_APP_KEY="yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
curl -X GET "https://api.datadoghq.com/api/v1/validate" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -H "DD-APPLICATION-KEY: ${DD_APP_KEY}"

🐶 The one-line takeaway

Datadog is one backend, one tagging model, many product views — Infrastructure, APM, Logs, RUM, Synthetics, Cloud Security, CI Visibility, and Agent Observability (the current name for what used to be called LLM Observability) all read from the same tagged telemetry stream. That stream can arrive via the Datadog-native Agent/tracers or via vendor-neutral OTLP — proven above, both the Agent’s own otlp_config receiver and a standalone OpenTelemetry Collector’s Datadog Exporter are real, current, supported ingestion paths. An API key lets telemetry in; an Application key lets an authenticated user’s scripts and tools read or manage Datadog resources afterward.

Reading AI-generated code

🐛 Spot the bug

# AI comment: "Send OTel Collector traces straight to Datadog"
receivers:
otlp:
  protocols:
    grpc:
      endpoint: 0.0.0.0:4317

exporters:
datadog:
  apikey: "${env:DD_API_KEY}"
  site: datadoghq.com

service:
pipelines:
  traces:
    receivers: [otlp]
    exporters: [datadog]

Show the answer

This is a completely plausible OpenTelemetry Collector config — real receiver, real exporter name, real pipeline wiring. The bug, proven above with the real Collector binary’s own validate command: the Datadog exporter’s API key field is nested (api: { key: ... }), not a flat apikey: top-level key. validate rejects this exact config with Error: exporters::datadog: api.key is not set — the Collector fails at startup, not silently at runtime, which is the one piece of good news here, but it still means zero traces reach Datadog until the shape is fixed to api.key.

Mental Model

Think of Datadog’s backend as a single warehouse with one tagged intake conveyor belt, not eight separate warehouses. Every product — Infrastructure, APM, Logs, RUM, Synthetics, Cloud Security, CI Visibility, Agent Observability — is a different window looking into the same warehouse, filtered by what kind of telemetry (and which tags) that window cares about. The conveyor belt itself accepts freight in two dock formats: Datadog’s own native format (Agent, Datadog tracers) or the vendor-neutral OTLP format (proven above, both directly into the Agent and via a Collector) — both formats end up on the same belt, tagged the same way, visible in the same windows.

Trade-offs

• Datadog-native Agent/tracers vs. OpenTelemetry SDK + OTLP — Datadog-native gets you Datadog-specific features first (some integrations, some UI features ship for the native path before the OTel path catches up) and slightly simpler defaults; OpenTelemetry gets you vendor neutrality (swap backends without re-instrumenting) and one instrumentation story across multiple observability vendors, at the cost of needing the semantic-convention mapping proven above to land cleanly in Datadog’s service/env/version model.
• OTLP straight into the Agent vs. through a standalone Collector — sending OTLP directly to the Agent (proven above) is one fewer moving part to deploy and operate; a standalone Collector adds an extra hop but centralizes processing (sampling, filtering, fan-out to multiple backends) outside any single vendor’s agent, which matters once you’re sending the same telemetry to more than one place.
• docs.datadoghq.com/llm_observability/ naming — sticking with the URL/product-family name “LLM Observability” in your own docs is more searchable and matches years of existing external material; using the current “Agent Observability” name matches what a user actually sees in the Datadog UI today. Neither is wrong, but mixing them in the same document without noting they’re the same product (as this lesson does explicitly) is confusing.

Common Misconceptions

• “Datadog is a suite of separate products.” No — proven above, by design: a change to your tagging model (or turning on a new product) is a lens on the same backend, not a resync between separate tools.
• “You need Datadog’s own tracer/SDK to get data into Datadog.” No — proven above with a real Agent (feature_otlp_enabled: true, OTLP status Enabled/Running) and a real OTel Collector config (validate exit 0): plain OpenTelemetry instrumentation reaches Datadog through two real, current, supported paths.
• “LLM Observability and Agent Observability are two different products.” No — confirmed directly from docs.datadoghq.com/llm_observability/: that URL’s product now presents itself as “Agent Observability.” Older material (and a lot of AI training data) still says “LLM Observability” for the same thing.
• “An API key and an Application key are interchangeable, or the same key does both.” No — proven by their distinct purposes above: an API key only lets telemetry in; an Application key authorizes reading/managing resources as a specific user, and using the wrong one for a Terraform/script call fails outright.

Why do Infrastructure Monitoring, APM, and Log Management all improve when you fix your tagging once?

They are separate products with separate storage, so tagging must be fixed in each one manually They are different views over the same tagged telemetry stream on one backend, so better tags help every view at once Tagging only affects Infrastructure Monitoring Tagging is applied per-dashboard, not per-product

What is the CURRENT, docs-confirmed name for the Datadog product that monitors and evaluates LLM-powered applications like chatbots?

LLM Observability (this is still the current, only name) Agent Observability -- confirmed directly from docs.datadoghq.com/llm_observability/, which now presents the product under this name AI Application Monitoring Cloud Security Management

Proven above with a real datadog/agent:7 container, what does enabling otlp_config in datadog.yaml actually turn on?

Nothing -- otlp_config is not a real Agent config key A real OTLP gRPC/HTTP receiver inside the Agent itself, confirmed via agent status: feature_otlp_enabled: true and an OTLP section reading Status: Enabled / Collector status: Running It only works if you also install a separate OpenTelemetry Collector It replaces the Agent's own trace receiver on port 8126

Proven above with the real otelcol-contrib validate command, what happens when an OpenTelemetry Collector's Datadog exporter config uses a flat apikey: field instead of the correct nested shape?

It works identically -- apikey and api.key are aliases validate fails immediately with the real error "exporters::datadog: api.key is not set", because the Datadog exporter requires the nested api.key field It silently sends data unauthenticated The Collector falls back to reading DD_API_KEY automatically regardless of config shape

Per docs.datadoghq.com/opentelemetry/schema_semantics/semantic_mapping/, which OpenTelemetry attribute maps to Datadog's env tag, and what does it replace?

service.name -- replaces service.namespace deployment.environment.name -- replaces the deprecated deployment.environment convention, requires Agent 7.58.0+ / Datadog Exporter v0.110.0+ / direct OTLP intake k8s.namespace.name -- replaces deployment.environment There is no mapping; env must be set manually with a separate resource attribute

You are writing a Terraform provider config that needs to create and manage Datadog monitors. Which credential(s) do you need?

Only an API key Only an Application key Both an API key and an Application key Neither — Terraform uses the Agent's local config

Submit

Mark as complete