Datadog Reviews

Our primary use case is log management and we also use the solution for monitoring the application and underlying infrastructure. I'm an IT test manager. 

I appreciate that they are constantly adding new features, some of which we haven't yet had a chance to implement. 

I'd like to see more flexibility in the customization and they have a few settings which need to be changed but we are unable to make those changes as users or as the administrator. The tagging to get the different parts of the monitoring interconnected is a bit tricky and takes time to work out. 

I've been using this solution for 18 months. 

The stability is good. 

I would say that the amount that we are monitoring is not that large and we've never had any scalability issues. We have around 50 users in our department. 

The availability or accessibility to customer service is not always good, although they generally provide solutions once you do manage to get hold of them. 

We have previously used different tools for different parts of the monitoring. We changed to AWS when we moved to the cloud. We also found that the effort in maintaining Grafana and Prometheus and keeping it up to date was taking too much time.

The initial setup was straightforward, we used a service provider and they also maintain our operation in general.

We have a four-year contract with Datadog, and the solution is pay-as-you-use. 

I would suggest using the documentation, which is quite good. It's best to start with existing integrations, and then do the customization step-by-step.

I rate this solution eight out of 10. 

We are evaluating Datadog for observability and monitoring requirements that we have in our company. In our use case, our intention is to provide some kind of framework for multiple app teams to use the tool for our cyber ability and engineering practices.

They have a very good foundation in capturing metrics, logs, and traces. It's a very nice tool for that and it allows you to apply these monitoring tools in almost any technology.

Even if you have several layers, containers, EC2 instances, build machines or whatever you need in your infrastructure, Datadog can integrate with all of them across multiple cloud providers. It's a great product.

One of the improvement opportunities that we have identified in my project concerns how hard it is to manage an organizational structure when you have multiple things in one organization, and you want to provide some kind of isolation between them. At the same time, from the management perspective, you want to see an overall overview of what is happening in your business unit, or as a whole division. This is the kind of limitation we're facing.

I'm not sure what kind of features are in the roadmap right now, but I encourage the development of features for defining your organization, and allowing the visibility of what kind of metrics you can get. Those features would be really useful for us. 

I have been using Datadog for about six months.

It's a very scalable product. Right now we are using the SaaS version, so we don't need to worry about the infrastructure or whatever is needed for the platform it is running on. All the capturing of data is sent to the SaaS product and that can be as scaled as needed.

So far their support is pretty nice. They have established many meetings and training sessions, and they are supporting our requirements very well. I don't have any complaints with Datadog support.

While it is an expensive product, I would rate the pricing level at four out of five. 

Normally, the primary reason why people use these kind of tools is observability, but right from the beginning you have to understand what observability is, what it means for your company, and how the tool is going to help you to capture the proper metrics for making your applications observable.

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.

We deploy agents on-premise to collect data on on-premise VM instances. We don't use Datadog in our cloud network. We do have some Cloud apps that we have it on and we also have Containers. We have it on their headquarters, the main software for them is on their own Cloud.

Eventually, we're building out the process now and using it better. We plan to use Datadog for root cause analysis relating to any kinds of issues we have with software, with applications going down, latency issues, connection issues, etc. Eventually, we're going to use Datadog for application performance, monitoring, and management. To be proactive around thresholds, alerts, bottlenecks, etc. 

Our developers and QA teams use this solution. They use it to analyze network traffic, load, CPU load, CPU usage, and then Tracey NPM, API calls for their application. There are roughly 100 users right now. Maybe there's 200 total, but on a given day, maybe 13 people using this solution.

It hasn't improved the way our organization functions yet, because there's a lot of red tape to cut through with cultural challenges and changes. I don't think it's changed the way we do things yet, but I think it will — absolutely it will. It's just going to take some time.

I like that you can build out a dashboard pretty quickly. There are some things that come out of the box that you don't really need to do, which is great because they're default settings. Once you install the agent on the machine, they pick up a lot of metrics for you that are going to be 70 or more percent of what you need. Out of the box, it's pretty good.

I have been using Datadog every day since September 2020. I also used it at a previous company that I worked for.

Stability-wise, it's great.

