Closed thepwagner closed 2 years ago
cc @Owen-Cummings
imo I like the idea of renaming statsd
to metrics
. Also having an extra section called [opentelemetry]
and [statsd]
would make it more clear as to what sorts of metrics we are trying to configure. Just my opinion though!
I like the idea of renaming statsd to metrics.
I dig it!
I've updated the documentation to say that [metrics]
is now "the way" to specify the backend. The [statsd]
section is still supported, so that we're not breaking any existing configs!
backend
and tags
are common to all implementations, so they migrate to the new [metrics]
section.addr
and sampling_interval
fields are specific to statsd, so they stay behind in the [statsd]
section.addr
, insecure
and interval
fields are specific to opentelemetry, so they move to the new [opentelemetry]
section.(addr
looks like it might be shared here - but it does nothing when `backend = "datadog").
I've updated the PR description, this is ready for another review - PTAL!
Add support for https://github.com/open-telemetry/opentelemetry-go metrics, with the configuration supporting
otlp
overhttp
andgrpc
.RFC: Configuration schema
The initial version of this PR slapped the configuration into the existing
[statsd]
section, but since opentelemetry != statsd we opted to make configuration changes:[statsd]
section is effectively renamed[metrics]
: instead of awkwardly specifyingstatsd.backend = "otel"
, you saymetrics.backend = "otel"
.statsd
client stay behind in the[statsd]
sectionopentelemtry
client are added to a new[opentelemetry]
section.Thanks _rxbchen for the feedback on this layout!
Testing instructions
To test this, I started from Shopify's configuration:
Within that configuration, I tweaked the
[statsd]
section:Then I used
voucher_client
to trigger attestations and verify the metrics.