Dynatrace cost vs self-hosted Grafana and Prometheus

Usage above the commitment keeps accruing against the Dynatrace Platform Subscription (DPS) at the per-capability rates in your rate card. DPS is consumption-based, and agreements typically run one to three years with a minimum annual commitment, so overage depends on which capabilities teams switch on and how much telemetry they send. Cost growth often comes from new services and log volume added mid-term, which a yearly review can miss. Ask for the overage rate for each capability, how usage is metered, and whether SaaS and Managed usage share the subscription. Model the rate card against recent telemetry before you sign.

Whether unused commitment is carried forward, credited or lost depends on your agreement, and the public DPS documentation does not settle it, so confirm the terms in writing. A minimum annual commitment is payable whatever your consumption, so a team that moves telemetry to OpenTelemetry and self-hosted tools during the term can keep paying for capacity it no longer uses. Ask how unused amounts are handled at each annual boundary and at term end, whether the commitment can be resized at renewal, and whether the migration can be phased so consumption tracks the commitment. Review consumption by capability each month so any shortfall is visible well before the final year.

Start with consumption by capability over the past term, then size the next commitment from that history and a written plan for change. Points worth raising with the vendor:

• Overage rates for each capability on the rate card
• Treatment of unused commitment at each annual boundary and at term end
• Term length and whether the commitment can be resized at renewal
• Whether SaaS and Managed deployments can share the subscription, as the DPS documentation describes

Keep a dated export of usage and your dual-shipping plan so the negotiation rests on evidence from your own environment and timeline.

Every Grafana edition supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT, according to the Grafana authentication docs. Those methods cover most single sign-on needs if your identity provider supports OAuth or LDAP. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. If your policy requires SAML or automated provisioning from your identity provider, that requirement changes the licensing decision. Confirm your identity provider's OAuth or LDAP options with your security team before you choose the edition.

The supplied pricing facts do not give a self-managed Grafana Enterprise price, so request a quote from Grafana Labs for your deployment size and support needs. The Grafana pricing page lists a minimum commitment of 25,000 US dollars per year for the Enterprise tier of Grafana Cloud, which is a hosted offering and a different product from a self-managed license. Ask whether the quote covers the license only or also support, and how it renews. Factor in the staff time to operate the identity integration, which recurs as long as the stack runs.

Loki has no built-in authentication layer, so its documentation says you must run an authenticating reverse proxy in front of it, such as nginx, HAProxy, OAuth2 Proxy or Pomerium. Loki identifies tenants by the X-Scope-OrgID header when auth_enabled is true, so the proxy must decide which user can send or query each tenant. The proxy adds components to build, certificate and patch, along with its own configuration and access rules, and that work belongs in your effort estimate. Confirm the proxy design with your security team before any log data arrives.

Logs are kept indefinitely, because the Loki compactor applies retention only when retention_enabled is set, and that setting is disabled by default. Storage then grows with ingest on object storage such as Amazon S3, Google Cloud Storage or Azure Blob Storage, and that bill recurs every month. Retention can be set globally, per tenant or per stream selector, and each stream rule must be at least 24 hours. Decide retention periods with your compliance owner before go-live, because changing them later does not restore logs already removed.

Your own team does, and the stack has more components that can page someone than a single SaaS console. Grafana high availability needs two or more active-active servers behind a load balancer on MySQL or PostgreSQL, and Alertmanager runs as a cluster through its cluster flags. Prometheus local storage is not clustered or replicated, so it needs its own backup and failure plan. Patch releases for Grafana arrive at least monthly, and Prometheus minor releases follow a six-week cycle, so upgrade work recurs. Budget the on-call rota, the upgrade calendar and the patch effort as ongoing staff costs.

