Il giorno mar 28 gen 2020 alle ore 09:15 Romain Manni-Bucau < [email protected]> ha scritto:
> +1 generally since all extensions doing that report wrong data > -1 to use a mainstream impl if not shaded - it would just bring us new > conflicts i think. > Totally agree. In my view any "impl" will be plugged with an "extension". We will provide only a default no-op implementation Enrico > Side note being: we can start we just counters so no lib is fine imho. > > Le mar. 28 janv. 2020 à 08:56, Enrico Olivelli <[email protected]> a > écrit : > > > Hi, > > I would like to work on introducing an explicit support in Maven Core for > > recording "metrics". > > As far as I know (and I have still limited knowledge about the internals) > > you can write an "extension" and you can intercept main lifecycle events, > > and using these hooks you can try to record metrics. > > But my proposal is from another point of view and I want to go deeper. > > > > We are adding caches, making refactors....all good things, but we should > > have a way to track how Maven is behaving in a measurable manner. > > > > Usually in order to capture realtime metrics you are using some Metrics > > framework, like Prometheus, Dropwizards....and you attach your process > to a > > metrics database and capture all of the values. > > Then you can process all of the data, realtime and/or offline, you can > > create dashboards, you can also fine tune your configuration or change > your > > code. > > > > These frameworks deal with time series created by capturing Counters, > > Summaries, Gauges. > > > > I would like to introduce an API to be used by Maven Core and by Plugin > to > > expose internal metrics, like: > > - internal caches size > > - memory usage > > - disk reads/writes > > - network traffic > > - any kind of specific metric for plugins (like "number of tests > executed", > > "number of files sent to javac...") > > - .... all of the usual stuff you track in order to understand wha's > going > > on > > > > I am saying a Maven Metrics API because we must not stick to a single > > "provider" (say "DropWizard"), it will be a bad choice in the long term. > > > > The API will expose to Maven Core and to plugins a way to get access to > > Metrics and report useful values. > > > > @InjectMe > > MetricsProvider metrics; > > > > metrics.getCounter("javacFiles").add(....) > > metrics.getSummary("downloadTime").add(....) > > > > I don't want to go down into details as this is only a preliminary email > > but in my view we could let the user attach an "implementation" just by > > dropping in an "extension", in order not to ship with Maven Core a lot of > > third party dependencies. > > > > I have some "production" experience with this topic (actually I did > > something like that in my company and in ZooKeeper project) so I will be > > happy to prepare and share a design document. > > > > With this work we will open up the way to knowing how a Maven build > works, > > with the 'time dimension', on the local machine of the developer but even > > on CI servers. > > > > Any comment is very welcome > > > > Regards > > Enrico > > >
