Splunk vs. Dynatrace

To quickly isolate root causes across hundreds of interconnected services you need flexible workflows and all your data with no blind spots. Dynatrace's resource-heavy instrumentation, expensive solution and inflexible debugging workflows lead to blind spots in cloud native workloads.

Contact Sales

Microservices in Kubernetes can horizontally scale up and down in seconds. Dynatraces’s batch telemetry collection and visualization is too slow for engineers to pinpoint critical problems and quickly respond.

With <10 second data collection and visualization, we provide insights to events as they happen in containerized applications. This speeds up MTTR, reduces user frustration and protects company reputations and wallets when your business depends on digital.

Dynatrace Grail doesn’t support the transaction and search scale large enterprises need. Its indexes are built at query time which significantly reduces query performance, especially when run concurrently. As an immature product, Grail has a smaller support community and a complicated query approach that depends on three different query languages making it difficult to use. Without a robust logging solution and logs in context with metrics and traces, troubleshooting is a longer, more tedious process.

Splunk can ingest, index, store and search extremely large data sets with relative ease. We fully index telemetry data on ingestion, making the search for root cause easy. Our unified analytics correlates logs, metrics and traces. Combined with our world-class unified search, Splunk performs well regardless of concurrency, reducing MTTR.

Dynatrace pricing uses multiple, non-intuitive pricing metrics. Likewise, host license sizing based on memory capacity requires customers to expend significant time and effort, leaving them frustrated with their Dynatrace spend.

Splunk’s simple, intuitive pricing offers a complete observability. Pricing is based on the monthly average of the number of hosts to be monitored across. Infrastructure monitoring, application performance monitoring, always-on code profiling, log exploration, real-user monitoring, session replay and synthetics.

Before we started using Splunk, every resolution was bespoke — logging into production machines to analyze logs and run scripts — but Splunk enables us to answer questions about application history with simple queries.

Aki Yamada, Staff Engineer, Rent the Runway

Read the Customer Story

Splunk vs Dynatrace

	Splunk	Dynatrace
Business analytics	Splunk ITSI ingests, indexes and stores any human readable file from any source, whether homegrown or third party apps. It combines this data with metrics and traces and offers highly configurable glass tables to track and troubleshoot any business process.	Visibility gaps prevent Dynatrace customers from having a complete view of their business processes. Telemetry data is often missing from Dynatrace’s solutions because their host license is expensive. Their proprietary agent is resource intensive, preventing it from being widely deployed, particularly in cloud native environments. Even with limited data, Dynatrace business views are inflexible and rigid making it hard for engineering and ITOps teams to identify and resolve issues.
Detection and alerting	Splunk streams granular, one-second metrics in near real time, visualizing it for engineers in seconds. We collect all traces, ensuring issues are never missed and engineers have what they need to troubleshoot issues as they occur. Our architecture speeds up MTTD and MTTR, improving consumer experiences and reducing work for engineers and ITOps teams.	Dynatrace’s metrics collection architecture is slow, extending MTTD and degrading user experience. Engineer satisfaction drops when required to wait for Dynatrace’s sampling algorithm to capture problems.
Retention and data pipeline management	By default, Splunk retains most data longer and at a greater level of detail than Dynatrace.¹Engineers have more information and historical context to troubleshoot complicated issues. With Splunk logs and metrics pipelines edge processing and data export capabilities, teams can route, transform, obfuscate and omit data, enabling engineers to keep the telemetry they need and discard what they don’t.	Dynatrace saves high resolution metrics for a short time², after which the detail is reduced, giving engineers less information to work with as the problem ages. Today, Dynatrace doesn’t have an offering that matches Splunk’s capability. They’ve announced intentions to launch a pipeline tool in the May 2024 timeframe.³
Troubleshooting experience	Splunk Observability Cloud's troubleshooting workflows include business context that tells engineers where to look, why the problem occurred, its impact on their business and suggest a fix. Our logs are fully indexed creating rich context which ensures users can find what they want quickly. Engineers can start from a user, service, application or infrastructure layer, identify what’s affected and isolate what’s broken quickly and easily.	Getting to the root-cause of unanticipated issues or issues that Davis could not isolate is difficult and time consuming. Dynatrace does not offer easy navigation such as tag spotlight, business workflows or related content for exploration. The Dynatrace Grail logging platform builds its indexes at query time, which results in a slower, unstructured search and less context. Users might eventually find an answer, but it will be slow. As a result, even with Davis’s assistance, MTTR can take a long time with Dynatrace.
OpenTelemetry support	Only Splunk allows for data to be collected in any format and has natively embraced OpenTelemetry as a standard collection approach. We collect, process, transform, visualize and alert on OpenTelemetry data without constraints or relying on proprietary agents. We are the only vendor that offers continuous profiling and commercial support⁴ for our OpenTelemetry implementation. Splunkcustomers can directly contribute to the community and fully realize the business value of OpenTelemetry for their enterprise.	Dynatrace’s fledgling support for OpenTelemetry isn’t suitable for enterprises. While they make significant community contributions, their ability to surface analytics and insights on OpenTelemetry data is limited. Users must run the Dynatrace proprietary agent and an OpenTelemetry collector concurrently. Both collectors send telemetry to the backend where it's stored separately, making it difficult to query and garner insights. Continuous profiling support isn’t available in the distribution they recommend.

¹Enterprise monitoring metricsets and real user monitors are stored at one second resolution for three months and one minute resolution stored for 13 months by default. Splunk’s no sample tracing stores all traces by default. Indexed logs, traces and synthetic monitors are stored for 30 days with longer retention available through federated S3.
²Dynatrace Service metrics are stored at 30 second resolution for one hour and one minute resolution for 35 days by default. Distributed traces (sampled above 1000MTS/min) and RUM action data is stored for 10 days with aggregate rollup available for 35 days. Customers are required to declare log retention buckets.
³https://www.dynatrace.com/news/blog/dynatrace-openpipeline-converging-observability-security-and-business-data-at-massive-scale-for-unmatched-analytics-in-context/
⁴Commercial support is defined as phone or online support delivered by the vendor’s employees to help engineers use, enhance and fix the OTEL receivers & collectors recommended by the vendor.