25bda7ceb5
Unfortunately, these values aren't available from getrusage(2), or any other builtin Go API. Go itself doesn't provide a mechanism (like on Windows) to call into system libraries. Using a 3rd party package[1] to dynamically call system libraries was proposed and rejected, to avoid adding to the number of dependencies. That leaves using cgo, which is used here when available. When not available (either because of cross compiling or explicitly disabling it), a stub function is linked instead, and the metrics are not exported. That way, cross compiling of other platforms is unaffected (and can also still be done with Darwin too, but at the cost of not exporting these metrics). Note that building an amd64 image on an arm64 mac or vice-versa is cross compiling, and will use the stub method by default. This can be avoided by setting `CGO_ENABLED=1` in the environment to force the use of cgo for both architectures. I'm unsure of the usefulness of the potential adjustment made to the virtual memory value after calling `mach_vm_region()`. I've not seen that code get run with a native amd64 or arm64 image, or with an amd64 image running under Rosetta. But that's what the `ps(1)` command does, and I think we should report what the system tools do. When I was testing this on a beta of macOS 15 with Go 1.21.13 (the current minimum support for this module), the amd64 image ran fine under Rosetta, but the arm64 image immediately printed a message that it was killed, even prior to the cgo call. This seems to be a recurring issue on macOS[2][3], and passing `-ldflags -s` to `go build` avoided the issue. Go 1.23.1 worked out of the box, without fiddling with linker flags, so I don't think this is an issue- Go 1.21 is simply too old to support macOS 15, but I thought it was worth noting. I supposed we could gate the cgo code with an additional build flag, if anyone is concerned about this. [1] https://github.com/ebitengine/purego [2] https://github.com/golang/go/issues/19841#issuecomment-293334802 [3] https://github.com/golang/go/issues/11887#issuecomment-125694604 Signed-off-by: Matt Harbison <mharbison72@gmail.com> |
||
|---|---|---|
| .bingo | ||
| .github | ||
| api | ||
| dagger | ||
| examples | ||
| internal/github.com/golang/gddo | ||
| prometheus | ||
| tutorials/whatsup | ||
| .gitignore | ||
| .golangci.yml | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| Makefile | ||
| Makefile.common | ||
| NOTICE | ||
| README.md | ||
| SECURITY.md | ||
| VERSION | ||
| dagger.json | ||
| generate-go-collector.bash | ||
| go.mod | ||
| go.sum | ||
| supported_go_versions.txt | ||
| update-go-version.bash | ||
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.21 or later.
The library mandates the use of Go1.21 or subsequent versions. While it has demonstrated functionality with versions as old as Go 1.17, our commitment remains to offer support and rectifications for only the most recent three major releases.
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, but plans for further development of v2 at the moment.
NOTE: The initial v2 attempt is in a separate branch. We also started experimenting on a new
prometheus.V2.*APIs in the 1.x's V2 struct. Help wanted!
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.
client_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 themaincommit 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
VERSIONfile. - 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>title. - Announce on the prometheus-announce mailing list, slack and Twitter.
- Merge the release branch back to the
mainusing the "merge without squashing" approach (!).
NOTE: In case of merge conflicts, you can checkout the release branch in a new branch, e.g.
<yourname>/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 intomain, 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
mainbranch (or add new commits) to fix critical bugs for that patch release. - Follow steps 3-8 as above.