Antifeature: inconsistent use of colours and bar positioning in same view over time.

[quasipedia]

So, this is a snapshot of my view, it basically counts the number of log messages per unit of time, splitting the bars between INFO and ERROR messages. These logs refer to incoming API calls.

All nice and dandy, but then one of our partners automated jobs started, and we got inundated by requests:

See the problem? No?! I didn't either for a little while!

Kibana actually switched the colour-keys and the relative position of the bar segments (see the legend on the right) so the second graph does not read "ok, an automated job is running" but rather "OMG! Nothing is working as it should, alarm!!".

What is happening is that Kibana4 uses the colour green for the bucket with the most objects in it, and places this segment of the bar at the bottom. In our case the balance between INFO and ERROR tipped with the broken import.

I classify this as an anti-feature as it defeats the purpose of having an intuitive, visual data representation, but I don't have a killer solution to it. The best I could come up with is:

1. Allow to optionally "lock down" colours (so, kibana will keep track of what colours have been used for what values and never recycle a colour for a new value, unless the colour cache is manually flushed
2. Allow to optionally "lock down" order. This is same principle as above, but with "position in the bar" rather than colours (so, in my case, INFO would always be the bar segment on the bottom, with ERROR on top of it, regardless of maybe having 200 INFO below 20.000 ERROR.

The two could be possibly combined. As I said, none of the two is ideal: I'd be more than happy if somebody would come up with a better suggestion.

[rashidkpc]

This is a great write up, can you add it as a comment to the existing color rationalization ticket? #485