Mukul SharmaandClaude Opus 5
6321533c47
Vendored prometheus-community/prometheus 29.27.1 the same way Contour/ArgoCD/Vault/Gitea/Harbor/Jenkins already are here — a thin Chart.yaml dependency plus a committed .tgz — rather than hand-written like postgresql, which has no official chart to vendor. Server only: alertmanager, kube-state-metrics, prometheus-node-exporter and prometheus-pushgateway are all enabled by default in this chart and all disabled here. None are needed for what actually consumes this — toolshed's per-app CPU/memory metrics read straight from the chart's built-in kubernetes-nodes-cadvisor scrape job (kubelet's own cAdvisor endpoint) — and each is its own pod on a node that was already at its 8GB ceiling before this. Trimmed for the same ceiling: 3Gi PVC on local-path (not the chart's 8Gi default), 7-day retention (not 15), resources capped at 512Mi. nameOverride pinned to exactly "prometheus" matters more here than for any other component pinning it: the chart's server Service renders as "<release-name>-server", so this is what makes it "prometheus-server" — the exact hostname toolshed's PROMETHEUS_URL was already seeded to point at, before this existed, so the connection is already correct the day this deploys. Verified with `helm template` against the real chart and these values: server-only object set (ClusterRole, ClusterRoleBinding, ConfigMap, Deployment, PVC, Service, ServiceAccount — nothing from the four disabled subcharts), and the rendered PVC/retention/resources/Service name all match what's written above. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wajog7nELA3i8JWTjxYGHF
87 KiB
87 KiB