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.

Sign up for GitHub

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

Jump to bottom

Add granularity on Kubernetes integration #1017

Closed
ChrsMark opened this issue Mar 31, 2021 · 3 comments · Fixed by #1018
Closed

Add granularity on Kubernetes integration #1017

ChrsMark opened this issue Mar 31, 2021 · 3 comments · Fixed by #1018
Assignees
@ChrsMark

Comments

@ChrsMark
Copy link
Member

We want granularity on Kubernetes integration (like AWS), with one package shipping multiple integrations: kubelet, kube_state, etc.. Outcome from #526 should be able to apply to kubernetes integration as well.
@elasticmachine
Copy link

Pinging @elastic/integrations (Team:Integrations)

@sorantis
Copy link

sorantis commented Apr 1, 2021

Suggested Kubernetes package structure

Screen Shot 2021-04-01 at 12 48 34

@ChrsMark ChrsMark transferred this issue from elastic/beats May 24, 2021
@ChrsMark ChrsMark mentioned this issue May 24, 2021
Merged
4 tasks
@ChrsMark
Copy link
Member Author

Btw @sorantis now I realise that this one will be landed really in time with the changes applied in elastic/beats#25640 and elastic/beats#25782 where kubelet metricsets/data_streams will share the input coming from the stats endpoint (request happen on Metricbeat level and cached). Same goes for state_* metricsets/data_sets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ChrsMark ChrsMark

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Introduce kubernetes package granularity ChrsMark/integrations
3 participants
@sorantis @ChrsMark @elasticmachine