32-BIT Metricbeat (7.8.0) return abnormal value for system.network.in.bytes

[Razby (Tadej)]

Hi,

32-BIT Metricbeat (7.8.0) return abnormal high value for system.network.in.bytes such as "6,424,932,420,939,677,696".
With 64-BIT version I got acceptable value such as "3,652,142,427"

I really don’t know what is the reason for such a difference?

Regards,
Tadej

[jsoriano (Jaime Soriano)]

Hey @Razby,

Would it be possible that these machines have a lot of network traffic?
These values are directly taken from the network counters available in /proc/net/dev, could you compare with the values there in your machines?

[Razby (Tadej)]

Hi @jsoriano,

This machine hasn't a lot network traffic.
I checked the same counter directly in Performance Monitor but there are correct numbers.
There seems to be something wrong with processing in the metricbeat.

metricbeat.log/Kibana

Perf monitor

Regards,
@Razby

[jsoriano (Jaime Soriano)]

Oh this is Windows, then don't look for /proc

In any case take into account that the value that metricbeat is reporting, is a cumulative counter of bytes since the machine started. The value you see in the Performance Monitor is probably in bytes/sec, i.e. a rate calculated from the original counter. You can get an equivalent metric using the derivative aggregation in a time series visual builder visualization.

There are more details about these aggregations, on this blogposts:

• How to visualize these metrics using Kibana: https://www.elastic.co/blog/visualizing-observability-with-kibana-event-rates-and-rate-of-change-in-tsvb
• How to query this data using the API: https://www.elastic.co/blog/querying-and-aggregating-time-series-data-in-elasticsearch

If the derivative values still don't make any sense, then this could be a bug. What version of Windows is this one?
I see there is some code to handle 32-bit versions in the library used by Metricbeat to get these metrics: https://github.com/shirou/gopsutil/blob/fc7e5e7af6052e36e83e5539148015ed2c09d8f9/net/net_windows.go#L170

[MarianaD]

@Razby, from the lines @jsoriano referenced you can see we are calling a different win 32 api for the 32 bit machines, this returns DWORD(uint32) values instead of ULONG64 (for 64 bit machines) but we are handling them in the same manner. This is most likely where the issue comes, can you open a github ticket in the beats repo (https://github.com/elastic/beats) so we can follow up on that?