Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support HTTP Traceparent header field reading in Go 1.24 #1318

Open
grcevski opened this issue Nov 27, 2024 · 6 comments
Open

Support HTTP Traceparent header field reading in Go 1.24 #1318

grcevski opened this issue Nov 27, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@grcevski
Copy link
Contributor

Swiss maps have been enabled by default in Go main, which means they will probably become the default in Go 1.24 and break the reading of the HTTP request maps. gRPC is not affected, since we read an array there.

https://go-review.googlesource.com/c/go/+/574516

Go 1.24 is scheduled for release in February (2nd week), we need a fix by then: https://docs.google.com/presentation/d/1jvc0RzrshOOjkeEnsyea2jwjs_zVOcyETG558pqPOK0/mobilepresent?slide=id.g840eaeb4b4_0_0

One possible fix for this is to write a version of the map lookup code which is meant for Swiss maps. Based on some quick code reading I did, this looks more complex now than it used to be.

Another possible solution we discussed at the Go Auto SIG today is potentially reading the Traceparent field while the headers are being parsed, although this will be slower since we will run a uprobe on every header field. The advantage of this approach is that this works for all Go versions.

@grcevski grcevski added the enhancement New feature or request label Nov 27, 2024
@grcevski
Copy link
Contributor Author

I also realized that maybe we simply need to figure out how to work with the swiss maps. To support manual spans we also read a Go map in fill_partial_tracer_id_from_tracers_map, which also reads a Go map.

@MrAlias
Copy link
Contributor

MrAlias commented Jan 7, 2025

We need to fully audit the existing probes to determine where we instrument using maps.

We should see if we can find short-term fixes for all these locations if we cannot get support for swiss maps working before their release.

@MrAlias
Copy link
Contributor

MrAlias commented Jan 7, 2025

@grcevski plans to contribute the code from Beyla they used to get a stop-gap solution working for HTTP

@MrAlias
Copy link
Contributor

MrAlias commented Jan 7, 2025

@MrAlias OTel global needs to be documented that it will not work with newer version of Go (if using the old versions of otel).

@MrAlias
Copy link
Contributor

MrAlias commented Jan 7, 2025

Doing a quick search for MAP_BUCKET_TYPE shows only two locations we are using that definition:

For completeness, it looks like the kafka header is read from a slice:

// Read the header
struct kafka_header_t header = {0};
bpf_probe_read(&header, sizeof(header), headers_slice.array + (i * sizeof(header)));

@MrAlias
Copy link
Contributor

MrAlias commented Jan 7, 2025

Plan for OTel global instrumentation support:

  • Add package constraints to the uprobes that ensure they are not loaded for versions of Go >= 1.24
  • Document in COMPATIBILITY.md that ...

    Versions of go.opentelemetry.io/otel < v1.33.0 are not supported when using Go >= 1.24.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants