Check prometheus metrics

[MarcoGomes00]

When I test the metrics form exporter I'm getting this result

curl -qs 0.0.0.0:9479/metrics | ./promtool check metrics
filebeat_cpu_ticks counter metrics should have "_total" suffix
filebeat_cpu_time_miliseconds counter metrics should have "_total" suffix
filebeat_libbeat_config_reloads counter metrics should have "_total" suffix
filebeat_libbeat_output counter metrics should have "_total" suffix
filebeat_libbeat_output_read_bytes counter metrics should have "_total" suffix
filebeat_libbeat_output_read_errors counter metrics should have "_total" suffix
filebeat_libbeat_output_write_bytes counter metrics should have "_total" suffix
filebeat_libbeat_output_write_errors counter metrics should have "_total" suffix
filebeat_memstats_gc_next counter metrics should have "_total" suffix
filebeat_memstats_memory_total non-counter metrics should not have "_total" suffix
filebeat_system_cpu_cores counter metrics should have "_total" suffix
filebeat_uptime_seconds counter metrics should have "_total" suffix

Can you please check?

[shivas]

Thanks for the report, yes makes sense, but given that this exporter is just mapping of JSON to Prometheus metrics I'm not sure changing metrics names would create more clarity in this case.

[lichuan0620]

Same here. For me, adding the _total suffix makes it more clear what kind of metrics I am working with.

[CNG]

I think filebeat_memstats_gc_next was correct as that is a gauge, not a counter?

How to interpret memory stats in filebeat log - Elastic Stack / Beats - Discuss the Elastic Stack

// NextGC is the target heap size of the next GC cycle.
//
// The garbage collector's goal is to keep HeapAlloc ≤ NextGC.
// At the end of each GC cycle, the target for the next cycle
// is computed based on the amount of reachable data and the
// value of GOGC.

[CNG]

Same with CPU cores, and maybe uptime seconds? It's true uptime seconds counts up but it's a constant rate, you wouldn't take a rate() over it, it's more like a gauge.