How to Use Prometheus: The Beginner's Guide (First Install, First Scrape Job, the Up Rule, and Node Exporter)

CodexFuse Team · 2026-10-31T10:21:07.445Z · 14 min read

The complete beginner guide to Prometheus: Docker install, your first prometheus.yml, the up rule, the Node Exporter scrape job, PromQL basics, and where Alertmanager fits.

If you want to learn how to use Prometheus, this guide takes you from zero to your first real monitoring setup: installing Prometheus with Docker, writing your first prometheus.yml, checking the famous up rule, adding the Node Exporter so you can watch your own server, and learning enough PromQL to ask your first questions. If you would rather have pretty auto-detected dashboards without writing queries, read the Netdata beginner guide first — it is the dashboard sibling of this monitoring cluster, while Prometheus is the pull-metrics, query-and-alert engine you are about to learn.

What is Prometheus, and why does everyone use it for monitoring?

Prometheus is an open-source monitoring and alerting toolkit that scrapes numeric metrics from your servers and applications over HTTP, stores them in its own time-series database, and lets you query them with its own language, PromQL. It was originally built at SoundCloud in 2012 and graduated from the Cloud Native Computing Foundation (CNCF) in August 2018, which is why it has become the default monitoring layer for cloud-native infrastructure (SigNoz, "What Is Prometheus?", updated October 26, 2026).

The core idea that makes Prometheus different is the pull model. Instead of your apps pushing data somewhere, the Prometheus server comes to your apps and scrapes their /metrics endpoints on a schedule — every 15 seconds by default. Each target exposes metrics, Prometheus collects them, and alert rules evaluated against that data send firing alerts to Alertmanager.

That pull model is exactly what this tutorial teaches you to use: a single server, a config file that lists what to scrape, and queries that tell you whether everything is healthy.

What do I need before installing Prometheus?

You need a machine to watch and a way to run containers. The fastest path is the Docker beginner guide — the one-command install below assumes Docker is already running — and if you want this monitoring to watch a real server, the what is VPS hosting guide explains the box most people point Prometheus at.

