Datadog Reviews

We primarily use the solution for the service catalog.

We use this type of offering for our Microservices applications, and it gives a good view of flow. It is a must when we have different developers working on different services.

Having the trace and log features are useful for locating the microservice for the on-call person.

We would like to see some more useful applications for health monitoring where we can customize the cases based on data from the database.

It needs to have the facility to monitor data inside tables and the status of the UI.

The service catalog helped improve our organization by giving a good view of the flow for our microservices applications. It's important when we have different developers working on different services and having the trace and log features help the on-call person locate the microservice.

The application performance monitoring has also been useful. This module had a few functionalities that we needed for the application health check. This needs to have some more features to consolidate the view in one tree. We may need more of a one-stop shop on top of the dashboard, and that is missing in Datadog. We'd like to be able to scrap our existing monitoring tool.

The service catalog is very useful. We use this type of offering for our Microservices applications, and it gives a good view of flow. It is a must when we have different developers working on different services. Having the trace and log features have been useful in order to locate the microservice for the on-call person.

The dashboard is great. It is helpful to get a view of specific things that we need to monitor for our application. It has been a good way to watch specific things and add them together.

The application performance monitoring is an excellent aspect. This module had a few functionalities that we needed for the application health check. This needs to have some more features to consolidate the view into one tree, however.

The dashboard could be improved. It would be helpful to get a view of specific things that we need to monitor for our application. However, it was a good way to watch specific things and add them together.

The application performance monitoring module had very few functionalities that we needed for the application health check. This needs to have some more features to consolidate the view into one tree.

I've used the solution for one month. 

We previously used ITRS Geneos.

We are using the latest version of the solution. 

I'd rate the solution seven out of ten. 

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 Datadog for logs, APM, infrastructure monitoring, and lambda visibility.

We have built a number of critical dashboards that we display within our office for engineers to have a good understanding of the application performance, as well as business partners to understand at a high level the traffic flowing through the app.

We started with logging, as our primary monitor, and have shifted to APM to get a deeper understanding of what our system is doing, and how the changes we are making impact the apps.

Datadog has given us near-live visibility across our entire cloud platform. We are finally in a state where we are alerting our users about degraded performance well before the helpdesk tickets start rolling in.

We are making major architectural decisions based on the data we are getting from Datadog. It also gives us an idea of where the complexity really lies in some older, monolithic apps. 

We have used the APM endpoint monitoring to prioritize work on slower endpoints because we can see the total count, as well as the latency. That has been a big driver in our refactor work prioritization.

We have struggled to get more business-centric measures in our code to surface actual business values in our reports, but that is our next initiative.

We started with Log analytics in the beginning stages of our monitoring journey. Those were very insightful, but obviously only as useful as we made them with good logging practices.

The dashboards we created are core indicators of the health of our system, and it is one of the most reliable sources we have turned to, especially as we have seen APM metrics impacted several times lately. We can usually rely on logs to tell us what the apps are doing.

APM and Traces have been crucial to understanding how users are actually using the app. That drives a lot of our decisions around refactoring and focusing our limited engineering resources.

Continued improvement around cost and pricing model is needed. It is pretty complex and takes a fair amount of intimate knowledge to know exactly how turning on a single function is going to impact your bill, especially when you don't see the metrics for a day or two. 

We have recently had a number of issues with stability and delays on logging, monitoring, metric evaluation, and alerts. More often than not in the past month, it seems that we get the banner across the to of our dashboards that some service is impacted. They don't always show up on the incident page, either.

We have been using Datadog for two years.

Overall, it has been fairly stable for us. There are the occasional issues with importing data, that has usually been resolved in a short time. We have never had an issue where that data was lost, just delayed, and eventually backfilled. 

It seems (anecdotally, of course) that there have been a few more stability issues lately. We have noticed several days that we are getting in-app alert banners indicating that some metric or log ingestion was delayed, or the web app itself was experiencing severe slowness. 

Overall, these issues are resolved rather quickly - kudos to their engineering teams. I hear that they actually use Datadog to monitor Datadog. 

Datadog is very scalable but just watch the cost.

Technical support is hit and miss; there are a number of nuances to how this tool should be implemented, and it is difficult to re-explain how our infrastructure and applications are set up every time we need an in-depth investigation to understand what is broken.

