feat(observability): turn on the agentgateway chart's own monitors and board - #616
Draft
QuentinBisson wants to merge 1 commit into
Draft
QuentinBisson wants to merge 1 commit into
QuentinBisson wants to merge 1 commit into
Conversation
…d board The packaging chart vendors upstream's Grafana board and the monitor objects that feed it, and nothing ever turned them on: monitoring.enabled defaults to false and this chart never set it. So the platform had no scrape of the agentgateway controller at all, and upstream's board — the MCP tool-call, XDS and runtime rows among them — sat unused in a chart we publish, over series we already collect. agentgateway.monitoring.enabled follows the resolved global.observability.metrics.serviceMonitor.enabled like every other monitor of this chart, at the fleet's 60s interval rather than upstream's 15s, with the tenant label on both monitors and the board in Shared Org / Agent Platform. The connectivity chart's own data-plane PodMonitor goes with it. Upstream's selects the same pods by GatewayClass where ours selected by gateway name, so keeping both would double every data-plane series. The range floor moves to 2.4.0: through 2.3.0 the packaging chart's schema closed monitoring.serviceMonitor.extraLabels and monitoring.grafanaDashboard.labels against their concrete defaults and rendered no annotations on the dashboard ConfigMap, so none of these values were settable (giantswarm/agentgateway#60). Pin first — the values only work above the floor.
Published Helm chart
|
| Chart | agent-platform |
| Version | 4.49.1-dev.feat-agent--monitoring.2026-09-21.15-08-14.h04473da |
| OCI reference | oci://gsoci.azurecr.io/charts/giantswarm/agent-platform:4.49.1-dev.feat-agent--monitoring.2026-09-21.15-08-14.h04473da |
| Digest | sha256:0e3f33de13c320f28b8a00c0ad117435a7e5ff962ae2e7237b80dcea604932e4 |
| Registry | public — gsoci.azurecr.io |
| Git catalog | giantswarm-test-catalog (index) |
Pull this chart
helm pull oci://gsoci.azurecr.io/charts/giantswarm/agent-platform --version 4.49.1-dev.feat-agent--monitoring.2026-09-21.15-08-14.h04473daPosted by architect-orb · build 10962 · commit 04473da · updated in place on every push
Published Helm chart
|
| Chart | agent-platform-connectivity |
| Version | 4.49.1-dev.feat-agent--monitoring.2026-09-21.15-08-14.h04473da |
| OCI reference | oci://gsoci.azurecr.io/charts/giantswarm/agent-platform-connectivity:4.49.1-dev.feat-agent--monitoring.2026-09-21.15-08-14.h04473da |
| Digest | sha256:5cad4de342e689b710058b9acb06308b3472c73bace7c9096f71dd7baec29169 |
| Registry | public — gsoci.azurecr.io |
| Git catalog | giantswarm-test-catalog (index) |
Pull this chart
helm pull oci://gsoci.azurecr.io/charts/giantswarm/agent-platform-connectivity --version 4.49.1-dev.feat-agent--monitoring.2026-09-21.15-08-14.h04473daPosted by architect-orb · build 10963 · commit 04473da · updated in place on every push
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The agentgateway packaging chart vendors upstream's Grafana board (
helm/agentgateway/files/agentgateway-dashboard.json) and the monitor objects that feed it, and nothing ever turned them on:monitoring.enableddefaults tofalseand this chart never set it.Two consequences. The platform has no scrape of the agentgateway controller at all, so the control plane that serves every data plane its config is unobserved. And upstream's board — with rows for MCP tool calls, XDS and process, cgroup and tokio runtime — sits unused in a chart we publish, over series we already collect and nothing reads.
Change
agentgateway.monitoring.enabled, following the resolvedglobal.observability.metrics.serviceMonitor.enabledlike every other monitor of this chart (auto | true | false). It turns on the controller ServiceMonitor, upstream's proxy PodMonitor and the dashboard ConfigMap, at the fleet's 60s interval rather than upstream's 15s, withobservability.giantswarm.io/tenanton both monitors and the board inShared Org / Agent Platform.The connectivity chart's own
templates/agentgateway/podmonitor.yamlis deleted. Upstream's selects the same pods by GatewayClass where ours selected by gateway name, so keeping both would double every data-plane series.The board is upstream's to maintain, generated there from
controller/install/dashboards/agentgateway-dashboard.py, so a version bump carries its fixes and we copy no JSON. The boards the platform writes itself stay ingiantswarm/dashboards.Blocked: pin first
components.agentgateway.versionRangemoves to>=2.4.0 <3.0.0. Through 2.3.0 the packaging chart's schema closedmonitoring.serviceMonitor.extraLabelsandmonitoring.grafanaDashboard.labelsagainst their concrete defaults and rendered no annotations on the dashboard ConfigMap, so the tenant label, the discovery label, the organization and the folder were all refused or dropped.verify-components-chartsis red on purpose until giantswarm/agentgateway#60 merges and releases 2.4.0, and says so:Nothing published carries that schema, releases and branch builds alike, so
RENDER_AGAINSTcannot name one. TheUNRELEASEDentry and this note go with the release.Tests
verify-auto: the new leaf resolves in both directions and is in the byte-for-byte fleet comparison.verify-llm-routing: this chart renders no PodMonitor of its own any more, the data-plane policy still admits port 15020, and the meta chart turns monitoring on withllmRoutingoff — the MCP path's series are not the LLM path's.verify-target: the monitoring block is held on both sides, and the retired PodMonitor document is left out of the golden comparison.verify-*target passes.verify-model-serving-policiesneeds a localkyvernoCLI I do not have.Second of three PRs putting every agent platform board in one folder, after #615. Part of giantswarm/giantswarm#36711.