Update monitoring-es-mb.json to correct datatype

[ash-darin]

This fixes #116766

Datatype for bytes should not be keyword but (unsigned_)long. Chose unsinged_long as there should be no negative amounts of bytes.

[elasticsearchmachine]

Pinging @elastic/es-data-management (Team:Data Management)

[consulthys]

Thanks for your contribution @ash-darin
Can you add to the description how this PR should be tested? We're especially interested in what happens when the monitoring data stream rolls over and the old index has keyword fields and the new one has unsigned_long. Does the Stack Monitoring UI keep working as expected? Are any alerting rules impacted?

[ash-darin]

@consulthys Of course this breaks the dataview by creating a conflict but I see no way around it. This will stay broken till the old mappings rotate out.
To my knowledge these fields are not used in any dashboards but I can make no exhaustive search. As they are text fields, using them for any graphing or math would have been impossible anyway beyond simple display / reporting functions. The Stack monitoring UI for elasticsearch does not show memory usage based on cgroups. The dashboards of the elasticsearch integration do not show memory based on cgroups. This mismatch only showed up because I created custom dashboards, trying to make use of these values as these seem to be the only ones reflecting memory use of my cluster. I have to note that all other uses of byte values in the ECS are long. So them being keyword makes no sense to begin with. In comparison:

beat.stats.cgroup.memory.mem.usage.bytes

is of type long. The only reason these might be keyword is if long would not have been enough to store the number value but 2^63-1 bytes is about 9 Exabytes by my calculation, so that can't be it. Thinking about it now, making it unsigned is actually not necessary.

[consulthys]

Thanks for the details @ash-darin
First of all, I totally agree that those fields being keywords is a bug. I'll try to get to the genesis of it and get back to you.