🇧🇷 Leia a versão em português aqui.

Once a Kubernetes cluster is up and running, monitoring what's happening inside it — CPU and memory usage, number of active replicas, application latency — stops being optional. Prometheus is today's de facto standard for monitoring in the Kubernetes ecosystem: a time-series database that periodically collects metrics (pull model) and lets you query and alert on them.

In this article, I show how to install Prometheus on an on-premise cluster using Helm, and how to prepare your own applications to be monitored by it.

Prerequisites

Before installing Prometheus, make sure you already have:

  1. Helm installed (see the dedicated article if you don't have it yet);
  2. Metrics Server installed and working — confirm with: 
kubectl top nodes

Enter fullscreen mode Exit fullscreen mode

If the command returns CPU and memory usage data for the nodes, the cluster already has a basic metrics source active.

Installing Prometheus via Helm

Prometheus charts (like practically any popular tool in the Kubernetes ecosystem) are available on Artifact Hub — the main centralized community Helm chart repository.

1. Add the official Prometheus community repository:

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

Enter fullscreen mode Exit fullscreen mode

To check the repositories already added to Helm:

$ helm repo list

Enter fullscreen mode Exit fullscreen mode

2. Export the chart's default values, so you can customize them before installing:

$ helm show values prometheus-community/prometheus > prometheus-values.yaml

Enter fullscreen mode Exit fullscreen mode

This prometheus-values.yaml file contains all of the chart's configurable options — Service type, resources (CPU/memory), data retention, and many others. It's worth reviewing (or at least skimming through) before installing, adjusting whatever makes sense for your environment — for example, changing the service exposure type to NodePort, as we'll see next.

3. Install the chart, using the customized values file:

$ helm install prometheus prometheus-community/prometheus --values prometheus-values.yaml

Enter fullscreen mode Exit fullscreen mode

About kube-state-metrics

It's worth noting that the prometheus-community/prometheus chart automatically installs, as a subchart, kube-state-metrics — a component responsible for exposing metrics about the state of Kubernetes objects (desired vs. available pods, Deployment status, resource usage per namespace, etc.), complementing the infrastructure metrics already collected via Metrics Server. In other words, by installing Prometheus this way through Helm, you don't need to manually create the ServiceAccount, ClusterRole, ClusterRoleBinding, Deployment, and Service manifests for kube-state-metrics — the chart already handles that.

Accessing Prometheus

Depending on how the Service was exposed in prometheus-values.yaml (for example, via NodePort), Prometheus becomes accessible at a URL like:

https://adm.bagarote.com.br:30001

Enter fullscreen mode Exit fullscreen mode

And the raw metrics endpoint (used internally by Prometheus itself, but also queryable manually for debugging):

https://adm.bagarote.com.br:30001/metrics

Enter fullscreen mode Exit fullscreen mode

The host and port values above are just examples — adjust them to your cluster's actual address and the port defined in values.yaml.

Enabling monitoring in your applications

By default, Prometheus doesn't automatically know which pods it should monitor. The simplest way to indicate this — used in this configuration — is through annotations in the application's manifest:

spec:
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/path: /metrics
        prometheus.io/port: "8080"
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: mycompany/api:1.0.0
          ports:
            - containerPort: 8080

Enter fullscreen mode Exit fullscreen mode

These annotations tell Prometheus:

  • prometheus.io/scrape: "true": that this pod should be monitored;
  • prometheus.io/path: the path where the application exposes its metrics (by convention, /metrics);
  • prometheus.io/port: the port where this metrics endpoint is available.

For this to work, the application itself needs to expose a /metrics endpoint in a format Prometheus understands — usually through a client library specific to the language being used (for example, micrometer for Java/Spring Boot applications, or prom-client for Node.js).

Final thoughts

With Prometheus installed and applications correctly annotated, the cluster already has a solid foundation of metrics — both infrastructure and application-level. This is the natural first step before setting up friendlier visualizations (with Grafana, the topic of the next article in this addons series) and, eventually, automatic alerts based on those metrics.