Prometheus
prometheus.io- Category
- Developer Tools
- Rank
- No. 278Tools index
- Pricing
- Open Source
- Type
- TOOL
- Builder
- prometheus
- GitHub
- 66.1k stars
- Latest release
- v3.15.0-rc.0
- Date
About
Open-source metrics database. The de facto open-source metrics system. Pull-based scraping, multi-dimensional data model, PromQL query language. Pair with Grafana for dashboards.
What it does
Prometheus is a monitoring server that pulls metrics over HTTP from targets it finds through service discovery or static lists, then stores each sample in a local time series database on the same node. Every series is identified by a metric name plus key and value labels, and PromQL queries that dimensional data for graphs, dashboards and rules. Recording rules precompute expensive aggregations into new series; alerting rules evaluate conditions and hand firing alerts to Alertmanager. Ingested samples are grouped into two hour blocks, guarded by a write ahead log that replays on restart, and optionally copied to remote endpoints.
Why it's ranked here
The strongest argument here is the written stability contract. The project names exactly what is frozen for the current major line: the query language, data model, rule files, configuration format, agent mode and the v1 HTTP API, and it names what is not: remote read, server side HTTPS and basic authentication, the exact on disk format and the log format. Few monitoring tools tell you where the ground moves. Against that, the maintainers state plainly that this repository builds a program and was never designed to be used as a library, so treat it as a binary you operate.
What's good
Operational detail is documented with numbers rather than hand waving: roughly one to two bytes per sample for capacity planning, a recommended retention size of at most 80 to 85 percent of allocated disk to leave room for compaction, chunk segment files up to 512 MB, write ahead log segments of 128 MB, and at least three log files retained. Agent mode reuses the same scraping and discovery code but drops querying, rules and local blocks for a trimmed log. Build tags let you compile out the service discovery integrations you do not use.
Tradeoffs
Local storage is neither clustered nor replicated, so a drive or node loss is data loss; the documentation says to manage it like any other single node database and to back it up from snapshots. Non POSIX filesystems, NFS and Amazon EFS included, are unsupported. Remote read pulls raw series into the querying server before evaluation, so it does not distribute query work. Agent mode gives up local queries, recording rules and alerting entirely. The experimental surface is wide: many capabilities sit behind opt in flags whose behaviour the documentation warns can change.
How to use it well
Reach for this when you run your own infrastructure and want dimensional metrics with a real query language. It fits a stack where one server per environment scrapes exporters and applications, keeps fifteen days by default, and forwards a copy onward to central storage. Agent mode suits edge clusters that only need to ship data out. It does not route or deduplicate alerts, that is Alertmanager, and it does not draw dashboards, hold logs or traces, or provide clustered long term storage; each of those needs a separate system.
Technical notes+
The entry point cmd/prometheus/main.go defines the kingpin flag set, tags flags as server-only or agent-only, and translates every --enable-feature value into concrete options across the scrape, tsdb, agent and web option structs before wiring the components together and running them as coordinated actors. config/config.go does strict YAML unmarshalling into one Config tree with per-section defaults (a one minute scrape interval, ten second scrape timeout, remote write queues capped at 50 shards and 2000 samples per send), rejects alerting, rule_files and remote_read when agent mode is active, and rebases relative paths onto the config file directory. documentation/internal_architecture.md walks the discovery manager, per-job scrape pools and the fanout storage that merges local and remote reads, but the code links in it are pinned to a 2.3.1 walkthrough and no longer line up. docs/feature_flags.md is the honest catalogue of what is still moving, docs/storage.md carries the on-disk layout and capacity formula, and go.mod shows why the binary is large: AWS, Azure, GCP, Kubernetes, Consul, OpenStack, Docker and OpenTelemetry client libraries are all direct dependencies, which is what the build tags documented in README.md exist to trim.
Observed
- License
- Apache License 2.0
- Language
- Go, single module, plus a React web UI built with Node and npm
- Binaries
- prometheus server and promtool command line tool
- Operating modes
- Server and agent from the same binary, selected by flag
- Interfaces
- HTTP pull scraping, HTTP query API, remote write and remote read over snappy-compressed protobuf, OTLP receiver
- Storage
- Local on-disk time series database, two hour blocks, write ahead log, no clustering or replication
- Install surface
- Precompiled binaries, container images on Quay and Docker Hub, or build from source with Go and Node
- Build customization
- Go build tags exclude optional service discovery integrations; file, static and HTTP discovery always remain
- Governance
- Cloud Native Computing Foundation project with a published API stability policy
Read from README.md, go.mod, cmd/prometheus/main.go, config/config.go, documentation/internal_architecture.md, docs/getting_started.md, docs/storage.md, docs/stability.md, docs/prometheus_agent.md, docs/feature_flags.md.
Tags
Tech Stack
Media
Comments (0)
No comments yet
Editorially curated, with community endorsements as a secondary signal. Corrections welcome.