Skip to main content
In this lesson we examine Datadog’s architecture and the platform components that make the observability solution work end-to-end. Although Datadog is presented as a single Software-as-a-Service (SaaS) console, the platform is composed of several integrated parts: local collectors (Agents), cloud and system Integrations, and APIs that enable custom logic, ingestion, and checks. These components work together to collect, process, store, and surface telemetry (metrics, logs, traces, and profiles).
The image illustrates the architecture of Datadog, featuring the Datadog Console (SaaS) and its installed components: Agent, APIs, and Integrations.

​
Delivery models: SaaS vs Self-hosted

When evaluating observability platforms you’ll encounter two common delivery models: Choose based on technical, compliance, and operational requirements: latency, data residency, control of infrastructure, and security posture are common decision drivers.

​
Core components and responsibilities

  • Datadog Console (SaaS): Central UI, dashboards, alerting, and control plane.
  • Agents: Lightweight collectors that gather metrics, logs, traces, and continuous profiles from hosts, containers, and serverless runtimes.
  • Integrations & APIs: Cloud, database, and third-party system connectors; public APIs for custom ingestion, checks, and automation.
  • Clients: Engineers and responders use browsers and mobile apps to view dashboards, receive alerts, and manage incidents.
Table — Core components at a glance: Datadog supports telemetry from containerized applications, serverless functions (AWS Lambda, Azure Functions), cloud platforms, on‑prem infrastructure, and frontend applications. Each source typically has a tailored collection method or a dedicated integration.
The image illustrates Datadog's architecture, showing data sources like frontend and cloud providers feeding metrics, logs, traces, and profiles into Datadog, which is accessed by clients on mobile and laptop and used by engineers.

​
Platform capabilities and observability features

Datadog ingests and correlates multiple telemetry types to provide holistic observability:
  • Metrics, logs, traces, and continuous profiling (correlated across dimensions).
  • UX monitoring: Real User Monitoring (RUM) for frontend performance and behavior.
  • CI/CD monitoring: pipeline and workflow observability.
  • LLM observability: monitoring of large language model usage and behavior.
  • Security tooling: SIEM, SOAR, code analysis, runtime security.
  • Cost monitoring: cloud cost insights and allocation.
  • Dashboards, alerting, incidents, metrics analytics, and notebooks.
Use these capabilities to connect incidents with root causes — trace to metric to log — for faster resolution.

​
How data reaches Datadog

Data collection typically begins with Agents and platform integrations:
  • Agents: Installed where telemetry originates (hosts, containers, or as binaries). For Kubernetes, deploy an Agent inside the cluster to collect node, pod, and service telemetry.
  • Serverless and cloud-native integrations: Some integrations collect telemetry without a persistent agent by using platform APIs or function-level instrumentation (e.g., Datadog’s Lambda Forwarder for AWS Lambda logs).
  • Ingestion pipelines: Datadog supports pre-ingestion processing, enrichment, and parsing rules so telemetry is normalized before storage and analysis.
Example: installing the Datadog Agent into a Kubernetes cluster (Helm):
After collection, telemetry is sent to the Datadog backend where it’s processed, stored, and surfaced in the Console and mobile clients.
The image illustrates Datadog's data workflow, showing how data from a cloud platform, database, and application are processed by an agent before being sent to Datadog.

​
Enterprise network considerations

Access and authentication:
  • Datadog is accessed over the public internet with standard browsers and the mobile app.
  • Integrate with your Identity Provider (IdP) for SSO and centralized access control to enforce corporate policies.
Egress, proxies, and firewall considerations:
  • Many organizations require outbound traffic to be routed through proxies or firewalls. Configure Datadog Agents and integrations to work through your proxy.
  • Verify required allowlists (hostnames, IPs) and TLS interception rules so agents can reach Datadog endpoints.

​
Sites, regions, and data residency

Datadog operates multiple sites/regions. Your site selection affects latency and compliance (data residency). Important points:
  • Site selection is persistent for an organization; data cannot be moved later.
  • Evaluate regulatory and business requirements (e.g., GDPR, data residency) before choosing a site.
The image is a table showing different Datadog site options, including site URLs, parameters, and their respective locations.
Carefully evaluate data residency and compliance requirements before choosing your Datadog site. The selection is persistent for your organization and cannot be changed later.

​
Summary

Datadog is a SaaS console backed by a distributed collection layer (Agents and Integrations) and public APIs. Understanding where and how telemetry is collected, the difference between agent-based and platform-native integrations, and the implications of networking and site selection will help you design an observability deployment that meets performance, security, and compliance goals. Further reading and references: That’s it for this lesson. I hope you found it useful.

Watch Video