Is there a way I can get package or publish stats ...
# general
w
Is there a way I can get package or publish stats per target? I'd like to be able to track build metrics in CI I'm running
pants package src/target-a src/target-b
and while I can time the pants package invocation, I don't see an easy way to get per target metrics.
c
You could presumably get this from https://www.pantsbuild.org/2.21/reference/subsystems/workunit-logger but that's rough around the edges and possibly too much of a fire hose. What's the metric you are trying to get at? At least with our config the many layers of caching make it somewhat complicated to reason about.
w
I want two metrics: 1. Time to package a target (PEX/Docker) 2. Time to publish a target to Docker registry For package time the dynamic pants output one of does it, as a running count. It looks like I could try parsing stand and end time out of the logs too. Context: • we have a python monorepo with 7 services, using PEX/Docker. Some are light weight apps (100mb) and some depend on PyTorch/CUDA (5gb+). • In CI build and publish both take a long time. We run pants package and publish against multiple docker targets at once (—changed-since) My understanding is that it might not be easy to reason about as the combination of things you package simultaneously as they run in parallel. From the publish output it looks like image pushes run sequentially (I guess because they’re network bound?), so I could parse logs again, or split the targets into one pants evocation each and measure each one with time
Basically, my ideal here, would be a stats output option for both commands, that generates some json with metrics per target
In a really ideal world that include a breakdown of the the multiple PEX decencies (some services use split deps/srcs PEX’s), so I can pipe all of this to datadog with appropriate tagging to see ongoing changes to build/package time
c
From the publish output it looks like image pushes run sequentially (I guess because they’re network bound?)
https://github.com/pantsbuild/pants/issues/17613 I suggest taking a look at the workunit logger and seeing if that make sense for what you are trying to do (I suspect it has "too much" information, but it could be missing something!) and then based on how that goes either use that or write up an issue for less fire-hosey way to get at that timing data (a-la the reapi stats perhaps)
👍 1