Understanding OpenCensus and instrumentation in Kubernetes cluster

In my last article in this series, I introduced monitoring with Prometheus, the leading open source metric instrumentation, collection, and storage toolkit. While Prometheus has become the de facto standard for monitoring Kubernetes for many users, there may be reasons why you might choose another approach for metric telemetry.

One reason is that using Prometheus introduces another component in your cluster that needs to be maintained and updated and will require additional management to ensure data persistence over the long term. Another reason is that Prometheus collects an incredibly large set of metrics right out of the box, and this could become cost-prohibitive in situations where metric volume is an input into your overall observability costs.

This article will introduce you to OpenCensus, a set of open source libraries for observability instrumentation. OpenCensus is the currently recommended library to use for instrumenting services to collect traces and metrics. The OpenTracing and OpenCensus projects have been merged into OpenTelemetry, which will become the recommended library.

While OpenCensus enables both metrics and distributed tracing, this article focuses on metrics by:

• Describing the OpenCensus approach to instrumentation and its data model
• Walking through a tutorial to explain how to instrument an application, deploy a sample application, and review the metrics that you can create with OpenCensus

I will revisit tracing in a future article.

OpenCensus basics

OpenCensus' implementation depends on three core components:

• The instrumentation to create metrics and record data points (varies by language)
• An exporter to send metric data to a storage backend (varies by language)
• The backend to store metrics and enable querying metric data (varies by database)

To use OpenCensus in your application to record custom metrics, you will need to understand these elements for your particular programming languages and infrastructure.

Instrumentation

To understand how to instrument your application, you need first to understand OpenCensus' primitives, which are measurements, measures, views, and aggregations.

• Measurement: A measurement is the most fundamental entity; it's the single data point collected that represents a value at a point in time. For example, for a latency metric measured in milliseconds (ms), a measurement of 100 could represent an event with 100ms latency.
• Measure: A measure represents a metric to be recorded. For example, you could use a "latency" measure to record HTTP response latency from your service. A measure is made up of a name, a description, and the units that the metric uses. For example, to measure latency, you might specify:
  • Name: response_latency
  • Description: latency of server response in ms
  • Unit: ms
• View: A view is the combination of a measure, an aggregation, and optional tags. Views are the mechanism you'll use to connect to an exporter to send the captured values to a storage backend. A view includes:
  • Name
  • Description
  • The measure that will produce measurements for this collection
  • TagKeys, if you're using tags
• Aggregations: Each view is also required to specify an aggregation; that is, how the view will treat multiple measures. Aggregations can be one of the following:
  • Count: The count of the number of measurement points in the view
  • Distribution: Histogram distribution of the points in the view
  • Sum: A sum of the values of the measurement points
  • LastValue: Only the last recorded value in the measurement

You can also refer to OpenCensus' source for additional information about the primitives.

Exporters

Once you have written the instrumentation to create measures, capture measurements, and aggregate them into views, you need an exporter to send your recorded metric data to your chosen storage backend. Unlike Prometheus, where you expose a dedicated metric endpoint to be scraped, OpenCensus works on a push model—the exporter pushes your collected data to the specified backend. You need to choose the exporter based on:

• The language that your application and instrumentation are written in
• Available support for stats (metrics)
• The available backend options

Using an exporter requires instantiating it in your code, registering it, and then registering your view to have the exporter send the collected data to the backend.

Leverage metrics in OpenCensus

Now that you understand the terminology for how OpenCensus works to collect and export metrics, the next thing to learn is how metrics in OpenCensus function. Unlike Prometheus, where you have to define the metric kind upfront, OpenCensus simply requires you to collect the measurements and then aggregate them in the view before sending them to the exporter. The measurements support integer and float values. From there, you can use create histograms using the distribution aggregation, add up the number of samples using the count aggregation, or add up the collected values using the sum aggregation.

Now you have a basic understanding of what OpenCensus is, how it works, and the kinds of data it can collect and store. Download your favorite tooling (or use my tutorial here and a quickstart lab) and take OpenCensus for a spin.