search

parca-dev / parca

Continuous profiling for analysis of CPU and memory usage, down to the line number and throughout time. Saving infrastructure cost, improving performance, and increasing reliability.
https://parca.dev/
Apache License 2.0
4.04k stars 210 forks source link

Flamegraph - coloured stacks based on the binary name #2145

Closed manojVivek closed 1 year ago

manojVivek commented 1 year ago

Request from Discord: https://discord.com/channels/877547706334199818/877547706334199821/1042763253849272320

Cluas commented 1 year ago

package name is better

brancz commented 1 year ago

I think both could be useful? As in binary plus package.

Cluas commented 1 year ago

Can we adjust the transparency of the color in proportion to the value, so that it is easy to see which piece wastes the most resources.

brancz commented 1 year ago

The width of a span already shows the value, no? I don't really see how color makes that better. Color to group pieces of code does make sense I think.

Cluas commented 1 year ago

The width of a span already shows the value, no? I don't really see how color makes that better. Color to group pieces of code does make sense I think.

by example: 20221118-175256

Cluas commented 1 year ago

Of course I agree that the modules can be differentiated according to different colors, and different transparency can look more like flames.

brancz commented 1 year ago

I don't think we should do something just to make it look like flames or icicles, we should focus on providing meaning. I think providing the same meaning through two visual clues is not making effective use, but I think coloring packages and or binaries differently is very useful.

metalmatze commented 1 year ago

I'd vote for just going with binaries / mappings for now. Especially in bigger flame graphs going with colors by package will be too much different color again, such that it just becomes noise.

We can always iterate after having tried with the binaries first.

Cluas commented 1 year ago

how about image

Cluas commented 1 year ago

I admit that too many colors can be noisy, like pyroscope, and I think phare's flamegraph is a compromise option

kakkoyun commented 1 year ago

One other color distinction can be between user calls, runtime calls, and system calls (kernel).

leeoniya commented 1 year ago

Grafana viz dev here :wave:

for our FlameGraph panel, we may consider simply allowing arbitrary fields to be used for coloring via Value mappings or Thresholds. our current (WIP) profile DataFrame structure looks like this:

level value self label
0 100 12 root
1 40 1 func1
1 30 15 func2
2 15 3 func3

so theoretically, additional columns (fields) can be added at-will and configured to represent node color, act as data links/drill-downs, etc.