Robert Pająk
Robert Pająk
> For instance, when facing code like this, It looks like a **terminating** error to me which falls into https://github.com/open-telemetry/semantic-conventions/blob/main/docs/general/recording-errors.md#recording-errors-on-spans: > When the operation ends with an error, instrumentation:
My plan is to add OTel Go specfic "recording errors" guidelines into our [Style Guide](https://github.com/open-telemetry/opentelemetry-go/blob/main/CONTRIBUTING.md#style-guide). Maybe it should be part of some more public user-facing docs like https://pkg.go.dev/go.opentelemetry.io/otel/trace. However, I...
> Would your proposed guidlines be in-line with the current Development spec, or are you proposing something new? I want them to be following the current semantic conventions that are...
@open-telemetry/go-maintainers, can you make a rough review if it looks like a good way to implement https://github.com/open-telemetry/opentelemetry-specification/pull/4161? This PR is done in a PoC manner and it lacks unit tests...
> Prometheus exporter is only supposed to add those attributes to the otel_scope_info metric, btw. I think this is what I described. If not then please update my description 😉
> This look nice. Does it impact the benchmarks for tracer/meter/logger retrieval? It does (because there is a bigger memory footprint) but IMO not significantly. E.g. ``` pkg: go.opentelemetry.io/otel/sdk/log cpu:...
> Looks reasonable to me. Prometheus exporter is only supposed to add those attributes to the otel_scope_info metric, btw. @dashpole, PTAL ea10e400c
You can assign me to this issue and set appropriate labels.
Unassigning myself as I continuously have other stuff which IMO has bigger priority.