Convert Figma logo to code with AI

census-instrumentation logoopencensus-go

A stats collection and distributed tracing framework

2,053
326
2,053
108

Top Related Projects

OpenTracing API for Go. 🛑 This library is DEPRECATED! https://github.com/opentracing/specification/issues/163

OpenTelemetry Go API and SDK

21,647

Blazing fast, structured, leveled logging in Go.

24,520

Structured, pluggable logging for Go.

Prometheus instrumentation library for Go applications

Quick Overview

OpenCensus Go is an open-source library for metrics collection and distributed tracing. It provides a set of APIs to instrument Go applications for collecting telemetry data, which can be exported to various backends for analysis and visualization.

Pros

  • Easy integration with existing Go applications
  • Supports multiple exporters for various monitoring and tracing systems
  • Provides both metrics and distributed tracing capabilities
  • Offers a vendor-neutral approach to observability

Cons

  • Learning curve for developers new to observability concepts
  • Some features may require additional configuration
  • Limited built-in visualization tools (relies on external systems)
  • Project is in maintenance mode, with active development shifted to OpenTelemetry

Code Examples

  1. Creating a simple span:
import "go.opencensus.io/trace"

ctx, span := trace.StartSpan(context.Background(), "MyOperation")
defer span.End()

// Perform your operation here
  1. Recording a metric:
import "go.opencensus.io/stats"
import "go.opencensus.io/stats/view"

var mLatency = stats.Float64("latency", "The latency in milliseconds", "ms")

func init() {
    view.Register(&view.View{
        Name:        "task_latency",
        Measure:     mLatency,
        Description: "The distribution of the task latencies",
        Aggregation: view.Distribution(0, 25, 50, 75, 100, 200, 400, 800, 1000, 2000, 4000, 8000, 16000),
    })
}

// Record the latency
stats.Record(ctx, mLatency.M(64.25))
  1. Setting up an exporter:
import "contrib.go.opencensus.io/exporter/prometheus"

exporter, err := prometheus.NewExporter(prometheus.Options{})
if err != nil {
    log.Fatal(err)
}
view.RegisterExporter(exporter)

Getting Started

To start using OpenCensus Go in your project:

  1. Install the library:

    go get -u go.opencensus.io
    
  2. Import the necessary packages in your Go code:

    import (
        "go.opencensus.io/stats"
        "go.opencensus.io/stats/view"
        "go.opencensus.io/trace"
    )
    
  3. Instrument your code using the OpenCensus APIs for tracing and metrics.

  4. Set up an exporter to send the collected data to your preferred backend.

  5. Run your application and start collecting telemetry data!

Competitor Comparisons

OpenTracing API for Go. 🛑 This library is DEPRECATED! https://github.com/opentracing/specification/issues/163

Pros of OpenTracing

  • More widespread adoption and community support
  • Flexible and vendor-neutral API design
  • Extensive language support beyond Go

Cons of OpenTracing

  • Less integrated with other observability components (metrics, logs)
  • Requires more manual configuration and setup
  • Lacks some advanced features present in OpenCensus

Code Comparison

OpenTracing:

span := opentracing.StartSpan("operation_name")
defer span.Finish()

span.SetTag("key", "value")
span.LogFields(
    log.String("event", "soft error"),
    log.Int("retry", 3),
)

OpenCensus:

ctx, span := trace.StartSpan(ctx, "operation_name")
defer span.End()

span.AddAttributes(trace.StringAttribute("key", "value"))
span.Annotate([]trace.Attribute{
    trace.StringAttribute("event", "soft error"),
    trace.Int64Attribute("retry", 3),
}, "")

Both libraries provide similar functionality for creating and managing spans, but OpenCensus integrates more tightly with other observability features. OpenTracing offers a more flexible API, while OpenCensus provides a more opinionated and integrated approach to instrumentation.

OpenTelemetry Go API and SDK

Pros of OpenTelemetry Go

  • More comprehensive and unified approach to observability, combining metrics, tracing, and logging
  • Broader industry support and adoption, leading to better long-term sustainability
  • More flexible and extensible architecture, allowing for easier customization and integration

Cons of OpenTelemetry Go

  • Steeper learning curve due to its more comprehensive nature
  • Potentially higher overhead in some scenarios, as it covers a wider range of observability features

Code Comparison

OpenCensus Go:

import "go.opencensus.io/trace"

span := trace.NewSpan("my-span")
defer span.End()

OpenTelemetry Go:

import "go.opentelemetry.io/otel/trace"

ctx, span := tracer.Start(ctx, "my-span")
defer span.End()

The main difference in the code is that OpenTelemetry uses a context-based approach, which allows for better propagation of trace context across different parts of the application. OpenCensus, on the other hand, uses a more straightforward span creation method.