You also need two free ports: 9090 for Prometheus itself and 9100 for the Node Exporter. If 9090 is already taken on your machine, the same guide the writer-caution notes flag (Guvi's Docker setup tutorial, 47 days ago) warns about this exact collision — just remap to another host port.

How do I install Prometheus with Docker?

You install Prometheus with Docker by writing a small prometheus.yml file and mounting it into the official prom/prometheus container. Follow these seven steps and you will have a working server with one scrape job — itself — in under five minutes:

  1. Create a working directory for the setup, for example mkdir prometheus && cd prometheus.
  2. Write a prometheus.yml with a single job that scrapes Prometheus itself on port 9090 (full file in the next section).
  3. Create a data volume directory so metrics survive container restarts: mkdir data.
  4. Start the server with one Docker command:
    docker run -d \
      --name prometheus \
      -p 9090:9090 \
      -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \
      -v $(pwd)/data:/prometheus \
      prom/prometheus
  5. Check the container is up: docker ps | grep prometheus.
  6. Ask Prometheus if it is healthy: curl http://localhost:9090/-/healthy — it should print Prometheus Server is Healthy.
  7. Open http://localhost:9090 in your browser to see the web UI with its query bar.

This arc mirrors the install path in Hugo's Docker monitoring guide (blog.hugow.dev, 115 days ago), which also teaches the /-/healthy check as the moment your install goes from "running" to "confirmed working".

What does the prometheus.yml file actually contain?

The prometheus.yml file contains three blocks: global for server-wide settings, rule_files for alert and recording rules, and scrape_configs that list every target to monitor. The official Prometheus "First steps" documentation (prometheus.io, crawled this run) teaches exactly this shape, and the stripped-down version is all you need to start:

global:
  scrape_interval: 15s     # how often to scrape targets
  evaluation_interval: 15s # how often to evaluate rules

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['localhost:9090']
BlockWhat it controlsBeginner setting to know
globalServer-wide defaults for every scrape jobscrape_interval: 15s — scrapes each target every 15 seconds
rule_filesWhere alert and recording rules liveLeave it empty or commented out until you write your first alert
scrape_configsThe list of jobs Prometheus monitorsEach job has a name and a targets list of host:port pairs

Before starting Prometheus with a hand-written config, validate it the way the SigNoz quick-start (October 26, 2026) recommends: ./promtool check config prometheus.yml. A typo in YAML is the most common reason a first install refuses to start, and this one command catches it.

How do I know Prometheus is running correctly?

You know Prometheus is running correctly when curl http://localhost:9090/-/healthy answers with Prometheus Server is Healthy. and the Targets page at http://localhost:9090/targets shows your job's target as UP. The official "First steps" guide gives it about 30 seconds after startup to collect its first data about itself.

The health endpoint is a liveness probe — it tells you the server is up. The /targets page tells you whether scraping actually works. A target marked UP means the last scrape returned HTTP 200 from the /metrics endpoint; a target marked DOWN means Prometheus could not reach it, which is your first diagnostic: check the host, the port, and any firewall between them.

What is the "up" rule, and why does every Prometheus tutorial start with it?

The "up" rule is a built-in metric that equals 1 when the last scrape of a target succeeded and 0 when it failed, and every tutorial starts with it because it is the simplest possible question you can ask your monitoring: "is the thing I am watching actually reachable?" Open the expression browser at http://localhost:9090/query, type up, choose the Table tab, and hit Execute.

You should see a row for your prometheus job with the value 1. Filter it to one job with up{job="prometheus"} — the label selector inside the braces picks one time series out of all the ones named up. The SigNoz guide (October 26, 2026) describes this exact check as the confirmation that a scrape succeeded, and Hugo's guide (115 days ago) uses it as the first query every reader runs.

Count your targets with count(up), and count only the healthy ones with count(up == 1). These three tiny queries are the whole foundation of PromQL: a metric name, a label filter, and a function over the result.

How do I add the Node Exporter scrape job to Prometheus?

You add the Node Exporter by running its container and appending a second job to scrape_configs, then restarting Prometheus so it picks up the new config. The Node Exporter is the official tool that exposes host-level Linux or macOS metrics — CPU, memory, disk, network — as a Prometheus scrape target, and it serves them on port 9100 by default (official Prometheus docs, crawled this run).

docker run -d \
  --name node-exporter \
  -p 9100:9100 \
  prom/node-exporter

Now add the job to prometheus.yml:

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['localhost:9090']

  - job_name: node_exporter
    static_configs:
      - targets: ['localhost:9100']

Restart the container to load the new config — docker restart prometheus — then wait about 30 seconds. The official docs note that restarting is required here because this quick-start setup does not enable the config-reload endpoint; editing the file alone changes nothing until the server reads it again.

Verify it worked: type up{job="node_exporter"} in the expression browser and confirm it returns 1, then open /targets and check that the node_exporter pool shows its target as UP.

What is the Node Exporter actually measuring on my server?

The Node Exporter is measuring your host's operating-system counters through per-subsystem collectors, and each collector becomes dozens of metrics you can query. The latest release at write time is v1.12.1, published July 14, 2026 (GitHub releases API, prometheus/node_exporter). Here are the collectors a beginner will use first:

What you want to knowMetric to queryWhat it tells you
Is the server running out of memory?node_memory_MemAvailable_bytesAvailable RAM in bytes — the official docs use this as the first node_exporter example
How much CPU is free?100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100Average CPU usage across cores over the last 5 minutes
Is the disk filling up?100 * (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes)Filesystem usage percentage per mount point
Is the machine up?node_time_seconds - node_boot_time_secondsCurrent uptime in seconds, straight from the kernel
Is the server overloaded?node_load11-minute load average — compare against your CPU core count

Every one of these is a PromQL expression you can paste into the Graph tab at /query and watch as a live line chart. The CPU example shows the pattern you will reuse forever: pick the raw counter, apply rate() over a window, then aggregate across cores with avg().

What are the PromQL basics a beginner should learn first?

The PromQL basics you need first are label selectors, the four aggregation functions, and the rate() function — those three ideas cover most of what a beginner asks in the first month. Prometheus stores each measurement as a time series identified by a metric name plus key-value labels, and PromQL is how you filter, aggregate, and calculate over them (SigNoz, October 26, 2026).

Question you askPromQL you writeWhat it does
Is everything healthy?up1 per successful scrape, 0 per failed scrape
Just one job?up{job="node_exporter"}Label selector filters to one time series
HTTP 200s per second?rate(promhttp_metric_handler_requests_total{code="200"}[1m])rate() turns a growing counter into per-second speed — the official docs' own graphing example
Total series per job?count by (job) (up)Aggregates the series count grouped by job label
Which targets are down?up == 0Comparison filter — returns only failing series

Learn the label-selector syntax cold: {job="x"} is exact match, {job=~"x.*"} is regex match, and {job!="x"} excludes. Almost every query you will ever write is a metric name plus a selector plus one function.

What are the four Prometheus metric types?

The four Prometheus metric types are Counter, Gauge, Histogram, and Summary, and choosing the right one is what makes rate() and percentile math work. The SigNoz guide (October 26, 2026) defines them the way the client libraries implement them:

  • Counter — only goes up (resets to zero on restart). Use it for request counts and error totals; always query it with rate(), never read it raw.
  • Gauge — goes up and down. Use it for current memory usage, queue depth, or temperature; read it directly or with avg().
  • Histogram — records distributions in buckets (request durations, response sizes). Use histogram_quantile() to estimate p95/p99 latency across instances.
  • Summary — precomputes quantiles inside the application over a sliding window. Fine for one instance, but you cannot meaningfully average summaries across instances — prefer histograms when you need combined percentiles.

The beginner's rule of thumb: if the number can only increase, it is a counter and you graph its rate(); if it can move either way, it is a gauge and you graph it directly.

How does Alertmanager fit into Prometheus?

Alertmanager fits into Prometheus as the separate process that receives firing alerts, deduplicates and groups them, then routes notifications to receivers like email, Slack, or PagerDuty — Prometheus itself only evaluates the rules; Alertmanager decides who gets woken up. The writer caution on this topic is strict for a reason: Alertmanager needs its own config file and its own process, so never conflate it with the Prometheus server.

The flow is: you write an alert rule in PromQL (for example, "CPU usage above 90% for five minutes"), Prometheus evaluates it every evaluation_interval, and when it fires, Prometheus sends it to Alertmanager. Alertmanager groups related alerts so one outage is one notification, applies silences you set during maintenance, and uses inhibition rules to suppress the noise when one alert already explains another (SigNoz, October 26, 2026).

For a beginner, the practical takeaway is sequencing: get scraping and querying working first, then add one alert rule and one Alertmanager, then wire the receiver. If you want the dead-simple "is my site up" alerting first and the full metrics stack later, the Uptime Kuma beginner guide covers the outside-in alerting sibling — Uptime Kuma pings your services from the outside while Prometheus watches from the inside.

Prometheus vs Zabbix: which should a beginner pick?

A beginner setting up monitoring in 2026 should pick Prometheus if they want pull-based scraping, PromQL, and the cloud-native ecosystem, and Zabbix if they want an all-in-one appliance with agents, maps, and built-in dashboards on day one. The cluster member list for this article includes "prometheus vs zabbix" because beginners keep asking it, and the honest answer is that they solve different problems:

QuestionPrometheusZabbix
How do metrics get collected?Pull — server scrapes HTTP /metrics endpointsPush or poll — agents on hosts send data in
What do you query with?PromQL, a language built for time seriesA web UI with item/history views, no query language
Dashboards out of the box?Minimal built-in UI — pair with GrafanaFull dashboards, maps, and screens included
Alerting?Separate Alertmanager process you configureBuilt-in triggers, actions, and escalations
Best beginner fit?Docker/homelab/Kubernetes users who want to learn the modern stackSysadmins who want one package that does everything today

If you chose Prometheus, keep reading — the next section is where most beginners go immediately after this one.

How do I connect Grafana to Prometheus?

You connect Grafana to Prometheus by adding it as a data source in Grafana's Connections screen and pointing the URL at your Prometheus server — http://prometheus:9090 if both run in Docker on the same network, or http://localhost:9090 from the host. Every panel in Grafana then runs a PromQL query you already know how to write from this guide.

The full dashboard-building arc — first install, first data source, first panel, and your first alert — lives in the Grafana beginner guide, which is PUBLISHED and linked from this article's monitoring cluster. One caution carried over from the Guvi setup tutorial (47 days ago): never leave Grafana's default admin/admin credentials on an internet-facing instance — change them on first login.

The same hardening rule applies to Prometheus itself: it has no authentication by default, so bind it to 127.0.0.1 in your Docker port mapping or put it behind a reverse proxy before exposing it to the internet.

What mistakes do beginners make with Prometheus?

Beginners make the same five mistakes with Prometheus, and each one is cheap to avoid once you know it exists:

MistakeWhy it hurtsThe fix
Installing from the distro package manager and assuming it is currentDebian/Ubuntu's packaged Prometheus lags official releasesTeach the Docker path or the official binary — this guide's install uses the official prom/prometheus image (current release v3.15.1, published October 21, 2026 — GitHub releases API)
Editing prometheus.yml and expecting the change to applyThe server only reads the config at startup in this setupdocker restart prometheus after every config edit, or enable the reload endpoint
Querying a counter's raw value instead of its rateA counter always climbs, so the raw number means nothingAlways wrap counters in rate(metric[5m]) — see the PromQL table above
Exposing port 9090 to the internet with no authPrometheus has no built-in authenticationBind to 127.0.0.1 or front it with a reverse proxy that adds auth
Treating Alertmanager as part of the Prometheus serverAlerts silently go nowhere without a running AlertmanagerRun it as its own process with its own config file before writing alert rules

Sources

  • Prometheus, "First steps with Prometheus" — official documentation (prometheus.io, crawled 2026-10-31): single binary install, prometheus.yml three-block structure, scrape_interval 15s, node_exporter on port 9100, node_memory_MemAvailable_bytes, promhttp_metric_handler_requests_total, rate(...[1m]) graphing example.
  • SigNoz, "What Is Prometheus? Understanding the OSS Monitoring & Alerting Toolkit" (signoz.io, updated October 26, 2026): SoundCloud 2012 origin, CNCF graduation August 2018, four metric types, rate(http_requests_total[5m]), promtool check config, up{job="prometheus"} semantics, Alertmanager grouping/silences/inhibition.
  • GitHub releases API, prometheus/prometheus (queried 2026-10-31): latest tag v3.15.1, released 2026-10-21.
  • GitHub releases API, prometheus/node_exporter (queried 2026-10-31): latest tag v1.12.1, released 2026-07-14.
  • blog.hugow.dev, "Prometheus Monitoring: Observe Your Containers Like a Pro" (115 days ago): Docker install arc, curl /-/healthy check, first up query, node_exporter job, Loki/Jaeger lane note.
  • guvi.in, "Prometheus and Grafana Setup Tutorial" (47 days ago): port-9090 collision warning, Grafana admin/admin default-credential warning.

Frequently asked questions about using Prometheus

What is Prometheus used for?

Prometheus is used for monitoring servers and applications by scraping numeric metrics over HTTP, storing them as time series, and alerting on them. The typical beginner stack is Prometheus for collection and alerting, Grafana for dashboards, and exporters like the Node Exporter for host metrics — the combination this guide sets up.

How do I check if Prometheus is scraping my target?

Open http://localhost:9090/targets and look for your target marked UP, or query up{job="your_job_name"} in the expression browser — a value of 1 means the last scrape succeeded and 0 means it failed. This up check is the first diagnostic every Prometheus guide teaches.

What is PromQL in simple terms?

PromQL is Prometheus's query language for time-series data: you name a metric, filter it with label selectors like {job="node_exporter"}, and transform it with functions like rate() or avg(). If you can write rate(node_cpu_seconds_total[5m]), you already know the pattern behind most production queries.

Does Prometheus need Grafana?

No — Prometheus ships with its own expression browser and graphing tab that are enough for learning and debugging. Grafana becomes worth adding when you want permanent, shareable dashboards; the Grafana beginner guide covers connecting it to the Prometheus server you built here.

Prometheus vs Zabbix — which is easier for a beginner?

Zabbix is easier on day one because it ships dashboards, agents, and alerting in one package. Prometheus is easier to grow with: the pull model, PromQL, and the exporter ecosystem are the modern standard for Docker and Kubernetes monitoring, and this guide's Docker install takes about five minutes.

Featured on Twelve Tools Launch Llama Tools Launch your MCP