Datadog Reviews

We use the solution for application hosting and a little bit of everything when it comes to supporting a worldwide logistics tracking service. It's used as a central service for collecting telemetrics and logs. We find it does the same work as all of our old tools combined, including Prometheus, Kibana, Google Logs, and more; putting all of this information in a single platform makes it easy to corroborate information and associate a request with the data, which might be lost when it is saved as logs.

At my organization, we have plenty of microservices written in different languages. Different teams prefer one or the other framework or library within those languages.

With Datadog, we can get in a single line and march in the same direction; our logs and metrics are collected in the same fashion, making it easy to find bugs or integration problems across services and understand how they interact with other systems.

I primarily prefer to utilize the profiling and tracing feature. It can potentially be used as a more-informed alternative to logs.

Beyond that, anything I've wanted to do, I found a way to get it done through Datadog. It allows for testing, logging, hardware monitoring, system performance, memory consumption, advanced observability, AI assistance, cross-team collaboration, and business analytics. Datadog helps some of the world’s biggest brands transform faster with the help of true AIOps, AI-assisted answers, UX and business analytics, cloud observability, and smart AI assistance.

It's all supporting my desire to build a great application, and in a centralized SaaS application, it's hard to say anything can beat it.

The storage of logs is a little bit unexpected; most services generate gigabytes of logs, and their size is not excessive. When it comes to storing the logs with Datadog, I'm not sure why it costs so much to store gigabytes or terabytes of information when it's a fraction of the cost to do so myself.

I've used the solution for one year.

We have no concerns with stability.

It appears to be that there are no issues with scaling.

Technical support is slow. It takes forever to get responses from the support team.

I've previously used Kibana and Prometheus. We are still using these.

Setting up through the environment variables made it unbelievably easy to get started.

We've implemented the solution in-house.

I do not have this number off-hand, as I am not the finance guy. I just like the product.

I'd advise new users not to start off by sending logs.

We did not really look at other options.

We are using the solution for migrating out of the data center. Old apps need to be re-architected. We plan to move to multi-cloud for disaster recovery and avoid vendor lockouts. The migration is a mix between an MSP (Infosys) and in-house devs. The hard part is ensuring these apps run the same in the cloud as they do on-prem. Then we also need to ensure that we improve performance when possible. With deadlines approaching quickly, it is important not to cut corners which is why we needed observability.

The product has created a paradigm shift in how we deploy monitoring. Before, we had a one-to-one lookup in service now. This wouldn't scale, as teams wouldn't be able to create monitors on the fly and would have to wait on us to contact the ServiceNow team to create a custom lookup. Now, in real-time, as new instances are spun up and down, they are still guaranteed to be covered by monitoring. This used to require a change request, and now it is automatic.

For use, the most valuable features we have are infrastructure and APM metrics. The seamless integration between Datadog and hundreds of apps makes onboarding new products and teams a breeze. 

We rely heavily on the API crawlers that Datadog uses for cloud integrations. These allow us to pick up and leverage the tags teams have already deployed without having also to make them add them at the agent level. Then we use Datadogs conditionals in the monitor to dynamically alert hundreds of teams, and with the ServiceNow integration, we can also assign tickets based on the environment. Now, our top teams are using APM/profiler to find bottlenecks and improve the speed of our apps.

The real issue with this product is cost control. For example, when logs first came out, they didn't have any index cuts. This leads to runaway logs and exploding costs. 

It seems that admin cost control granularity is an afterthought. For example, synthetics have been out for over four years, yet there are no ways to limit teams from creating tests that fire off every minute. If we could say you can't test more than once every five minutes that would save us 5X on our bill.

I've been using the solution for about three years. 

The solution is very stable. There are not too many outages, and they fix them fast.

It is easy to scale. It's why we adopted it. 

Before premium support, I would avoid using them since it was so bad.

Neutral

We previously used App Dynamics. It isn't built for the cloud and is hard to deploy at scale.

The initial setup was not complex. We just had to teach teams the concept of tags.

We implemented the solution in-house. It was me. I am the SME for Datadog at the company.

We have seen an ROI. It has saved months of time and reduced blindspots for all app teams.

We'd advise new users to be careful with logs, and the APM as those are the ones that can get expensive fast.

We looked into Dynatrace. However, we found the cost to be high.

We use Datadog for observability and system/application health, mainly for product support, triaging, debugging, and incident responses.

We use a lot of the logging and the Datadog agent to collect logs, metrics, and traces from our GKE workloads. We use APM and continuous profiling for latency and performance measurement. We use RUM to observe frontend user events, such as tracing on request and what actions they take before errors occur. We also use error tracking and source maps to debug production failures.

