The customer would like to gather normalized CPU accounting per cgroup (e.g. for LXC containers). Metricbeat's CPU accounting can be collected per cgroup, but is then reported in snapshots of nanoseconds of CPU time since the cgroup was started, for example:
"cgroup": {
"cpuacct": {
"percpu": {
"1": 3831401199507,
"2": 4619294890800,
"3": 4604619599210,
"4": 4379214837270,
"5": 4126400747412,
"6": 3939661307456
},
"stats": {
"user": {
"ns": 15226370000000
},
"system": {
"ns": 8906990000000
}
},
"id": "lxv1393",
"total": {
"ns": 25500592581655
},
"path": "/lxc/lxv1393"
}
}
Since we do have the total nanoseconds, we can provide the percpu values as normalized percentages, similar to how it's done for system module's cpu metricset:
cpu.metrics: [percentages, normalized_percentages, ticks]
We would probably need a similar config option for cgroups, like:
cgroups.cpu.metrics: [percentages, normalized_percentages, ticks]
The customer would like to gather normalized CPU accounting per cgroup (e.g. for LXC containers). Metricbeat's CPU accounting can be collected per cgroup, but is then reported in snapshots of nanoseconds of CPU time since the cgroup was started, for example:
Since we do have the total nanoseconds, we can provide the
percpuvalues as normalized percentages, similar to how it's done for system module's cpu metricset:We would probably need a similar config option for cgroups, like: