Prometheus Review

Prometheus stores metrics as time series, values recorded with timestamps and optional key-value labels. The docs list a multi-dimensional data model, PromQL for querying, pull-based collection over HTTP plus a gateway for pushed metrics, target discovery through service discovery or static configuration, and multiple graphing and dashboarding options. Components include the Prometheus server, client libraries for instrumenting code, the Pushgateway for short-lived jobs, exporters for services such as HAProxy, StatsD, and Graphite, Alertmanager for deduplication, grouping, silencing, and routing, and support tools. Service discovery covers Kubernetes, Consul, EC2, and others, and Grafana or other API consumers typically visualize the data. The storage docs describe two-hour blocks (each with chunks, an index, meta.json, and tombstones), a write-ahead log in 128 MB segments, compaction into larger blocks of up to 10% of the retention time or 31 days, WAL compression (default since 2.20.0), and a built-in remote write receiver (--web.enable-remote-write-receiver at /api/v1/write) with remote read that returns raw series only.

A Prometheus server is a single binary or container: download and extract the release, write a minimal prometheus.yml with a scrape_interval (the guide uses 15s) and a job that scrapes localhost:9090, and run ./prometheus --config.file=prometheus.yml, with the database in ./data by default and the expression browser at localhost:9090. Reload configuration without a restart with SIGHUP. Retention defaults to 15 days if neither flag is set (--storage.tsdb.retention.time and --storage.tsdb.retention.size, whichever triggers first), expired blocks can take up to two hours to clean up, and the docs estimate an average of only 1 to 2 bytes per sample, giving needed disk space as retention seconds times ingested samples per second times bytes per sample, with advice to keep the retention size at 80 to 85 percent of allocated disk. The docs stress that local storage is not clustered or replicated, so it is a single-node database, that NFS filesystems including AWS EFS are not supported, and that backups should use snapshots (otherwise you can lose data since the last block, about every two hours). The Prometheus 3.0 migration guide lists breaking changes: regex dot now matches newlines, range selectors are left-open so subqueries such as foo[1m:1m] may return one point, scrapes fail on a missing or unrecognized Content-Type unless you set fallback_scrape_protocol, le and quantile label values normalize to float form (le=1 becomes le=1.0), UTF-8 metric and label names may change validation, the Alertmanager v1 API is unsupported, logging moved to slog, and v3 TSDB data can only be read back by v2.55 or newer, so consider upgrading to v2.55 first. The current version shown is v3.15.0.

You instrument services or run exporters, tell Prometheus where to scrape, write PromQL queries and alert rules, and view results through Grafana or the built-in expression browser. Recording rules precompute expensive queries, as in the getting-started example that records an average CPU rate. PromQL has a learning curve but is very expressive for aggregations across labels. This section reflects the documentation and OpenAlternative; we did not run Prometheus.

• Multi-dimensional time-series data model with labels
• PromQL for querying and aggregating metrics, plus recording rules
• Pull-based scraping, with a gateway for short-lived jobs
• Alertmanager for deduplication, grouping, silencing, and routing
• Service discovery for Kubernetes, Consul, EC2, and static targets
• Local on-disk storage with WAL compression and optional remote write and read

• The de facto standard for cloud-native metrics, with about 66,500 stars and a huge exporter ecosystem
• Reliable by design: each server is standalone and needs no remote services
• Very efficient storage, at roughly 1 to 2 bytes per sample
• Apache-2.0 license and CNCF governance, with an excellent migration guide for major versions

• Not suited to uses that need 100% accuracy, such as per-request billing, because its data is not detailed or complete enough
• Metrics only: logs, traces, and dashboards need other tools such as Loki, Tempo, and Grafana
• Local storage is single-node and not clustered or replicated, NFS and EFS are unsupported, and long-term or multi-cluster setups need remote storage components
• Upgrading to v3 has real breaking changes (regex, range selectors, label formatting, scrape Content-Type, logging), and downgrading is limited to v2.55
• PromQL and alert design take time to learn, and there is no built-in UI beyond a basic expression browser

Prometheus is free and open source under Apache-2.0. Your costs are the infrastructure and the people who run it, and disk needs are modest at 1 to 2 bytes per sample. The OpenAlternative page carries an affiliate VPS offer, which is not Prometheus pricing.

Datadog, New Relic, Splunk, and SolarWinds are commercial observability suites that bundle agents, storage, dashboards, and APM. Prometheus is the metrics core of an open stack: you pair it with Grafana for dashboards and other open tools for logs and traces. It is far cheaper at scale and avoids lock-in, but you assemble and operate the pieces. Netdata is an easier all-in-one option for single hosts.

• Teams running Kubernetes or microservices that need metrics and alerting
• Organizations that want an open, vendor-neutral monitoring base
• Engineers who want to write precise queries over labeled data

• Use cases that require exact, complete records such as billing
• Teams that want logs, traces, and metrics in one product without assembly
• Small teams without the capacity to operate monitoring infrastructure