We are still relatively new to the product, and we are planning to use more of the notebook functionality and power packs to record run books and break knowledge silos. We also need to utilize dashboards and continuous profiling more for performance measurement and integrate Datadog alerts for incident response.

We have way more observability than what we had before - on the application and the overall system. That includes the GKE cluster, nodes, and pods. It's helped with our cloud-run instances, databases, and data storage.

We also started observability in the CI pipeline to measure our CI performance, as it was a pain point for us. We are aiming to do incremental deployments and releases, and the bottleneck so far has been our CI performance. The visibility on which actions or functions take the most time allows us to pinpoint and focus on improving configurations on these.

We use structure logging a lot to triage production issues. The querying, attributes and tags manipulation, and customization have been very helpful in isolating and filtering environments. The integration with Winston logger has also been a breeze.

First and foremost, was that structured logging, tags, and attributes have not only allowed us to narrow down to a problem quickly in production, they have also let us create dashboards from these logs to understand more user behaviors, such as how many users stop and leave our application before an upload has completed. That helps us understand how important processing time is to a user.

We also intend to use distributed tracing more to understand where the error has occurred in a particular request.

Definitely, documentation could use improvement. As I navigated and try to find instrumentation and implementation details, I discovered inconsistency among SDKs based on languages. 

There are also places where highlighting can be improved. I once created an issue on GitHub, and it was resolved right away by an engineer. He pointed out that it was actually in the documentation. I looked again and found it was not very obvious. We were stuck on the problem for days.

Auto instrumentation on tracing has not been very easy to find in the documentation. We ended up using OpenTelemetry, yet the conversion between tracing contexts has been difficult.

We've used the solution between six months and a year. 

Customer service and support are generally very fast. I did experience one ticket, which involved changing the log index retention period, not being responded to. Any support tickets related to technical issues were resolved pretty fast.

Positive

We used to use GCP Stackdriver for logging and monitoring since our infrastructure is all GCP based. It was lacking a lot, particularly on tracing and structured logging. We often had a lot of trouble triaging and diagnosing a production problem. Datadog's specialty is observability. Since we started using the product, we were able to create dashboards, and utilize APM, continuous profiling, RUM, and distributed tracing for production support and user trends.

Datadog also offers labs and workshops for its products, which is very helpful.

We implemented the product ourselves.

I'm not sure what our ROI would be.

We started with on-demand pricing as we were re-writing our product, and we weren't sure about the total usage. After we went into production and released the product, we experienced a price surge. Fortunately, our Datadog account manager reached out to us and suggested a monthly subscription, which is what we'll be switching to.

I'd advise keeping an eye on the usage and possibly setting up some monitoring on price. We didn't have much of a setup cost; we started with a free trial and continued with on-demand after the trial ended.

We didn't evaluate many of the other options. However, we do also use OpenTelemetry, which is vendor agnostic and integrates with Datadog.

We always keep the Datadog agent to the latest version.

We share dashboards, set up alerts, and monitor everything that happens in our system. We use it in staging, features, production, and our load test environment. It is exceptionally helpful for making our engineering more data-driven. 

I came from a company that believes we should focus on being telemetry driven. Instilling this in a smaller, less mature engineering organization has been challenging. However, it is much easier while using Datadog.

The dashboards are great. They are an easy way to give visibility into what we need to watch with others who are not SMEs.

I enjoy the custom metrics. With this, we can take things that were once logs and then retain them longer.

We are able to parse logs. To be honest, this was only useful due to the fact that we had not yet set up the Datadog agent properly in PHP. Once we did this, the Datadog log parsing was no longer needed.

The ability to pin to a date and time is very helpful. This allows us to pinpoint exactly what was happening.

We need more advanced querying against logs. While most issues I have had here can be alleviated by way of sending better-formatted logs, it would be cool to do SQL-type queries against our data.

We need a way to see dashboard metadata. We launched a huge customer, and we saw more people using Datadog than ever across the entire organization, yet had no way to tell.

It would be ideal if we had some way to compare arbitrary date times more easily. We would love to use the Diff Graph command against some hard-coded value, for instance, against some known event.

I've used the solution for eight months.

The scalability is great!

We previously used New Relic. I was not part of the decision-making team that made the switch.

The ROI is the speed at which we can debug live sites. It has been excellent. It's amazing how many incidents we can capture before customers notice.

We looked into New Relic and a home-brewed solution as potential other options.

We primarily use the solution for log monitoring across our entire cloud infra (EB, EC2, Batch, and Lambda).