It seems like it'll scale well. We're automating it with Ansible scripts and service now so that when we build a new virtual machine it will automatically install Datadog on that box.

The tool itself is pretty good and the customer service is good, but I think they're a growing company. I think better access to their engineers when we have a problem could be better. For example, if I asked the question, "Hey, how do I install it on this type of component?" We'll try to get an engineer on the phone with us to step us through everything, but that's a challenge because they're so busy.

Technically-wise, everything's fine. We don't need any support, everything that I need to do, I can do right out of the box. But as far as, in the knowledge of their engineers on how to configure it on given systems that we have, that's maybe at six because they're just not as available as I would've hoped.

We were using AppDynamics. Technically, we still have it in-house because it's tightly wound into certain systems, but we'll probably pull that off slowly over time. The reason we added Datadog and eventually we'll fully switch over is due to cost. It's more cost-friendly to do it with Datadog.

Yes, we looked at Dynatrace, AppDynamics, and New Relic. Personally, I wouldn't have chosen Datadog for the POC if it were up to me. Datadog was a leader, but New Relic was looking really good. In the end, the people above me decided to go with Datadog — it's a big company, so they wanted to move fast, which makes sense.

If you're interested in using Datadog, just do your homework, as we did. We're happy so far I think; time will tell as we are still rolling things out. It's a very good company. It's going to be a year before we really can tell anything. If you do your homework, you'll find that if you're really concerned with cost, it's good.

There are some strengths that AppDynamics and Dynatrace have that Datadog I don't think will have down the road, but they're not things we necessarily need — they're outliers. It would be nice to have them, but we can manage without them.

Know what you want. There is no need to pay for solutions like Dynatrace or AppDynamics that are more expensive or things that are just nice to have if you don't absolutely need to have them. That's something people need to understand. You just have to make sure you understand what it is that you need out of the tool — they are all a little different, those three. I would say to anybody that's going with Datadog: you just have to be patient at the beginning. It's a very busy company right now. They're very hot in the market.

Overall, on a scale from one to ten, I would give Datadog a rating of eight. It does what we need it to do, and it seems to be pretty user-friendly in terms of setting things up.

Features-wise, I'd give them a rating of ten out of ten. The better access we get to assistance from the engineers on how to configure dashboards and pulling metrics that we need, that would bring it up a little bit. So overall it would be harder and it would have to be perfect for it. I would say maybe they could bring it to a nine.

Our primary use case would be using the dashboards and getting proper insights based on the dashboards.

The monitoring, SLO, and SLA have been better and easier since we started using the Terraform infrastructure. APM has been easier as we had to enable it through the CronJob directly.

Profiling has been made easier. We are able to get many insights into the code. Profiling provides really good insights right now. 

Logs are the most valuable and the best solution so far. Datadog can help solve any slow queries or database-related errors. 

The primary use case would be using the dashboards and getting proper insights based on the dashboards.

Monitoring has been better and easier since we started using the Terraform infrastructure.

APM has been easier as we had to enable it through the CronJob directly.

Profiling has made it easier in terms of getting many insights into the code.

The logs are the most valuable and the best solution. Datadog can help us to solve any slow queries or database-related errors.

Profiling provides really good insights, and APM has really good tracing visibility. 

The SLA and SLO definitions and the monitoring are also really important and very valuable parts of the product and make great Datadog features. 

Datadog support is also really valuable as they provide support for the product through the chat as well. 

The Datadog premium support has helped us to provide faster outcomes for a problem. 

Also, rather than having an email thread, it would be better to get the support on call and sort out the issue, which is the support we get from Datadog CSM.

Integration should have been easier. It is very tough to go to all the services and enable Datadog integration for each AWS service. 

We can add the AWS services and the services on one page and show only the services that are enabled. A similar approach should be for any other integration.

Lately, chat support has a longer waiting time. We would love to get faster chat support. We also need additional support for sending the flare files

I am using the solution for monitoring metrics, logs, traces, etc. It's mainly for making dashboards as well as monitoring our services. 

We also use Datadog to help centralize our incident management to show the logs, where issues spiked, and some metrics. 

We use Datadog to do troubleshooting in Kubernetes, specifically in our Azure Kubernetes service. Beyond that, we are looking to use open telemetry in tandem with Datadog to further our log-tracing efforts. In the future, this may be expanded.

