There was some back and forth between prometheus and opentelemetry.

I'm not opposed to directly use opentelemetry, especially given the small num of deps:
https://github.com/open-telemetry/opentelemetry-go/blob/main/go.mod

It also comes with a prometheus exporter sub-module: https://github.com/open-telemetry/opentelemetry-go/tree/main/exporters/prometheus

Additionally, to metrics it also supports proper tracing which also can be beneficial if we actually use that here.

Only downsides of opentelemetry I can think of:

some limitations on the prometheus exporter (e.g. can't be push based: https://opentelemetry.io/docs/reference/specification/metrics/sdk_exporters/prometheus/)
still very young project
less known/established
cognitive overhead for engineers as we use go-kit/prometheus for metrics in core (though this might also change eventually: Open Tracing Support tendermint/tendermint#3849 (comment))

Might add some extra overhead because of its flexibility, both in onboarding new engineers as well as when configuring metrics etc. Though I do think it might be worth it.

Opentelemetry metric types with examples: https://opentelemetry.uptrace.dev/guide/go-metrics.html#getting-started
Prometheus metric types with examples: https://prometheus.io/docs/concepts/metric_types/

Decide on a metrics solution (e.g. Prometheus) and create lightweight spec #663

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions