-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add strict semantic convention 1.27 support #39
Conversation
http/client/transport_metrics.go
Outdated
metric.WithUnit(v127.HTTPClientRequestDurationUnit), | ||
metric.WithDescription("Time spent on TLS negotiation and connection"), | ||
kotelconfig.TimeBucketsOpt) | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
avoid the else, just return at the end of the if and let the other branch take control of the rest of the method
http/client/transport_metrics.go
Outdated
if meter == nil { | ||
return nil | ||
} | ||
type metricFillerFn func(metricsOpts *TransportMetricsOptions, meter metric.Meter, tm *transportMetrics) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type definitions don't require named arguments
This PR enables to set
global
options at the endpoint level, only for settingstatic_metrics_attributes
andstatic_traces_attributes
.Since the semantic convention's
http.server.*
signals for metrics are reported at the "global" / "service" level , we might want to add per endpoint attributes, that are assigned to those metrics.In order to opt-in for the changes that make those metrics we add a
semantic_convention
param, that will use the newest names (for now the"1.27"
option is the only valid version, a part from""
that keeps using the initial set of metrics). The param is only set at the global level, but is taken into account also for each of the backends, to use thehttp.client.*
metrics that are in the spec.To decide: in case we "opt-in" for sem conv, what to do with non standarized metrics (the ones that do not have a correlation to standarized names) ? should we not report them anymore, or keep reporting them.
Checked that 1.27 is the same as 1.29 semantic convention for the metrics we are interested in