[azuremonitorexporter] Seems to not respect semantic convention on http field for mapping

[aygalinc]

Component(s)

exporter/azuremonitor

What happened?

Hello !
When I read the documentation about azuremonitor, it states that to compute response code for appInsight it took http.response_status or status_code.
Or Latest Semantic convention says that field that contains http status is http.response.status_code should be used so the mapping is really weird in our system.

Collector version

latest

Environment information

No response

OpenTelemetry Collector configuration

No response

Log output

No response

Additional context

No response

[github-actions]

Pinging code owners:

• exporter/azuremonitor: @pcwiese

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[JorTurFer]

We are affected too by this

[aygalinc]

@pcwiese :
Maybe i 'm wrong because i clearly have no experience in Go, i just download vscode for this and browse project and dependencies but for me it seems that the library that is genrated upon the semantic convention specification is not aligned with the latest version of the spec: https://pkg.go.dev/go.opentelemetry.io/collector/semconv@v0.94.1/v1.6.1 .

It clearly not integrate all breaking change on http introduce in version 1.21.0 dure to alignement with ECS naming.

[aygalinc]

Seems the same for all other exporter if they rely on the same package no ?

[JorTurFer]

The problem is that v1.21 doesn't contain the new value either: https://pkg.go.dev/go.opentelemetry.io/collector/semconv@v0.94.1/v1.21.0 despite it's documented in the spec: https://github.com/open-telemetry/opentelemetry-specification/blob/main/schemas/1.21.0

[aygalinc]

Yep i check all the version and for me the code generation seems broken. But as i said i m not a go expert so i do not know if i look the right set of package module.
And i m also surprised that the module end at version 1.22.0 because they have release 2 news versions of the semantic spec

[aygalinc]

Yep the root cause is the same

[crobert-1]

I'm going to close in favor of #29687, but let me know if this should remain open.