-
Notifications
You must be signed in to change notification settings - Fork 813
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
Exposes metrics ports on pods in order to enable GCP Managed Prometheus #2712
Exposes metrics ports on pods in order to enable GCP Managed Prometheus #2712
Conversation
Build Succeeded 👏 Build Id: d752667a-1771-401b-a365-14d6f794b995 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
Thanks for digging into this! I'm now also learning how Google Cloud Managed Prometheus works! i think in general this looks like the correct approach (exposing the container ports on the relevant pods) It's worth noting that we have a metrics endpoint on the controller as well as the allocation system (controller's service monitor) - so this will need to cover both. 🤔 another thought I had, not sure if it sticks, but does it make any sense to allow someone to add arbitrary container ports to either the controller or the allocation Pods? Much in the same way we do Just trying to think more generically, rather than a specific solution for this specific problem. (Also docs are good 😄 ) WDYT? |
Hey Mark, the controller metrics port is actually already exposed since it's the same port that is used for its other http traffic. There's probably some work that can be done to unify the way that these ports are setup/exposed since some have names and port numbers coming from the Thinking about the more generic solution: outside of this port, I'm not sure what other ports even have something interesting running on them and aren't exposed on the pod by default(as opposed to a service) so I don't know if that would be of too much value at this point in time(but might be if another one of these crops up). |
That 100% makes sense. My thought here then, would be to just leave the container port always open (i.e. don't bother putting in a helm configuration variable). It's inside the cluster anyway, so I don't think it really matters. @roberthbailey WDYT? Regarding documentation - good point re: platform specific. I'm thinking something generic like "if your metric collection agent needs to scrape container ports directly (such as with Google Cloud Managed Prometheus), the ports you would need to scrape can be found at {insert details}" How does that sound? |
Build Succeeded 👏 Build Id: a2f03f1f-27fe-4020-900b-2138ede895d4 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
I agree that it should be fine to just add the port all the time. If nothing scrapes it then it doesn't do any harm, but it's there if someone wants to scrape it (using GMP or a different prometheus scraper that uses |
Sounds like we have consensus! If we could add some docs with a feature tag around it for the next version, that would be perfect 👍🏻 |
Just a heads up, we are one week away from our release candidate, so if you have time to implement the above comments, it would be awesome to get that in for that release. |
Sorry, the week got away from me. I think everything should be good now. Let me know if you want any changes with the little blurb I added in the docs. |
Build Failed 😱 Build Id: 797931f1-ddf6-4050-bfd0-96bdc665d58c To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
Build Succeeded 👏 Build Id: 9e75dc67-aacc-4e7b-aeda-2bf2ec7f35df The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
Co-authored-by: Mark Mandel <markmandel@google.com>
Build Failed 😱 Build Id: 286bc54c-9343-429c-926b-3974ee2a86f1 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
oooh, I see what it is. If you could run |
Lemme know if you run into any issues doing that, and I can do it on my end, and submit a PR to your PR 😄 |
…e/agones into expose-metrics-ports
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: austin-space, markmandel The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
New changes are detected. LGTM label has been removed. |
Build Succeeded 👏 Build Id: 0af444b2-ccef-4959-8cd2-5759e104261c The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
Build Succeeded 👏 Build Id: 4915143f-ae06-4744-a3a1-9b76c5c9b1fe The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
What type of PR is this?
/kind feature
What this PR does / Why we need it: GKE managed prometheus(GMP) makes some interesting decisions in how it implements a prometheus operator-like system. The most notable change is that there is no concept of a
ServiceMonitor
in GMP, only aPodMonitoring
custom resource. As the name implies this monitor only has visibility on pods, not onto services. Fortunately I can setupPodMonitoring
resources that closely imitate theServiceMonitor
resources in the included helm charts, the only issue is that the metrics port for the allocator service is not defined on the pod itself, just on the metrics service.This is the least intrusive way of introducing this. Alternatively a GMP flag could be included in the values and I could add all of the pod monitors as well.
Which issue(s) this PR fixes: none that I'm aware of
Special notes for your reviewer: