* add: exponential backoff for CAS operations of floats
Signed-off-by: Ivan Goncharov <i.morph@gmail.com>
* add: some more benchmark use cases (higher contention)
Signed-off-by: Ivan Goncharov <i.morph@gmail.com>
* fmt: fumpted some files
Signed-off-by: Ivan Goncharov <i.morph@gmail.com>
* add: license header
Signed-off-by: Ivan Goncharov <i.morph@gmail.com>
* add: comment explaining origin of backoff constants
Signed-off-by: Ivan Goncharov <i.morph@gmail.com>
---------
Signed-off-by: Ivan Goncharov <i.morph@gmail.com>
The header has a warning when included, with no way to shut it off, and no
alternative to obtain these symbols. They're technically architecture specific
values, but they aren't different between amd64 and arm64, so combine the
definitions.
Signed-off-by: Matt Harbison <mharbison72@gmail.com>
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>
* Enable autogeneration for default runtime metrics list in collectors tests according to Go version
Signed-off-by: Arianna Vespri <arianna.vespri@yahoo.it>
* Adapt withDefaultRuntimeMetrics function to work regardless of the Go version
Signed-off-by: Arianna Vespri <arianna.vespri@yahoo.it>
* Autogenerate go collector test for go1.23
Signed-off-by: Arianna Vespri <arianna.vespri@yahoo.it>
* Modify gen_go_collector_set.go to please linter and regenerate files
Signed-off-by: Arianna Vespri <arianna.vespri@yahoo.it>
* Simplify gen_go_collector_set.go logic by modifying func computeMetricsList
Signed-off-by: Arianna Vespri <arianna.vespri@yahoo.it>
* Slight simplification of withDefaultRuntimeMetrics func
Signed-off-by: Arianna Vespri <arianna.vespri@yahoo.it>
* Refactor withDefaultRuntimeMetrics with generated default runtime metrics subsets
Signed-off-by: Arianna Vespri <arianna.vespri@yahoo.it>
---------
Signed-off-by: Arianna Vespri <arianna.vespri@yahoo.it>
mdIdx was redundant when len(exemplars)>1, so got rid of it, rIdx
is enough.
Don't compare timestamp of incoming exemplar to timestamp of
minimal distance exemplar. Most of the time the incoming exemplar
will be newer. And if not, the previous code just replaced an
exemplar one index after the minimal distance exemplar. Which had
an index out of range bug, plus is essentially random.
Signed-off-by: György Krajcsovits <gyorgy.krajcsovits@grafana.com>
* process_collector: fill in most statistics on macOS
Unfortunately, the virtual memory, resident memory, and network stats will
require access to undocumented C functions. I was warned off of cgo in IRC
because it would then have to be enabled in a bunch of different projects that
use this module, but I already was against it because that would break the
ability to cross-compile. There is no interface to `dlopen` built into golang.
The `github.com/ebitengine/purego` module looks promising (I can cross-compile
and call these methods), but I'm currently getting unexpected results. I'll
follow up with that separately if I can get it working, but hopefully this stuff
is pretty uncontroversial.
Tested on macOS 10.14.6 (amd64), macOS 14.6.1 (amd64), and macOS 15.0 (arm64)
by spawning `/usr/bin/ulimit -a -S` and `/usr/sbin/lsof -c $my_process` from
the test exporter process, and `ps -o lstart,vsize,rss,utime,stime,command` from
the shell, and comparing results with the exported metrics.
I can't find documentation for `RLIMIT_AS` on macOS (specifically if it's in
bytes or pages). It's currently being reported back as `RLIM_INFINITY`, which
seems reasonable, because I've come across reports that the value is ignored
anyway[1]. The bash 3.2 code for the built-in `ulimit` divides the value
reported by `getrusage(2)` by 1024 when printing, as it does for `RLIMIT_DATA`,
which is documented as being bytes in `getrusage(2)`. The help for `ulimit`
indicates it prints both in kbytes, so it's reasonable to assume this is already
in bytes.
[1] https://issues.chromium.org/issues/40581251#comment3
Signed-off-by: Matt Harbison <mharbison72@gmail.com>
* Update prometheus/process_collector_darwin.go
Co-authored-by: Ben Kochie <superq@gmail.com>
Signed-off-by: Matt Harbison <57785103+mharbison72@users.noreply.github.com>
---------
Signed-off-by: Matt Harbison <mharbison72@gmail.com>
Signed-off-by: Matt Harbison <57785103+mharbison72@users.noreply.github.com>
Co-authored-by: Ben Kochie <superq@gmail.com>
Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com>
* changed the name of all variables with min/max name
Signed-off-by: Parth Lawania <parthlawania@gmail.com>
* removed predeclared ignore condition for min and max identifiers
Signed-off-by: Parth Lawania <parthlawania@gmail.com>
---------
Signed-off-by: Parth Lawania <parthlawania@gmail.com>
Co-authored-by: Parth Lawania <parth.lawania@super.money>
Now that 1.23 is out, update the supported version matrix to Go 1.21
through 1.23. This allows us to start using `log/slog`.
* Update generated tests.
Signed-off-by: SuperQ <superq@gmail.com>
* Removeed go_memstat_lookups_total which was always set to 0; added runtime/metrics info to memstat metric helps.
I know we ideally should not remove any metric from default list, but
this one is always zero, so let's save everyone's money.
Signed-off-by: bwplotka <bwplotka@gmail.com>
* Update prometheus/go_collector.go
Co-authored-by: Arthur Silva Sens <arthursens2005@gmail.com>
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
---------
Signed-off-by: bwplotka <bwplotka@gmail.com>
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
Co-authored-by: Arthur Silva Sens <arthursens2005@gmail.com>
* go collector: add default metrics acceptance tests; adding more context to HELP
The context and details for help were possible thanks to @vesari research, thanks for that!
Signed-off-by: bwplotka <bwplotka@gmail.com>
* Update prometheus/go_collector.go
Co-authored-by: Arianna Vespri <36129782+vesari@users.noreply.github.com>
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
---------
Signed-off-by: bwplotka <bwplotka@gmail.com>
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
Co-authored-by: Arianna Vespri <36129782+vesari@users.noreply.github.com>
* feat: Support zstd encoding
This allows endpoints to respond with zstd compressed metric data, if
the requester supports it.
I have imported a content-encoding parser from
https://github.com/golang/gddo which is an archived repository to
support different content-encoding headers.
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Update prometheus/promhttp/http.go
Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com>
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Update prometheus/promhttp/http.go
Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com>
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Update prometheus/promhttp/http.go
Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com>
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Integrate review comments
* String typed enum
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Test with gzip compression
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Update prometheus/promhttp/http.go
Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com>
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Reorder error handling
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Apply suggestions from code review
Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com>
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
* Include review suggestions
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
---------
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
Co-authored-by: Bartlomiej Plotka <bwplotka@gmail.com>
Kemal Akkoyun