Multiple row metric heat hap


(Dave Willoughby) #1

I'm trying to achieve the same style of heat map as this post.

I'm trying to follow the advice in this post, but seem to be missing something.

My data is already counted , so i don't need kibana to do counts for me.

Maybe i'm thinking too much in relational tables, spreadsheets.

I'm ingesting "rows", that have a timestamp field and multiple fields that are floats that are already counts.

I'd like a heat map that has a row for each field that is already counted before ingest by logstash, and my timestamps across the bottom. I would set colors based on my incoming counts.

For example, the data coming in could be failure counts at each station. I'd like a heat map as follows:

Station1 2 0 0 1
Station2 0 0 0 4
Station3 4 5 9 8

                     11:00h    12:00h   13:00h   14:00h 

with ingest data being timestamped csv rows like:

11:00,4,0,2
12:00,5,0,0
13:00,9,0,0
14:00,8,4,1

The 11:00 Logstash ingest would be:

"Station1" => 2.0
"Station2" => 0.0
"Station3" => 4.0

Please let me know if this is possible, maybe give some more hints, or pointers to samples, etc.

Everything I've seen in documentation, videos seems to start with kibana counting raw events, but i've already counted the events. My endpoints have smarts, have already done one level of data summation. :wink:

Thanks!


(Jon Budzenski) #2

The context for Kibana doing the counting is in most cases there's more data than the browser can render, so we use elasticsearch to group all this data together for us. Like you mentioned, Kibana visualizations expect raw events that get grouped into buckets of data, (although there's some work coming down the line with the canvas plugin that can do point series).

The only only way around this I can think of is somewhat imperfect. We still have to group the data by timestamp, and then we can use the top hits metric to give the the most recent value in that bucket. The downside is there may be buckets that have multiple readings and all but one will be ignored.


(Dave Willoughby) #3

Thanks @jbudz! I appreciate the great help!!

I'm totally fine with using Top Hit, as I likely have one event per interval.

I think what I'm really looking for is an "Add Metric" in the upper section of the configuration panel on the left. So in my case, I'd have one row in the heat map for Station1, and could use Top Hit just fine, then I'd add a metric, for a second row in the heat map for Station2, etc.

Prior guidance suggested using the split chart in the Buckets section, but that's creating subordinate, subbuckets, like in my example, within failures, maybe showing several severity of failures. But this guidance doesn't seem to work for me.

Splitting doesn't seem to work, since subordinate is implied. I want independent metrics, one per row, in my heat map.

I think I, and the prior poster I referenced, really want multi metric capability in heat map.

I think a work around is for me to create a separate event for each single failure at each station. Even though I have a count already, I need to dumb it down to simple events, one per failure. So for example, at 14:00 in my example, I'd have 8 station1 events, 4 station2 events, and 1 station3 event, and let kibana count them up


(Jon Budzenski) #4

Yup I'm thinking you have the right idea. Kibana's classic visualizations will work best with flattened, singular events. Points via multiple metrics would be great, but I suspect it'll be bucketing focused for the near future.


(system) #5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.