Is your feature request related to a problem? Please describe.
I have a benchmarking use case on a Kubernetes node where I need to track energy and resource consumption for very specific targets at a high frequency (1Hz). K8s nodes generate hundreds of active cgroups (for every pod, ephemeral container, system service, etc.). The problem is that exporting cgroups at this frequency sends all this unwanted raw data to the exporter, causing massive I/O overhead, database bloat, and rapid disk exhaustion.
Describe the solution you'd like
I would like a native filtering mechanism (such as an explicit whitelist or regex support) built into the agent's configuration file. This could be implemented as a new parameter directly inside the [plugins.cgroups] block, or by adding filtering logic to the existing [plugins.filter] plugin. This would allow users to specify exactly which targets to export (for example: /system.slice/kubelet.service, crio.service, docker.service, and global RAPL), dropping all unmapped cgroups at the source before they are serialized or sent to the database.
Additional context
If we can filter metrics at the source, the database bloat practically disappears. This solves the root cause of disk exhaustion on edge nodes and makes aggressive TTL configurations or custom purging scripts completely unnecessary. Filtering at the source would drastically improve Alumet's footprint and make it much easier to use for targeted benchmarking scenarios.
Is your feature request related to a problem? Please describe.
I have a benchmarking use case on a Kubernetes node where I need to track energy and resource consumption for very specific targets at a high frequency (1Hz). K8s nodes generate hundreds of active cgroups (for every pod, ephemeral container, system service, etc.). The problem is that exporting cgroups at this frequency sends all this unwanted raw data to the exporter, causing massive I/O overhead, database bloat, and rapid disk exhaustion.
Describe the solution you'd like
I would like a native filtering mechanism (such as an explicit whitelist or regex support) built into the agent's configuration file. This could be implemented as a new parameter directly inside the
[plugins.cgroups]block, or by adding filtering logic to the existing[plugins.filter]plugin. This would allow users to specify exactly which targets to export (for example:/system.slice/kubelet.service,crio.service,docker.service, and global RAPL), dropping all unmapped cgroups at the source before they are serialized or sent to the database.Additional context
If we can filter metrics at the source, the database bloat practically disappears. This solves the root cause of disk exhaustion on edge nodes and makes aggressive TTL configurations or custom purging scripts completely unnecessary. Filtering at the source would drastically improve Alumet's footprint and make it much easier to use for targeted benchmarking scenarios.