fae2f6306b
* Introduce MetricVecOpts and add constraints to VariableLabels MetricVecOpts exposes options specific to MetricVec initialisation. The first option exposed by MetricVecOpts are constraints on VariableLabels, allowing restrictions on the possible values a label can take, to prevent cardinality explosion when the label value comes from a non-trusted source (as a user input or HTTP header). Signed-off-by: Quentin Devos <4972091+Okhoshi@users.noreply.github.com> * Add tests Signed-off-by: Quentin Devos <4972091+Okhoshi@users.noreply.github.com> Signed-off-by: Quentin Devos <4972091+Okhoshi@users.noreply.github.com> |
||
---|---|---|
.circleci | ||
.github | ||
api | ||
examples | ||
prometheus | ||
scripts | ||
.gitignore | ||
.go-version | ||
.golangci.yml | ||
CHANGELOG.md | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
Dockerfile | ||
LICENSE | ||
MAINTAINERS.md | ||
Makefile | ||
Makefile.common | ||
NOTICE | ||
README.md | ||
SECURITY.md | ||
VERSION | ||
go.mod | ||
go.sum |
README.md
Prometheus Go client library
This is the Go client library for Prometheus. It has two separate parts, one for instrumenting application code, and one for creating clients that talk to the Prometheus HTTP API.
This library requires Go1.17 or later.
Important note about releases and stability
This repository generally follows Semantic Versioning. However, the API client in prometheus/client_golang/api/… is still considered experimental. Breaking changes of the API client will not trigger a new major release. The same is true for selected other new features explicitly marked as EXPERIMENTAL in CHANGELOG.md.
Features that require breaking changes in the stable parts of the repository are being batched up and tracked in the v2 milestone. The v2 development happens in a separate branch for the time being. v2 releases off that branch will happen once sufficient stability is reached. In view of the widespread use of this repository, v1 and v2 will coexist for a while to enable a convenient transition.
Instrumenting applications
The
prometheus
directory
contains the instrumentation library. See the
guide on the Prometheus
website to learn more about instrumenting applications.
The
examples
directory
contains simple examples of instrumented code.
Client for the Prometheus HTTP API
The
api/prometheus
directory
contains the client for the
Prometheus HTTP API. It allows you
to write Go applications that query time series data from a Prometheus
server. It is still in alpha stage.
Where is model
, extraction
, and text
?
The model
packages has been moved to
prometheus/common/model
.
The extraction
and text
packages are now contained in
prometheus/common/expfmt
.
Contributing and community
See the contributing guidelines and the Community section of the homepage.
clint_golang
community is also present on the CNCF Slack #prometheus-client_golang
.
For Maintainers: Release Process
To cut a minor version:
- Create a new branch
release-<major>.<minor>
on top of themain
commit you want to cut the version from and push it. - Create a new branch on top of the release branch, e.g.
<yourname>/cut-<major>.<minor>.<patch>
, - Change the
VERSION
file. - Update
CHANGELOG
(only user-impacting changes to mention). - Create PR, and get it reviewed.
- Once merged, create a release with the
release-<major>.<minor>
tag on GitHub with the<version> / <date>
title. - Announce on the prometheus-announce mailing list, slack and Twitter.
- Merge the release branch back to the
main
using the "merge without squashing" approach (!).
NOTE: In case of merge conflicts, you can checkout the release branch in a new branch, e.g. /resolve-conflicts
, fix the merge problems there, and then do a PR into main from the new branch. In that way, you still get all the commits in the release branch back into
main`, but leave the release branch alone.
To cut the patch version:
- Create a branch on top of the release branch you want to use.
- Cherry-pick the fixes from the
main
branch (or add new commits) to fix critical bugs for that patch release. - Follow steps 3-8 as above.