Alternatives to OpenCensus logo

Alternatives to OpenCensus

Prometheus, OpenTracing, Zipkin, Jaeger, and Istio are the most popular alternatives and competitors to OpenCensus.
37
19
+ 1
0

What is OpenCensus and what are its top alternatives?

It is a set of libraries for various languages that allow you to collect application metrics and distributed traces, then transfer the data to a backend of your choice in real time. This data can be analyzed by developers and admins to understand the health of the application and debug problems.
OpenCensus is a tool in the Monitoring Tools category of a tech stack.

Top Alternatives to OpenCensus

  • Prometheus

    Prometheus

    Prometheus is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true. ...

  • OpenTracing

    OpenTracing

    Consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation. ...

  • Zipkin

    Zipkin

    It helps gather timing data needed to troubleshoot latency problems in service architectures. Features include both the collection and lookup of this data. ...

  • Jaeger

    Jaeger

    Jaeger, a Distributed Tracing System

  • Istio

    Istio

    Istio is an open platform for providing a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies and aggregate telemetry data. Istio's control plane provides an abstraction layer over the underlying cluster management platform, such as Kubernetes, Mesos, etc. ...

  • New Relic

    New Relic

    The world’s best software and DevOps teams rely on New Relic to move faster, make better decisions and create best-in-class digital experiences. If you run software, you need to run New Relic. More than 50% of the Fortune 100 do too. ...

  • Kibana

    Kibana

    Kibana is an open source (Apache Licensed), browser based analytics and search dashboard for Elasticsearch. Kibana is a snap to setup and start using. Kibana strives to be easy to get started with, while also being flexible and powerful, just like Elasticsearch. ...

  • Grafana

    Grafana

    Grafana is a general purpose dashboard and graph composer. It's focused on providing rich ways to visualize time series metrics, mainly though graphs but supports other ways to visualize data through a pluggable panel architecture. It currently has rich support for for Graphite, InfluxDB and OpenTSDB. But supports other data sources via plugins. ...

OpenCensus alternatives & related posts

Prometheus logo

Prometheus

2.6K
3K
237
An open-source service monitoring system and time series database, developed by SoundCloud
2.6K
3K
+ 1
237
PROS OF PROMETHEUS
  • 46
    Powerful easy to use monitoring
  • 38
    Flexible query language
  • 32
    Dimensional data model
  • 27
    Alerts
  • 23
    Active and responsive community
  • 21
    Extensive integrations
  • 19
    Easy to setup
  • 12
    Beautiful Model and Query language
  • 7
    Easy to extend
  • 6
    Nice
  • 3
    Written in Go
  • 2
    Good for experimentation
  • 1
    Easy for monitoring
CONS OF PROMETHEUS
  • 12
    Just for metrics
  • 6
    Bad UI
  • 6
    Needs monitoring to access metrics endpoints
  • 4
    Not easy to configure and use
  • 3
    Supports only active agents
  • 2
    Written in Go
  • 2
    Requires multiple applications and tools
  • 2
    TLS is quite difficult to understand

related Prometheus posts

Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 14 upvotes · 3M views

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’s 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’s 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
Matt Menzenski
Senior Software Engineering Manager at PayIt · | 13 upvotes · 113.4K views

Grafana and Prometheus together, running on Kubernetes , is a powerful combination. These tools are cloud-native and offer a large community and easy integrations. At PayIt we're using exporting Java application metrics using a Dropwizard metrics exporter, and our Node.js services now use the prom-client npm library to serve metrics.

See more
OpenTracing logo

OpenTracing

