otelgin uses non-standard error field to transport error information

[bripkens]

Description

otelgin uses a span attribute gin.errors to transport information about errors attached to the handlers/middleware. This is

opentelemetry-go-contrib/instrumentation/github.com/gin-gonic/gin/otelgin/gintrace.go

Lines 86 to 93 in a111e3e

	status := c.Writer.Status()
	span.SetStatus(semconvutil.HTTPServerStatus(status))
	if status > 0 {
	span.SetAttributes(semconv.HTTPStatusCode(status))
	}
	if len(c.Errors) > 0 {
	span.SetAttributes(attribute.String("gin.errors", c.Errors.String()))
	}

Expected behavior

I expect otelgin to either:

1. Use the standard span status description field for error messages – which is only possible when the status code is error according to spec. This is debatable, because we don't know whether these attached errors are the cause of the returned status code.
2. By recording errors on the span. For example, by doing:

for _, err := range c.Errors {
	attrs := make([]attribute.KeyValue, 0, 2)
        // to be replaced with semconv usage https://opentelemetry.io/docs/specs/semconv/attributes-registry/error/
	attrs = append(attrs, attribute.String("error.type", fmt.Sprintf("%d", err.Type)))
	if err.Meta != nil {
		attrs = append(attrs, attribute.String("meta", fmt.Sprintf("%v", err.Meta)))
	}
	
	span.RecordError(err.Err, oteltrace.WithAttributes(attrs...))
}

Option 2. seems a preferable option to me. As this would be leveraging standard tracing fields to transport the information. Previously, there would be one error field and with this change this would be split across multiple attributes that will then permit searching/filtering/grouping in o11y solutions.

I would be happy to contribute option 2.

[adityaAllen]

Agreed with assessment. Option 2 would let better grouping of errors and search ability