I'm trying to setup Metricbeat, unfortunately not much data is being visualized.
I am mostly interested in the CPU usage. I am using the example configuration presented at Step 2: Configure Metricbeat. Elasticsearch, Kibana and Metricbeat are running on version 6.2.1.
The CPU usage gauges would be great to begin with. The gauge itself is shown in the sample dashboard, unfortunately it is not receiving any data so it's constantly at 0% (see screenshot above).
I've been using stress --cpu 2
to generate some stress testing, unfortunately the metric didn't change. When creating a new dashboard the "common" CPU usage graph displays data but the gauge doesn't. I've checked, they are both pulling their data from the "system.cpu.user.pct" field. What am I doing wrong here?
The graph on the left clearly shows a spike, but that spike is in the past. Have you checked the gauge while you are load testing? You can select the time range in the left visualization. Try to select a range the CPU was active at.
Yes, I did monitor the gauge while the CPU spike in the graph on the left took place. It did not change. Also tested with different time ranges.
If it helps, I'm running the newest version of Ubuntu. Is the CPU gauge supposed to pull the same data as the graph on the left or is it supposed to get the data from a different field?
I have the same problem but no solution yet. What I did was, used beats to ship the metrics to Kibana without logstash.
Is it an issue of indexing? As these dashboard uses metribeat-* and logstash uses logstash-*. So, basically it means, do we need logstash configured for beats for visualizing these dashboards?
I am actually sending it directly from Metricbeat to Kibana not taking any detour via Logstash. Still, the gauge doesn't seem to receive any data, even though the "normal" graph is working.
I have tried on latest Ubuntu beta and CPU metrics are properly collected, so I don't think it is related to this. Also mention that both, the graph and the gauge use the same data, so if it appears in one of the visualizations then it must be properly collected and stored.
The main difference I see is that the graphs show any point stored in Elasticsearch as is, it doesn't matter if there are gaps in this data. But the gauge does some calculation and is intended to show in a glance the current status of the visualized metrics, so a gauge is more useful with a good, continuous dataset and specially with data in the final time range.
To better illustrate this, look at this example, it shows the same dataset, with different time ranges, the first one with metrics in most of the range:
I'm having the same problem and I think the issue is that the interval is set to "auto".
Auto is nice if you collecting metrics at very short intervals but its horrible if you have longer intervals because you get those spikes in graphs and gauges will simply stop working.
Try setting the interval to 1m or 5m and see what happens. Ideally the value should be the same as the interval you have metricbeat set to. The downside of this is that you'll quickly run into generating too many buckets is you select long time spans.
It would be best if there was some kind of option in the visualbuilder (and Kibana in general) to select the MINIMUM interval. e.g. don't go below 1m because that might break graphs but still create large buckets e.g. 1 hour if you select long time ranges and 1m will run into the max. bucket limit.
Sorry for the late reply. I've tried using longer intervals but the problem persists nonetheless. The CPU usage graph is displaying gathered data, however, the gauge does not move one bit.
Sorry, I accidentally skipped over your reply. You were right all along. My error was the selected time window which I still don't understand that well. For future reference: I selected a relative time range:
From: 10 minutes ago
To: 5 seconds ago
This seems to have done the trick for me. Thanks a lot.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.