What is Dynatrace architecture
Step 1: Collect and Understand what monitored systems generate
Interview takeaway: Collection is about which signals exist. It is not the same as the method used to send them to Dynatrace.
Step 2: Capture data into Dynatrace
Dynatrace supports multiple capture and ingestion approaches:
- OneAgent runs on monitored hosts or workloads, discovers processes, and gathers supported infrastructure and application telemetry. With appropriate monitoring configuration, it provides deep application visibility and automatic tracing.
- OpenTelemetry instruments applications and exports supported telemetry to Dynatrace through configured OTLP ingestion paths.
- Dynatrace APIs and extensions ingest additional observability, infrastructure, security, or business data.
- Real User Monitoring (RUM) captures browser or mobile user experience when instrumented; Synthetic Monitoring performs configured active checks.
An Environment ActiveGate can act as a communication endpoint between monitored environments and Dynatrace SaaS. It is useful for connectivity and selected monitoring use cases, but OneAgent does not always require an ActiveGate; supported direct connectivity is also possible.
Interview takeaway: OneAgent is primarily a monitoring/data-collection agent. ActiveGate is a gateway/connectivity component, not a replacement for OneAgent or the Grail database.
Step 4: Store and query with Grail
Grail is Dynatrace's unified data lakehouse for observability, security, and business data. According to Dynatrace documentation, its architecture separates ingest and processing, storage, and query processing. OpenPipeline routes processed data into Grail buckets; Grail then makes the stored records available for querying and analysis under the applicable permissions.
For SREs, the benefit is the ability to investigate logs, spans, events, and other supported data in a shared environment instead of manually comparing disconnected tools. Retention, permissions, access, and ingestion still depend on your environment's configuration.
Interview takeaway: Grail is the platform's storage and analytics foundation; OpenPipeline handles configurable data routing and preparation before storage.
Step 5: Analyse and Investigate performance and root cause
Once telemetry and relationships are available, Dynatrace provides several ways to analyse them:
- Dynatrace Intelligence / Davis AI: anomaly detection, causal root-cause analysis, and predictive capabilities, depending on the enabled features and available signals.
- Smartscape: a dynamic topology view of monitored entities and their dependencies. Smartscape on Grail represents entities as nodes and relationships as edges.
- DQL (Dynatrace Query Language): a query language for exploring and transforming Grail data in dashboards, notebooks, and other supported interfaces.
A basic DQL investigation can count recorded error logs during the last 30 minutes:
fetch logs, from:now()-30m
| filter loglevel == "ERROR"
| summarize error_count = count()
The query counts ingested logs marked ERROR; it does not automatically equal the service's failed-request count. Log fields, available datasets, and access depend on the environment.
Interview takeaway: Dynatrace not only displays that a metric crossed a threshold; it can correlate available signals and dependencies to help narrow down a probable cause. Engineers should still validate the findings.
Step 6: Automate findings into controlled actions
AutomationEngine powers Dynatrace workflows. Based on configured triggers and permissions, a workflow can notify the right team, create or update an incident through an integration, gather diagnostic information, or run approved remediation actions. AppEngine provides a way to build and run custom Dynatrace apps; it is a related platform capability, not simply an alert-delivery service.
A responsible SRE team starts with notifications and evidence collection. Any action that changes production, such as restarting a process or changing capacity, should follow predefined approvals, access controls, safeguards, and verification.
Interview takeaway: Dynatrace supports automation, but automatic remediation does not happen by default. Engineers define the triggers, integrations, decision rules, and permitted actions.
Step 7: Solve and put the insight in the hands of the right team
The final stage is the consumer's outcome, not a separate ingestion engine. SRE and observability teams use the information to protect reliability and user experience; security teams investigate exposure or threats; business teams understand service impact; and organisations can create tailored use cases with custom apps.
For example, an SRE may confirm that API latency is caused by slow database calls, involve the database owner, track recovery in service health views, and document corrective actions. Dynatrace can help connect the evidence, but the team's operational decisions still matter.
Interview takeaway: The architecture is valuable when data produces a clear decision, faster diagnosis, or safer operational response.
End-to-end example: An e-commerce checkout API becomes slow
Imagine customers report that checkout takes eight seconds instead of two. Here's how to apply the architecture without guessing the cause:
- Collect: The checkout application generates response-time metrics, traces, and logs.
- Capture: OneAgent or configured OpenTelemetry instrumentation exports supported signals to Dynatrace.
- Contextualise: The signals carry service identifiers and request relationships; configured OpenPipeline processing structures ingested records.
- Process: Ingested data is stored in Grail and becomes available for authorised analysis.
- Analyse: Dynatrace Intelligence, Smartscape, PurePath, and DQL help identify whether a downstream call, code path, or infrastructure dependency contributes to the slowdown.
- Automate: A configured workflow can notify on-call staff, open an incident, and attach evidence. Production remediation requires the team's defined safeguards.
- Solve: The owner fixes the confirmed issue, and the SRE verifies latency, errors, and user experience have returned to an acceptable level.