OpenTelemetry Go provides a more modern and flexible API, but it may require more setup and configuration compared to OpenCensus Go. However, the additional complexity comes with the benefit of a more powerful and extensible observability framework.

21,647

Blazing fast, structured, leveled logging in Go.

Pros of zap

  • Extremely fast and efficient logging with minimal allocations
  • Highly customizable with flexible logging levels and field types
  • Supports structured logging out of the box

Cons of zap

  • Focused solely on logging, lacks tracing and metrics capabilities
  • Steeper learning curve compared to simpler logging libraries
  • Requires more setup and configuration for optimal performance

Code Comparison

zap:

logger, _ := zap.NewProduction()
defer logger.Sync()
logger.Info("Failed to fetch URL",
    zap.String("url", url),
    zap.Int("attempt", attempt),
    zap.Duration("backoff", backoff),
)

opencensus-go:

stats.Record(ctx, MLatencyMs.M(75))
span := trace.FromContext(ctx)
span.Annotate([]trace.Attribute{
    trace.StringAttribute("key", "value"),
}, "something happened")

Summary

zap is a high-performance, structured logging library for Go, offering excellent speed and flexibility. It excels in logging scenarios but lacks the tracing and metrics capabilities found in opencensus-go. opencensus-go provides a more comprehensive observability solution, including distributed tracing and metrics collection, but may be overkill for projects only requiring logging functionality. Choose zap for projects prioritizing efficient logging, and opencensus-go for full observability needs.

24,520

Structured, pluggable logging for Go.

Pros of Logrus

  • Simpler and more focused on logging, making it easier to integrate into existing projects
  • Offers a wide range of formatters and hooks for customizing log output
  • Provides a familiar API similar to the standard library's log package

Cons of Logrus

  • Limited to logging functionality, lacking the broader observability features of OpenCensus
  • May require additional libraries or tools for advanced metrics and tracing capabilities
  • Less suitable for distributed systems monitoring compared to OpenCensus

Code Comparison

Logrus:

log := logrus.New()
log.WithFields(logrus.Fields{
    "animal": "walrus",
}).Info("A walrus appears")

OpenCensus:

stats.Record(ctx, MeasureLatency.M(100))
span := trace.FromContext(ctx)
span.Annotate([]trace.Attribute{
    trace.StringAttribute("key", "value"),
}, "something happened")

Summary

Logrus is a popular logging library for Go, offering enhanced logging capabilities with a familiar API. It's ideal for projects primarily focused on logging. OpenCensus, on the other hand, provides a more comprehensive observability solution, including metrics and tracing, making it better suited for distributed systems and complex monitoring needs. The choice between the two depends on the specific requirements of your project and the depth of observability features needed.

Prometheus instrumentation library for Go applications

Pros of client_golang

  • More mature and widely adopted in the Prometheus ecosystem
  • Extensive documentation and community support
  • Built-in support for Prometheus-specific features like histograms and summaries

Cons of client_golang

  • Limited to Prometheus-specific metrics and data model
  • Less flexibility for supporting multiple backends or exporters
  • Steeper learning curve for developers new to Prometheus

Code Comparison

opencensus-go:

import "go.opencensus.io/stats"

m := stats.Float64("my_metric", "A description", "unit")
stats.Record(ctx, m.M(42.0))

client_golang:

import "github.com/prometheus/client_golang/prometheus"

gauge := prometheus.NewGauge(prometheus.GaugeOpts{
    Name: "my_metric",
    Help: "A description",
})
gauge.Set(42.0)

Summary

opencensus-go offers a more flexible and vendor-neutral approach to instrumentation, supporting multiple backends and exporters. It's designed to be part of a larger observability framework.

client_golang is specifically tailored for Prometheus, providing deep integration with its features and ecosystem. It's ideal for projects already committed to Prometheus or those seeking a mature, well-supported solution for metrics in Go.

The choice between the two depends on your specific requirements, existing infrastructure, and future scalability needs.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Warning

OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing.

OpenTelemetry has now reached feature parity with OpenCensus, with tracing and metrics SDKs available in .NET, Golang, Java, NodeJS, and Python. All OpenCensus Github repositories, except census-instrumentation/opencensus-python, will be archived on July 31st, 2023. We encourage users to migrate to OpenTelemetry by this date.

To help you gradually migrate your instrumentation to OpenTelemetry, bridges are available in Java, Go, Python, and JS. Read the full blog post to learn more.

OpenCensus Libraries for Go

Build Status Windows Build Status GoDoc Gitter chat

OpenCensus Go is a Go implementation of OpenCensus, a toolkit for collecting application performance and behavior monitoring data. Currently it consists of three major components: tags, stats and tracing.

OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing. OpenTelemetry will offer backwards compatibility with existing OpenCensus integrations, and we will continue to make security patches to existing OpenCensus libraries for two years. Read more about the merger here.

Installation

