Prometheus Scrape Config Generator

Introduction:

Prometheus scrape configuration tells a Prometheus server which targets to collect metrics from, which HTTP path to request, how often to scrape, and which labels should travel with the collected time series. It is one of the most practical parts of Prometheus setup because a small YAML mistake can leave exporters missing, scraped too slowly, or labeled in a way that makes queries and alerts harder to trust.

A static scrape job is useful when the target list is known in advance, such as node exporters on fixed hosts, appliance exporters, application endpoints, or a small set of internal services. Each target is usually written as a host and port. Scheme, path, interval, timeout, and labels decide how Prometheus turns that address into a scrape request and how the resulting metrics can be filtered later.

Label choices matter because Prometheus identifies time series by metric name plus label set. A helpful target label such as site=dc1 or role=node makes dashboards easier to filter. A label with unbounded values can create too many series and make storage, queries, and alerts more expensive.

Generated YAML is a starting point for configuration review, not proof that the target endpoint is reachable or that the final server will reload cleanly. Check the YAML with promtool check config after placing it in the full Prometheus file, then reload Prometheus only after the target list, labels, and timeout budget match the deployment plan.

Technical Details:

A scrape_config defines a set of scrape parameters and targets. In a typical static job, job_name becomes the default job label, scheme and metrics_path build the request URL, and scrape_interval and scrape_timeout control the timing budget for each scrape.

static_configs holds target addresses and labels that apply to those addresses. Prometheus treats targets as host and optional port values, while the request scheme and metrics path stay separate. That separation is why api01.example.internal:8443 with scheme=https and path=/actuator/prometheus is safer than pasting a full URL into a target list.

Prometheus also supports special internal labels in the target label set. Labels such as __scheme__, __metrics_path__, __scrape_interval__, __scrape_timeout__, and __param_name can override scrape settings for a target before scraping. Labels beginning with double underscores are removed after target relabeling, so they should be used only for deliberate scrape behavior, not for normal query dimensions.

Scrape Config Field Map:

Target Row Translation:

Everyday Use & Decision Guide:

Start with a narrow static job. Enter a stable Job name, keep Scheme and Metrics path at their common defaults when every exporter exposes /metrics, and use one target row per host. Add labels such as site=dc1, role=node, or env=prod only when those labels will help queries, dashboards, alert routing, or ownership review.

The generator is a good fit for static hosts, network devices, appliance exporters, small service lists, and handoff snippets that need quick YAML. It is not a replacement for service discovery, authentication blocks, TLS settings, relabeling rules, or full Prometheus configuration review. If the scrape job needs those pieces, use this output as the static target core and add the missing configuration in the full file.

• Use Common labels when every target shares the same values. Row-specific labels override matching common labels.
• Leave Group identical label sets enabled when repeated labels make the YAML noisy.
• Choose Full scrape_configs block for a standalone paste, or Job item only when the destination file already has a scrape_configs list.
• Turn on Honor scraped labels only when labels from the exporter should win conflicts with Prometheus-side labels.
• Leave Honor scraped timestamps enabled unless a target exports timestamps that should be ignored.
• Use Sample limit, Target limit, and Label limit only when a runaway exporter or large static list needs explicit scrape guardrails.

If Scrape config needs attention appears, fix that banner before copying YAML. Common causes are a target written as a full URL, a metrics path without a leading slash, a blank label value, an unsupported internal label, or a timeout greater than the interval.

After the summary says Scrape config ready, review Target Ledger for label placement and Config Audit for timeout, duplicate target, grouping, override, and limit findings. Copy the YAML only after those rows match the config you intend to load.

Step-by-Step Guide:

Build the static target list first, then review the generated YAML and audit rows before handoff.

1. Set Job name. The summary should show that value as the primary job name once required inputs are valid.
2. Choose Scheme, enter Metrics path, then set Scrape interval and Scrape timeout. The timeout must stay at or below the interval.
3. Enter one address per line in Targets and labels, such as sw01.example.internal:9100,site=dc1,role=switch. Lines beginning with # are ignored.
4. Add per-target overrides only when needed. Use scheme=https, path=/actuator/prometheus, interval=15s, timeout=5s, or param_module=http_2xx after the address.
5. Open Advanced to choose YAML scope, add Common labels, change grouping, or include honor and limit options.
6. If the validation banner appears, fix the listed row or field. A full URL belongs in separate scheme and path settings, not in the target address.
7. Use Scrape YAML to copy or download the YAML, then use Target Ledger to copy, download, or export the target table when a review record is needed.
8. Use Config Audit and JSON for handoff evidence only after the summary badges show the expected target count, static block count, interval, and label or override count.

Interpreting Results:

Scrape YAML is the configuration text to paste into a Prometheus file. Read it together with Target Ledger because the ledger shows the target address, visible labels, special overrides, label count, and static group for each row. That makes label mistakes easier to catch before the YAML moves into a deployment branch or operations ticket.

Config Audit is a review aid, not a live Prometheus check. A ready audit means the entered values passed the generator's format and timing checks. It does not prove the endpoints answer requests, the exporter returns valid metrics, authentication is present, or the surrounding Prometheus file is valid.

A clean result can still fail during deployment if a target is unreachable, the path returns non-metrics content, TLS or authentication is required, or the YAML is inserted at the wrong indentation in the final file. Treat the generated job as reviewed source text, then validate it in the real Prometheus context.

Worked Examples:

Network exporters with shared labels:

A job named network-devices uses http, /metrics, 30s, and 10s. The target list has sw01.example.internal:9100,site=dc1,role=switch, sw02.example.internal:9100,site=dc1,role=switch, and fw01.example.internal:9100,site=dc1,role=firewall. With grouping enabled, Scrape YAML groups the two switch targets together and writes the firewall target in a separate static config. Target Ledger shows three targets, two visible labels per row, and the static group assigned to each address.

Application endpoint with a custom path:

An application exposes metrics at api01.example.internal:8443 under /actuator/prometheus. The row api01.example.internal:8443 site=dc2 role=api scheme=https path=/actuator/prometheus timeout=5s keeps the address clean while adding three special overrides. Config Audit reports per-target overrides, and Scrape YAML emits labels for __scheme__, __metrics_path__, and __scrape_timeout__ for that static config.

Standalone job item for an existing file:

A team already has a scrape_configs key in prometheus.yml. Choosing Job item only makes the output begin with - job_name: instead of adding another parent key. That output is easier to paste under the existing list, while JSON still records the selected scope, target count, grouped static configs, audit findings, and final YAML.

Full URL pasted as a target:

If a row starts with https://api01.example.internal:8443/metrics, the validation banner says the target is not a host[:port] target. The fix is to enter api01.example.internal:8443, set Scheme to https, and set Metrics path to /metrics or use row-level scheme=https and path=/metrics. After that correction, the summary can return to Scrape config ready.

FAQ:

Glossary:

scrape_config

A Prometheus configuration entry that defines targets and scrape parameters for a job.

static_config

A static list of targets and labels inside a scrape config.

job_name

The scrape job name that becomes the default job label.

Metrics path

The HTTP path Prometheus requests from a target, commonly /metrics.

Scrape interval

The time between scrape attempts for a job or target.

Scrape timeout

The maximum time one scrape may run before Prometheus stops waiting.

Internal label

A double-underscore label used by Prometheus during target processing, such as __scheme__.

Cardinality

The number of unique time series created by metric names and label values.

References:

• Configuration, Prometheus Authors.
• promtool, Prometheus Authors.
• Data model, Prometheus Authors.
• Metric and label naming, Prometheus Authors.