The Datadog Live View is your real-time window into what’s actually happening inside your containers and on your hosts, not just what your dashboards think is happening.
Let’s see it in action. Imagine you’ve got a Kubernetes cluster, and you’re curious about a specific pod.
# This is a conceptual command, Datadog's UI is where you'd interact
# but imagine this is how you'd ask the system for live data:
datadog-cli container list --filter 'kubernetes.pod_name:my-web-app-7b8c4d9f-xyz12'
This would yield output that looks something like:
[
{
"id": "abcdef1234567890",
"image": "nginx:latest",
"name": "my-web-app-7b8c4d9f-xyz12-container-0",
"state": "running",
"pid": 1,
"cpu_usage": {
"total_seconds": 123.45,
"user_seconds": 80.12,
"system_seconds": 43.33
},
"memory_usage": {
"rss_bytes": 56789012,
"cache_bytes": 12345678
},
"processes": [
{
"pid": 1,
"name": "nginx",
"cpu_percent": 0.5,
"memory_percent": 1.2,
"command": "/usr/sbin/nginx -g 'daemon off;'"
},
{
"pid": 5,
"name": "worker_process",
"cpu_percent": 0.1,
"memory_percent": 0.3,
"command": "worker_process"
}
]
}
]
This view isn’t about aggregated metrics; it’s about the ephemeral, the here-and-now. It tells you which containers are up, what processes are running inside them, and their immediate resource consumption (CPU, memory). The key is that this data is collected by the Datadog Agent directly from the host’s operating system and container runtime interfaces (like Docker’s API or Kubernetes’ CRI), bypassing the need for traditional metric collection pipelines for immediate visibility.
The problem Datadog Live View solves is the "black box" problem of containers and ephemeral infrastructure. When a pod crashes, or a service becomes unresponsive, you need to know exactly what was running, exactly when, and exactly why. Traditional monitoring might tell you CPU spiked or memory was high, but Live View shows you the specific process that was consuming resources, or the exact command line that was executed. It bridges the gap between infrastructure-level metrics and application-level behavior.
Internally, the Datadog Agent, when configured for Live Container and Process monitoring, leverages OS-level APIs and container runtime APIs to query this information. For Linux hosts, it might use /proc filesystem entries or cgroup information. For container runtimes like Docker or containerd, it queries their respective APIs for container status, PIDs, and resource usage. Kubernetes integration allows it to correlate this host-level data with Kubernetes metadata (pod names, labels, namespaces). The "Processes" section is particularly powerful, as it’s not just showing the main container process, but all processes running within that container’s PID namespace.
You control the granularity of this view through the Datadog Agent configuration. Specifically, the process_agent.enabled setting in your datadog.yaml (or equivalent for containerized agents) turns on the process collection. You can further fine-tune what gets collected using include_process_commands and exclude_process_commands to filter by command line arguments, or include_containers and exclude_containers to focus on specific workloads. The dd-agent.conf file for older agent versions or the conf.d/process.d/conf.yaml file for newer, modular agents are where these settings live. For example, to ensure you’re only collecting process data for containers tagged with env:prod, you’d add to your process.d/conf.yaml:
init_config:
instances:
- include_containers:
- 'tags:env:prod'
This ensures that the agent is actively querying the OS and container runtime for process information on a per-container basis. The data is then sent to Datadog’s backend, where it’s indexed and made available for real-time exploration.
The most surprising thing is that the "Processes" tab in Datadog Live View isn’t just showing the main entrypoint of your container. It’s showing every process that the Datadog Agent can see within that container’s PID namespace, including background workers, helper scripts, and even shells that might have been spawned interactively. This means you can spot rogue processes or unexpected forks that might be impacting performance or security, even if they aren’t directly part of your application’s main CMD or ENTRYPOINT.
The next step you’ll likely want to take is correlating this live process data with security signals or performance anomalies detected by other Datadog features.