docs: unify getting started content into first steps (#3066)

[santhiprakash]

Fixes #3066

Problem

tutorials/getting_started and introduction/first_steps heavily overlap: both walk through downloading/configuring/running Prometheus. Per @jan--f's correction on #3069, the direction is now to unify the content in introduction/first_steps and remove tutorials/getting_started.

Triage / what changed

• Folded the tutorial's unique hands-on piece (download → run node exporter → add a second scrape_configs job → query a host metric) into first_steps' existing "Monitoring other targets" section, keeping the deeper node exporter guide link.
• Added an early pointer to the Overview for readers who want concepts/architecture before hands-on (the conceptual sections of the tutorial — "what is Prometheus", metrics basics, architecture — were already covered there and in the glossary).
• Removed docs/tutorials/getting_started.md and its three images, which nothing else referenced (architecture.png, sample_graph.png, node_exporter.png under public/assets/docs/tutorial/).
• Added /docs/tutorials/getting_started/ → /docs/introduction/first_steps/ to public/_redirects, matching the file's existing format.
• Updated the Summary to reflect the node exporter step.

Verification

• make check (mdox fmt --check) passes.
• Every link in the rewritten section verified against the tree or existing generated routes: /download#node_exporter matches the existing pattern in docs/guides/node-exporter.md:16; overview, node-exporter, and exporters pages exist.
• grep confirms no remaining references to tutorials/getting_started or the removed images anywhere in the repo.

Notes

• The two YouTube embeds in the old tutorial were not carried over (they duplicate the on-page steps); happy to re-add either one to first_steps if you'd like to keep them.
• @jan--f you also mentioned unifying https://prometheus.io/docs/prometheus/latest/getting_started/ into first steps — that page is sourced from prometheus/prometheus's docs directory, so it needs a cross-repo PR plus _redirects updates (lines 2 and 46 point at it today). Should I proceed with that after this one, or handle it separately?

[lasomethingsomething]

I wonder if we could rename the "First Steps" page to "Binary Setup" to clarify which path it describes and help us differentiate it from other similarly titled pages? ie as a newcomer I used the Docker image.

[santhiprakash]

@lasomethingsomething Good question — before renaming I checked what the page actually covers and what the other similarly-titled pages are, and there's a wrinkle worth surfacing.

What's on this page: it's entirely the precompiled-binary path (tar xvfz → ./prometheus → local prometheus.yml → binary node_exporter) — no Docker anywhere. The other "getting started" candidate is /docs/prometheus/latest/getting_started/ (imported from prometheus/prometheus, where the homepage "Get Started" button points today) — and that page is also a binary walkthrough. The Docker first-run path (docker run -p 9090:9090, volumes) currently only exists on /docs/prometheus/latest/installation/. So today there are two differently-named binary intros and no Docker quickstart page at all — the ambiguity you're flagging is real, and slightly worse than two competing paths.

The wrinkle: jan--f's open #3110 already renames this exact file — nav title "Prometheus quickstart" at /docs/get-started/quickstart/, repoints the homepage button there, and hides the imported getting_started from the nav so there's a single introductory entry. It resolves the same ambiguity in the other direction (one canonical quickstart rather than a binary-labeled page). Its one gap for your point: the frontmatter title: would still read "First steps with Prometheus", so the on-page H1 still wouldn't signal the path.

Given that, I've held off pushing "Binary setup" on this PR for two reasons:

1. A file/slug move would collide with Restructure documentation navigation #3110's new route table (docs-routes.ts keys introduction/first_steps.md by path) and add redirect churn that Restructure documentation navigation #3110 would supersede anyway.
2. Whether "Binary setup" is the right permanent name seems to hinge on the recommended-path call in your Epics 1–2: if Docker becomes the canonical newcomer path, this page is exactly the binary parallel and "Binary setup" (or "Install from binary") is the right name at that point; if binary stays canonical, quickstart naming probably wins.

Happy to do either: (a) push a title-only retitle in this PR now — title:/nav_title: frontmatter only, no slug move, no _redirects churn, no conflict with #3110 — if you'd rather not wait on the epic ordering, just say the name you want; or (b) fold the naming into the epic's step-1 change once #3110 lands and the recommended path is declared.

[lasomethingsomething]

@santhiprakash @jan--f I'm not sure the binary setup is the "quick" way, though? do you have any metrics/data around this from users (maybe it takes time upfront to save time later)? For me Docker was pretty quick. I'll try to get the binary setup to work and share my own impressions here w.r.t. "quick"...

[santhiprakash]

@lasomethingsomething Fair challenge. Honest answer on the metrics: none exist, as far as I can tell. OSS Prometheus ships no telemetry, and I couldn't find any published install-time data. The only public numbers are volume proxies, and they don't answer your question:

• Docker Hub prom/prometheus: ~2.03B pulls
• GitHub prometheus-3.15.0.linux-amd64.tar.gz: ~179K downloads on the latest release (darwin-amd64: ~2.1K)

Both are dominated by CI/production traffic, so they show Docker is the dominant distribution channel — they say nothing about which path is quicker for a first-timer on a laptop.

What I could measure myself (single datapoint, cloud VM, fast link — not a newcomer laptop): docker pull prom/prometheus (~114MB compressed) ≈5s; downloading + untarring the ~106-111MB release tarball ≈1-5s warm, though one cold GitHub-CDN fetch took ~2min; both reached a ready server ~3s after the artifact existed. So once the prerequisite is in place, artifact→running is roughly a wash on both paths. Which suggests the "quick" question really lives one step earlier — what's already installed. docker run is one command if Docker's there; if it isn't, a Docker Desktop install outweighs tar xvfz && ./prometheus, and on macOS the binary path additionally pays the Gatekeeper step (already on your #3137 list).

So I read your point the same way you framed it: whether binary deserves the "quickstart" slot is exactly the open "declare the recommended newcomer path" call in #3137, and the answer probably depends on the newcomer's starting state — which argues for the epic's two-clearly-labeled-paths direction rather than a single "quick" claim. (Also: this page reads long partly because it keeps going past install into prometheus.yml + node_exporter — the install leg itself is short.)

Running the binary path yourself and reporting impressions is the best data available right now — curious what you hit, especially the Gatekeeper step.

[lasomethingsomething]

Thanks, I think it's best for this PR to be merged, then I'll set to work in a different issue/PR.

[santhiprakash]

@lasomethingsomething Sounds good — agreed. I'll leave this PR as-is (no rename), so nothing further is coming from my side here. Feel free to ping me on the follow-up issue if the binary-vs-Docker timing data would be useful there.