This solution improves our organization as now we have higher visibility into our application that we otherwise would not have. 

Since the Datadog agent comes in three forms, agentless, scraping, and through the API, it is very flexible. It is this flexibility in how to report our logs that keeps our logs centralized and organized. 

One major drawback of Datadog is the cost. Sometimes we set up flows in place to monitor resources that end up logging more than we thought, and the bill is too high.

Dashboards have been marrying the most valuable parts of Datadog. Dashboards use metrics that are very helpful for monitoring services. I recently used metrics to monitor the number of pods in Kubernetes, the spikes in requests in Kubernetes, and overall CPU and memory usage in our Kubernetes clusters. 

We can also use log analytics to further our understanding. We can handle debugging and find out why things are breaking in our applications. 

The log portion of Datadog has robust features to debug the applications we are running. I really appreciate the ability to use facets to par down the logs.

The documentation leaves a lot to be desired for new users. The documentation is way too much text and has no real information just to help get people started. Sometimes it doesn't help to read an entire essay just to get a grasp on how the logs or metrics work.

I've used the solution for two years.

Our use case is mainly deploying into our applications for monitoring/logging observability. We currently have our microservices feed into an actuator that exists in each instance of our application that extends to a local and central Grafana for client and internal visibility. The application we use is Grafana.

Logging captures application and system logs that are ported to each application instance for querying.

Whenever anything occurs that is considered unhealthy from a range of health checks, we have notification rules configured internally and externally for a prompt response time.

We have been able to be a more confident, knowledgeable, and capable team when everything is being ported into a centralized format. Beforehand, knowledge was isolated to individuals. Knowledge in terms of what information represented and where it was led to a lack of confidence. By having everything in one place, rules out that confusion and allows us to respond better to issues.

It also allows for personal growth as our team is learning the application from the ground up, and each person is enhancing their own skills.

The valuable features include the following: 

• We are currently utilizing a decentralized distributed framework for our deployment, including our monitoring/logging observability capabilities. Centralizing them, if contingent on our company privacy guidelines, will be a big help in tracking and responding to issues that come up and have the means to understand the origin of the log management tools that were demonstrated.
• The ability to fiddle around and manipulate how logs are outputted.
• The ability to track AWS Lambda functions, Cloudformation, and Cloudwatch allow someone that is not savvy to dip their toe into understanding their own product.
• The integration into AWS is key as well as our software is currently bound to AWS.

The ability to find what you are looking for when starting out could be improved. It was a bit overwhelming trying to figure out what is the best solution. It led to many prototypes or time spent just perusing documentation. If we were able to select bundles or template use cases, we would hit the ground running quicker.

I've used the solution for one year.

We use it mostly for logging log messages from our Kubernetes and EC2 instances, for example, system messages and errors. Also, we want log messages from our firewalls and other network infrastructure in case of network issues. We intend to use it for application logging, et cetera, to get insight into internal problems in the applications in Kubernetes pods. We want to use it for monitoring in case of system problems and hardware failures so that it can notify us.

It's good to have a single location for all the logs. If you have logs coming from a whole lot of sources, it makes it hard to find where the problem lies. 

We had to spend a lot of time logging into various systems and pursuing a billion different log files looking for something that stands out as a possible cause of the issue. That can take a lot of time and doesn't give much visibility into the possible interactions between systems.

Datadog has a lot of features to be able to drill down deep into the swath of logs that our platforms generate. 

It has a lot of ability to make fancy and deep searches using regular expressions and to graph them into useful and interesting dashboard graphs. 

The plethora of built-in/downloadable integrations make it much easier to set up for our platforms. Otherwise, we'd have to parse the log files ourselves, which would take a great deal of effort. Had to do it before when had to use an ELK stack for logging, which was painful.

Some of the interface is still confusing to use. It has many features, and it takes a lot of effort to figure out what they all mean. Maybe having tooltips or something would be helpful. Also, some of the integrations are better than others.

I've used the solution for a month.

The solution seems very stable.

Have used an ELK stack before. However, it took a lot of effort to maintain, and parsing the logs was difficult.

We implemented the solution in-house.