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

feat: prometheus metrics on separate http port #177

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

saksmt
Copy link

@saksmt saksmt commented Jul 31, 2024

Use case: pikvm exposed to internet via port forwarding, prometheus metrics scrapped in intranet without need to bother about authentication

@mdevaev
Copy link
Member

mdevaev commented Jul 31, 2024

Prometheus by default is closed by auth. What is use case for this?

@saksmt
Copy link
Author

saksmt commented Jul 31, 2024

Prometheus by default is closed by auth. What is use case for this?

Total isolation on network level (imagine closed off trusted intranet where only some endpoints are exposed to internet and all of the internal communication is trusted and secure by default) which is more secure and does not require fiddling with authentication in prometheus scrapping (especially this point becomes valid when using OTP)

@saksmt
Copy link
Author

saksmt commented Jul 31, 2024

Here's an example:

Given: server, pikvm and a network.

Network is walled off and only allows:
0.0.0.0:443 -> server:443 {homelab: git, grafana, ...}
0.0.0.0:22080 -> pikvm:80
0.0.0.0:22443 -> pikvm:443

In this case you'd want maximum security for pikvm, hence you'll enable TOTP. But you still want to collect metrics from pikvm and store them on server for alerting/dashboarding/etc.

Reasonable solution in that case is to disallow prometheus metrics on default port in pikvm, disable authentication for them and expose them lets say on 22091 to be collected by server. That way prometheus metrics from pikvm are unavailable from internet and are still possible to be collected by server since that does not require port forward for 22091


Maybe there's a bit more elegant solution to do this in python server itself (I mean binding route to different port/socket/...), but since I don't really know how to do that and as far as I understood all binding to actual ports (as opposed to unix sockets) is done only in nginx, I've done it that way. Which works and is actually tested on my pikvm through copying template and prepending block with needed values (<% ... %>)

@mdevaev
Copy link
Member

mdevaev commented Sep 4, 2024

I think I forgot to answer. It's reasonable and I'll think about what the best solution might be. It is likely that what you are suggesting is exactly what it is.

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

Successfully merging this pull request may close these issues.

2 participants