* Add OpenAPI 3.2 specification generation for Prometheus HTTP API This commit introduces an OpenAPI specification for the Prometheus API. After testing multiple code-generation servers with built-in APIs, this implementation uses an independent spec file outside of the critical path. This spec file is tested with a framework present in this pull request. The specification helps clients know which parameters they can use and is served at /api/v1/openapi.yaml. The spec file will evolve with the Prometheus API and has the same version number. Downstream projects can tune the APIs presented in the spec file with configuration options using the IncludePaths setting for path filtering. In the future, there is room to generate a server from this spec file (e.g. with interfaces), but this is out of scope for this pull request. Architecture: - Core OpenAPI infrastructure (openapi.go): Dynamic spec building, caching, and thread-safe spec generation - Schema definitions (openapi_schemas.go): Complete type definitions for all API request and response types - Path specifications (openapi_paths.go): Endpoint definitions with parameters, request bodies, and response schemas - Examples (openapi_examples.go): Realistic request/response examples - Helper functions (openapi_helpers.go): Reusable builders for common OpenAPI structures Testing: - Comprehensive test suite with golden file validation - Test helpers package for API testing infrastructure - OpenAPI compliance validation utilities The golden file captures the complete specification for snapshot testing. Update with: go test -run TestOpenAPIGolden -update-openapi-spec REVIEWERS: The most important thing to check would be the OpenAPI golden file (web/api/v1/testdata/openapi_golden.yaml). Test scenarios are important as they test the actual OpenAPI spec validity. Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com> * Add OpenAPI 3.1 support with version selection Add support for both OpenAPI 3.1 and 3.2 specifications with version selection via openapi_version query parameter. Defaults to 3.1 for broader compatibility Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com> * Enhance OpenAPI examples and add helper functions - Add timestampExamples helper for consistent time formatting - Add exampleMap helper to simplify example creation - Improve example summaries with query details - Add matrix result example for range vector queries Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com> * web/api: Add AtST method to test helper iterators Implement the AtST() method required by chunkenc.Iterator interface for FakeSeriesIterator and FakeHistogramSeriesIterator test helpers. The method returns 0 as these test helpers don't use start timestamps Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com> * OpenAPI: Add minimum coverage test Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com> * OpenAPI: Improve examples handling Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com> --------- Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com> |
||
|---|---|---|
| .github | ||
| cmd | ||
| config | ||
| discovery | ||
| docs | ||
| documentation | ||
| internal/tools | ||
| model | ||
| notifier | ||
| plugins | ||
| prompb | ||
| promql | ||
| rules | ||
| schema | ||
| scrape | ||
| scripts | ||
| storage | ||
| template | ||
| tracing | ||
| tsdb | ||
| util | ||
| web | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .gitpod.Dockerfile | ||
| .gitpod.yml | ||
| .golangci.yml | ||
| .promu.yml | ||
| .yamllint | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| Dockerfile.distroless | ||
| go.mod | ||
| go.sum | ||
| go.work | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| Makefile | ||
| Makefile.common | ||
| NOTICE | ||
| README.md | ||
| RELEASE.md | ||
| renovate.json | ||
| SECURITY-INSIGHTS.yml | ||
| SECURITY.md | ||
| ui-commits | ||
| VERSION | ||

