Baseline for the Kong replacement on api.riotpiao.com. Brings the working tree under version control for the first time: gateway source, the task board that drives the agent runs, test fixtures, and K8s manifests. Anchor the gateway ignore rule to the repo root. Unanchored, "gateway" also matched the cmd/gateway/ source directory, so the program entrypoint was excluded from every commit. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
1.6 KiB
1.6 KiB
5.3 — ServiceMonitor for gateway scraping (GREEN)
Phase: 5 — Observability Stage: GREEN Depends on: 5.2
Exposing metrics is not the same as having them collected. Kong's plugin was picked up cluster-wide; the gateway must be explicitly registered or the dashboards go blank at cutover.
- A ServiceMonitor selects the gateway Service and is committed to git, applied by Argo — never
kubectl apply - It carries whatever label the cluster's Prometheus uses to select ServiceMonitors, verified against the running Prometheus rather than assumed
- The scraped port is a named port on the gateway Service, matched by name not number
- Scrape interval and timeout are explicit
- The gateway appears as an
up == 1target in Prometheus, in the expected namespace - Metric labels identify the gateway pod and namespace, so 2 replicas are distinguishable
- Scraping works while the gateway is still unexposed to public traffic — this lands before cutover, not after
- Note:
prometheus-operated.monitoringis headless with ClusterIPNone, so any egress policy that touches it needs pod selectors, not a ClusterIP
Verify
kubectl -n monitoring get servicemonitor -l release --show-labels | grep -i frontend
# expected: the gateway ServiceMonitor exists and carries the selector label Prometheus uses
# Query Prometheus for the gateway target
curl -s 'http://localhost:9090/api/v1/query?query=up{job=~".*homelab-frontend.*"}' \
| python3 -c "import json,sys;r=json.load(sys.stdin)['data']['result'];print(len(r),[x['value'][1] for x in r])"
# expected: 2 targets, both reporting "1"