Datadog Reviews

We use the solution for monitoring, logging, and alerts. 

Thanks to Datadog, we report errors using the logger integrated into our services, which is crucial since we only do unit tests. The infrastructure team handles the monitoring part, so I can't give more insights about that. I am an API developer, so I use Datadog mainly for logging.

The alerts are connected to Microsoft Teams in a specific channel, and we pay a lot of attention to it, and we usually create tickets based on these alerts.

Thanks to the logs, we manage to make better reports through Jira and also to trace the request with more facility than we would be able to do otherwise. 

Since there are many teams in my company, the fact that we can share the trace of an error, for example, together with all the information about the log, we are able to save a lot of time when it comes to communication between everyone.

The most valuable feature for me so far is logging. We do not do integration tests, so we rely a lot on tracing all the requests and we report errors to different teams in the company together with logs that we take from Datadog.

Since I am an API developer, I do not use so much with the other features. Also, I have been in the company for only four months. I have only worked with monitors and alters.

I value tracing the request and being able to tell other teams which component, service, or line of code has an issue.

Since I have only been in the organization for four months, I only worked with the log, alerts, and monitoring. I do not have so many insights to share about what can be improved.

I am not an expert user, and not even an intermediate user yet. Rather, I am a beginner.

That said when the logs are too big, and Datadog splits them, the JSON format breaks and it is not so useful for us.

I've used the solution for four months.

I did not previously use a different solution.

I will get informed about this, I have no idea about costs as an API developer. But I get curious about it

I did not evaluate other options previously.

The RUM is implemented for customer support session replays to quickly route, triage, and troubleshoot support issues which can be sent to our engineering teams directly. 

Customer Support will log in directly after receiving a customer request and work on the issue. Engineers will utilize the replay along with RUM to pinpoint the issue combined with APM and Infra trace to be able to look for signals to find the direct cause of the customer impact. 

Incident management will be utilized to open a Jira ticket for engineering, and it integrates with ITSM systems and on-call as needed.

The RUM solution has improved our ability to triage faster and hand more capabilities to our customer support.

The RUM is implemented for customer support. It can quickly route, triage, and troubleshoot support issues that are sent to our engineering teams. 

Customer support can log in and start troubleshooting after receiving a customer request. The replay and RUM help pinpoint the issue. This functionality is combined with APM and Infra trace to be able to look for the cause of the issue. Incident management is leveraged to open a Jira ticket for engineering, and it can integrate with ITSM systems and on-call as needed.

RUM with session replay combined with a future use case to support synthetics will help to identify issues earlier in our process. We have not rolled this out yet but plan for it as a future use case for our customer support process. This, combined with integrated automation for incident management, will drive down our MTTR and time spent working through tickets. Overall, we are hoping to use this to look at our data and perfection rate over time in a BI-like way to reduce our customer support headcount by saving on time spent.

I would like to see retention options greater than 30-days for session replay. I'd also like to see forwarding options for retention to custom solutions, and a greater ability to event and export data from the tooling overall to BI/DW solutions for reporting across the long term and to see trends as needed.

I've used the solution for about nine months.

So far, stability has been great.

I'd like to see more bells and whistles added over time. Widgets are coming soon to help with RUM.

Support is very good. They are responsive and gave us the help we need.

Positive

We have utilized New Relic, however, not for RUM. We went with Datadog to potentially switch the entire platform into an all-in-one solution that makes sense for a company of our size.

We started on the beta, and the documentation was lagging behind. We also needed direct instructions and links from the customer support/account representative that was not immediately available by searching online.

We implemented the solution ourselves.

Ideally, this will inform our strategy to not increase our customer support headcount as significantly into 2023 and beyond.

The pricing is a bit confusing. However, the RUM session replay, in general, is very inexpensive compared to whole solutions.

We looked into LogRocket and New Relic.

I'd advise other users to try it out.

We collect all data logs from all operating systems, such as Windows, Linux, VMware, and bare metal data centers. We also automatize the installation of the agent on servers. 

Now we are starting a POC to analyze the APM module. In the feature, the next step is to do a POC of security modules. 

The final idea is to have a unique portal for observability. This will make it easy to troubleshoot and for layer levels 1 and 2. 

We are looking into a lot of modules. We collect all data logs from all operating systems, including Windows, Linux, VMware, and bare metal data centers. We also automatize the installation of the agent on servers. 

We're developing POCs for APM and security modules. We'll also have a unique portal for observability. This will make it easy to troubleshoot. 

The most valuable aspect is for us to have everything in one place.

We're investigating many modules. We collect all data logs from all operating systems (Windows, Linux, VMware, and bare metal data centers). We also automatize the installation of the agent on servers. 

We're doing POCs in APM and security. 

Soon, we'll have a unique portal for observability. This will make troubleshooting easy at levels 1 and 2. 

The most valuable aspect for us is to have everything in the same place.

We need a lot of modules since we collect all data logs from all operating systems. 

The most important module for us is log management. The second is the security module. The third one is the APM.

We've used the solution for one year.

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.