Prometheus
Visit prometheus.io for the full documentation, examples and guides.
Prometheus, a Cloud Native Computing Foundation project, is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts when specified conditions are observed.
The features that distinguish Prometheus from other metrics and monitoring systems are:
- A multi-dimensional data model (time series defined by metric name and set of key/value dimensions)
- PromQL, a powerful and flexible query language to leverage this dimensionality
- No dependency on distributed storage; single server nodes are autonomous
- An HTTP pull model for time series collection
- Pushing time series is supported via an intermediary gateway for batch jobs
- Targets are discovered via service discovery or static configuration
- Multiple modes of graphing and dashboarding support
- Support for hierarchical and horizontal federation
Architecture overview
Install
There are various ways of installing Prometheus.
Precompiled binaries
Precompiled binaries for released versions are available in the download section on prometheus.io. Using the latest production release binary is the recommended way of installing Prometheus. See the Installing chapter in the documentation for all the details.
Docker images
Docker images are available on Quay.io or Docker Hub.
You can launch a Prometheus container for trying it out with
docker run --name prometheus -d -p 127.0.0.1:9090:9090 prom/prometheus
Prometheus will now be reachable at http://localhost:9090/.
Building from source
To build Prometheus from source code, You need:
- Go: Version specified in go.mod or greater.
- NodeJS: Version specified in .nvmrc or greater.
- npm: Version 10 or greater (check with
npm --versionand here).
Start by cloning the repository:
git clone https://github.com/prometheus/prometheus.git
cd prometheus
You can use the go tool to build and install the prometheus
and promtool binaries into your GOPATH:
go install github.com/prometheus/prometheus/cmd/...
prometheus --config.file=your_config.yml
However, when using go install to build Prometheus, Prometheus will expect to be able to
read its web assets from local filesystem directories under web/ui/static. In order for
these assets to be found, you will have to run Prometheus from the root of the cloned
repository. Note also that this directory does not include the React UI unless it has been
built explicitly using make assets or make build.
An example of the above configuration file can be found here.
You can also build using make build, which will compile in the web assets so that
Prometheus can be run from anywhere:
make build
./prometheus --config.file=your_config.yml
The Makefile provides several targets:
- build: build the
prometheusandpromtoolbinaries (includes building and compiling in web assets) - test: run the tests
- test-short: run the short tests
- format: format the source code
- vet: check the source code for common errors
- assets: build the React UI
Service discovery plugins
Prometheus is bundled with many service discovery plugins. You can customize which service discoveries are included in your build using Go build tags.
To exclude service discoveries when building with make build, add the desired
tags to the .promu.yml file under build.tags.all:
build:
tags:
all:
- netgo
- builtinassets
- remove_all_sd # Exclude all optional SDs
- enable_kubernetes_sd # Re-enable only kubernetes
Then run make build as usual. Alternatively, when using go build directly:
go build -tags "remove_all_sd,enable_kubernetes_sd" ./cmd/prometheus
Available build tags:
remove_all_sd- Exclude all optional service discoveries (keeps file_sd, static_sd, and http_sd)enable_<name>_sd- Re-enable a specific SD when usingremove_all_sd
If you add out-of-tree plugins, which we do not endorse at the moment,
additional steps might be needed to adjust the go.mod and go.sum files. As
always, be extra careful when loading third party code.
Building the Docker image
You can build a docker image locally with the following commands:
make promu
promu crossbuild -p linux/amd64
make npm_licenses
make common-docker-amd64
The make docker target is intended only for use in our CI system and will not
produce a fully working image when run locally.
Using Prometheus as a Go Library
Remote Write
We are publishing our Remote Write protobuf independently at buf.build.
You can use that as a library:
go get buf.build/gen/go/prometheus/prometheus/protocolbuffers/go@latest
This is experimental.
Prometheus code base
In order to comply with go mod rules, Prometheus release number do not exactly match Go module releases.
For the Prometheus v3.y.z releases, we are publishing equivalent v0.3y.z tags. The y in v0.3y.z is always padded to two digits, with a leading zero if needed.
Therefore, a user that would want to use Prometheus v3.0.0 as a library could do:
go get github.com/prometheus/prometheus@v0.300.0
For the Prometheus v2.y.z releases, we published the equivalent v0.y.z tags.
Therefore, a user that would want to use Prometheus v2.35.0 as a library could do:
go get github.com/prometheus/prometheus@v0.35.0
This solution makes it clear that we might break our internal Go APIs between minor user-facing releases, as breaking changes are allowed in major version zero.
React UI Development
For more information on building, running, and developing on the React-based UI, see the React app's README.md.
More information
- Godoc documentation is available via pkg.go.dev. Due to peculiarities of Go Modules, v3.y.z will be displayed as v0.3y.z (the y in v0.3y.z is always padded to two digits, with a leading zero if needed), while v2.y.z will be displayed as v0.y.z.
- See the Community page for how to reach the Prometheus developers and users on various communication channels.
Contributing
Refer to CONTRIBUTING.md
License
Apache License 2.0, see LICENSE.