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?
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?
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.
Oh this is Windows, then don't look for
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:
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
@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?
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.