commit 8a7358d1686588689ef59e61e3382115c0cc301f
author Jonathan Amsterdam <jba@google.com> Sun Jun 06 17:15:04 2021 -0400
committer Jonathan Amsterdam <jba@google.com> Thu Jun 10 11:49:57 2021 +0000
tree 2611408e0009510331582edf0929522c701ca737
parent cd2df34ff7e5aa78e2fea95e961a1d01771df384

event: WIP: another try at metrics

The code that is recording the metric is the best place to describe
that metric. For example, an RPC layer knows that number of sent RPCs
is a counter, and that bytes received is a distribution.

We want to keep that information separate from the actual metric
recoding, both to avoid duplication and to amortize any costs
involved.

The idea in this CL is to have a lightweight representation for
metrics. The world seems to have converged on just three kinds:
counter, gauge and distribution in the terminology of this CL.

A package must first create the metrics it wants to record, by calling
NewMetric with the metric kind, a name, and a description. We create a
namespace for the metric using the import path of the caller of
NewMetric.  That can be overridden, but not to the empty string. By
forcing a non-empty the namespace we can prevent ambiguous metric
names, such has having many packages use the name "call_count".

It's up to the package whether it creates the metrics globally and
unconditionally, or each time a value of a certain type is created. A
cache that has just one global instance would use the former, while
and RPC package with a Client type would ask the caller of NewClient
to pass a namespace, and store the created metrics in the Client.

Builder.Metric records a metric value as before. Its first argument is
one of the previously created metrics, from which it can extract
whatever values it needs to build an Event. Its second argument is an
event.Value, allowing any type to be a metric value.

We provide convenience functions for two common cases: Count for
marking a single instance of an event, like an RPC call or cache
probe; and Since for recording the latency since a start time.

Units are a necessary annoyance that we don't fully deal with here.
For time we use time.Duration, which lets the exporter choose the unit
and correctly convert values.

Change-Id: I26d0ac095fa2cd8b19201edc47350704636de89c
Reviewed-on: https://go-review.googlesource.com/c/exp/+/325490
Trust: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>