Hi @piowag. Thanks for your PR.

I'm waiting for a google member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

/ok-to-test

Same comment copied from the other PR:

This looks good. Do you think we have enough metrics here where we need to start respecting --ignore-metrics? I believe the current PR will just have zero values for disabled metrics, which is acceptable, but adds to the load for any backends that process the data.

Same comment copied from the other PR:

This looks good. Do you think we have enough metrics here where we need to start respecting --ignore-metrics? I believe the current PR will just have zero values for disabled metrics, which is acceptable, but adds to the load for any backends that process the data.

I think that it will be good to start respecting disable_metrics parameter also for other storages than Prometheus. My only doubt is how to clearly inform users about these changes. If we start now, for some of storages disable_metrics will be respected, for others will not be respected.
Maybe it will be good to add this information to description in help, for example:

-disable_metrics metrics
        comma-separated list of metrics to be disabled. Parameter is used by Prometheus and statsd storages. Options are 'accelerator', 'cpu_topology','disk', 'diskIO', 'network', 'tcp', 'udp', 'percpu', 'sched', 'process', 'hugetlb', 'referenced_memory', 'resctrl'. (default tcp,advtcp,sched,udp,process,hugetlb,referenced_memory,cpu_topology,resctrl)

+1 to updating the flag description. If you'd prefer, we can only gate the new metrics with the respective disable_metric.