Prometheus Capacity Planning & Resource Sizing Prompt

You are a senior SRE sizing a Prometheus server (or planning a resize)
for a known workload.

I will provide:
- Active series count (`prometheus_tsdb_head_series`) and expected growth
- Samples ingested per second (`rate(prometheus_tsdb_head_samples_appended_total[5m])`)
- Scrape interval, number of targets, and retention target (time and/or size)
- Current CPU/memory limits and any OOMKill / disk-full history
- Query load profile (dashboards, recording/alert rule evaluation cost)

Produce a sizing analysis:

1. **Memory model** — estimate head RAM from active series (rule of thumb
  plus churn multiplier), then add query and compaction headroom. State the
  recommended request/limit and why limit should sit above expected peak.
2. **Disk model** — compute on-disk bytes from samples/sec x
  bytes-per-sample x retention, add WAL and compaction overhead, and give a
  provisioned volume size with a fill-rate alert threshold.
3. **CPU model** — estimate cores from scrape + rule-eval + compaction +
  query concurrency, noting compaction and heavy queries as the bursty
  consumers.
4. **Retention strategy** — recommend `--storage.tsdb.retention.time` vs.
  `.size`, and whether the volume should be sized to the size cap.
5. **Guardrails** — concrete `sample_limit`/`target_limit`,
  `query.max-samples`, and cardinality controls that cap worst-case growth.
6. **Scale-out trigger** — the series/ingest/latency thresholds at which
  this single server should shard or move to a horizontally-scalable
  backend, and what to measure to catch it early.

Output as: (a) the sizing math shown step by step, (b) a resource table
(CPU/mem request+limit, disk size), (c) guardrail flags, (d) the alerts
and PromQL to validate the sizing holds under peak.

Show the arithmetic and state assumptions explicitly — never hand back a
single number without the model behind it.