Datadog Reviews

We use Datadog for observability and monitoring primarily. Various cross-functional teams have built various dashboards, including Developers, QA, DevOps, and SRE. 

There are also some dashboards created for senior leadership to keep tabs on days to day activities like cost, scale, issues, etc. 

Also, we've set up monitors and alarms that kick off when any metrics go beyond the threshold. With Slack and PagerDuty integration, correct team members get alerted and react to solve the issue based on various runbooks.

Using Datadog metrics has helped the organization a lot in many manners. With one centralized monitoring place, it's a lot less effort to keep track of the system and applications' health. 

Using this also helps teams be proactive in dealing with any issues before they get escalated by customers. 

Lastly, having so many integrations makes the DevOps and SRE's lives a lot easier when automating the detection and resolution of any issues hidden in the system or applications. Overall, it has helped a lot.

My favorite feature is creating dashboards as that empowers me to sleep calmly at night and not to keep watch on critical system metrics. Be it DB metrics or computer-related metrics, it's always easy to view them. 

The ease of correcting these dashboards and widgets when needed is amazing. 

The only issue I face is when more than one person editing these dashboards simultaneously, one or the other person sometimes loses his/her work. That said,  they will resolve that soon. With the variety of widgets, it's so easy to plot the data in a timely manner, and that makes monitoring a lot easier.

The solution can be improved in a few areas. 

The parallel editing of the dashboards should not cause users to lose the work of another person. 

Secondly, we would like to see more demos of tools that are in beta version, when they come live. I am sure they will help us a lot.

I've been using the solution for slightly over two years.

I find the solution to be very stable.

I totally love it. It is scalable. 

We previously used Sumo Logic.

The initial setup is not so difficult.

We implemented the solution in-house.

The ROI is very fair so far.

I can't recommend the licensing.

I was not involved in any pre-evaluation process.

I use the solution to manage security-related logs and metrics, as well as create detection rules for security events. I am a security engineer, so one area of interest is the CSPM product, giving us the ability to look at findings across the cloud environment. 

The great part about the Datadog security products is that they incorporate the context of the resources/hosts where the security event is found. This allows us to see exactly what is running on a host that we see as a security alert.

The greatest impact it has had is on the ability to democratize observability and put monitoring into the hands of the people. Teams can quickly get the information they need, without needing a bunch of training, since the UI is super intuitive and easy for beginners. This helps reduce time to resolution during incidents and gives context to developers quickly and easily. Context is really important since seconds matter when the ship is down, and you don't know why.

I find the greatest feature is being able to search across logs from various microservices. As a member of the security team, I find that I often need visibility into other teams' services in order to get a good picture of our security posture.

I also am a fan of the ability to easily create monitors and get alerts into Slack quickly, without too much overhead. For example, I often need to create monitors where I am not too sure where the baseline lies. Having the ability to create anomaly monitors makes this process much more straightforward. Anomaly monitors are great for a security team.

One area where I was really looking for improvement was the CSPM product line. I had really wanted to have team-level visibility for findings, since the team managing the resources has much more context and ability to resolve the issue, as the service owner. However, this has been added to the announcement in a recent keynote. 

Personally, I've used it my entire time employed here, more than three years.

We're moving towards the cloud yet still have several active data center contracts. As we move to the cloud, we are interested in knowing more about our services, and DataDog APM/logs should give us this perspective. 

We currently use the infrastructure monitoring part of DataDog. Still, I've really seen the advantage of moving more data into the cloud for comparison and being able to have one place where we can view all related pieces of information regarding a possible incident or potential issue.

We've been able to glean from the monitors what servers are down, and can alert the team in Slack. Knowing what we need to do next is what we would like to move to, so seeing the power of Notebooks is key. We also have several other services that we are underutilizing (logging, error tracking, etc.) that would be better housed in DataDog since it gives us more visibility into linking all of the things together into one cohesive picture.

Monitoring has been invaluable, and as we start to look to other products, bringing in logs and APM traces will create a full picture of what we need to do to resolve incidents. We're also interested in our users' perspectives and when things are slowing down for them.

Additionally, we are interested in the workflows announced today as an actionable decision tree that will allow our teams to see what is wrong and know what to do based on the connected runbook/notebook. I feel that this is the final piece that will make DataDog so much more valuable than its competition.

I have talked to vendors that mention that DataDog is drawing attention to an issue. However, you'll still need to take action on your own. The more tools that they can build that allow you to run AWX playbooks, or other similar fixes, would benefit clients greatly.

We've used the solution for two years.

We primarily use the solution for observability, metrics, logs, tracing, and end-to-end user flow monitoring. 

