Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] PoC: top cpu/memory #2825

Open
blanquicet opened this issue May 9, 2024 · 3 comments
Open

[RFE] PoC: top cpu/memory #2825

blanquicet opened this issue May 9, 2024 · 3 comments

Comments

@blanquicet
Copy link
Member

PoC: top cpu/memory

Several people in the community is asking why we don’t have a gadget like top block-io, that shows the pods consuming more CPU/memory.

Q&A from IG meeting:

  • Isn't it already provided by kubectl top? Yes, but:
    • IG would not depend on the metrics server like kubectl top does.
    • People already implementing the integration of IG for other use cases will get memory and CPU info for free. They won't need to integrate also kubectl top.
  • As far as we know, there is no way to implement this using eBPF. So, how can we feed the IG data pipeline?
    • One of the proposals is that the gadget image doesn't contain an eBPF program but a binary which collect the CPU/Memory info. Then, IG will be in charge of creating a datasource from it which will feed the data pipeline. Is it feasible? We are not sure, so the proposal is to create a PoC with this idea to evaluate its feasibility.
@flyth
Copy link
Member

flyth commented May 16, 2024

If it's easy enough to support it from the IG core and provides enough value for many use cases, we can introduce it as a helper DataSource that can be activated from just the gadget.yaml by adding an annotation to the gadget. In this case (CPU/mem) it could just take an additional parameter for the interval whenever activated and then create a new DataSource and emit the values for every interval.

@blanquicet
Copy link
Member Author

But we were considering make it a gadget, not a complement for other gadgets. Or did I misunderstand what you said?

@flyth
Copy link
Member

flyth commented May 17, 2024

Sure, but does it matter where information is coming from? If it's easy to maintain and can be useful in different scenarios, IMHO providing such functionality from the core is okay (WASM or spawning other binaries always increases overhead and in the latter case could also raise security concerns.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🆕 New
Development

No branches or pull requests

2 participants