Support Open-Telemetry middleware in contrib

[n9te9]

Abstract / Background

Microservice architecture is often required integrated observability.
Open-Telemetry is attracted attention one of the integrated observability method.

What

• Support open-telemetry middleware in echo-contrib

Example

I suppose below echo-contrib API.

import (
	"go.opentelemetry.io/otel/trace"
         "github.com/labstack/echo-contrib/otelecho"
)

func newTracerProvider() (*sdktrace.TracerProvider, error) {
	exp, err := stdouttrace.New(stdouttrace.WithPrettyPrint())
	if err != nil {
		return nil, err
	}

	tp := sdktrace.NewTracerProvider(
		sdktrace.WithBatcher(exp),
		sdktrace.WithResource(resource.NewWithAttributes(
			semconv.SchemaURL,
			semconv.ServiceName("echo-service"),
		)),
	)

	return tp, nil
}

func main() {
  tp, err := newTracerProvider()
  if err != nil {
    log.Fatalf("failed to create tracer provider: %v", err)
  }
  otelMiddleware := otelecho.Middleware("echo-service", otelecho.WithTraceProvider(tp))
  e := echo.New()
  e.Use(otelMiddleware)
  // ...
}

[vadimi]

hello @aldas , would it make sense to move Open Telemetry support into this repo from open-telemetry/opentelemetry-go-contrib? I've opened a PR in there to support echo v5 (open-telemetry/opentelemetry-go-contrib#8457), but there is a question about the ownership and the actual location of the new package.

What do you think? I'd be happy to open a PR against this repo

[aldas]

@vadimi Hi, I'm probably a bit of a Luddite by today's standards, and I haven't used Open Telemetry before. That middleware part config.go+echo.go does not seem too complex. so we probably can support it. If you look at the commit history this repo is not that active, so I do not know if this suitable for otel tempo?

about internal/semconv stuff in that PR - without me trying to understand that - is that also needed?

[vadimi]

internal/semconv is normally used for keeping otel attributes that will be used in spans/traces, it's autogenerated in open-telemetry repo, but it doesn't necessary need to be structured like that here.

In terms of activity - I don't expect lots of changes and we can keep it as a sub-package to avoid pulling too many dependencies in the main echo-contrib module similar to how it's done in open-telemetry contrib repo or https://github.com/redis/go-redis/tree/master/extra/redisotel

[aldas]

Alright, @vadimi, please open PR in this repo.

Lets try sub-package out. We actually had this idea #52 couple of years ago.

[vadimi]

Nice, opened this PR - #141.

One thing I'm not sure about is github.com/labstack/echo-contrib/otelecho/v5 path for the sub module to be able to introduce breaking changes into echo, but keep the previous versions still available. Please let me know if you're ok with it or not.

[aldas]

Echo OpenTelemetry middleware is located here https://github.com/labstack/echo-opentelemetry

[aldas]

Please leave first impressions and feedback under this issue labstack/echo-opentelemetry#4