chore: tidy use of bpfSupportedMetrics for NewStats()

[maryamtahhan]

Tidy up the universal passing around of bpfSupportedMetrics for NewStats()

• Introduce a reasonable default set of bpfSupportedMetrics in the stats package so that these can be used for NewStats() whenever it's invoked.
• Remove the InitAvailableParamAndMetrics() function and simply initialise the variables in the package at declaration.
• Remove dependency between bpf and stats packages entirely

[github-actions]

🤖 SeineSailor

Here is a concise summary of the pull request changes:

Summary: The "chore: tidy universal use of bpfSupportedMetrics" pull request aims to standardize the use of bpfSupportedMetrics across the codebase. It introduces a contained lookup function, replacing the redundant !stats.AvailableBPFMetrics.HardwareCounters.Has(config.CPUTime) checks.

Key Modifications:

1. Simplified code: The changes reduce code redundancy and improve organization.
2. Improved maintainability: The consistent use of bpfSupportedMetrics makes the code easier to maintain.
3. Potential behavioral impact: The changes might affect the initialization of available parameters and metrics.

Observations and Suggestions:

• The pull request is still a work-in-progress (WIP), indicating that further refinements are needed.
• It would be beneficial to include unit tests to ensure the new lookup function behaves as expected.
• A thorough review of the affected code paths is recommended to ensure the changes do not introduce unintended consequences.

Overall, this pull request takes a step towards improving code consistency and maintainability. However, it requires further attention to ensure the changes do not impact the code's behavior.

[maryamtahhan]

Hola @dave-tucker @sthaha @rootfs

Would really appreciate a review if you get the chance.

Thanks in advance
Maryam

[dave-tucker]

Following up from my earlier comment I feel like we're treating a symptom (bpfSupportedMetrics is being passed everywhere) and not the disease (why does bpfSupportMetrics NEED to be plumbed in so many places).

The bigger problem is that pkg/stats depending on pkg/bpf...
However, pkg/stats is regularly being called from parts of the codebase where a bpfExporter object isn't in scope.

I think the pkg/stats -> pkg/bpf dependency can be removed entirely by simply populating the hashmap with all the possible eBPF features. We're already filtering them before being posted to prometheus - see: CollectResUtilizationMetrics. That should clean up most of the mess.

I don't feel like the cleanup to make pkg/model depend on a maybe-unititialized value in pkg/stats is a good idea - depending on being provided a bpfSupportedStats struct seems fine.

[maryamtahhan]

I've moved the stats globals cleanup to #1659 ... and i think this ready for another round of review

[rootfs]

@maryamtahhan can you rebase to pick the e2e test diagnostics? thanks

[maryamtahhan]

Hi @dave-tucker
I think this is ready for review again. Please let me know if there are any other issues

Thanks in advance

[maryamtahhan]

I will rebase this again

[maryamtahhan]

This is rebase now :) \o/ yay!

[dave-tucker]

LGTM pending resolution of merge conflict