$ go get -u go.opencensus.io

The API of this project is still evolving, see: Deprecation Policy. The use of vendoring or a dependency management tool is recommended.

Prerequisites

OpenCensus Go libraries require Go 1.8 or later.

Getting Started

The easiest way to get started using OpenCensus in your application is to use an existing integration with your RPC framework:

If you're using a framework not listed here, you could either implement your own middleware for your framework or use custom stats and spans directly in your application.

Exporters

OpenCensus can export instrumentation data to various backends. OpenCensus has exporter implementations for the following, users can implement their own exporters by implementing the exporter interfaces (stats, trace):

Overview

OpenCensus Overview

In a microservices environment, a user request may go through multiple services until there is a response. OpenCensus allows you to instrument your services and collect diagnostics data all through your services end-to-end.

Tags

Tags represent propagated key-value pairs. They are propagated using context.Context in the same process or can be encoded to be transmitted on the wire. Usually, this will be handled by an integration plugin, e.g. ocgrpc.ServerHandler and ocgrpc.ClientHandler for gRPC.

Package tag allows adding or modifying tags in the current context.

ctx, err := tag.New(ctx,
	tag.Insert(osKey, "macOS-10.12.5"),
	tag.Upsert(userIDKey, "cde36753ed"),
)
if err != nil {
	log.Fatal(err)
}

Stats

OpenCensus is a low-overhead framework even if instrumentation is always enabled. In order to be so, it is optimized to make recording of data points fast and separate from the data aggregation.

OpenCensus stats collection happens in two stages:

  • Definition of measures and recording of data points
  • Definition of views and aggregation of the recorded data

Recording

Measurements are data points associated with a measure. Recording implicitly tags the set of Measurements with the tags from the provided context:

stats.Record(ctx, videoSize.M(102478))

Views

Views are how Measures are aggregated. You can think of them as queries over the set of recorded data points (measurements).

Views have two parts: the tags to group by and the aggregation type used.

Currently three types of aggregations are supported:

  • CountAggregation is used to count the number of times a sample was recorded.
  • DistributionAggregation is used to provide a histogram of the values of the samples.
  • SumAggregation is used to sum up all sample values.
distAgg := view.Distribution(1<<32, 2<<32, 3<<32)
countAgg := view.Count()
sumAgg := view.Sum()

Here we create a view with the DistributionAggregation over our measure.

if err := view.Register(&view.View{
	Name:        "example.com/video_size_distribution",
	Description: "distribution of processed video size over time",
	Measure:     videoSize,
	Aggregation: view.Distribution(1<<32, 2<<32, 3<<32),
}); err != nil {
	log.Fatalf("Failed to register view: %v", err)
}

Register begins collecting data for the view. Registered views' data will be exported via the registered exporters.

Traces

A distributed trace tracks the progression of a single user request as it is handled by the services and processes that make up an application. Each step is called a span in the trace. Spans include metadata about the step, including especially the time spent in the step, called the span’s latency.

Below you see a trace and several spans underneath it.

Traces and spans

Spans

Span is the unit step in a trace. Each span has a name, latency, status and additional metadata.

Below we are starting a span for a cache read and ending it when we are done:

ctx, span := trace.StartSpan(ctx, "cache.Get")
defer span.End()

// Do work to get from cache.

Propagation

Spans can have parents or can be root spans if they don't have any parents. The current span is propagated in-process and across the network to allow associating new child spans with the parent.

In the same process, context.Context is used to propagate spans. trace.StartSpan creates a new span as a root if the current context doesn't contain a span. Or, it creates a child of the span that is already in current context. The returned context can be used to keep propagating the newly created span in the current context.

ctx, span := trace.StartSpan(ctx, "cache.Get")
defer span.End()

// Do work to get from cache.

Across the network, OpenCensus provides different propagation methods for different protocols.

Execution Tracer

With Go 1.11, OpenCensus Go will support integration with the Go execution tracer. See Debugging Latency in Go for an example of their mutual use.

Profiles

OpenCensus tags can be applied as profiler labels for users who are on Go 1.9 and above.

ctx, err = tag.New(ctx,
	tag.Insert(osKey, "macOS-10.12.5"),
	tag.Insert(userIDKey, "fff0989878"),
)
if err != nil {
	log.Fatal(err)
}
tag.Do(ctx, func(ctx context.Context) {
	// Do work.
	// When profiling is on, samples will be
	// recorded with the key/values from the tag map.
})

A screenshot of the CPU profile from the program above:

CPU profile

Deprecation Policy

Before version 1.0.0, the following deprecation policy will be observed:

No backwards-incompatible changes will be made except for the removal of symbols that have been marked as Deprecated for at least one minor release (e.g. 0.9.0 to 0.10.0). A release removing the Deprecated functionality will be made no sooner than 28 days after the first release in which the functionality was marked Deprecated.