Le dim. 10 mai 2020 à 20:11, Karl Heinz Marbaise <khmarba...@gmx.de> a écrit :
> > On 10.05.20 19:59, Romain Manni-Bucau wrote: > > Events vs metrics is an old topic. > > The choice between both is not only design but also about perf. In terms > of > > design it brings the ability to export data without exposing it in code > > (events are public). It also avoid to expose a stable api of events and > > create coupling between plugin/exts and only require a single stable api > > which is very minimal (lot of projects kept their metric abstraction > > stable). > > > > Typically wagon should export metrics but if you fire an event per > download > > progress it will be quite slow currently and you will allocate a lot of > > objects (or create contentions) just to increase a monotonic counter (a > > longadder concretely). > > > > So I think Enrico is right and we cant avoid metrics (I have to admit > > events are overcomplex to use for plugin/ext dev, see all profiling > > extensions, > > > not a single one works and report accurate data whereas metrics > > can miss some drilldown data but would be right). > > Interesting point cause can you give some more details on which the > testimony is based that none of them works? > They all measure bus events, mainly mojo_start, mojo_end but at the end several mojo have a duration of 0ms...even if they take minutes. What I saw last time I checked the two top rated by github (and google I think), some events were missing (one ex where metrics are easier to handle, you push your data, no computation on consumer side). Out of my head in the project i was working on, gmaven plugin was totally missed. > Can you explain a accurate implementation? > If my build take 5mn and i sum all not overlapping times of the report of a monothreaded (T1) build then i should be close to 5mn (+- some sec for the boot, ioc, logging, final report). If I cant extract where time is spent these tools are uselesd. For the story i used a javaagent (based on sirona) to instrument the build i was optimizing, was using in memory counters with dump at shutdown (in csv). Indeed bytecode instrumentation overhead was not low enough but i managed to explain the build duration properly with such a tool. If we put these basic metrics in maven core (executor for ex) I'm pretty confident results will be less random than events interpretation and required code is very low and trivial to maintain for any dev so guess it is worth it even if off by default (noop metrics system). > Kind regards > Karl Heinz Marbaise > > > > > > > Now we can limit the surfacing api and start only by counters and gauges > > maybe and later add histogram, meters etc only if needed (not sure for > mvn). > > > > Le dim. 10 mai 2020 à 19:32, Enrico Olivelli <eolive...@gmail.com> a > écrit : > > > >> Il Dom 10 Mag 2020, 17:49 Robert Scholte <rfscho...@apache.org> ha > >> scritto: > >> > >>> Hi Enrico, > >>> > >>> These could all be solved by firing events. > >>> > >> > >> Yes > >> I see your point. > >> Unfortunately those are the first points that I have instrumented in > order > >> to see some data. > >> > >> > >>> And there's another benefit: since there won't be an API, we don't need > >> to > >>> maintain it,or be afraid of mistakes. > >>> > >> > >> Exposed metrics won't be an API, or at least something to be maintained. > >> Each Maven version, component version, plugin version may expose any > metric > >> is valuable for the component developer or for the users. > >> > >> Exposed metrics are not an extension point, it is not expected that a > >> MetricsProvider is able to alter the behaviour of Maven. > >> Events/Extension point must be maintained forever, but you can drop/add > a > >> metric at each release. They are very low level tracking points in code. > >> > >> This is because I say that metrics are like loggers: you add logs where > you > >> think it is useful, you can change log point at every version, there is > not > >> strong contract with the user, logging implementation is totally > pluggable. > >> > >> The Metrics API is mostly the contract with Metrics Provider developers. > >> It will be very stable, I don't think there will be many changes in the > mid > >> term. > >> It is only about the ability to give a name to counters, summaries and > >> gauges. > >> > >> Having a simple implementation that dumps the final values at the end is > >> not the full power of this mechanism. > >> > >> You can attach Prometheus or any other time series based metrics > database > >> and see the evolution of the build, this will be very useful for long > >> running builds and especially on CI or during component development. > >> > >> I will finish the implementation with Prometheus and try to create a > >> Grafana dashboard. > >> > >> It would be super useful that some Maven-internals experts could suggest > >> useful values to track during the execution of the build. > >> > >> I hope that explains better the value of the Metrics system. > >> > >> Thank you Robert for your feedback and help > >> > >> Enrico > >> > >> > >> To me this is the wrong approach to embed metrics. > >>> > 7 >
