Choose how to ingest data into Dynatrace

Latest Dynatrace
Explanation
4-min read
Published Jun 22, 2026

Data doesn't go directly from your environment into dashboards. It passes through a processing layer that shapes how it lands in storage and becomes available for analysis and action.

Choosing the data ingestion method that's right for you mainly depends on:

What you're running
Whether you can install software on it
What you're already using
How you want to instrument

If you already know how you want to ingest data, go directly to Ingest data into Dynatrace and select your method.

Concepts

Workloads and services

Workloads and services need different ingestion approaches; most environments contain both.

Category	Definition	Monitoring path	Examples
Workload	Infrastructure or processes you own and control. You can install software, add code, or run an agent alongside them.	OneAgent, OpenTelemetry, or both, depending on platform and constraints	Linux server, Kubernetes pod, Docker container, a Lambda function you wrote
Service	Infrastructure managed by a cloud provider. You consume it but can't install anything on the underlying process.	Cloud integrations only: a cloud provider's API is the only access point	AWS RDS, Azure SQL, Google Cloud Storage, Amazon SQS

OneAgent, Dynatrace Operator, and ActiveGate

These are tools, not ingestion choices. Understanding what each one does helps you follow setup guides without confusing the tool with the path.

Tool	What it does	When you use it
OneAgent	The monitoring agent that runs on your host or container and collects metrics, logs, traces, and topology automatically	Servers, VMs, Docker hosts, Kubernetes nodes (deployed via the Operator on K8s)
Dynatrace Operator	Manages OneAgent deployment on Kubernetes clusters; handles rollout, upgrades, and configuration across all nodes	Any Kubernetes environment; it's how OneAgent is deployed on K8s, not an alternative to it
ActiveGate	A connectivity and routing component; proxies traffic from agents to Dynatrace, and enables monitoring of cloud services and synthetic tests in restricted networks	Environments that can't reach Dynatrace directly, or cloud integrations that require a local polling point

Choose an ingestion path

1. What are you running?

What you have	What it means	Recommended path
Server or VM	Physical or virtual machines you manage, including Linux, Windows, AIX, Solaris, and z/OS	See Can you install software on it?
Kubernetes cluster	Orchestrated containers on a K8s cluster: any cloud provider or self-managed	Kubernetes
Containers or PaaS platform	Docker on a host, Cloud Foundry, Heroku, Azure App Service; not orchestrated by Kubernetes	Containers and PaaS
Serverless function	AWS Lambda, Azure Functions: no persistent process for OneAgent to attach to	AWS Lambda or Azure Functions
Cloud-managed service	AWS RDS, Azure SQL, GCP services: the cloud provider runs the process; you consume it	Amazon Web Services, Microsoft Azure, or Google Cloud Platform
Custom or unsupported technology	No agent or SDK exists for your data source; you need to push custom metrics, logs, or events	Extend and customize

2. Can you install software on it?

For most environments, this is already answered in step 1. But what if the environment looks like a workload but you can't deploy an agent on it?

Environment	Constraint	Implication
ECS Fargate	No daemon can run on the host; Fargate manages the underlying infrastructure	Use OpenTelemetry SDKs in your application code
Azure Functions on Consumption or Premium plan	Ephemeral execution environment; no persistent process for OneAgent to attach to	Use OpenTelemetry; see Azure Functions for language-specific guides
Containers in a locked-down or read-only environment	Host-level OneAgent deployment blocked by policy or access model	OpenTelemetry travels with the container image and doesn't require host access
All other workloads	Agent deployment is possible	See What are you already using?

3. What are you already using?

Your existing stack can confirm or override the recommendation for your environment. If you have an existing investment that covers your needs, you often don't need to change your instrumentation at all.

What you have	What it means	Recommended path
Nothing yet (greenfield)	No existing instrumentation or monitoring investment	OneAgent, but see Still haven't decided?
OpenTelemetry SDKs already in your code	Instrumentation is done; you only need to configure where to send data	OpenTelemetry: configure OTLP export, no re-instrumentation needed
AWS CloudWatch, Azure Monitor, or GCP Operations	Cloud-native monitoring already captures metrics and logs; Dynatrace connects to these APIs	Amazon Web Services, Microsoft Azure, or Google Cloud Platform; no code changes required
Prometheus metrics	Your services already emit Prometheus-format metrics	Extend and customize: Dynatrace can scrape Prometheus endpoints
A technology with no SDK or agent coverage	Neither OneAgent nor any OTel SDK supports your data source	Extend and customize: build an extension or push data via the ingestion APIs

4. Do you need more than one approach?

Some environments require multiple ingestion approaches simultaneously. This isn't a problem to solve; it reflects the reality that workloads and services need different methods, and different parts of an environment may have different constraints.

Scenario	Paths required	Note
Kubernetes on EKS	Kubernetes + Amazon Web Services	The Kubernetes section covers your workloads; Amazon Web Services covers managed services in the same account (RDS, S3, SQS, and similar)
Kubernetes on AKS	Kubernetes + Microsoft Azure	The Kubernetes section covers your workloads; Microsoft Azure covers managed services (Azure SQL, Blob Storage, and similar)
Kubernetes on GKE	Kubernetes + Google Cloud Platform	The Kubernetes section covers your workloads; Google Cloud Platform covers managed services (Cloud SQL, Cloud Storage, and similar)
EC2 instances alongside managed AWS services	OneAgent + Amazon Web Services	Servers section covers EC2 workloads; Amazon Web Services covers what AWS manages on your behalf
OneAgent on hosts, OTel in a specific service or library	OneAgent or Kubernetes + OpenTelemetry	OneAgent handles infrastructure and autoinstrumentation; OTel handles application-level spans you want to control explicitly; Dynatrace correlates both

5. Still haven't decided?

For undecided greenfield deployments, we recommend OneAgent. OpenTelemetry is equally valid but requires explicit instrumentation work and produces less automatic context: no topology discovery, and no code-level traces without additional configuration. If you have no existing constraints, OneAgent reaches value faster.

Approach	What you get	Best when
Automatic: OneAgent	Full-stack observability with no code changes: metrics, logs, traces, service topology, AI-powered anomaly detection, and code-level visibility from day one	You want the fastest path to value; your environment is greenfield; you have no instrumentation to preserve
SDK-based: OpenTelemetry	Vendor-neutral telemetry you define and control; works in any environment regardless of agent support; portable across observability backends	You prefer open standards; you have specific instrumentation requirements; you want to control exactly what gets measured

What happens after ingestion?

Your data flows through OpenPipeline before it reaches Dynatrace for analysis. Default pipelines handle your data automatically; you don't need to configure anything to get started.

Question	Answer
Is OpenPipeline configuration required now?	No. Default pipelines handle your data automatically.
When would a custom pipeline be useful?	When you need to filter sensitive fields before storage, drop records or store data with custom retention time, enrich records with business context, or normalize signal formats.