No single figure settles this, because the two bills are built differently. Dynatrace Platform Subscription (DPS) is a consumption model: you sign an agreement of typically 1 to 3 years with a minimum annual commitment, and usage accrues against it on a per-capability rate card. A self-hosted stack has no license fee for Prometheus (Apache-2.0) or Grafana (AGPL-3.0-only), so its costs are infrastructure, storage, implementation and the people who run it. Cost drivers on the open-source side include the number of active series, log volume, retention period, high availability, and the hours your engineers spend on upgrades and on-call. Ask Dynatrace for your contracted rate card and commitment term, then model the open-source side against your own telemetry volumes.

The duration depends on how much of your estate is instrumented by OneAgent and how many dashboards, alerts and automations depend on Dynatrace. The main drivers are the number of services that need OpenTelemetry instrumentation, the number of dashboards and alert rules to rebuild in Grafana, and whether you run both platforms in parallel while the DPS commitment is still active. Because Dynatrace ingests OTLP, many teams send the same telemetry to both backends during a transition, which lets them compare results before cutting over. Timing should be set against your commitment end date. Ask any partner for a written scope and timeline, and confirm which Dynatrace features (such as automatic discovery and root-cause analysis) your teams rely on, since those need replacement planning.

Many teams can, but the stack is assembled from several components, so the skills need to be planned rather than assumed. Prometheus stores data in a local time series database that is not clustered or replicated, so it must be managed like any other single-node database. Grafana needs MySQL or PostgreSQL for production and high availability, with two or more active-active servers behind a load balancer. Alertmanager needs its own cluster configuration, and Loki, if used for logs, depends on object storage and an authenticating reverse proxy. Your team should cover Kubernetes or Linux operations, database administration, OpenTelemetry instrumentation, PromQL and alert design, and a regular upgrade cadence. Grafana's own guidance says minor releases come every other month and patch releases at least monthly, so the upgrade workload recurs.

It depends on how you use the software. Prometheus is Apache-2.0 and has no paid enterprise edition, so it carries the fewest licensing questions. Grafana was relicensed from Apache-2.0 to AGPL-3.0-only on April 20, 2021, starting with Grafana 8.0, and Grafana Loki and Tempo moved to AGPLv3 on the same date. The AGPL requires that users interacting with a modified version over a network can obtain its source, so legal teams should review any internal changes or forks. Grafana Enterprise is a separate commercial option, and some features such as SAML and SCIM are only in Enterprise and Grafana Cloud. Ask your legal and compliance team to confirm how the AGPL applies to your planned use, including any modifications.

Ask for a fixed scope in writing before work starts, with deliverables and timelines agreed up front. A useful quote separates instrumentation work (OpenTelemetry collectors and service-by-service changes), platform build (Prometheus, Grafana, Jaeger or Loki, plus Alertmanager and storage), dashboard and alert rebuild, cutover and parallel running, and documentation. Ask how high availability, backups, authentication and upgrades are handled after go-live, and whether ongoing support is a separate retainer. Confirm which Dynatrace capabilities are out of scope, such as automatic discovery, AI root-cause analysis and real user monitoring. DeployOpen does not publish a price list; a quote follows from the written scope.

Yes, it changes who operates the platform, but not the license model. Dynatrace Managed is run in your own environment, and DPS can be shared across SaaS and Managed deployments, so the subscription still applies. The comparison therefore shifts toward operating effort: with Managed, Dynatrace supplies the software and you run the environment, while a self-hosted stack also requires you to choose, configure and upgrade each component. Ask Dynatrace which parts of the Managed environment you operate, what offline or air-gapped operation includes, and how upgrades are delivered. Compare those answers against the staff time and infrastructure you would commit to Prometheus, Grafana and Jaeger.

Plan for retention to be set by your own storage budget, not carried over from Dynatrace. Prometheus stores data locally with a default retention of 15 days, configurable by time or size, and can send samples to external long-term storage through remote write. Loki retention is disabled by default, so logs are kept indefinitely until you enable it, and retention can be set globally, per tenant or per stream. Long-term metric storage often uses a system such as Grafana Mimir, which is also AGPL-3.0-only. Telemetry history collected in Dynatrace generally does not move with a migration, so decide which historical comparisons you need and export them before the subscription ends. Confirm the export options with Dynatrace.