Version 0.4.0 build information in metrics

Features

Build information support

This version adds tracking of the build information in metrics, see https://fiberplane.com/blog/autometrics-rs-0-4-spot-commits-that-introduce-errors-or-slow-down-your-application for more information

Breaking changes

Long flags consistency

All long flags now take  2 - in front of them, notably in the //go:generate arguments

- //go:generate autometrics -otel -custom-latency
+ //go:generate autometrics --otel --custom-latency

Initialization call

The initialization of autometrics now takes a BuildInfo argument that is meant to be filled with the relevant build information. See the examples in the repository for more information.

- autometrics.Init(nil, autometrics.DefBuckets)
+ autometrics.Init(nil, autometrics.DefBuckets, autometrics.BuildInfo{})

0.3.1 - Release artifacts

This release has no feature change compared to version 0.3.0, but only adds automation to attach the generator binary to the release

OpenTelemetry support

Breaking change

For people who tested the 0.2.0 version, the import to add in your code changed

- import "github.com/autometrics-dev/autometrics-go/pkg/autometrics"
+ import amImpl "github.com/autometrics-dev/autometrics-go/pkg/autometrics/prometheus"

[…]

- autometrics.Init(nil, autometrics.DefBuckets)
+ amImpl.Init(nil, amImpl.DefBuckets)

The generator will automatically replace all the other previous calls to autometrics

Release notes

OpenTelemetry support

The main addition of this release is the support of OpenTelemetry to collect metrics instead of only working with prometheus client.

The only difference is the implementation of metric collection; the OpenTelemetry implementation still uses the Prometheus exporter to expose the collected data, so the same documentation links actually work with the otel implementation, as shown in the new example directory

Custom latencies and input validation

To prevent users from making SLOs that would not trigger the bundled alerts, there is now a verification step in the generator, that will error if a -latency-ms value (in a //autometrics:doc directive) does not match one of the values in the autometrics.DefBuckets default list. This assumes the user used DefBuckets in the amImpl.Init call in their code.

There are situation where the default buckets aren't what we want, so we can change those buckets, and the target latencies in //autometrics:doc directives. In that case, the validation would trigger a false positive and prevent code generation.

The generator now takes a -custom-latency flag to bypass the latency threshold verification, in the case the Init call does not use the default bucket values anyway.

v0.2.0

Add Licenses

Small fixes on alert generation rules

Initial version of autometrics-go

First version

This release of autometrics-go marks the first point where both main features of autometrics are implemented:

• Documentation link generation to Prometheus graphs is implemented, and
• Automatic alert generation for Prometheus is implemented.

Both happen solely from:

• adding a go:generate call for Autometrics, and
• annotating the functions with an autometrics:doc directive, that optionally takes arguments to add the alert
  generation part.

Demo

The example in the examples/web subfolder is the main source to learn about usage of autometrics.