Previously, we used AppDynamics. The pricing model didn't seem to fit with actual cloud spend. Now we may have swung the pendulum a little too far, and seem to be dealing with pricing on every facet of the application. 

The initial setup was pretty straightforward. Additional tweaks and configuration have been a bit more difficult as we get deeper and deeper into the guts of the integrations. Making sure we are keeping up with a rapid release schedule, and keeping our server clients in sync with our app packages has been troublesome. There have been some major changes in the APM that have introduced a number of bugs and broken some of our dashboards and alerts.

Our in-house team handled the deployment, with a lot of tickets created for the Datadog team.

ROI is difficult to measure completely. Our first year spend compared to our second and now going into the third year spend have been significantly different.

My advice is to really keep an eye on your overage costs, as they can spiral really fast. We turned on some additional span measures and didn't realize until it was too late that it had generated a ton.

Frankly, we love the visibility it gives us into our applications, but it is a bit cumbersome to ensure we are paying for the right stuff. Overall, the cost is worth it, as it helps us keep system-critical applications up and running, and reduces our detection and correction times significantly.

We evaluated Dynatrace and AppD before choosing this product.

Datadog requires pretty close supervision on the usage page to ensure you aren't going out of control. They have provided a bunch of new features to assist in retention percentage, but it can be a bit confusing on what is being retained, and what can be viewed again after triggering an alert. It's a difficult balance of making sure you are getting the right data for alerts, and still having the correct information still available for research after the fact.

We used Datadog to capture the salvatory of our AWS fleet of around 1,200 servers.

Datadog's ability to group and visualize the servers and the data makes it relatively easy for the root cause analysis.

Datadog lacks a deeper application-level insight. Their competitors had eclipsed them in offering ET functionality that was important to us. That's why we stopped using it and switched to New Relic.

Datadog's price is also high.

I have been using Datadog for about three years.

Stability really wasn't ever an issue. We didn't have any outages specific to Datadog where we couldn't get reports or insights to information. We were more concerned about the stability of our own systems and applications.

There was no issue with scaling as such. It didn't scale well only from the cost perspective.

Fortunately, because of the stability of the solution, we never had reasons to deal with technical support. Most of our interaction was with their product management, which was focused on the feature capability and ultimately pricing.

It didn't scale well from the cost perspective. We had a custom package deal.

We switched from Datadog to New Relic because it offered ET functionality. Datadog was traditionally born out of monitoring infrastructure. Over the years, they have improved their ability to give you insights at the application layer and to be considered under APM. New Relic really started at the application layer and has worked its way down. 

Ultimately, we were able to accept New Relic because coming from an operations team, infrastructure was more important. As our application became more complex, our application developers needed better insight. Because there is a significant overlap in the Venn diagram between Datadog and New Relic, we felt that the needs of the infrastructure team and the applications team could be met with New Relic and its expansion in providing a sort of lightweight security.

Datadog started off at the infrastructure level, and New Relic started off at the application level. Both of them were expanding not only into each other's space but also into the SIM space.

There are a lot of options out there. For folks like me, it becomes a costly proposition because, at the end of the day, we're talking about logs, events that get pushed out. I have to push out some to Datadog and some to the security event manager. Then you start to think why can't you just push them to one place and let a product do that. That's where these products are trying to grow. They're not quite there yet because the SIM space is pretty mature. An enterprise like ours needs something fully focused and dedicated. Startups can live with New Relic that has a security capability or Datadog.

I would advise you to really understand the value that you're trying to go after. Make sure that you're not trying to solve all problems that you have from the observability perspective with Datadog because that will erode the value you get out of this solution.

Make sure that you are going to use Datadog for infrastructure, and it is going to be great. If you start adding other kinds of stuff to it, you'll probably start losing some of that value. Especially, if you want to go for application-level monitoring, you may be a bit disappointed.

I would rate this solution a six out of ten. I'm a very price-conscious kind of purchaser.

We primarily use Datadog for alerts. If we're running out of database connections or CPU credits we want to find out in Slack. Datadog provides nice features for that.

Secondarily, we use Datadog for analyzing historical trends and forecasting potential issues.

I'm trying to learn how to add in Continuous Profiler in our primary backend servers and set up Synthetic Tests for monitoring our front end.

