Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

metrics for bake command #2519

Closed
crazy-max opened this issue Jun 12, 2024 · 5 comments
Closed

metrics for bake command #2519

crazy-max opened this issue Jun 12, 2024 · 5 comments

Comments

@crazy-max
Copy link
Member

Since Buildx v0.13.0 we support exporting OpenTelemetry metrics for the build command. We currently track:

newLocalSourceTransferMetricRecorder(meter, attrs),
newImageSourceTransferMetricRecorder(meter, attrs),
newExecMetricRecorder(meter, attrs),
newExportImageMetricRecorder(meter, attrs),
newIdleMetricRecorder(meter, attrs),
newLintMetricRecorder(meter, attrs),

We should do the same for bake with slight changes/enhancements. For example we should track the underlying attributes within the loaded bake definition for built targets and one thing that would be interesting to set along the attributes is what kind of files are being consumed (hcl, compose, json) when merging the definition. This would help understand user's workflow.

@crazy-max
Copy link
Member Author

@jsternberg Started something to implement metrics for bake based on your work for build command: master...crazy-max:buildx:bake-metrics

Current attributes need more work I think. We need to set the context and dockerfile path for each target. Would need to have the bake definitions and targets loaded first though. Also wonder if we need a metric for each target?

@jsternberg
Copy link
Collaborator

jsternberg commented Jun 24, 2024

I think we might want to identify what things we want to measure from bake similar to what we did for build. We presently measure the following metrics:

  • local source transfer
  • image source transfer
  • execution time
  • export time
  • idle time
  • which lints were recorded

For bake, do we want to measure these same attributes? Do we want to measure these attributes per target in the bake execution? I think it might be too complicated to measure these particular metrics in a per-target way because the underlying implementation executes all of them at the same time and I don't think these metrics would be very accurate or the most useful.

For build, we include a build options hash to try and get a way to correlate the same invocations with each other. This happens to include the context and dockerfile for build. For bake, I'd argue that we want to use different attributes for that. Maybe just the targets and the name of the bakefile definition?

@thompson-shaun thompson-shaun modified the milestones: v0.16.0, v0.17.0 Jul 3, 2024
@jsternberg jsternberg modified the milestones: v0.17.0, bake-ga Jul 11, 2024
@jsternberg
Copy link
Collaborator

I have an implementation here that should close this issue: #2610

It reports the same metrics as the build command and uses a different method of computing the build identifier. I don't attempt to differentiate between different builds within the bake command since bake runs them all at the same time and in parallel if possible, so I think differentiating which action applies to which target would be too difficult. This should still give us a bunch of information about how bake is used and we can expand it to also include the number of targets or number of files that were used if we want to.

@thompson-shaun
Copy link
Collaborator

thompson-shaun commented Aug 8, 2024

Implementation is in #2610 as noted above. Follow-on required for integration tests, let's keep this issue open until the tests are added.

@crazy-max
Copy link
Member Author

Follow-on required for integration tests, let's keep this issue open until the tests are added.

We have #1857 opened to track this. See "Tracing support" task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants