Generate New Server Metrics in otelhttp

[MrAlias]

The semconv.HTTPServer already produces the existing v1.20.0 server metrics (#6002). The following methods need to be updated to produce the new server HTTP metrics:

• RecordMetrics

These updates should ensure that when OTEL_SEMCONV_STABILITY_OPT_IN="http/dup" is set the produced telemetry is compliant with these semantic conventions:

• http.server.request.duration
• http.server.request.body.size
• http.server.response.body.size

[dennisme]

I'd like to do this one!

[dmathieu]

This issue hasn't been updated in quite some time. Unassigning it so someone else can pick it up.

[flc1125]

I can give it a try.

[flc1125]

Thanks.

Give me some time, I need to understand it, including some information about Metric.

[flc1125]

I've spent some time studying the code recently, and I found that the design might be better with some refactorings or improvements.

Here are some of my ideas: (Of course, this part of the improvement has nothing to do with the current issue)__

Question:

• We use oldHTTPServer and newHTTPServer to distinguish the semantic differences between the corresponding 1.20 and 1.26 versions.
• Suppose there are still 1.27, 1.28... When the time comes, do we need to add many new methods to solve them?

My thoughts:

• Separate different versions of related methods, such as RequestTraceAttrs, etc., and abstract them into interfaces
• We implement this interface through multiple versions
• We inject these implementations through semconv.HTTPServer, and we can implement it at any time even if new versions change or add in the future.

Other thoughts, thoughts on the version section of semconv

• We can inject up to 3 versions through semconv.HTTPServer.
• One is the latest version, the other is the previous version that is maintained, and the other is the version that is planned to be scrapped and is not maintained and has an abandonment time

[dmathieu]

We should keep things simple.
We currently have breaking changes because we used semantic conventions that were not stable yet.
The state of the HTTP semantic conventions is now that they are stable, with parts that are still experimental. Once something is stable, the only way it would have breaking changes would be with a major release.

This is why we only emit stable metrics, not the experimental ones so far. If we wish to start emiting experimental metrics, we should provide a way to mark that specific metric as experimental, to make upgrades smoother (with no migration path).

With that, I think we can assume there won't be three semantic convention versions with breaking changes at the same time.
So we shouldn't need to handle that case.

Also, the migration plan keeps two versions running alongside each other for a fairly limited amount of time.
This is taking longer, because only tracing has been tackled so far. But once metrics are done, we should be able to remove the duplicate versions about a quarter later.

So while I agree there are ways for readability and usability improvements in the otelhttp package and the handling of semconv (I started one a couple days ago, which will change how you would handle this issue: #6400), I think we can make this change with minimal changes in the library and then clean things up.

[flc1125]

My preliminary assumption is as follows: (Currently in progress, it is not ruled out that it may be overthrown in order to solve this problem first and adjusted in subsequent versions)

• I defined an interface

   type HTTPServerHandler interface {
   	// RecordMetrics records the metrics of the server.
   	RecordMetrics(ctx context.Context, md ServerMetricData)
   }

• Then I asked old HTTPServer and new HTTPServer to implement this interface.

• env.HTTPServer has added a property handlers []HTTPServerHandler

• env.HTTPServer's RecordMetrics only needs to call loop handlers

---

Assuming this direction is valid, it actually means that multiple versions in the future can also be supported. Of course, whether to do it or not is another question.

[dmathieu]

You don't need a new interface.
The behavior you describe is kinda what we already do for traces.

For example:

opentelemetry-go-contrib/instrumentation/net/http/otelhttp/internal/semconv/env.go

Lines 51 to 56 in 04815fd

	func (s HTTPServer) RequestTraceAttrs(server string, req *http.Request) []attribute.KeyValue {
	if s.duplicate {
	return append(oldHTTPServer{}.RequestTraceAttrs(server, req), newHTTPServer{}.RequestTraceAttrs(server, req)...)
	}
	return oldHTTPServer{}.RequestTraceAttrs(server, req)
	}

For RecordMetrics, you would need something like this:

func (s HTTPServer) RecordMetrics(ctx context.Context, md ServerMetricData) {
	if s.requestBytesCounter == nil || s.responseBytesCounter == nil || s.serverLatencyMeasure == nil {
		// This will happen if an HTTPServer{} is used instead of NewHTTPServer.
		return
	}

	// Emit the old http server metrics.

	if s.duplicate {
		// Emit the new http server metrics.
	}
}

[flc1125]

Okay, I'll adjust it this way.