Everything is mostly on AWS, and the Datadog integrations help a ton.

Datadog has helped us a ton by allowing us to set up a multitude of easily configurable alarms across our tech stack and infrastructure. It doesn't matter if it's in AWS Lambda or a Docker container in AWS EC2, Datadog's intuitive interface makes alarms incredibly easy to configure, reducing our resolution time for incidents.

A lot of the value comes from how frictionless the integrations are. Adding in a Datadog agent or flipping a switch on the Datadog UI to start streaming Lambda data makes the product so incredibly appealing for my company.

The monitoring feature has been the most valuable.

I really like the dashboard. Monitoring has a straightforward tie-in to business value at my company (i.e. declaring incidents, etc). Things like having a dashboard and APM make my job easier. That said DevX is a little bit of a harder sell to executives in my company.

The dashboard feature makes it so easy to inspect multiple metrics at once across services. It's truly been a lifesaver when I'm personally trying to understand why performance degradation is happening.

I found the documentation can sometimes be confusing. I tried configuring APM for some of our Python containers, and I had to cross-reference multiple blog posts and the official documentation to figure out which Datadog-agent to use. If I needed a ddtrace trace, what environment variables I should set, etc. 

Furthermore, to generate my own traces, I wasn't aware that ddtrace adds its own "monkey patching," which led to headaches with respect to configuring the service for RabbitMQ.

A more unified and up-to-date documentation suite would be greatly appreciated.

I've used the solution for about two years.

I don't recall seeing an incident from Datadog in the past couple of years and that's been wonderful.

The solution is incredibly scalable! To be fair, our data throughput to Datadog isn't super huge, however, we have never seen issues as it scaled to handle more of our data.

We used to use AWS Cloudwatch for a lot of our monitoring needs. That said, the interface felt clunky, confusing, and limited.

We don't have hard numbers on ROI. That said, overall, it has been a wonderful addition to our tooling suite.

We also looked at Honeycomb and are currently using both in production.

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 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. 

Our clients use it for monitoring applications. Its deployment depends on our customer's use case. 

It is 100% cloud. We have got a multi-tenant environment, so we segment it out.

It helps us to be more proactive. We can help customers with their e-commerce applications for any networking issues. We can also help them in any area from a development standpoint. It could be a non-prod environment where they're going through testing and various functionalities. It helps them be able to be more successful with their deployments.

The visibility that it provides is valuable. It is helping in being proactive around incident management. It is helping us to be able to get more visibility into our customers' applications so that we can assist them at the application layer. We also provide them the infrastructure from an AWS standpoint. We are able to make sure that our customers are aware of certain critical things around the analytical piece of either the network or the application. We're able to call customers before they even know about the issue. From there, we can start putting together some change management processes and help them a bit.

It can have a more modernized pricing mechanism. We're actually working with them to figure out how to become more modular and have a better and more modernized pricing mechanism. The issue with Datadog is that you have to buy the whole suite of different products, and you kind of get stuck in the old utilization of 40% of their suite. Most organizations today break down between application development, networking, and security. Therefore, there should be a way to break down different modules into just app dev, infosec, networking, etc. Customers have various needs across their business lines, and sometimes, they're just not willing to have tools that they're not using 100%. AppDynamics is probably a little bit better in terms of being modular.

I have been using this solution for almost four years.

We haven't lost any customers for Datadog. It must be stable.

As long as you're willing to pay for 100% but utilize only 40%, it can scale and do anything you want. In an organization, its users are usually the app group, the security group, and the network group.

We're certified in Datadog, and we have our own internal engineers to support the customers. We handle steps two and three.

It is usually pretty complex. 

It has a module-based pricing model.

I would advise others to review the overall functionality. If you're looking for different APN tools, then Datadog is a good tool. If you're not looking for it to handle all aspects of your environment and your application from the security infrastructure aspect, there are other tools out there that you could possibly utilize for each one of those areas. 

We do a lot of proof of concepts in helping our customers understand the micro and macro pieces of deployment. We're able to be a true advocate and value-add for our customers in utilizing the tool.

I would rate Datadog a seven out of ten. This space is a very competitive space, and a lot of organizations are trying to figure out how to become better in the full life cycle of a deployment. There'll be a lot of changes for different companies going forward.