This is in addition to Rstudio Workbench, which has its own logs that would not be picked up via Cloudwatch(https://docs.rstudio.com/ide/server-pro/server_management/logging.html#default-log-file-locations). 

We own several dozen of these servers, and we used to manage instance logs by tailing logs when incidents occurred. Datadog allows for much better visibility across our entire fleet and has saved us countless hours.

It is now way easier to search in one place rather than across all of Cloudwatch (and needing to know log groups, etc.). 

Primarily, we run several separate deployments of Rstudio Workbench, which has its own logs that would not be picked up via Cloudwatch. 

We own several dozen of these servers. We used to manage instance logs manually. 

Datadog allows for much better visibility.

We've found it most useful for managing Rstudio Workbench, which has its own logs that would not be picked up via Cloudwatch. 

Datadog allows for much better visibility across our entire fleet and has saved us countless eng hours as a result. 

We plan on trying out offerings such as APM moving forward too.

Some things that Datadog does very well:

• Technical documentation (the docs are clear, concise, and include realistic code samples)
• Overall education efforts (e.g. the codelabs/workshops)

We primarily use the log management functionality, and the only feedback I have there is better fuzzy text searching in logs (the kind that Kibana has). 

I've learned about a ton of other offerings, like APM, NPM, etc., over the course of workshops. Once I try those out, I'm sure I will have additional feedback.

I've used the solution for one year. 

We use this solution for our customer's IP and to support their cloud infrastructure.

Datadog is easy to use and easy to deploy. It's a better solution compared to others on the market in terms of being budget friendly for our customers.

Datadog could be improved if it could detect other software in a container or server. Datadog is better than other APM or observability tools, but it focuses mostly on telling the customer what they need to know about the software, database or applications that land on the server. We also need to know the version before setting up an agent with the APM modeling tool.

In some instances, the owner of a particular software changes to another person and this person did not originally transfer the knowledge or data to manage the server. The new person needs to monitor this server and they need to know what software or version of software was installed on this server before they used the APM agent for monitoring. If datadog could provide this insight, it would improve how we use the solution. 

In a future release, we would like to be able to complete a network traffic or network flow analysis to detect the errors or problems on the network.

I have been using this solution for two years. 

This is a stable solution. 

The initial setup was straightforward. We needed two engineers for the deployment.

This solution is budget friendly.

Overall, Datadog is a good product to use and is easy to deploy.

I would rate this solution a nine out of ten. 

I used Datadog typically for monitoring website statistics and some of the cloud networking equipment.

The most valuable features are the dashboards and the reporting.

I have been using this solution for approximately three years.

I found the solution to be stable, I did not experience any bugs or glitches. However, some of the managing team did.

The scalability of the solution was good. Being a cloud solution, if there was an issue with the scalability it would be easily fixed with an update.

We have approximately 200 users using the solution in my organization.

I did not need to use the support.

I was previously using SolarWinds in the company I was working with before.

I rate Datadog nine out of ten.

Datadog is expensive. 

The tool's deployment is easy. 

The solution's pricing depends on project volume. 

I rate Datadog a seven out of ten. 

We mainly use the product to monitor our infrastructure and apps. It is the go-to tool when we want to check that things are running properly. We use Datadog synthetic monitors to ensure our app works across different locations in the United States. 

We also have set up Datadog monitors to send alerts if things stop working as expected. 

We use Continuous Integration Pipeline visibility to make sure our developers are not being blocked by infrastructure and other things that might be out of their control.

Datadog helps us detect issues early on and helps in troubleshooting. Creating Service Level Objectives and defining monitors is helping us to stay on top of potential issues that might affect our users. 

We take advantage of Application Performance Monitoring to ensure our applications are working as expected, and our users can get the healthcare they need at a price they can afford. 

Synthetic monitoring also helps us in testing our application in different browsers.

The most valuable aspects of the solution include: 

CI visibility, which helps us in making sure our CI systems are running efficiently and are not blocking our developers from releasing new software and fixing bugs.

Logs, which help us in debugging issues where we can search for logs and can make sure they are relevant to the issues we are looking at.

APM, which can help us to stay on top of our applications by giving us the confidence that our apps are running.

Monitoring. We use monitoring a lot to ensure we know about potential issues and fix them before they affect our customers.

Overall, we really like the quality and relevance of all of the Datadog products that are currently being used. 

The documentation is very well organized and is the go-to place for us to find answers to our questions. 

We would really like to see more from the Service Catalog. It is something that we are interested in. However, some might think it lacks some key features at this time. We will definitely keep our eye out for this and adopt it when all the features are implemented. 

We're really looking forward to all the great things DD will do.

I've used the solution for three years.

The stability is great.

The scalability is great.

Technical support is great.

We handled the initial setup in-house.

I don't have any insights into pricing.

We primarily use the solution for logging and APM, and for real user metrics.

The solution has helped out organization gain improved visibility.

The most useful aspects of the solution include RUM, session replay, and APM.

The product needs a better Datadog agent installation.

I've used the solution for one year.

We previously used App Dynamics.

Before choosing Datadog, we looked at Splunk.