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

Adding a Kubernetes/Docker config #581

Closed
wants to merge 3 commits into from

Conversation

chzbrgr71
Copy link
Contributor

This PR includes the resources needed to deploy to a container and run in Kubernetes.

  • Dockerfile
  • YAML for DaemonSet, Service, ServiceMonitor
  • Instructions
  • Updated main README to link in

Signed-off-by: Brian Redmond <brianisrunning@gmail.com>
Signed-off-by: Brian Redmond <brianisrunning@gmail.com>
Signed-off-by: Brian Redmond <brianisrunning@gmail.com>
ports:
- containerPort: 9100
hostPort: 9100
name: https
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does windows_exporter support TLS?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think TLS and auth need to be handled for this. I saw that TLS came up in the past for this project: #57

Also note that the linux prom node_exporter still has TLS as experimental. https://github.com/prometheus/node_exporter#tls-endpoint

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool. I just was confused a bit when tested this solution.

@carlpett
Copy link
Collaborator

carlpett commented Aug 6, 2020

Hey @chzbrgr71,
Thanks for getting this started! I hadn't had any opportunity to run Windows nodes on Kubernetes yet, but I started up a small cluster to test it out. I think the main issue here will be what metrics work, and if they actually match what would have been seen on the node.
Some findings from my experimental setup, please let me know if you had a different experience

  • The container collector did not work (cannot reach the Host Compute Service, likely due to container isolation)
  • CPU metrics did not have core information (core label was empty), and seemed to be related to the container CPU usage, not host CPU
  • In general, most collector information seemed related to what was going on in the container, not the host.

I suspect the container running the exporter is a bit "too isolated", so we'll just collect data on the container itself, but I haven't been able to validate this from my short time.

Maybe @sachinmsft has some insights, or could ping someone from within the Hyper-V/Windows team with knowledge of how this would work?

@sachinmsft
Copy link
Contributor

Hi @chzbrgr71 ,
I am confused with this PR . I have below question.
Are you trying to get the node metrics through running wmi-exporter on each node as daemonset like node-exporter gets for Linux node ?

If yes, then I don't think that you can achieve that by running the wmi-exporter inside the pod. reason being that Windows does not support privilege container so you can not run wmi-exporter in the node context.

You have to run the wmi-exporter.exe on the node to get the node metrics. If you want to run it through K8s then you can use the Wins (https://github.com/rancher/wins) to run the process on the node through container. but it adds the dependency of running wins service on each Windows node beforehand.

@chzbrgr71
Copy link
Contributor Author

Thanks for taking a look at this.

@sachinmsft - you are correct that I'm trying to get node metrics in the same fashion as node-exporter. It makes sense that this might not work in a Windows scenario. We're not really able to run the wmi-exporter on the node since this is being deployed on AKS and we're not able (allowed) to install software directly on the VM's. That might prevent us from using the Rancher Wins utility as well.

If you have any other ideas, please let me know. We're seeing more and more AKS customers looking for this capability.

@sachinmsft
Copy link
Contributor

Hi @chzbrgr71,
I don't see any other way. We should not need wins once Windows has privilege containers support.

@keikhara
Copy link

Just to add on this.. conversation. The way you can collect the metrics data like other vendors like datadog, azmon is using named pipe. Here's a url which explains this.
https://dille.name/blog/2017/11/29/using-the-docker-named-pipe-as-a-non-admin-for-windowscontainers/
Bare in mind that the base metrics will not be as elaborate as linux containers as windows containers are different. You may need to do some calculation to normalize for customers who wants to do both linux and windows containers in the same graph.

@casey-robertson
Copy link

Just to add on this.. conversation. The way you can collect the metrics data like other vendors like datadog, azmon is using named pipe. Here's a url which explains this.
https://dille.name/blog/2017/11/29/using-the-docker-named-pipe-as-a-non-admin-for-windowscontainers/
Bare in mind that the base metrics will not be as elaborate as linux containers as windows containers are different. You may need to do some calculation to normalize for customers who wants to do both linux and windows containers in the same graph.

Where do you tell the Windows exporter to use the localhost listener as a target?

@jsturtevant
Copy link
Contributor

Kubernetes now has support for HostProcess Containers so we can move forward with this PR 🥳

I've took this work and add the support for hostprocess here: https://github.com/jsturtevant/windows_exporter/tree/use-hostprocess

@chzbrgr71 Let me know if you are interested in taking this forward otherwise I am happy to submit a separate PR.

Couple screen shots of this working:

node cpu:
Screenshot from 2021-11-05 09-43-57

containers running:
Screenshot from 2021-11-05 09-37-44

targets:
Screenshot from 2021-11-05 09-38-19

@perithompson
Copy link

ah you got here before me @jsturtevant 😄

@carlpett
Copy link
Collaborator

carlpett commented Nov 5, 2021

Fantastic news! Let us know if it'll go in this or another PR and we can get it reviewed :)

@chzbrgr71
Copy link
Contributor Author

This is awesome. Great work here. This had dropped off my radar over 12 months ago and I know @jsturtevant and team put a lot of work upstream to make it work.

Feel free to move forward with a PR on this since I don't have cycles now to look at it.

@jsturtevant
Copy link
Contributor

opened a new PR: #864

/close

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

Successfully merging this pull request may close these issues.

8 participants