Applications Manager monitors a Kubernetes cluster by reading the metrics the cluster's Prometheus already collects. On NKP, Prometheus is usually exposed behind a login proxy (traefik-forward-auth with Dex), which a plain integration cannot pass. APM supports this through a Form-based Login authentication mode: it logs in with the same credentials used on the NKP login page, keeps the session, and replays it on every query.
Complete these before adding the integration.
Prometheus running in the cluster. NKP ships kube-prometheus-stack as a platform application; enable it per cluster or across a workspace. The deployment must include these exporters, which are the data source for APM's Kubernetes monitors:
A discovery label on the scraped targets. APM discovers monitors by a custom label on the metrics. Without it the integration connects but discovers nothing. Add a label with:
apm_filter;The simplest way is external_labels, which stamps the label on every series from that cluster's Prometheus:
global:
external_labels:
apm_filter: "<unique-cluster-name>"
Per-job control through relabel_configs works too, as long as the label lands on the targets you want monitored.
Network reachability from the APM server to the cluster's Prometheus endpoint on the required port (443 for the proxy path, 6443 for the API-server path).
Pick one path per cluster, based on how Prometheus is exposed.
| Path | APM auth mode | When to use | Needs |
|---|---|---|---|
| Through the login proxy | Form-based Login | Prometheus is behind the NKP Dex / forward-auth proxy (the default) | A Dex local or LDAP username and password. Not usable if the IdP is external or enforces MFA. |
| Through the Kubernetes API server | Service Account Token | You can reach the API server and grant RBAC | Port 6443 reachable, a service account token with read access and services/proxy permission; endpoint is the API-server service-proxy path. |
| Through a direct ingress | No Authentication or Basic Authentication | Prometheus is exposed without the proxy | The direct URL, plus basic credentials if any. |
Form-based Login is the usual choice on NKP because it needs no cluster-side networking change.
Go to Settings → Integrations (Add-On Settings) → Prometheus, then fill in:
General specifications
Prometheus Server Details
443 for the proxy path over HTTPS./dkp/prometheus.Discovery Specifications
apm_filter. This must match the label on the targets.Save. APM runs a readiness check: it logs in through the proxy, confirms the session, and then discovers monitors using the filter label.
Each APM integration points at one Prometheus endpoint, so for multiple clusters you either:
The per-cluster discovery label from the prerequisites is what keeps clusters apart in either model, so apply it consistently.
| Symptom | Cause and fix |
|---|---|
| 307 or 302 redirect error when adding | A non-login auth mode was used against the proxy. Switch Authentication to Form-based Login. |
| "Login to the authentication proxy ... failed. Check the username and password." | Wrong username or password, or an unsupported IdP. Verify the exact credentials used on the NKP login page. Form-based Login does not work with an external IdP or MFA. |
| "redirected to a login page that is not a supported username/password form" | Dex is using an external identity provider, multiple sign-in options, or MFA. Use the Service Account Token path instead, or expose Prometheus without the proxy. |
| Integration saves but no monitors are discovered | The discovery label is missing on the targets, or the Data Collection Filter Label does not match it. Confirm the label name and value on the Prometheus targets. |
| Connection or SSL errors | Check reachability on the port, proxy settings, and that the protocol and port match (HTTPS on 443). NKP endpoints are commonly self-signed, which APM accepts. |
| Login works, polling fails after hours | The proxy session expired and re-login did not succeed. Re-check credentials; confirm the APM server clock is in sync. |