We are looking to implement this as a company-wide standard for cloud solutions.

At this time, we're currently in a POC, and we're interested in using either a Datadog agent or the OTel agent with a Datadog exporter. We have dashboards with panels that correlate metrics and allow you to link through to traces. Flame graphs to show latency across services and the various spans. 

While we are not security minded, we still require it and are interested in more. It's used for monitoring critical systems.

It has provided visibility with ease of implementation and allowed multiple teams to quickly onboard it. This provided a standard way to approach observability and visibility. 

Monitoring rules and alerting thresholds can also be set and exported to other teams for use. 

There is an issue with federated dashboards, as multiple teams running on different Datadog instances cannot use features like the service catalog or easily switch between services in a long business flow.

The K8 monitoring is extremely useful in Datadog. Preset dashboards that it provides help to speed up the work. 

The metrics summary is useful. Tracing with a span breakdown is helpful for us. We like the dashboarding with power packs and logging correlation with traces and logs. 

The Flame graph for tracing helps determine where the latency is the highest. 

Dashboards are created as a standard set and then exported into other Datadog instances for other teams. 

These dashboards would be updated regularly and pushed out to the teams. Unfortunately, there is no way to automatically push or deploy code in a quicker way. Each team I work with has its own Datadog instance.

Federated views for Datadog dashboards are critical as large companies utilize multiple instances of the product and cannot link the metrics or correlate the metrics together. This stunts the usage of Datadog. Additionally, using an OTel agent would be more acceptable and allow for easier adoption of Datadog across the hundreds of teams here.

I've used the solution for four months.

We primarily use the solution for observability.

The solution has helped with our POV phase.

The observability on offer is the most useful aspect of the product.

The FinOps needs improvement. 

The stability is good.

The scalability is good.

We previously used AppDynamics and Dynatrace.

We also evaluated AppDynamics and Dynatrace.

We primarily use the solution for monitoring and telemetry.

We use lots of log collections, log-based metrics, and dashboard visualization.  The logging, metrics, and APM are vital.  

My team focuses on the backend. Day-to-day monitoring includes observing metrics such as the CPU and memory until it gets too high. This solution provides an alert during the metric collection.  

APM and tracing are super useful. We use it for daily monitoring of CPU and memory. We can get alerts to tail to specific metrics.

We also find the tracing feature useful. We often run into bugs, and when a production issue happens, it is super useful to see the related services and sense where the problem is.

We would like to see smaller or shorter tutorials and video sessions. Also, the ability to provide a custom formula for monitoring is vital. Perhaps there can be more training materials on this. We often need to detect slow-running queries and slow network responses. We also focus a lot on the abuse of request limits. Having some form of rate limit features or metrics would be useful.  

Profiling could also be useful. Some services are CPU-intensive, and others are IO-intensive. Knowing where the bottleneck is, is crucial. 

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 mostly use it to handle log aggregation, monitor our web application, and alert us on data pipeline failures. 

Our system is fully on AWS, and so we pipe in all of our Cloudwatch logs into Datadog to have a central place to index and search logs. 

Our web app is built on an Elastic Beanstalk backend, and we use the Datadog agent to keep track of all of the requests that hit our backend and all of their components. 

We also use the prebuilt AWS pipeline dashboards to monitor our batch jobs and lambdas.

Datadog has made it much easier to have a central place for people to look for logs and made it much easier to notify them of any elevated error rates or failures. 

It is also easier to get high-level views of platform health, whereas looking directly at AWS tends to provide very specific insight into particular surface areas or products. 

By having the whole team onboard onto Datadog, we also have a single source of truth that everyone can use when triaging and resolving incidents that occur across any surface area.

The ease of setting up metrics and alerting and integrating with Slack has significantly reduced the friction of keeping the team up to date on the platform's health. Before creating custom Cloudwatch metrics was never very intuitive, and also it was non-trivial to set up integrations with other services we use, especially Slack. 

It also provides a good way to gain the context needed when trying to fix issues, as it's a central place to look through logs, requests, AWS metrics, and more - overall contributing to the health of our platform.

The product is quite complex, and there are so many features that I either didn't know about or wasn't sure how to use.

One thing that could be improved is somehow surfacing interesting or relevant products that might be applicable given our infrastructure. 

Additionally, the billing can sometimes be confusing and opaque, especially around not making it obvious what the implications can be if you add different AWS integrations. This has caused some unexpected costs in the past due to engineers not understanding how Datadog pricing works.

We've used the solution for around two years.

This was the first solution we tried.

It is quite expensive, especially if you don't know how the pricing works.