Which fits your situation: Dynatrace or a self-hosted Grafana and Prometheus stack
If your Dynatrace renewal is coming up and your team has no one who wants to run an observability stack, Dynatrace is usually the lower-effort choice, and the open-source route only makes sense if you accept more operating work in exchange for control. The decision turns on who will own the platform after cutover. Dynatrace fits best when staffing is thin and you need automatic discovery of services, dependencies and problems out of the box, along with AI-assisted root-cause analysis that reduces the time your on-call engineers spend correlating signals by hand. Dynatrace Platform Subscription is also a consumption model with a committed minimum, so a team that values one vendor for APM, infrastructure and logs may prefer to keep that single point of accountability even at higher run cost.
The self-hosted stack fits best when data control, portable instrumentation or in-house skills matter more than turnkey depth. OpenTelemetry gives you application instrumentation that any compliant backend can receive, and Prometheus, Grafana and Jaeger keep storage and dashboards in your own infrastructure, which helps with residency and lock-in concerns. Be realistic about the skills involved: Prometheus local storage is a single-node database that you manage yourself, Grafana needs MySQL or PostgreSQL for production and high availability, and alerting, retention and upgrades become your responsibility. Confirm current release support windows with each project before you commit a team to a version.
Three questions should drive the decision. First, staffing: can you name the people who will run, upgrade and back up these components for the next several years? Second, how much APM depth you need: if you depend on automatic service discovery and deep code-level diagnostics across many services, the open-source stack will require more manual instrumentation and design. Third, real user monitoring: OpenTelemetry does not define a stable RUM specification, so browser and session visibility needs its own tool and budget. Map these three answers against your current Dynatrace usage before you request a quote for either path.
Which option fits which scenario
This table maps common team situations to the better fit, Dynatrace or a self-hosted OpenTelemetry, Prometheus, Grafana and Jaeger stack, and the condition that tips the decision. Read each row against your own staffing, data rules and monitoring goals rather than picking the first match.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Small platform team with no observability engineers | Dynatrace | The team cannot staff someone to run Prometheus storage, Grafana HA and Jaeger upgrades, and accepts a consumption commitment in return |
| Regulated team that must keep telemetry inside its own environment | Self-hosted Grafana stack, or Dynatrace Managed | Self-hosted fits when policy bars any data leaving the enclave; Dynatrace Managed fits when the licensing and offline terms in your contract cover the requirement. Confirm both with your compliance owner |
| Mostly Kubernetes and service metrics with stable instrumentation | Self-hosted Prometheus and Grafana | Services already expose metrics or accept OpenTelemetry SDKs, and the team is comfortable with PromQL and alert rule ownership |
| Automatic full-stack APM with minimal configuration | Dynatrace | Teams need automatic discovery, dependency mapping and AI-assisted root-cause analysis across many services with little manual setup, which assembled open-source components do not provide out of the box |
| Real user monitoring and session-level front-end visibility | Dynatrace or a dedicated session replay tool | Browser telemetry is required and OpenTelemetry has no stable real user monitoring specification, so a separate tool such as OpenReplay is needed alongside a self-hosted stack |
| Mixed estate with long-term trace and log history | Self-hosted stack with a defined storage plan | Retention needs are set in writing, storage and backup are sized and owned, and the team accepts that a Prometheus local store is single-node and not replicated |
| Team migrating away from an existing commitment | Dual-ship OpenTelemetry, then cut over | The DPS commitment term is known, both backends receive the same OTLP data during the overlap, and dashboards and alerts are rebuilt before the cutover |
How the open-source stack fits together
OpenTelemetry is a framework, not a backend, so the stack is assembled from separate parts. Applications emit traces, metrics and logs through OpenTelemetry SDKs, and the OpenTelemetry Collector receives, processes and exports that data. In a typical layout, traces go to Jaeger, which is Apache-2.0 licensed and built on Collector components in v2, metrics go to Prometheus, and Grafana queries both to draw dashboards. Each hop is a configuration decision you own: which Collector runs as an agent beside services and which runs as a gateway, how exporters authenticate, and which team is paged when a pipeline drops data. Plan those ownership lines before the first dashboard is built, because Dynatrace's OneAgent previously made most of them invisible.
Grafana's license changed in 2021, and the change matters for how you use the stack. On April 20, 2021, Grafana Labs moved Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3, while plugins and SDKs kept other licenses. Grafana Mimir, which provides long-term storage for Prometheus metrics, is also AGPL-3.0-only. Internal use is generally unaffected, but if you modify Grafana and make it available to users over a network, or offer it as part of a hosted service to customers, have counsel confirm the obligations under AGPLv3 and whether Grafana Enterprise is the simpler path. Commercial terms for Grafana Enterprise are on Grafana Labs licensing.
Prometheus local storage runs on a single node, and the Prometheus storage documentation says it is not clustered or replicated. Plan for backup, disk sizing against your retention setting and a recovery procedure, or send long-term data to external storage through remote write. Alerting has its own high-availability rule: Alertmanager can run as a cluster using its --cluster flags, and Prometheus should be configured with every Alertmanager instance rather than a load balancer in front of them. Test that a single Alertmanager failure does not silence or duplicate pages in a drill before you rely on the setup for on-call.
Where the data lives and who controls the platform
Each card answers a question a CISO or platform lead asks before a renewal: where telemetry is stored, who operates the platform and who controls sign-in. The answers differ sharply between a Dynatrace subscription and a self-hosted Grafana and Prometheus stack, so check each one against your own data handling and access requirements before choosing a path.
Dynatrace SaaS or Managed under DPS
Dynatrace is offered as SaaS or as Dynatrace Managed, a deployment that runs in your own environment, and Dynatrace Platform Subscription can be shared across both. DPS is consumption-based with a minimum annual commitment, typically on a one to three year agreement, so your renewal date sets the decision point. Managed moves hosting responsibility to your team, but the license and rate card still come from Dynatrace. Ask which capabilities draw from the commitment and how unused capacity is handled at term end.
Data location and regional choices
Where telemetry is stored determines which data protection rules apply to it. For Dynatrace SaaS, confirm in writing which region hosts your tenant and where backups and vendor support access sit. A self-hosted Prometheus server keeps metrics on the disk you choose, but each server is a single node with local storage that is not clustered or replicated, so durability and placement become your design decisions. Ask where traces, logs and metrics are kept at each stage and for how long.
Fully self-hosted stack in your infrastructure
Grafana, Prometheus, Jaeger and the OpenTelemetry Collector can run entirely inside your cloud account, data center or enclave, with applications sending OTLP to collectors you operate. Telemetry leaves your network only where you configure an export. The trade-off is operational: you own high availability, which for Grafana means at least two active-active servers behind a load balancer sharing a supported production database, plus patching, backups and the Alertmanager cluster. Confirm who holds the on-call role before you commit.
Identity: SAML and SCIM tiers in Grafana
LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT work in every Grafana edition, so many organizations can keep existing directory sign-in on the open-source build. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your access policy requires SAML or automated deprovisioning through SCIM, either budget for Enterprise licensing or design a compensating control, and settle this with your identity team before design sign-off.
Confirm compliance mapping with your assessor
Architecture choices change which controls you can evidence, including access control, logging, retention and change management. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors or certification bodies make those determinations. Before you choose a path, ask your assessor how they will test data location, identity controls and retention for each option, and record their answers in the agreed scope.
Where browser monitoring leaves a gap in the open-source stack
The open-source stack in this comparison covers servers, services and backend requests well, but it does not observe what happens inside a user's browser. OpenTelemetry generates and exports traces, metrics and logs from the code it instruments, while Prometheus, Grafana and Jaeger store and display them. None of these components records a browser session, captures front-end JavaScript errors or replays what a user clicked. Dynatrace notes in its OpenTelemetry ingestion documentation that OpenTelemetry has no stable real user monitoring specification, so browser sessions, front-end errors and session replay need a separate tool in your design. If Dynatrace RUM is in use today, that capability must be replaced explicitly.
OpenReplay is the option covered in the companion page on front-end monitoring. It is self-hosted, handles session replay and browser errors, offers data masking, and links user sessions to backend traces, which matters most when a slow checkout turns out to be a slow database call. Before you rely on it, confirm the factors that determine fit: which browser performance signals it records compared with the Dynatrace RUM dashboards your teams use, whether its masking rules can meet your privacy review for form fields and personal data, how the session identifier reaches backend spans in your OpenTelemetry pipeline, and how many components it runs and who patches each one. Get these answers in writing and test them on one application before committing.
If browser monitoring is a current requirement, treat this gap as a scope decision before the migration plan starts. Inventory the Dynatrace RUM and session features your teams use day to day, such as error alerts, session replay for support cases and performance by region, and mark each one as covered, partly covered or missing. Then choose between running a second self-hosted tool, accepting a gap for a defined period, or keeping Dynatrace for front-end monitoring while moving back-end traces to Jaeger and metrics to Prometheus. The partial option is workable, but it must be reflected in the DPS commitment plan. Each path adds recurring work: another upgrade cycle, another storage footprint for session data and another privacy review.
What each side costs to run, and what drives it
Dynatrace Platform Subscription is consumption-based. You sign an agreement, typically for one to three years, with a minimum annual commitment, and usage accrues against that commitment on a per-capability rate card. Your recurring cost is therefore the commitment plus any usage above it, and the rate card determines how fast consumption turns into spend. Ask your account team to show the rate card line by line for the capabilities you actually use.
- Minimum annual commitment: You pay for the committed amount whether or not usage reaches it, so an underused commitment is a sunk cost.
- Per-capability rate card: Each capability you enable, such as APM, logs or infrastructure monitoring, meters separately. Enabling a new feature changes the bill.
- Consumption drift: Growth in services, hosts, log volume or retention can push usage past the commitment and into overage. Track it monthly against the agreement.
- Term and renewal: A one to three year term fixes the commitment for its duration. Confirm the renewal and true-up terms before you plan an exit.
- Shared or Managed deployment: Subscriptions can span SaaS and Managed deployments, so ask whether a Managed installation changes your operating burden or only where data sits.
Before any cutover decision, confirm the commitment end date, the notice period and whether unused commitment can be carried or refunded.
The self-hosted stack has no license fee for Prometheus, which is Apache-2.0 with no paid enterprise edition. Its costs come from compute, disk and networking in your own accounts or data centers, plus any long-term storage layer you add. Prometheus runs as a local, non-clustered time series store, and its default retention is 15 days, so a longer history means more disk or a remote write target. Grafana and Jaeger add their own compute and database needs.
- Compute for scraping and queries: Cost scales with active series, scrape intervals and query load. Size it from your own cardinality measurements.
- Storage and retention: Local retention is set by time or size. Longer retention or high-cardinality metrics drive disk, and a long-term store adds its own cluster.
- Grafana backend database: Production and high availability need MySQL or PostgreSQL, so the database is an additional cost.
- Grafana Cloud as an option: Grafana Cloud has a free tier and a Pro tier starting at 19 US dollars per month plus usage, with an Enterprise tier that has a minimum commitment of 25,000 US dollars per year, according to Grafana's pricing page. It is a separate hosted cost, not a free self-hosted one.
- Backups and disaster recovery: Plan backups for Prometheus data, Grafana configuration and Jaeger storage as recurring infrastructure work.
Ask for a sizing estimate built on your series count, retention target and query pattern, and confirm it with a proof of concept before committing hardware.
The largest recurring cost in a self-hosted stack is usually people. Someone must run Prometheus, Alertmanager, Jaeger, Grafana and the OpenTelemetry Collector as a supported service, handle on-call for the monitoring itself, and keep alert routing correct. Dynatrace's automatic discovery and root-cause analysis reduce that workload, and you should estimate what the team will spend on work that a managed platform did for you.
- Platform engineering effort: Operating several components with separate release cycles, configuration and failure modes requires ongoing time from skilled engineers.
- Prometheus operations: Single-node storage, federation or remote write design, and Alertmanager clustering each need attention.
- Jaeger and Collector operations: Trace storage sizing, sampling policy and Collector configuration are continuing tasks.
- Upgrade cadence: Prometheus minor releases arrive every six weeks, and Grafana minor releases arrive every other month, so upgrades are a standing cost.
- Instrumentation and dashboard rebuild: Replacing OneAgent with OpenTelemetry instrumentation and rebuilding dashboards and alerts is one-time labor that the commercial product did not require.
Ask any implementation partner to split its quote into one-time build work and recurring operations, and to name the staff roles each part assumes.
Costs move in different directions on each side, so the same change can raise one bill and lower another. Dynatrace spend rises with consumption and enabled capabilities, while the self-hosted stack rises with series, retention, query load and the hours your team spends on operations. Knowing which driver your environment hits first makes the comparison more accurate than a headline price.
- Cardinality and series growth: More unique label combinations raise memory, disk and query cost in Prometheus.
- Retention and sampling policy: Longer trace and metric retention increases storage on both sides, and sampling choices change what you pay to keep.
- Dual running during migration: Sending the same OpenTelemetry data to Dynatrace and a self-hosted backend means paying for both until the commitment ends.
- Upgrade and patch frequency: Staying within supported releases costs staff time each cycle, and falling behind adds risk.
- Support subscriptions: Vendor support for open-source components is optional. Ask whether any support tier is needed for your risk model.
For each driver, record the current value in your environment and the expected change over the commitment term.
What a move from Dynatrace to this stack involves
The sequence moves service telemetry, dashboards and alerts from OneAgent to OpenTelemetry, Prometheus, Grafana and Jaeger in an order that keeps Dynatrace available as a fallback until the new stack has proven it can replace what the team relies on. Each step closes with a check that tells the team whether it can move on.
Inventory services, dashboards and alerts
The platform owner and service owners list every monitored service, host, Dynatrace dashboard, problem alert, SLO and automation, and record who depends on each one. They also export the configuration as Monaco configuration-as-code files so the definitions are preserved outside the tenant. The step is done when every service has an owner and every dashboard or alert is marked as keep, rebuild or retire. Confirm with Dynatrace which configuration objects its export covers, because collected telemetry history mostly stays behind and cannot be assumed to move.
Instrument services with OpenTelemetry
Application teams replace OneAgent instrumentation with OpenTelemetry SDKs or auto-instrumentation, one service at a time, and route telemetry through an OpenTelemetry Collector running in your environment. Traces go to Jaeger, and metrics are exposed for Prometheus to scrape or receive over OTLP. The step is done when each service emits traces, metrics and logs with consistent service names and resource attributes, and the team can see them in Jaeger and Prometheus. Check each language's SDK stability on the OpenTelemetry status page before choosing a pattern.
Dual-ship OTLP to both backends
The Collector sends the same OpenTelemetry data to Dynatrace and to the self-hosted backends in parallel, because Dynatrace ingests OTLP. Platform engineers compare request counts, error rates and latency between the two views for the same services, and they measure the ingest volume they send to Dynatrace so that DPS consumption stays within the committed term. The step is done when the self-hosted views match Dynatrace for the core service indicators, and the gaps that remain are written down. Ask Dynatrace how dual shipping will be billed under your DPS agreement before you start.
Rebuild dashboards and alerts in Grafana
Dashboard and alert owners recreate the retained views in Grafana, with Prometheus as the metrics data source and Jaeger for trace exploration. Grafana provisioning loads data sources, dashboards and alerting resources from YAML or JSON files at startup, so the definitions live in Git and can be reviewed like code. Alertmanager receives alerts from Prometheus, and each alert route is tested against a known failure. The step is done when every retained dashboard and alert is provisioned from version control and each alert has been fired in a test. Grafana's documented as-code options, including Terraform and Git Sync, are an alternative if your team already uses them.
Plan for automatic discovery and root-cause loss
Dynatrace's automatic discovery, dependency mapping and AI root-cause analysis have no direct equivalent in this stack, so the team defines what replaces them. Owners document how incidents will be triaged using traces in Jaeger, Prometheus queries and Grafana dashboards, and they decide which dependency maps must be maintained by hand. Real user monitoring is a separate gap, since OpenTelemetry has no stable specification for it, and the team plans how front-end monitoring will be covered. The step is done when a written runbook exists for the top incident types and every lost capability has a named owner and a decision to accept, replace or keep Dynatrace for it.
Validate operations and staffing
Platform engineers confirm they can run the self-hosted stack without the vendor's managed services. This includes Prometheus local storage, which is not clustered or replicated, so retention and remote write to long-term storage must be planned. It also covers Grafana in high availability with a MySQL or PostgreSQL database, Alertmanager clustering, Collector upgrades and patching, and backup and restore testing. The step is done when the team has tested a restore, an upgrade in a non-production environment, and a failover of Grafana, and when the on-call rota covers the new components. Check that the Prometheus and Collector versions in use are still supported before cutover.
Cut over at the end of the commitment term
Teams switch alerting and on-call routing to the self-hosted stack service by service, starting with the least critical ones, and keep Dynatrace read-only for a fallback period. Dynatrace stays under DPS until the committed term ends, so the cutover date is set against that contract date rather than the technical readiness alone. The step is done when all in-scope services alert from Grafana and Alertmanager, Dynatrace ingest has stopped or been reduced to the agreed scope, and the decommissioning record lists what was kept for audit. Confirm the notice period and exit terms in your DPS agreement with Dynatrace before the cutover date is fixed.
Questions buyers ask before choosing or hiring help
How much effort does a self-hosted Grafana and Prometheus stack take to run?
It takes ongoing platform work, not a one-time install. A working stack is several components: Prometheus for metrics, Alertmanager for alert routing, Grafana for dashboards, and Jaeger for traces, with an OpenTelemetry Collector in front of them. Each one needs upgrades, backups, capacity planning, certificate and access management, and alert tuning. Grafana's own upgrade guidance describes minor releases every other month and patch releases at least monthly, and Prometheus minor releases follow a 6-week cycle, so someone must schedule and test those changes. Ask any partner to show the expected operating routine for each component before you compare totals.
What skills does the team need to run the open-source stack?
Your team needs working knowledge of several areas at once:
- Prometheus configuration, service discovery and PromQL
- OpenTelemetry instrumentation and Collector pipelines
- Grafana administration, provisioning and access control
- Database and high availability operations for Grafana's configuration store, which needs MySQL or PostgreSQL for production
- Linux, container or Kubernetes operations, depending on where you deploy
No single person usually covers all of these, so plan for named owners and cross-training. Confirm the skill mix against your own environment before assuming existing staff can absorb the work.
Can our team set up and run this stack without outside help?
Many teams with strong platform engineering can, provided they accept the operating load described above. The usual gaps are automatic discovery, root-cause analysis and real user monitoring, which Dynatrace bundles and an assembled stack does not. Teams that lack capacity for on-call tuning, upgrades and dashboard rebuilding often bring in help for a defined part of the work, such as the initial architecture, instrumentation rollout or hardening. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts.
What drives cost up or down on each side of this decision?
On the Dynatrace side, the Dynatrace Platform Subscription bills consumption against a rate card under an agreement of typically 1 to 3 years with a minimum annual commitment, so volume and commitment term are the main drivers. On the self-hosted side, Prometheus and Grafana carry no license fee for the open-source editions, so cost comes from infrastructure, storage, retention, implementation and staff time. Storage and retention grow with cardinality and with how long you keep data, and high availability adds database and load-balancer components. Ask any quote to separate one-time work (design, instrumentation, dashboard rebuild) from recurring work (upgrades, on-call, capacity).
What does a dual-shipping trial need from engineers?
Dual shipping means sending the same OpenTelemetry telemetry to Dynatrace and to the self-hosted backend during a parallel run. Dynatrace documents OTLP ingestion, so the instrumentation work is shared, but engineers still need to configure a Collector pipeline with two exporters, agree on service and attribute naming, and compare dashboards and alerts side by side. Engineers also need to watch for duplicate alerts and for double ingestion cost on the commercial side. Confirm the trial window against your DPS commitment term before you start.
Do we need Grafana Enterprise or Grafana Cloud for SAML single sign-on?
Yes, if you need SAML. According to the Grafana authentication docs, all editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT, while SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your identity provider supports OAuth or OIDC, the open-source edition may cover your sign-in needs. Confirm the required feature list with Grafana Labs and your identity team before deciding, because the answer depends on which provisioning and group features you rely on.
What do Prometheus retention and single-node storage mean for long-term data?
Prometheus keeps data in a local time series database with a default retention of 15 days, configurable by time or size. Its storage is not clustered or replicated, so it should be managed like any other single-node database, with backups and disk planning. For longer history, Prometheus supports remote write and remote read to external long-term storage systems such as Grafana Mimir, which is AGPL-3.0-only. Plan the retention target, the long-term store, and the restore process before go-live, and confirm the design against your compliance retention requirements.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that lists each component, the environment it runs in, and who owns each operating task after handover. Request deliverables for instrumentation, dashboards, alert rules, provisioning as code, backup and restore tests, hardening aligned to the Grafana security hardening guidance, and documentation. Ask how upgrades are handled, which Grafana and Prometheus versions are in scope, and what is excluded, such as dashboard rebuilds for every team. DeployOpen does not publish a price list, and a quote follows from the written scope, so compare proposals on the same deliverables and timelines.
How DeployOpen works on this
DeployOpen plans and implements self-hosted OpenTelemetry, Prometheus, Grafana and Jaeger stacks inside your own cloud accounts, data centers or air-gapped networks. Work starts from a written scope that covers which Dynatrace capabilities you need to replace, which you will accept losing, and what evidence your teams need before any cutover.
How we scope
- We inventory which Dynatrace capabilities your teams use: host monitoring, APM traces, dashboards, alerting and any real user monitoring.
- We document the services that would need OpenTelemetry instrumentation and the order in which they would move.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy Grafana with MySQL or PostgreSQL, Prometheus with Alertmanager, Jaeger and an OpenTelemetry Collector in your environment.
- We set up dual-shipping of OTLP telemetry so Dynatrace and the open-source stack receive the same data during the overlap period.
- We rebuild dashboards and alert rules as provisioned, version-controlled configuration and test them against known failure scenarios.
How we hand over
- We deliver architecture records, runbooks for upgrades, backup and restore, and a list of the capabilities that were not replaced.
- We walk your operations and platform engineers through alert routing, Collector configuration and Prometheus storage sizing decisions.
- We document access controls and hardening settings so your security and compliance teams can review them directly.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can prepare monitoring controls and evidence for your compliance assessors, who make the formal determinations.
- Ask us to confirm which release lines and support windows apply to your stack at the time of scoping.
