4 ms·
OP here. Unfortunately the ansi palette is pretty limited so I didn't have a lot of flexibility in the color choice. That said, this can definitely be improved.
by degio 12y ago
OP here. Unfortunately the ansi palette is pretty limited so I didn't have a lot of flexibility in the color choice. That said, this can definitely be improved. I can work on it if people find it useful.
In the meantime, it's very easy to tune the colors your own: just modify this line https://github.com/draios/sysdig/blob/master/userspace/sysdig/chisels/spectrogram.lua#L40 https://github.com/draios/sysdig/blob/master/userspace/sysdi... in your local version of the script, using this as a reference http://misc.flogisoft.com/_media/bash/colors_format/256_colors_fg.png http://misc.flogisoft.com/_media/bash/colors_format/256_colo....
- chrisan 12y ago> Unfortunately the ansi palette is pretty limited so I didn't have a lot of flexibility in the color choice. I believe the issue raised isnt the palette range itself, but rather that it is the reverse of what it is typically expected. The current red area "should" be green indicating there are many calls in the fast region while the current trailing green blocks "should" be red indicating problem issues This color of green=good and red=bad I believe stems from Triage tags: http://en.wikipedia.org/wiki/Triage_tag http://en.wikipedia.org/wiki/Triage_tag Sometimes white is used below green as 'dismiss/not an issue'
- morpher 12y agoHere, "good" is on the left and "bad" is on the right. The color is orthogonal (it gives the number of operations with latencies in a given bucket). For example, a red square on the right side of the output would have definitely been "bad".