83
89
0
Consistent, expressive, vendor-neutral APIs for distributed tracing and context propagation.
83
89
+ 1
0
PROS OF OPENTRACING
    Be the first to leave a pro
    CONS OF OPENTRACING
      Be the first to leave a con

      related OpenTracing posts

      Zipkin logo

      Zipkin

      95
      109
      9
      A distributed tracing system
      95
      109
      + 1
      9
      PROS OF ZIPKIN
      • 9
        Open Source
      CONS OF ZIPKIN
        Be the first to leave a con

        related Zipkin posts

        Jaeger logo

        Jaeger

        246
        347
        9
        Distributed tracing system released as open source by Uber
        246
        347
        + 1
        9
        PROS OF JAEGER
        • 4
          Open Source
        • 2
          Easy to install
        • 2
          CNCF Project
        • 1
          Feature Rich UI
        CONS OF JAEGER
          Be the first to leave a con

          related Jaeger posts

          Istio logo

          Istio

          664
          1.2K
          44
          Open platform to connect, manage, and secure microservices, by Google, IBM, and Lyft
          664
          1.2K
          + 1
          44
          PROS OF ISTIO
          • 13
            Zero code for logging and monitoring
          • 8
            Service Mesh
          • 7
            Great flexibility
          • 4
            Ingress controller
          • 3
            Resiliency
          • 3
            Easy integration with Kubernetes and Docker
          • 3
            Full Security
          • 3
            Powerful authorization mechanisms
          CONS OF ISTIO
          • 13
            Performance

          related Istio posts

          Anas MOKDAD
          Shared insights
          on
          KongKongIstioIstio

          As for the new support of service mesh pattern by Kong, I wonder how does it compare to Istio?

          See more
          New Relic logo

          New Relic

          18.6K
          6.9K
          1.9K
          New Relic is the industry’s largest and most comprehensive cloud-based observability platform.
          18.6K
          6.9K
          + 1
          1.9K
          PROS OF NEW RELIC
          • 415
            Easy setup
          • 344
            Really powerful
          • 244
            Awesome visualization
          • 194
            Ease of use
          • 151
            Great ui
          • 107
            Free tier
          • 81
            Great tool for insights
          • 66
            Heroku Integration
          • 55
            Market leader
          • 49
            Peace of mind
          • 21
            Push notifications
          • 20
            Email notifications
          • 17
            Heroku Add-on
          • 16
            Error Detection and Alerting
          • 12
            Multiple language support
          • 11
            SQL Analysis
          • 11
            Server Resources Monitoring
          • 9
            Transaction Tracing
          • 8
            Apdex Scores
          • 8
            Azure Add-on
          • 7
            Analysis of CPU, Disk, Memory, and Network
          • 6
            Detailed reports
          • 6
            Performance of External Services
          • 6
            Error Analysis
          • 6
            Application Availability Monitoring and Alerting
          • 6
            Application Response Times
          • 5
            JVM Performance Analyzer (Java)
          • 5
            Most Time Consuming Transactions
          • 4
            Top Database Operations
          • 4
            Easy to use
          • 4
            Browser Transaction Tracing
          • 3
            Application Map
          • 3
            Pagoda Box integration
          • 3
            Custom Dashboards
          • 3
            Weekly Performance Email
          • 2
            Easy visibility
          • 2
            App Speed Index
          • 2
            Easy to setup
          • 1
            Real User Monitoring Analysis and Breakdown
          • 1
            Incident Detection and Alerting
          • 1
            Real User Monitoring Overview
          • 1
            Worst Transactions by User Dissatisfaction
          • 1
            Metric Data Resolution
          • 1
            Metric Data Retention
          • 1
            Team Collaboration Tools
          • 1
            Super Expensive
          • 1
            Time Comparisons
          • 1
            Access to Performance Data API
          • 1
            Background Jobs Transaction Analysis
          • 1
            Free
          • 1
            Best of the best, what more can you ask for
          • 1
            Best monitoring on the market
          • 1
            Rails integration
          • 0
            Exceptions
          • 0
            Ddd
          CONS OF NEW RELIC
          • 19
            Pricing model doesn't suit microservices
          • 10
            UI isn't great
          • 7
            Visualizations aren't very helpful
          • 7
            Expensive
          • 5
            Hard to understand why things in your app are breaking

          related New Relic posts

          Farzeem Diamond Jiwani
          Software Engineer at IVP · | 5 upvotes · 697K views

          Hey there! We are looking at Datadog, Dynatrace, AppDynamics, and New Relic as options for our web application monitoring.

          Current Environment: .NET Core Web app hosted on Microsoft IIS

          Future Environment: Web app will be hosted on Microsoft Azure

          Tech Stacks: IIS, RabbitMQ, Redis, Microsoft SQL Server

          Requirement: Infra Monitoring, APM, Real - User Monitoring (User activity monitoring i.e., time spent on a page, most active page, etc.), Service Tracing, Root Cause Analysis, and Centralized Log Management.

          Please advise on the above. Thanks!

          See more
          Sebastian Gębski

          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
          Kibana logo

          Kibana

          15.4K
          12K
          255
          Visualize your Elasticsearch data and navigate the Elastic Stack
          15.4K
          12K
          + 1
          255
          PROS OF KIBANA
          • 88
            Easy to setup
          • 61
            Free
          • 44
            Can search text
          • 21
            Has pie chart
          • 13
            X-axis is not restricted to timestamp
          • 8
            Easy queries and is a good way to view logs
          • 6
            Supports Plugins
          • 3
            More "user-friendly"
          • 3
            Can build dashboards
          • 3
            Dev Tools
          • 2
            Easy to drill-down
          • 2
            Out-of-Box Dashboards/Analytics for Metrics/Heartbeat
          • 1
            Up and running
          CONS OF KIBANA
          • 5
            Unintuituve
          • 3
            Elasticsearch is huge
          • 3
            Works on top of elastic only
          • 2
            Hardweight UI

          related Kibana posts

          Tymoteusz Paul
          Devops guy at X20X Development LTD · | 23 upvotes · 4.8M views

          Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

          It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

          I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

          We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

          If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

          The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

          Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

          See more
          Patrick Sun
          Software Engineer at Stitch Fix · | 11 upvotes · 479.2K views

          Elasticsearch's built-in visualization tool, Kibana, is robust and the appropriate tool in many cases. However, it is geared specifically towards log exploration and time-series data, and we felt that its steep learning curve would impede adoption rate among data scientists accustomed to writing SQL. The solution was to create something that would replicate some of Kibana's essential functionality while hiding Elasticsearch's complexity behind SQL-esque labels and terminology ("table" instead of "index", "group by" instead of "sub-aggregation") in the UI.

          Elasticsearch's API is really well-suited for aggregating time-series data, indexing arbitrary data without defining a schema, and creating dashboards. For the purpose of a data exploration backend, Elasticsearch fits the bill really well. Users can send an HTTP request with aggregations and sub-aggregations to an index with millions of documents and get a response within seconds, thus allowing them to rapidly iterate through their data.

          See more
          Grafana logo

          Grafana

          11.5K
          9K
          399
          Open source Graphite & InfluxDB Dashboard and Graph Editor
          11.5K
          9K
          + 1
          399
          PROS OF GRAFANA
          • 84
            Beautiful
          • 67
            Graphs are interactive
          • 56
            Free
          • 55
            Easy
          • 33
            Nicer than the Graphite web interface
          • 24
            Many integrations
          • 16
            Can build dashboards
          • 10
            Easy to specify time window
          • 9
            Dashboards contain number tiles
          • 8
            Can collaborate on dashboards
          • 5
            Open Source
          • 5
            Click and drag to zoom in
          • 5
            Integration with InfluxDB
          • 4
            Threshold limits in graphs
          • 4
            Authentification and users management
          • 3
            Simple and native support to Prometheus
          • 3
            It is open to cloud watch and many database
          • 2
            Great community support
          • 2
            Alerts
          • 2
            You can visualize real time data to put alerts
          • 2
            You can use this for development to check memcache
          • 0
            Grapsh as code
          • 0
            Plugin visualizationa
          CONS OF GRAFANA
            Be the first to leave a con

            related Grafana posts

            Conor Myhrvold
            Tech Brand Mgr, Office of CTO at Uber · | 14 upvotes · 3M views

            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’s 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’s 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
            Matt Menzenski
            Senior Software Engineering Manager at PayIt · | 13 upvotes · 113.4K views

            Grafana and Prometheus together, running on Kubernetes , is a powerful combination. These tools are cloud-native and offer a large community and easy integrations. At PayIt we're using exporting Java application metrics using a Dropwizard metrics exporter, and our Node.js services now use the prom-client npm library to serve metrics.

            See more