Alternatives to Datadog logo

Alternatives to Datadog

New Relic, Splunk, Prometheus, Grafana, and AppDynamics are the most popular alternatives and competitors to Datadog.
2.2K
1.5K
+ 1
696

What is Datadog and what are its top alternatives?

Datadog is the leading service for cloud-scale monitoring. It is used by IT, operations, and development teams who build and operate applications that run on dynamic or hybrid cloud infrastructure. Start monitoring in minutes with Datadog!
Datadog is a tool in the Performance Monitoring category of a tech stack.

Datadog alternatives & related posts

New Relic logo

New Relic

14.5K
3K
1.9K
14.5K
3K
+ 1
1.9K
SaaS Application Performance Management for Ruby, PHP, .Net, Java, Python, and Node.js Apps.
New Relic logo
New Relic
VS
Datadog logo
Datadog

related New Relic posts

Sebastian G臋bski
Sebastian G臋bski
CTO at Shedul/Fresha | 4 upvotes 258.9K views
atFresha EngineeringFresha Engineering
CircleCI
CircleCI
Jenkins
Jenkins
Git
Git
GitHub
GitHub
New Relic
New Relic
AppSignal
AppSignal
Sentry
Sentry
Logentries
Logentries

Regarding Continuous Integration - we've started with something very easy to set up - CircleCI , but with time we're adding more & more complex pipelines - we use Jenkins to configure & run those. It's much more effort, but at some point we had to pay for the flexibility we expected. Our source code version control is Git (which probably doesn't require a rationale these days) and we keep repos in GitHub - since the very beginning & we never considered moving out. Our primary monitoring these days is in New Relic (Ruby & SPA apps) and AppSignal (Elixir apps) - we're considering unifying it in New Relic , but this will require some improvements in Elixir app observability. For error reporting we use Sentry (a very popular choice in this class) & we collect our distributed logs using Logentries (to avoid semi-manual handling here).

See more
Julien DeFrance
Julien DeFrance
Principal Software Engineer at Tophatter | 3 upvotes 75.5K views
atStessaStessa
New Relic
New Relic
Datadog
Datadog
#APM

Which #APM / #Infrastructure #Monitoring solution to use?

The 2 major players in that space are New Relic and Datadog Both are very comparable in terms of pricing, capabilities (Datadog recently introduced APM as well).

In our use case, keeping the number of tools minimal was a major selection criteria.

As we were already using #NewRelic, my recommendation was to move to the pro tier so we would benefit from advanced APM features, synthetics, mobile & infrastructure monitoring. And gain 360 degree view of our infrastructure.

Few things I liked about New Relic: - Mobile App and push notificatin - Ease of setting up new alerts - Being notified via email and push notifications without requiring another alerting 3rd party solution

I've certainly seen use cases where NewRelic can also be used as an input data source for Datadog. Therefore depending on your use case, it might also be worth evaluating a joint usage of both solutions.

See more
Splunk logo

Splunk

