solver/llbsolver: emit native build-completion metrics#6736
Open
asbarron wants to merge 2 commits intomoby:masterfrom
Open
solver/llbsolver: emit native build-completion metrics#6736asbarron wants to merge 2 commits intomoby:masterfrom
asbarron wants to merge 2 commits intomoby:masterfrom
Conversation
github-actions
Bot
added
the
area/dependencies
Threads the existing OTEL MeterProvider through llbsolver.Opt and emits three build-event instruments from the recordBuildHistory finalizer: - buildkit.builds (counter; labels: status, error_code) - buildkit.builds.steps (counter; labels: kind) - buildkit.build.duration (Base2 exponential histogram; labels: status) The duration histogram uses an exponential aggregation, rendered as a Prometheus native histogram by the existing exporter, to avoid the "tens of millions of series" cardinality blow-up reported in moby#5777. MeterProvider is passed explicitly through the constructor — buildkit policy (per the moby#4957 review) prohibits relying on the OTel global provider in library packages. error_code uses gRPC codes.Code.String() for a bounded set; rec.Error.Message is intentionally never used as a label. The frontend label is intentionally omitted — client.Build clears req.Frontend on the wire, so the field is empty for every caller that goes through the gateway-client API (buildctl, buildx). The metric is forward-compatible with a future buildkit change that populates rec.Frontend on that path. A follow-up PR will add observable gauges for worker count and cache state, plus an operator guide at docs/metrics.md. Refs moby#1544; addresses discussion moby#5777. Signed-off-by: Ava Barron <abarron@coreweave.com>
Signed-off-by: Ava Barron <abarron@coreweave.com>
asbarron
force-pushed
the
asbarron/buildkit-build-metrics
branch
from
06abd34 to
c2a5c1d
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Threads the existing OTEL MeterProvider through
llbsolver.Optand emits three build-event instruments from the recordBuildHistory finalizer:The duration histogram uses an exponential aggregation, rendered as a Prometheus native histogram by the existing exporter, to avoid the "tens of millions of series" cardinality blow-up reported by #5777.
MeterProvideris passed explicitly through the constructor; buildkit policy (from the #4957 review) prohibits relying on the OTel global provider in library packages.error_codeuses gRPCcodes.Code.String()for a bounded set; rec.Error.Message is intentionally never used as a label.The frontend label is intentionally omitted because
client.Buildclearsreq.Frontendon the wire, so the field is empty for every caller that goes through the gateway-client API (buildctl, buildx). The metric is forward-compatible with a future buildkit change that populatesrec.Frontendon that path.A follow-up PR will add observable gauges for worker count and cache state, and an operator guide at docs/metrics.md.
Refs #1544; addresses discussion #5777.