Help displaying correctly metricbeat/munin-node realtime data

Hi forum...

I'm not succeeding displaying correctly in kibana line or area visualization of real-time data coming from metricbeat munin plugin.

The events at elasticsearch are essentially number type reads of listeners on a couple streaming servers (real-time server stats, not a log line analysis). While munin graphs that data correctly (munin executes its plugins every 5 minutes and updates graph adding a new y-axis point/value result from executed plugin at a given x-axis time) I cannot do the same in kibana.

I'm having the data reads correctly in EL... I'm failing at the final step!
Setting metricbeat to read munin plugins every 5 minutes aleviated the problem, which is that I'm getting buckets at X-axis with too many reads sum, giving too high, wrong real-time values.

I can do, but, a metric or gauge visualization that reads current real-time value very accurately: I just need to sum reads of the last 5 minutes! but, on line or area visualizations i'm lost... buckets go beyond 5 minutes in span quickly, so, depending on the situation I can get figures with twice the real actual values (and I'm forced to slow down munin at metricbeat at 300s interval to at least go to something of this world)
Note but that I indeed need to sum... because number events come from a couple of servers, so I cannot do an average... I'm lost with this...

How is the right way to do this? I know that I can't tell kibana to stick to 5 minute buckets (too many buckets problem soon or later) ... but could I tell her to somehow average 5 minute neighboring buckets? or drop interleaving buckets? someway to prevent it to sum values from consecutive reads?...

Hope some experienced kibana user could help.
Thank you very much in advance anyways.
Best regards.

I'm not totally sure If I understand what you're after, and if this helps, but what I do in a similar situation is to try to create the query using elasticsearch aggregations in the console. Then you can know if what you need to get is even possible to do. Once you do that, creating the visualization is a matter of whether Kibana supports the aggregations you need.

This list is helpful on what aggregations Kibana supports. https://github.com/elastic/kibana/issues/58628
Seems tsvb is the only option if you need bucket script

Hi ... thank you very much for your advice!

Since I'm not a data analisys or management expert (I'm a sys admin) I don't know much beyond the very basic/classic visualizations.
Currently I'm having some, although limited, success, to do what I want using Timelion... which allows me to define a rigid, time bucked interval, but this has its limitations I'v learnt.

What I'm trying to do is to plot a line where, no matter how big the timespan is, the maximum never goes higer than the real maximum... i.e:
If I have 2 streaming servers, and I get a metricbeat runnuning on them, and let them send a metricbeat munin-node event, every 5 minutes (like munin does), where the data comes from the execution of the streaming-real-time-stats munin-node plugin (something metricbeat amazingly can do), and that data is just a numeric value, that reads how many listeners are connected, at that time, at each server, then I should be able to plot a line, where every point is just the sum of the two numeric values of every 'scheduled' read.

I try to 'fake' munin behaviour, by forcing somehow kibana to keep the buckets to be 5 minute span, so I can't have more reads than just two reads, one per server, every 5 minutes.
The problem is, that, obviously, you either get too much buckets if visualization timespan is too big, or false realtime reads, as buckets go larger than 5 minutes, and It sums more than 2 reads.

Now ... You've pointed me to TSVB ... i didn't knew it even exist!!! and it looks very very interesting!!! I'm still amazed and playing with Timelion... and I have a new toy to play with during covid-19 time :smiley:

Thank you very much for your help.
Best regards

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