- Issue created by @znerol
- 🇨🇭Switzerland znerol
The order of the stack trace is clearly defined in excimer:
/** * Get an array of associative arrays describing the stack trace at the time * of the event. The first element in the array is the function which was * executing, the second function is the caller (parent) of that function, * and so on. [...] */
Bot not so much in open-telemetry:
// locations_start_index along with locations_length refers to to a slice of locations in Profile.location_indices. int32 locations_start_index = 1; // locations_length along with locations_start_index refers to a slice of locations in Profile.location_indices. // Supersedes location_index. int32 locations_length = 2;
- 🇨🇭Switzerland znerol
The pprof README:
Each sample lists the id of each location where the sample was collected, in bottom-up order.
- 🇨🇭Switzerland znerol
Profile definition in pyroscope:
// The ids recorded here correspond to a Profile.location.id. // The leaf is at location_id[0]. repeated uint64 location_id = 1;
This mentions leaf. If the other side is the root, then the stack orientation seems to be the same as with excimer.
Also the code which converts the stack trace from otel profile to google profile in pyroscope is not changing the orientation:
for i := os.LocationsStartIndex; i < os.LocationsStartIndex+os.LocationsLength; i++ { gs.LocationId = append(gs.LocationId, p.convertLocationBack(p.src.LocationTable[p.src.LocationIndices[i]])) }