Prometheus — Dependencies#

Module info#

• Module: github.com/prometheus/prometheus
• Go version: 1.25.0
• Direct dependencies: 103 (first require block in go.mod, no // indirect marker)
• Indirect dependencies (explicitly listed): ~148 (second and third require blocks)
• go.sum entries: 837 lines (~418 unique module/version pairs, capturing the full transitive graph)

Dependency categories#

Core infrastructure#

Networking / HTTP / RPC#

Data / Serialization / Storage#

OpenTelemetry (OTLP bridge)#

Cloud provider SDKs (service discovery)#

These are the most striking part of Prometheus’s dependency graph: every major cloud is a first-class direct dependency because each service discovery provider gets its own SDK.

HashiCorp ecosystem#

Observability (self-instrumentation)#

Other infrastructure / Kubernetes#

Testing#

OpenAPI validation (unusual choice)#

pb33f/libopenapi and pb33f/libopenapi-validator are used to validate that the live Prometheus API responses conform to the bundled OpenAPI spec. This is a sophisticated approach to API contract testing and brings in a significant transitive dependency tree of its own (go-openapi/*, JSON Schema, etc.).

Stdlib reliance#

Prometheus’s core packages are stdlib-heavy. Key stdlib usage observed in cmd/prometheus/main.go and tsdb/head.go:

• context — pervasive cancellation and deadline propagation
• net/http — HTTP server for the web UI, API, and /metrics endpoint
• sync (Mutex, RWMutex, WaitGroup, Once) — extensive use in TSDB and scrape manager
• encoding/json — used at API layer
• log/slog — the project migrated to log/slog (Go 1.21+) for structured logging, though prometheus/common/promslog wraps it
• math, math/bits — TSDB integer arithmetic and chunk encoding
• regexp — still directly imported in some places where grafana/regexp isn’t applicable
• os, runtime, syscall — OS integration for signal handling, resource limits, mmap

The TSDB and PromQL engine layers are particularly stdlib-dependent: the parser, AST, and query evaluation loop use only Go builtins and internal packages, keeping that critical path dependency-free.

Shared dependencies#

Dependencies shared with other projects in the research set that create natural comparison points:

Vendoring#

No vendor/ directory present. Prometheus relies entirely on the Go module proxy and go.sum for dependency integrity. This is the standard modern approach for a project of this scale, though it means reproducible builds depend on module proxy availability (or a local GOMODCACHE).

The go.mod contains two exclude directives:

• github.com/linode/linodego v1.0.0 — excluded because that version was removed from GitHub
• github.com/grpc-ecosystem/grpc-gateway v1.14.7 and google.golang.org/api v0.30.0 — excluded due to breaking changes (issue #7621)

And two replace directives:

• Pins cloud.google.com/go to v0.123.0
• Pins github.com/go-openapi/testify/v2 to v2.0.2 to preserve YAML assertion support

Notable dependency decisions#

1. Every cloud = a direct dep. Rather than abstracting cloud SDKs behind an internal HTTP layer, each service discovery provider imports its vendor SDK directly. This maximises fidelity (auth, pagination, regional endpoints) but means adding a new SD provider requires evaluating a new SDK’s entire transitive dependency tree. The build-tag plugin architecture partially mitigates this by allowing users to build a binary with only the SD providers they need.

2. grafana/regexp over stdlib regexp. Prometheus replaced regexp with a Grafana-maintained fork that offers significantly better performance for the workloads PromQL generates (many label-matching regexes against large label sets). The //nolint:depguard comment at the import site documents exactly where the stdlib package is still required — a clean engineering decision that leaves a breadcrumb for future maintainers.

3. Dual protobuf stacks (gogo + google). The presence of both github.com/gogo/protobuf and google.golang.org/protobuf reflects a long-running migration. Remote Write v1 was designed around gogo for performance (zero-copy, arena allocation); Remote Write v2 uses the canonical library. Prometheus deliberately maintains both to avoid breaking the installed base of receivers.

4. OpenTelemetry as a first-class integration layer. The OTel dependency is not just for self-instrumentation; Prometheus implements full OTel Collector component interfaces (component, consumer, processor) so it can act as a node in an OTel pipeline. This is a strategic architectural choice that positions Prometheus as a citizen of the OTel ecosystem rather than a competing silo.

5. Minimal abstraction over stdlib HTTP. Prometheus does not use any third-party HTTP router framework (no Gin, Echo, Chi, Gorilla Mux). Routes are registered directly on http.ServeMux or via julienschmidt/httprouter (which comes in transitively). This keeps the web layer thin and dependency-light.

6. go.yaml.in instead of gopkg.in/yaml. The project has migrated to the go.yaml.in fork (v2, v3, v4 all present simultaneously), which is the CNCF-governed continuation of the widely-used gopkg.in/yaml.v3. Having all three versions at once is a transient compatibility state, but shows forward motion toward the new fork.