Add Prometheus metrics endpoint #4944
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I have a friend who is using k6 for some massive database load-tests that run for hours. However, k6 is OOMing sometimes and they'd like to understand if they need to modify GOGC values. The easiest way for them to do it is to leverage the Prometheus Golang runtime metrics. This was brought up before in grafana#3535 however, it was rejected for two reasons: 1. `client_golang` dependency might go away in favor of OTel 2. The future of metrics exposition is OTel However I'd like to reopen this for two reasons. `client_golang` is a dependency of `opentelemetry-go` as well. So that dependency is not going away. But the more important reason is that there are already many high performance Golang systems exposing `/metrics` and the metrics and tooling around them is pretty mature and extensive. The OTel Golang runtime metrics are new and not yet stable: https://opentelemetry.io/docs/specs/semconv/runtime/go-metrics/ Reimplementing everything for these metrics is not a trivial effort. Signed-off-by: gouthamve <gouthamve@gmail.com>
gouthamve
requested review from
ankur22 and
codebien
and removed request for
a team
|
|
ankur22
reviewed
Jul 18, 2025
There was a problem hiding this comment.
I'm probably not the best person to review this, but I'd like to get some clarification still. With this change, we would be exposing the standard Go runtime and process metrics that the client_golang library auto‐registers, correct? I don't think k6 registers any other data using prometheus.
Yes |
|
FYI https://github.com/szkiba/xk6-prometheus |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have a friend who is using k6 for some massive database load-tests that run for hours. However, k6 is OOMing sometimes and they'd like to understand if they need to modify GOGC values.
The easiest way for them to do it is to leverage the Prometheus Golang runtime metrics. This was brought up before in #3535 however, it was rejected for two reasons:
client_golangdependency might go away in favor of OTelHowever I'd like to reopen this for two reasons.
client_golangis a dependency ofopentelemetry-goas well. So that dependency is not going away.But the more important reason is that there are already many high performance Golang systems exposing
/metricsand the metrics and tooling around them is pretty mature and extensive.The OTel Golang runtime metrics are new and not yet stable: https://opentelemetry.io/docs/specs/semconv/runtime/go-metrics/ Reimplementing everything for these metrics is not a trivial effort.
make check) and all pass.cc @joanlopez @oleiade @mstoykov @dgzlopes
Checklist: Documentation (only for k6 maintainers and if relevant)
Please do not merge this PR until the following items are filled out.
Related PR(s)/Issue(s)