How to Set Up Prometheus and Grafana Monitoring for Kubernetes

Prometheus collects and stores metrics; Grafana visualizes them. This walks through deploying both into a Kubernetes cluster using the community-maintained Helm chart that bundles them together sensibly.

Step 1: add the Helm repository

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Step 2: install the kube-prometheus-stack chart

helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring --create-namespace

This single chart deploys Prometheus, Grafana, Alertmanager, and a set of pre-configured dashboards and scrape targets for core Kubernetes metrics — a considerably faster starting point than configuring each component independently from scratch.

Step 3: verify the components are running

kubectl get pods -n monitoring

You should see pods for Prometheus, Grafana, Alertmanager, and node-exporter (which collects per-node system metrics) all in a Running state.

Step 4: access the Grafana dashboard

kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80

Then open http://localhost:3000 — the default credentials for this chart are typically admin / prom-operator, though this should be changed immediately in any real deployment.

Step 5: explore the pre-built dashboards

Grafana → Dashboards → browse the pre-loaded set, including
  Kubernetes cluster overview, node metrics, and pod-level
  resource usage

The kube-prometheus-stack chart ships with a substantial set of dashboards already configured against Prometheus as a data source — worth exploring before building custom ones, since many common needs are already covered.

Step 6: query metrics directly with PromQL

Grafana → Explore → select the Prometheus data source →
  rate(container_cpu_usage_seconds_total[5m])

PromQL is Prometheus’s own query language — this example query shows per-container CPU usage rate over a 5-minute window, the kind of expression that underlies most of the dashboards you’ll build or customize.

Step 7: add a custom scrape target for your own application

# ServiceMonitor custom resource, if your app exposes /metrics
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-monitor
spec:
  selector:
    matchLabels: {app: myapp}
  endpoints:
    - port: metrics
      path: /metrics

A ServiceMonitor (provided by the Prometheus Operator this chart installs) tells Prometheus to automatically discover and scrape your own application’s metrics endpoint, the same declarative way Kubernetes handles most other configuration.

Step 8: set up an alert rule

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: high-error-rate
spec:
  groups:
    - name: myapp.rules
      rules:
        - alert: HighErrorRate
          expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
          for: 10m

This alert fires if the 5xx error rate exceeds 5% sustained for 10 minutes — routed through Alertmanager to whatever notification channel (Slack, email, PagerDuty) is configured separately.

Why the combined Helm chart is worth using over assembling components manually

Prometheus, Grafana, Alertmanager, and the various exporters that feed them metrics each have their own configuration surface — getting all of them correctly wired together (data sources, scrape configs, dashboard provisioning) by hand is a substantial amount of glue work that the kube-prometheus-stack chart has already solved and battle-tested across a huge number of real deployments, making it the sensible starting point for nearly any Kubernetes cluster’s monitoring setup rather than assembling the same stack manually from scratch.