-
Notifications
You must be signed in to change notification settings - Fork 19k
runtime/trace: execution trace doesn't include pprof labels #56295
Copy link
Copy link
Open
Labels
FeatureRequestIssues asking for a new feature that does not need a proposal.Issues asking for a new feature that does not need a proposal.NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.
Milestone
Metadata
Metadata
Assignees
Labels
FeatureRequestIssues asking for a new feature that does not need a proposal.Issues asking for a new feature that does not need a proposal.NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.
Type
Projects
Status
In Progress
Labels set through
runtime/pprof.SetGoroutineLabelsdon't show up in execution traces. In the CPU and goroutine profiles, samples include the labels from the sampled goroutine. Labels are quite useful for associating CPU usage with trace span IDs, HTTP endpoints, user IDs, etc.It would be useful to have these labels in execution traces as well. For example, since execution traces now include timestamped CPU profile samples, trace events could be associated with an application-level trace span ID using labels to get a breakdown of on-CPU and off-CPU time for an individual request. We can further bridge runtime/pprof and runtime/trace by making labels, which are already available in some profiles, available in traces as well.
Arguably there's already support for something similar to this through
trace.WithRegionandtrace.NewTask. However, these values are one-dimensional and seem to be intended for breaking down a process into steps (read an event stream, query a database, etc...). To record additional contextual information, like a specific distributed trace ID or user ID, you'd need to do something ad-hoc like pack that information into the task name, or show it in a designatedtrace.Logcategory.Perhaps profile labels could be added to the trace as a new event that is emitted whenever the labels for a goroutine are updated? (See this comment)
See also #41554