162
88
0
162
88
+ 1
0
Search, monitor, analyze and visualize machine data
    Be the first to leave a pro
    Splunk logo
    Splunk
    VS
    Datadog logo
    Datadog

    related Splunk posts

    Kibana
    Kibana
    Splunk
    Splunk
    Grafana
    Grafana

    I use Kibana because it ships with the ELK stack. I don't find it as powerful as Splunk however it is light years above grepping through log files. We previously used Grafana but found it to be annoying to maintain a separate tool outside of the ELK stack. We were able to get everything we needed from Kibana.

    See more
    Prometheus logo

    Prometheus

    1K
    725
    183
    1K
    725
    + 1
    183
    An open-source service monitoring system and time series database, developed by SoundCloud
    Prometheus logo
    Prometheus
    VS
    Datadog logo
    Datadog

    related Prometheus posts

    Conor Myhrvold
    Conor Myhrvold
    Tech Brand Mgr, Office of CTO at Uber | 10 upvotes 674.8K views
    atUber TechnologiesUber Technologies
    Prometheus
    Prometheus
    Graphite
    Graphite
    Grafana
    Grafana
    Nagios
    Nagios

    Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:

    By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node鈥檚 disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.

    To ensure the scalability of Uber鈥檚 metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...

    https://eng.uber.com/m3/

    (GitHub : https://github.com/m3db/m3)

    See more
    Raja Subramaniam Mahali
    Raja Subramaniam Mahali
    Prometheus
    Prometheus
    Kubernetes
    Kubernetes
    Sysdig
    Sysdig

    We have Prometheus as a monitoring engine as a part of our stack which contains Kubernetes cluster, container images and other open source tools. Also, I am aware that Sysdig can be integrated with Prometheus but I really wanted to know whether Sysdig or sysdig+prometheus will make better monitoring solution.

    See more

    related Grafana posts

    Conor Myhrvold
    Conor Myhrvold
    Tech Brand Mgr, Office of CTO at Uber | 10 upvotes 674.8K views
    atUber TechnologiesUber Technologies
    Prometheus
    Prometheus
    Graphite
    Graphite
    Grafana
    Grafana
    Nagios
    Nagios

    Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:

    By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node鈥檚 disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.

    To ensure the scalability of Uber鈥檚 metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...

    https://eng.uber.com/m3/

    (GitHub : https://github.com/m3db/m3)

    See more
    GK Palem
    GK Palem
    Grafana
    Grafana
    Kibana
    Kibana

    For our Predictive Analytics platform, we have used both Grafana and Kibana

    Kibana has predictions and ML algorithms support, so if you need them, you may be better off with Kibana . The multi-variate analysis features it provide are very unique (not available in Grafana).

    For everything else, definitely Grafana . Especially the number of supported data sources, and plugins clearly makes Grafana a winner (in just visualization and reporting sense). Creating your own plugin is also very easy. The top pros of Grafana (which it does better than Kibana ) are:

    • Creating and organizing visualization panels
    • Templating the panels on dashboards for repetetive tasks
    • Realtime monitoring, filtering of charts based on conditions and variables
    • Export / Import in JSON format (that allows you to version and save your dashboard as part of git)
    See more

    related Sentry posts

    Johnny Bell
    Johnny Bell
    Senior Software Engineer at StackShare | 10 upvotes 246.1K views
    React
    React
    JavaScript
    JavaScript
    LogRocket
    LogRocket
    Sentry
    Sentry
    Bugsnag
    Bugsnag
    Redux
    Redux
    #OpenSource
    #Chrome
    #OpenSorce
    #ErrorBoundry

    For my portfolio websites and my personal OpenSource projects I had started exclusively using React and JavaScript so I needed a way to track any errors that we're happening for my users that I didn't uncover during my personal UAT.

    I had narrowed it down to two tools LogRocket and Sentry (I also tried Bugsnag but it did not make the final two). Before I get into this I want to say that both of these tools are amazing and whichever you choose will suit your needs well.

    I firstly decided to go with LogRocket the fact that they had a recorded screen capture of what the user was doing when the bug happened was amazing... I could go back and rewatch what the user did to replicate that error, this was fantastic. It was also very easy to setup and get going. They had options for React and Redux.js so you can track all your Redux.js actions. I had a fairly large Redux.js store, this was ended up being a issue, it killed the processing power on my machine, Chrome ended up using 2-4gb of ram, so I quickly disabled the Redux.js option.

    After using LogRocket for a month or so I decided to switch to Sentry. I noticed that Sentry was openSorce and everyone was talking about Sentry so I thought I may as well give it a test drive. Setting it up was so easy, I had everything up and running within seconds. It also gives you the option to wrap an errorBoundry in React so get more specific errors. The simplicity of Sentry was a breath of fresh air, it allowed me find the bug that was shown to the user and fix that very simply. The UI for Sentry is beautiful and just really clean to look at, and their emails are also just perfect.

    I have decided to stick with Sentry for the long run, I tested pretty much all the JS error loggers and I find Sentry the best.

    See more

    related Elasticsearch posts

    Julien DeFrance
    Julien DeFrance
    Principal Software Engineer at Tophatter | 16 upvotes 518K views
    atSmartZipSmartZip
    Rails
    Rails
    Rails API
    Rails API
    AWS Elastic Beanstalk
    AWS Elastic Beanstalk
    Capistrano
    Capistrano
    Docker
    Docker
    Amazon S3
    Amazon S3
    Amazon RDS
    Amazon RDS
    MySQL
    MySQL
    Amazon RDS for Aurora
    Amazon RDS for Aurora
    Amazon ElastiCache
    Amazon ElastiCache
    Memcached
    Memcached
    Amazon CloudFront
    Amazon CloudFront
    Segment
    Segment
    Zapier
    Zapier
    Amazon Redshift
    Amazon Redshift
    Amazon Quicksight
    Amazon Quicksight
    Superset
    Superset
    Elasticsearch
    Elasticsearch
    Amazon Elasticsearch Service
    Amazon Elasticsearch Service
    New Relic
    New Relic
    AWS Lambda
    AWS Lambda
    Node.js
    Node.js
    Ruby
    Ruby
    Amazon DynamoDB
    Amazon DynamoDB
    Algolia
    Algolia

    Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.

    I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.

    For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.

    Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.

    Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.

    Future improvements / technology decisions included:

    Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic

    As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.

    One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.

    See more
    Tim Specht
    Tim Specht
    鈥嶤o-Founder and CTO at Dubsmash | 16 upvotes 100.5K views
    atDubsmashDubsmash
    Elasticsearch
    Elasticsearch
    Algolia
    Algolia
    Memcached
    Memcached
    #SearchAsAService

    Although we were using Elasticsearch in the beginning to power our in-app search, we moved this part of our processing over to Algolia a couple of months ago; this has proven to be a fantastic choice, letting us build search-related features with more confidence and speed.

    Elasticsearch is only used for searching in internal tooling nowadays; hosting and running it reliably has been a task that took up too much time for us in the past and fine-tuning the results to reach a great user-experience was also never an easy task for us. With Algolia we can flexibly change ranking methods on the fly and can instead focus our time on fine-tuning the experience within our app.

    Memcached is used in front of most of the API endpoints to cache responses in order to speed up response times and reduce server-costs on our side.

    #SearchAsAService

    See more
    LogicMonitor logo

    LogicMonitor

    17
    26
    12
    17
    26
    + 1
    12
    SaaS-based, automated IT performance monitoring platform for On-Premise, Hybrid, and Cloud infrastructures.
    LogicMonitor logo
    LogicMonitor
    VS
    Datadog logo
    Datadog
    SignalFx logo

    SignalFx

    20
    32
    10
    20
    32
    + 1
    10
    Monitoring and Operational Intelligence for the Cloud
    SignalFx logo
    SignalFx
    VS
    Datadog logo
    Datadog
    AppOptics logo

    AppOptics

    3
    1
    0
    3
    1
    + 1
    0
    APM with distributed tracing, infrastructure monitoring, and custom metrics, all in one place.
      Be the first to leave a pro
      AppOptics logo
      AppOptics
      VS
      Datadog logo
      Datadog
      ruxit logo

      ruxit

      246
      15
      5
      246
      15
      + 1
      5
      Full stack availability and performance monitoring powered by artificial intelligence
      ruxit logo
      ruxit
      VS
      Datadog logo
      Datadog
      Librato logo

      Librato

      97
      46
      31
      97
      46
      + 1
      31
      Real-Time Cloud Monitoring
      Librato logo
      Librato
      VS
      Datadog logo
      Datadog
      Azure Application Insights logo

      Azure Application Insights

      85
      50
      0
      85
      50
      + 1
      0
      It is an extensible Application Performance Management (APM) service for web developers
        Be the first to leave a pro
        Azure Application Insights logo
        Azure Application Insights
        VS
        Datadog logo
        Datadog

        related Skylight posts

        Jerome Dalbert
        Jerome Dalbert
        Senior Backend Engineer at StackShare | 3 upvotes 47.4K views
        atStackShareStackShare
        Heroku
        Heroku
        New Relic
        New Relic
        Skylight
        Skylight
        Rails
        Rails
        Pingdom
        Pingdom
        Slack
        Slack

        We currently monitor performance with the following tools:

        1. Heroku Metrics: our main app is Hosted on Heroku, so it is the best place to get quick server metrics like memory usage, load averages, or response times.
        2. Good old New Relic for detailed general metrics, including transaction times.
        3. Skylight for more specific Rails Controller#action transaction times. Navigating those timings is much better than with New Relic, as you get a clear full breakdown of everything that happens for a given request.

        Skylight offers better Rails performance insights, so why use New Relic? Because it does frontend monitoring, while Skylight doesn't. Now that we have a separate frontend app though, our frontend engineers are looking into more specialized frontend monitoring solutions.

        Finally, if one of our apps go down, Pingdom alerts us on Slack and texts some of us.

        See more
        phpMyAdmin logo

        phpMyAdmin

        69
        34
        0
        69
        34
        + 1
        0
        A free software, for MySQL and MariaDB
          Be the first to leave a pro
          phpMyAdmin logo
          phpMyAdmin
          VS
          Datadog logo
          Datadog

          related AppSignal posts

          Sebastian G臋bski
          Sebastian G臋bski
          CTO at Shedul/Fresha | 4 upvotes 258.9K views
          atFresha EngineeringFresha Engineering
          CircleCI
          CircleCI
          Jenkins
          Jenkins
          Git
          Git
          GitHub
          GitHub
          New Relic
          New Relic
          AppSignal
          AppSignal
          Sentry
          Sentry
          Logentries
          Logentries

          Regarding Continuous Integration - we've started with something very easy to set up - CircleCI , but with time we're adding more & more complex pipelines - we use Jenkins to configure & run those. It's much more effort, but at some point we had to pay for the flexibility we expected. Our source code version control is Git (which probably doesn't require a rationale these days) and we keep repos in GitHub - since the very beginning & we never considered moving out. Our primary monitoring these days is in New Relic (Ruby & SPA apps) and AppSignal (Elixir apps) - we're considering unifying it in New Relic , but this will require some improvements in Elixir app observability. For error reporting we use Sentry (a very popular choice in this class) & we collect our distributed logs using Logentries (to avoid semi-manual handling here).

          See more
          Scout logo

          Scout

          60
          43
          26
          60
          43
          + 1
          26
          Application Monitoring that Developers Love
          Scout logo
          Scout
          VS
          Datadog logo
          Datadog
          Blackfire.io logo

          Blackfire.io

          35
          29
          9
          35
          29
          + 1
          9
          Blackfire Profiler automatically instruments your code to gather data about consumed server resources like memory, CPU time, and...