Dynatrace is an APM scaled for enterprises with cloud, on-premise, and hybrid application and SaaS monitoring. Dynatrace uses AI-supported algorithms to provide continual APM self-learning and predictive alerts for proactive issue resolution.
$0
per synthetic request
Logstash
Score 8.0 out of 10
N/A
N/A
N/A
Pricing
Dynatrace
Logstash
Editions & Modules
Synthetic Monitoring
$0.001
per synthetic request
Kubernetes Platform Monitoring
$0.002
per hour for any size pod
Real User Monitoring
$0.00225
per session
Application Security
$0.018
per hour for 8 GIB host
Infrastructure Monitoring
$0.04
per hour for any size host
Full-Stack Monitoring
$0.08
per hour for 8 GIB host
No answers on this topic
Offerings
Pricing Offerings
Dynatrace
Logstash
Free Trial
No
No
Free/Freemium Version
No
No
Premium Consulting/Integration Services
No
No
Entry-level Setup Fee
No setup fee
No setup fee
Additional Details
—
—
More Pricing Information
Community Pulse
Dynatrace
Logstash
Considered Both Products
Dynatrace
Verified User
Project Manager
Chose Dynatrace
We selected Dynatrace because it is much more modern and depends on AI, on auto-discovery, and other features, making it really a next-gen monitoring solution. It is not easy to on-board to Dynatrace, as it has an extremely steep learning curve. It is also possible that other …
Dynatrace is well suited to a number of tasks. It is important to determine who the end users are and gather good information to tailor their experience accordingly. For instance, business/marketing should not have access to some of the more technical data, and business metrics can be a distraction for IT operations personnel.
Perfect for projects where Elasticsearch makes sense: if you decide to employ ES in a project, then you will almost inevitably use LogStash, and you should anyways. Such projects would include: 1. Data Science (reading, recording or measure web-based Analytics, Metrics) 2. Web Scraping (which was one of our earlier projects involving LogStash) 3. Syslog-ng Management: While I did point out that it can be a bit of an electric boo-ga-loo in finding an errant configuration item, it is still worth it to implement Syslog-ng management via LogStash: being able to fine-tune your log messages and then pipe them to other sources, depending on the data being read in, is incredibly powerful, and I would say is exemplar of what modern Computer Science looks like: Less Specialization in mathematics, and more specialization in storing and recording data (i.e. Less Engineering, and more Design).
We loved Dynatrace's ability to show the data flow - from the front end points through the back end points straight to the database and various API's. It was advanced in its data visualization. This is useful for debugging - showing when/where the errors are. It can even enable non-technical individuals in the corporation to help debug
Dynatrace has some great highly customizable integration options as well as monitoring. You can configure your layout & integration options to create custom monitoring alerts for your applications performance. Further you can increase the extensibility of using a REST API on your architecture.
Some advanced dev-ops systems are utilizing Kubernetes/docker aswell as Node.JS - Dynatrace was able to log and help understand all of our dev-ops needs. It gave us native alerts based off of deviations from the baseline that we set during initial configuration. These metrics are priceless.
Logstash design is definitely perfect for the use case of ELK. Logstash has "drivers" using which it can inject from virtually any source. This takes the headache from source to implement those "drivers" to store data to ES.
Logstash is fast, very fast. As per my observance, you don't need more than 1 or 2 servers for even big size projects.
Data in different shape, size, and formats? No worries, Logstash can handle it. It lets you write simple rules to programmatically take decisions real-time on data.
You can change your data on the fly! This is the CORE power of Logstash. The concept is similar to Kafka streams, the difference being the source and destination are application and ES respectively.
Dynatrace does not monitor easily on a C-based application.
The way DPGR is addressed by Dynatrace is not very complete, and not clear. One thing is to mask the IP and request attributes but is not enough, the replay session feature is great but raises serious questions about user tracking.
Since it's a Java product, JVM tuning must be done for handling high-load.
The persistent queue feature is nice, but I feel like most companies would want to use Kafka as a general storage location for persistent messages for all consumers to use. Using some pipeline of "Kafka input -> filter plugins -> Kafka output" seems like a good solution for data enrichment without needing to maintain a custom Kafka consumer to accomplish a similar feature.
I would like to see more documentation around creating a distributed Logstash cluster because I imagine for high ingestion use cases, that would be necessary.
We have already renewed our purchase with the company. They make it easy for us to get a temporary license for our contingency site that is only used for testing twice a year. We are expanding our license with for this tool. We find it very useful and will renew it again.
Dynatrace is great to use once you understand how to use it correctly and get used to the layout of it. While I do not actively use it every day, whenever I do use it, I do have to get refamiliarized with it. However, once you have your dashboards setup correctly with the data that you want to see when you first login to Dynatrace, it's amazing.
Given that Dynatrace has become an informal industry standard, the plethora of information available on forums is massive. Most problems or roadblocks you come across are most likely (almost certainly, in fact) already solved and solutions available on these forums. The tech support at Dynatrace is also quite good, with prompt and knowledgeable people at their end.
Synthetic Monitoring automatically does what other products do only through the use of other tools or through the development of user applications that still have a high cost of maintenance. The other products are not immediately usable and require many customizations. Through the use of configuration automatisms, you can be immediately operational and, in our case, we detected several imperfections in the applications.
MongoDB and Azure SQL Database are just that: Databases, and they allow you to pipe data into a database, which means that alot of the log filtering becomes a simple exercise of querying information from a DBMS. However, LogStash was chosen for it's ease of integration into our choice of using ELK Elasticsearch is an obvious inclusion: Using Logstash with it's native DevOps stack its really rational
Positive: Learning curve was relatively easy for our team. We were up and running within a sprint.
Positive: Managing Logstash has generally been easy. We configure it, and usually, don't have to worry about misbehavior.
Negative: Updating/Rehydrating Logstash servers have been little challenging. We sometimes even loose data while Logstash is down. It requires more in-depth research and experiments to figure the fine-grained details.
Negative: This is now one more application/skill/server to manage. Like any other servers, it requires proper grooming or else you will get in trouble. This is also a single point of failure which can have the ability to make other servers useless if it is not running.
