Skip to main content
So we got our application deployed onto Kubernetes:
Now it’s time to make Prometheus aware of these new targets. There are two main approaches:
  • The less ideal approach: use the chart’s additionalScrapeConfigs to append raw Prometheus scrape jobs to the server configuration.
  • The preferred approach: use ServiceMonitors, the Prometheus Operator–native, declarative way to add targets.
Below I show the high-level steps for the less-preferred approach, so you understand what to change. It will work, but there are caveats.
Using additionalScrapeConfigs means you are appending raw Prometheus scrape configuration. The chart does not validate these entries and upgrades could potentially break if the scrape config is incompatible with future Prometheus changes. Prefer ServiceMonitors for a more robust, operator-friendly solution.
  1. Dump the chart’s default values so you can edit them:
  1. Open values.yaml and search for additionalScrapeConfigs. This field lets you append Prometheus scrape jobs. The chart will not validate the contents, so ensure the jobs are valid Prometheus configuration blocks.
Here is an example of how you can add additional scrape jobs (this is one valid way to format the jobs; adapt jobs and relabeling rules to your environment):
Notes about the example:
  • The kubernetes_sd_configs and relabel_configs entries follow Prometheus server configuration syntax.
  • You must ensure the configuration is valid YAML and valid Prometheus config; the chart will not validate it for you.
  • Replace the service/port names and relabel rules to match how your application is exposed in Kubernetes.
  1. Apply the updated values by upgrading the Helm release:
After the upgrade completes, Prometheus should reload with the appended scrape jobs and begin scraping the newly added targets.
ServiceMonitors provide a declarative, Operator-native way to add targets to Prometheus and are generally the recommended approach.

Watch Video