1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
moby--moby/vendor/go.opencensus.io
Derek McGowan 52ed3e0896
Update containerd to 1.1
Updates swarmkit, grpc, and all related vendors

Signed-off-by: Derek McGowan <derek@mcgstyle.net>
2018-06-04 15:37:03 -07:00
..
exporter/stackdriver/propagation
internal
plugin
stats
tag
trace
LICENSE
README.md

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.

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.

Exporters

OpenCensus can export instrumentation data to various backends. Currently, OpenCensus supports:

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.

Start with instrumenting HTTP and gRPC clients and servers, then add additional custom instrumentation if needed.

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(0, 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:        "my.org/video_size_distribution",
	Description: "distribution of processed video size over time",
	Measure:     videoSize,
	Aggregation: view.Distribution(0, 1<<32, 2<<32, 3<<32),
}); err != nil {
	log.Fatalf("Failed to subscribe to view: %v", err)
}

Subscribe begins collecting data for the view. Subscribed views' data will be exported via the registered exporters.

Traces

ctx, span := trace.StartSpan(ctx, "your choice of name")
defer span.End()

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.