Business-service view
Connect applications, APIs, databases, queues, cloud resources, and infrastructure to the business service they support. A host alert without service impact and ownership context is rarely enough.
IT Operations & Cybersecurity Encyclopedia
Dynatrace Infrastructure and Application Observability Guide
A practical guide for designing, deploying, governing, and validating Dynatrace across servers, cloud services, Kubernetes, applications, APIs, logs, traces, and real user journeys—without turning observability into another noisy or uncontrolled tool.
OneAgent & ActiveGate
Applications & infrastructure
OpenTelemetry & Grail
Privacy, IAM & cost control
Start with decisions, not agents
Define what Dynatrace must help the organization decide
Installing telemetry is not the same as creating observability. A successful implementation begins with critical business services, measurable user outcomes, accountable owners, incident workflows, and an agreed definition of acceptable evidence.
User-experience view
Measure the journeys that matter—sign-in, search, checkout, scheduling, upload, or payment—using real-user signals, synthetic tests, service telemetry, and dependency evidence where appropriate.
Operational response
Make each actionable problem reach the correct team with severity, affected scope, recent changes, supporting traces or logs, and a runbook. Tune noise before expanding coverage.
Governed consumption
Decide which telemetry is necessary, how long it should be retained, who may see it, and how costs are attributed. Unbounded collection creates privacy, security, and budget risk.
Implementation rule: Every production service placed in scope should have a defined owner, environment and criticality metadata, expected service-level indicators, a tested alert route, a privacy classification, and a documented telemetry budget.
Reference architecture
Understand the collection and context path before deployment
Dynatrace can combine automatically collected data with open telemetry and cloud integrations, but the collection method should be chosen deliberately. The official OneAgent monitoring-mode documentation distinguishes Full-Stack, Infrastructure, and Discovery modes. Full-Stack is designed for application performance visibility; Infrastructure mode focuses on detailed host and process data without application-level tracing and profiling; Discovery provides lighter availability and topology signals under eligible subscription models.
Sources
Hosts, VMs, containers, Kubernetes, serverless functions, databases, network devices, cloud services, browsers, mobile applications, APIs, logs, metrics, traces, and business events.
Collection
OneAgent, cloud-platform APIs, extensions, Real User Monitoring, Synthetic Monitoring, OpenTelemetry collectors or SDKs, log forwarders, and supported ingest APIs.
Routing and control
ActiveGate, network zones, proxies, private synthetic locations, filtering, masking, enrichment, sampling, and secure outbound communication paths.
Context and action
Topology, service detection, Grail, DQL, dashboards, notebooks, SLOs, problems, workflows, ownership, incident tickets, and controlled automation.
When OneAgent is appropriate
Use OneAgent when the organization needs automated host/process discovery, deep application visibility, supported runtime instrumentation, infrastructure data, topology, and correlated signals. Test process injection and restart requirements in a representative non-production environment. Confirm operating-system support, change-control expectations, resource impact, upgrade policy, network egress, proxy behavior, and endpoint-security compatibility before broad deployment.
Do not assume every host needs the same mode. Business-critical application tiers may justify Full-Stack monitoring, while shared utilities, network appliances, or low-risk systems may use another supported collection method. Document the reason for each monitoring tier.
When ActiveGate or open telemetry is needed
ActiveGate may provide controlled routing for OneAgents, cloud monitoring, extensions, remote technologies, private synthetic tests, or constrained network zones. Design redundancy and firewall paths around the specific ActiveGate capabilities in use. A single routing component should not silently become a visibility bottleneck.
Dynatrace also accepts OpenTelemetry Protocol data through SaaS or ActiveGate endpoints and can use a collector as an intermediary. Define resource attributes, service naming, sampling, batching, retry behavior, certificate trust, secret handling, and masking before sending production telemetry.
Coverage model
Map monitoring depth to business criticality
A dependable coverage map starts from the business application inventory, not from the list of hosts where an agent happens to be installed. Record the business owner, technical owner, users, support window, environments, dependencies, sensitive-data exposure, recovery requirements, and planned telemetry for each service.
| Layer | Minimum questions | Useful signals | Acceptance evidence |
|---|---|---|---|
| End-user journey | Which transactions define availability and customer impact? Are browser, mobile, and remote locations represented? | Real-user performance, JavaScript errors, mobile crashes, synthetic browser or HTTP checks, geographic and device context. | Named journeys, privacy settings, baseline performance, test location rationale, and a demonstrated failure alert. |
| Application and API | Can teams follow a request across service boundaries? Are service names stable and meaningful? | Latency, throughput, failures, distributed traces, spans, exceptions, code-level hotspots, deployment and version context. | Representative trace, service dependency path, failure-detection rules, owner metadata, and release correlation. |
| Data and messaging | Are slow database calls, queue delays, cache failures, and third-party dependencies visible? | Database service time, query behavior where permitted, connection health, queue depth, consumer lag, dependency latency and errors. | Dependency inventory, safe data-capture configuration, tested alert, and an escalation path to the responsible owner or vendor. |
| Compute and containers | Are capacity, saturation, process health, restarts, scheduling, and cluster changes observable? | CPU, memory, disk, network, process availability, container restarts, Kubernetes workload and node health, cloud resource events. | Coverage report, monitoring mode, cluster/namespace mapping, exception list, capacity thresholds, and maintenance-window behavior. |
| Network and edge | Can the team distinguish an application problem from DNS, routing, firewall, WAN, Wi-Fi, or local edge failure? | Network flow and connectivity evidence, extension metrics, device health, synthetic checks, ActiveGate status, packet-loss or latency context. | Documented telemetry path, network-zone design, monitored interfaces, failover test, and integration with network monitoring operations. |
| Cloud platform | Are accounts/subscriptions, regions, services, tags, quotas, and access boundaries represented consistently? | Provider metrics and events, service health, resource metadata, cloud logs, serverless traces, deployment events and cost context. | Cloud integration permissions, account coverage, tag standard, missing-resource report, and reviewed API-rate or ingestion limits. |
Observe the complete transaction
Connect user experience to services and infrastructure
Infrastructure health alone cannot prove that an application works. A server can appear healthy while a sign-in dependency, certificate, DNS record, API, database query, payment provider, or front-end script is failing. Conversely, an application alert can be caused by network loss, exhausted compute, storage latency, or a third-party service.
For each important user journey, define the expected path and the evidence needed at each boundary. Use real-user signals to understand actual experience and synthetic checks to test a repeatable path from chosen locations. Connect those results to service traces, dependency health, change events, logs, and infrastructure signals. The goal is not maximum data; it is enough trustworthy context to isolate the fault and explain business impact.
- Choose journeys with an owner and business outcome.
- Exclude or mask personal and confidential data.
- Test normal, slow, failed, and dependency-error paths.
- Set thresholds from service objectives and baselines.
- Correlate releases, configuration changes, and incidents.
- Validate from user locations that matter.
Controlled implementation
Dynatrace deployment and validation runbook
Use a pilot to prove collection, privacy, alerting, ownership, cost, and rollback before expanding. Record the approved settings and evidence at every step.
Define scope and success
Select one representative business service with known owners, a test environment, real dependencies, a support team, and measurable user outcomes. Record the questions Dynatrace must answer and the incident scenarios it must detect.
Design data and access
Classify telemetry, decide what must never be captured, set masking and retention requirements, map user groups and service identities, and establish approval for agents, browser monitoring, session replay, logs, and integrations.
Prepare connectivity
Document SaaS, OneAgent, ActiveGate, collector, cloud-API, proxy, DNS, certificate, firewall, and private-location paths. Confirm outbound-only assumptions against the chosen architecture and test redundancy where routing is critical.
Deploy the pilot
Install or configure the approved collectors using change control. Capture the monitoring mode, installer source, parameters, host group, network zone, update policy, process-injection behavior, configuration owner, and rollback procedure.
Normalize context
Apply consistent application, service, environment, owner, business-unit, region, criticality, version, and cost-center metadata. Verify service detection and naming against the application inventory instead of accepting ambiguous defaults.
Prove coverage and privacy
Generate controlled transactions and failures. Confirm traces and dependencies appear, logs are parsed, sensitive values are absent or masked, access boundaries work, unsupported components are documented, and telemetry volume matches expectations.
Tune response
Create service objectives and actionable detection logic. Route a test problem through the incident workflow, verify the owner receives sufficient context, suppress planned maintenance appropriately, and measure duplicates and false positives.
Accept and expand
Review operational, security, privacy, performance, and cost evidence with stakeholders. Approve only after exit criteria pass. Expand by service tier, retain an exception register, and revalidate after platform, agent, application, or network changes.
Security, privacy, and administration
Treat observability data as a governed production asset
Identity and least privilege
Use federated sign-in where appropriate, managed groups, scoped policies, and separate administrative, analyst, developer, auditor, and service identities. Review account-level and environment-level permissions, emergency access, inactive users, and cross-environment visibility. Automate lifecycle management only after testing group mapping and deprovisioning.
Tokens and integrations
Prefer narrowly scoped OAuth clients or supported service identities for automation where practical. Inventory token owner, purpose, scope, storage location, creation date, last use, rotation, and revocation procedure. Never place secret values in tickets, dashboards, scripts, browser code, source repositories, or logs.
Data minimization
Review URLs, query strings, headers, request attributes, exception messages, logs, user identifiers, IP addresses, session data, and custom business events before collection. The official Dynatrace privacy documentation describes controls at capture, storage, and display; select the strongest point that fits the requirement.
Log and trace protection
Mask secrets, credentials, tokens, health information, payment data, personal data, and confidential business values before transfer when feasible. Use source or collector filtering for data that should never leave the environment, then add ingest-time processing as a second control where appropriate.
Change and configuration evidence
Track agents, ActiveGates, extensions, cloud integrations, detection rules, masking rules, dashboards, workflows, SLOs, synthetic monitors, API clients, and retention settings. Use configuration-as-code or exportable settings where supported, peer review material changes, and keep a tested restore path.
Separation of duties
Monitoring administrators should not automatically receive unrestricted access to sensitive application data. Application teams need useful context without broad account administration. Security and compliance reviewers need evidence without the ability to alter production detection or retention settings.
Privacy checkpoint: Dynatrace documents that monitored environments may expose personal or confidential information through requests, URLs, headers, exception details, logs, and end-user monitoring. Test the actual captured fields with representative traffic; do not approve privacy based only on intended settings.
Signals that lead to action
Build alerting around ownership, service objectives, and tested workflows
Dynatrace can correlate related events into problems, but useful response still depends on service context and routing design. Separate detection from notification: a condition may be worth recording without waking an engineer. Define severity, duration, scope, environment, business impact, support window, and escalation behavior before connecting a notification channel.
For current implementations, Dynatrace recommends workflow-based notification approaches for many use cases. Legacy problem-notification and alerting-profile patterns may still exist in established environments. Document which model is in use, who owns it, and how migration or coexistence is governed. Do not copy a production workflow into another environment without checking permissions, secrets, filters, and recipients.
Test the full path: create a controlled failure, confirm detection, correlation, notification, ticket creation, ownership, acknowledgement, escalation, resolution update, and closure. A successful email test alone is not an incident-response acceptance test.
Use service-level indicators
Choose indicators that describe delivered service: successful transaction ratio, valid synthetic completion, latency below an agreed threshold, or another measurable outcome. Infrastructure utilization can support diagnosis but is rarely a complete user-facing SLI.
Watch error-budget burn
An SLO summarizes a longer-term objective; burn rate shows how quickly the remaining error budget is being consumed. Use fast and slow evaluation windows appropriate to traffic and service criticality, then test low-volume and maintenance scenarios.
Connect changes to reliability
Ingest or annotate deployments, configuration changes, feature flags, infrastructure work, and vendor incidents. Review reliability before and after changes so teams can distinguish correlation from a verified cause.
Acceptance and audit evidence
Require proof that the implementation works
Evidence should be reproducible, dated, scoped, and owned. Screenshots are useful but should be paired with exports, settings, test records, tickets, or queries that show how the conclusion was reached.
| Control area | Evidence to retain | Pass condition | Common failure |
|---|---|---|---|
| Coverage | Application-to-entity map, agent/collector deployment inventory, cloud integration scope, missing entity report, documented exceptions. | Every in-scope critical service and dependency has the approved monitoring depth or an accepted exception with owner and date. | Agent count is treated as proof even though business services, external dependencies, or user journeys are missing. |
| Telemetry quality | Representative metrics, logs, traces, topology, service names, entity metadata, time synchronization check, dropped-data or sampling evidence. | Signals are timely, correctly attributed, searchable, and sufficient to follow a controlled transaction and failure. | Duplicate services, unstable names, missing resource attributes, clock skew, parsing failures, or uncontrolled cardinality. |
| Access and privacy | Group/policy export, service identities, token inventory, SSO/SCIM test, masking examples, retention settings, access-review sign-off. | Least privilege works, terminated access is removed, secrets are protected, and prohibited values are not captured or displayed. | Broad default access, orphaned tokens, personal data in URLs/logs, or masking tested only with synthetic sample fields. |
| Detection and response | Controlled incident record, problem details, workflow execution, ticket, acknowledgement and closure timestamps, runbook link, false-positive review. | The correct team receives an actionable notification and can identify scope, probable cause, and next action within the agreed target. | Alerts reach a generic mailbox, lack ownership/context, duplicate across channels, or remain open after service recovery. |
| Resilience | ActiveGate/collector health, network-zone design, proxy and certificate tests, failover evidence, queue/retry behavior, monitoring of the monitoring platform. | A defined component or path failure is detected and telemetry recovers without silent or unacceptable loss. | A single ActiveGate, collector, DNS record, proxy, certificate, or egress path becomes an unmonitored single point of failure. |
| Cost and capacity | Subscription/rate card, usage baseline, forecasts, allocation tags, retention, sampling and ingest controls, budget owner, abnormal-growth alert. | Expected consumption is understood, attributable, reviewed, and bounded by technical and financial guardrails. | High-cardinality dimensions, verbose logs, aggressive polling, long retention, or wide synthetic coverage expands unnoticed. |
Licensing and performance guardrails
Control telemetry volume before it becomes an operational problem
Use the actual contract model
The current Dynatrace Platform Subscription model is consumption based, while some organizations may retain classic licensing. Exact rate-card capabilities, units, included amounts, and retention terms depend on the agreement. Build estimates from the signed contract and measured pilot usage—not from an old blog post or another customer’s design.
Prevent cardinality and ingest surprises
Review metric dimensions, span attributes, log sources, custom events, OpenTelemetry resource attributes, synthetic frequency, RUM properties, session replay, query schedules, dashboard refresh intervals, and retention. Reject identifiers that create a new dimension value for every request, user, device, or session unless the use case truly requires it and privacy approval exists.
Measure agent and collector impact
Baseline CPU, memory, disk I/O, network traffic, process startup, application latency, and log volume before the pilot. Repeat after deployment and during peak load. Monitor OneAgent, ActiveGate, collectors, extensions, and ingest queues so observability components do not fail silently or compete with the workload they protect.
Ongoing operations
Run observability as a maintained service
The environment changes every week: applications are released, teams reorganize, cloud resources scale, certificates expire, integrations rotate, and business priorities move. A regular operating cadence prevents silent coverage and ownership drift.
Daily
- Review new high-impact problems and failed workflows.
- Check collector, ActiveGate, and ingestion health.
- Confirm critical synthetic journeys are running.
- Escalate unexpected coverage or data gaps.
Weekly
- Analyze noisy, duplicate, stale, and unactioned alerts.
- Review new entities without owner or environment metadata.
- Correlate reliability with releases and changes.
- Inspect major usage or cardinality increases.
Monthly
- Review SLO status and error-budget trends with service owners.
- Validate dashboards, workflows, tokens, and integration owners.
- Reconcile monitored services with application and asset inventories.
- Report reliability, recurring causes, risk, and remediation progress.
Quarterly
- Recertify privileged access and non-human identities.
- Test failover, privacy controls, and a representative incident path.
- Review retention, sampling, monitoring modes, and subscription forecasts.
- Retire stale configurations and approve expansion priorities.
Frequent failure patterns
- Monitoring deployment is counted as complete before service ownership and alert routing exist.
- Automatic service names change between releases, fragmenting dashboards and SLOs.
- Planned maintenance trains the baseline or floods the incident system.
- Logs and traces contain tokens, identifiers, or regulated data that were never reviewed.
- Dashboards multiply without an owner, audience, decision, or retirement date.
- OpenTelemetry collectors or ActiveGates lack capacity and failover monitoring.
- One global notification route sends every problem to the same queue.
- High-volume data is retained because no one owns the cost decision.
Troubleshooting order
- Confirm the user or service symptom and exact timeframe.
- Check whether the expected entity and telemetry are present.
- Validate time synchronization, service naming, environment tags, and transaction context.
- Follow the request through dependencies and inspect relevant errors, spans, logs, and infrastructure saturation.
- Check recent deployments, configuration, certificates, DNS, network paths, cloud events, and third-party status.
- Verify collectors, ActiveGates, proxies, queues, sampling, filters, and ingest limits.
- Preserve evidence, update the incident record, and document the confirmed cause—not only the correlated signal.
Current primary references
Use official documentation for implementation details
Dynatrace capabilities and interfaces change. Validate platform behavior, supported technologies, prerequisites, consumption units, and configuration steps against the tenant version and current contract.
- Application & Infrastructure Observability overview for current monitoring modes and subscription capability context.
- Dynatrace OneAgent documentation for deployment, capabilities, modes, and supported platforms.
- Dynatrace OTLP endpoint documentation for supported OpenTelemetry signal paths and ingestion options.
- Dynatrace Grail overview and the DQL reference for contextual storage, analytics, queries, dashboards, and notebooks.
- Dynatrace IAM overview for federation, groups, policies, service users, OAuth clients, and tokens.
- Dynatrace data privacy and security guidance for masking, personal data, audit logs, retention, RUM, logs, OpenTelemetry, and related controls.
- Dynatrace SLO documentation for DQL-based service objectives, error budgets, and burn-rate approaches.
- Dynatrace licensing documentation for the current subscription model, capability billing, allocation, and cost-management guidance.
Frequently asked questions
Dynatrace observability FAQ
Is Dynatrace only an infrastructure-monitoring product?
No. Dynatrace provides infrastructure and application observability capabilities, and it can ingest or correlate signals from hosts, processes, services, applications, browsers, mobile applications, Kubernetes, cloud platforms, logs, metrics, traces, OpenTelemetry, synthetic tests, and other supported sources. The selected license, deployment, monitoring mode, technology support, and configuration determine the available depth.
Does every server require Full-Stack monitoring?
No. Select monitoring depth from the business and technical requirement. Full-Stack is appropriate when deep application performance, tracing, and code-level visibility are needed. Infrastructure or Discovery modes may fit other use cases under supported licensing. Document the decision by service tier and validate what is and is not collected.
What is the difference between OneAgent and ActiveGate?
OneAgent collects supported host, process, application, and infrastructure signals according to its mode and configuration. ActiveGate can provide routing and enable particular capabilities such as cloud monitoring, extensions, remote technologies, private synthetic locations, or controlled communication paths. Exact roles depend on the architecture; design capacity, redundancy, network zones, proxies, certificates, and monitoring for each component used.
Can Dynatrace use OpenTelemetry data?
Yes. Dynatrace provides OTLP ingestion options for metrics, logs, and traces through supported endpoints, and a collector can batch, enrich, filter, mask, or route telemetry. Standardize resource attributes and service naming, protect credentials, control sampling and cardinality, and test retry and failure behavior before production rollout.
What should be tested before enabling real-user monitoring or session replay?
Test consent and privacy requirements, captured URLs and parameters, user identifiers, IP and location handling, input masking, session data, retention, role-based access, exclusion rules, third-party content behavior, application performance impact, and data deletion or anonymization processes. Legal and compliance owners should review requirements that apply to the organization and users.
How do teams reduce Dynatrace alert fatigue?
Start with service ownership and objectives, route only actionable conditions, use environment and criticality context, suppress or annotate planned maintenance, test workflow filters, measure duplicates and false positives, and review alerts that are never acknowledged or acted upon. Expand coverage only after the pilot produces trusted signals.
How should Dynatrace costs be estimated?
Use the signed rate card and current licensing documentation, then measure representative pilot consumption. Include hosts or other capability units, logs, metrics, traces, RUM, synthetic execution, retention, custom data, query and workflow behavior, and expected growth. Add allocation tags, forecasts, anomaly review, and an accountable budget owner.
Does this guide replace Dynatrace professional services or a security assessment?
No. It is an implementation and review framework. Tenant-specific architecture, product configuration, licensing, privacy, legal, compliance, performance, and security decisions should be validated by qualified internal stakeholders and, when appropriate, Dynatrace or another authorized specialist.
Plan the operational foundation
Make observability actionable, governed, and supportable
If your organization is planning or reviewing Dynatrace, IT Perfection can help assess the surrounding infrastructure, cloud, network, monitoring, documentation, ownership, and operational processes that determine whether the platform produces useful results.
This guide is for initial planning and operational guidance only. It does not replace Dynatrace documentation or support, a professional cybersecurity audit, compliance assessment, penetration test, privacy or legal review, or a tenant-specific architecture and licensing analysis. Dynatrace and related product names are trademarks of their respective owners.
